PHOENIX90'S PROFILE

Enemies visible on the map are very easy to implement using events, I don't think that's really required to be an in house feature, however I will add functions that will assist in making such a system easily, like the ability to clone events and to delete them permanently without using switches

8 directional movement will be optional, you'll be able to chose that in the database.

In programing it's not always easy to just make the basics and add stuff later as you may end up redoing everything just so the framework can run those features. On some features that works well, like adding new event commands post release but adding totally new systems like let's say a new layer system could require to recode half the map engine.

I am going to make a weekly blog where I post the latest progress of the project once development starts.

To be honest I was expecting a few more suggestions on what features to add.

Anyway : I'm going to change the layer system of the RPG Maker, instead of having a floor and a common layer for decoration, collision heroes etc
there will be a global height system and a map can have any number of layers with defined heights :

So a map can have layer with height 0 (floor)
layer with height 1 under hero
layer with height 2 hero height
layer with height 3 above hero
layer with height 10 clouds

when you display a picture or a battle effect you can also chose a height, so you can have pictures under trees but above grass etc
The collision will be handled with events that are on the same height.
if you mark layer with height 3 as default layer, the hero will be on that height when he enters the map. The teleport script will allow to set a target height for the hero on the map or use the default height.
If an event like a bird has a different height than you it will be over you but no collision, if an event has the same height you would collide.
Pictures and battle effects on the same height would use their IDs like in RPG Maker for pictures before to resolve what picture or effect would be on top of another.

What this basicly means :
- Tilesets no longer need layer or collision information
- You can have anything above or below any other thing, solving the problem of having combat systems that require one effect to be on top of the other but isn't
- You'll be able to define a collision box for heros and events that covers multiple layers or height and or multiple tiles in X and Y coordinates (basically a 3D collision box) if you don't define a collision box it'll use the default that you setup in the database (which is initially 28x28x1)
- There will be an event command to change the heroes current height allowing going above and under the same bridge without hassle

This may sound like a tedious thing to do but remember that you can keep it consistent like in RPG Maker and not have to bother with height shifting and always use the default collision box

This is an important feature that when used right will save time over the RPG maker's workarounds for height issues when dealing with multiple planes in an RPG

Collision of event to event will be trackable too and using the collision box feature that will make games such as shooters and space shooters a lot more convenient to code too

I am aware that I'm not the only person with such a project, which doesn't mean that it's not worth doing.

@fdelapena
I'm sorry but I'm not thinking of making a tool that imports RPG Maker projects. I'm not doing this open source either, the tool is supposed to be more than just an extension of the RPG maker, I want it to be it's own game making tool that I will put on steam. RPG Maker is just the inspiration.

@Trujin
You mean to search the variable chart by name?
I'm not sure yet how I'll make the variable picker, the way it's done in the RPG Maker is a bit hard to manage especially in large projects, I'll think of something

Hello Avee,

I am not thinking of limiting the number of pictures at all, I think that decent gaming engines should have as little restrictions as possible (within reason), so if you decide to attempt to use a million pictures at once, you're allowed but the performance that comes out in the product is your own responsibility. This way of thinking also allows the editor to be more long lived, if in future computers have enough performance for millions of pictures then no hacks or workarounds would be needed to use them.

I am going to include a full debugging experience in the editor, with breakpoints and debugging step by step the lines of event code that you picked from a chart (like in RPG Maker)

The speed of events will be just one of the local variables that you can change at will in pixel per second.

I'm not sure yet what language to implement for the scripting language. I know it's a big deal to have RGSS to support the maker, but RGSS is also a reason for the poor performance of the games. I would prefer if the script language is optional and only slows down the game if you actually use some of it. So instead of having like an RGSS class called actor with the actors logic, you would have to make a class that references actor and overrides behaviors that exist in the native code. Then it's important to chose a popular language, what comes to my mind is Python Ruby or Lua, I personally never used Lua, but I'll have to do research on the languages popularity to ensure that the system will be useful.

I cannot guarantee that you could make useful racing games with it. Racing games don't translate well into 2D, but the engine isn't meant to be just for RPGs, I won't even include the name RPG in the name of the finished product, currently I don't have a name for it yet though

Also the interface will be fully customizable, those of you who used visual studio before will know what to expect, you can move the tileset window, the project explorer and others around, you can have multiple maps open at same time with tabs and you can have floating windows, so you could open 2 maps and compare them side by side on 2 different monitors I'll post a picture of it later