I’m really happy to introduce the project that I’m working in this last months.
RDE (Retro games Development Engine) is a little engine specialized for the creation of 2.5D retro games (with graphic style of
old Resident evil and Alone in the Dark).
History
The idea was born more than one year ago, where with a lot of trouble (almost all of them solved with your support) I created
a prototype with some base features, as fixed cameras, 3D models and 2D layers.
First prototype for simulate the 2.5D used only one 2D background for view, and a model with depth draw and no colour.
Solution was immediate but with a lot of troubles:
- The model must had the same detail of the background (bad for performances and memory)
- In this way background needs to be rendered after the model creation, was not possible to use other sources
(for example and hand painted background), because needs to overlaps perfectly the model.
So after that I tried to remove completely the 3D component, except a very simple geometry for the collision detection (and obviously 3D entities).
Entities and layers (more than one for view, if there are some object not in the background) have a virtual depth value, for layers is static and for entities
it change based on the entity position, so some position “tell” to entities that they are behind than a certain layer, other tell that entity is before.
In this performances are very good (up to 500FPS in a mid low-end machine) and with a very low memory and space usage.
After that the problem was different, infact was too much difficult to build an high-level behavior over the prototype, so from here I started to think about a new
and flexible architecture. So I created a new project, keeping from the old only the base concept for 2.5D management.
RDE
The new solution manage each scene in a complete independent way. Each scene is totally configured by an XML.
The XML contains:
- Information about base geometry (reference to base geometry assets, and handler class name for manage the geometry)
- Information about entities (reference to each entity assets, and handler class name for manage the entities)
- Information about cameras (reference to each cameras and handler class name for manage cameras)
- Information about 2.5D handler (reference to each layer, depth values, walk sectors etc… and class name for manage 2.5D)
- Information about the app state (appstate class name and additional information)
The config structure is flexible, and depends by:
- parameters holder
- config builder
- handlers
A default set of handlers, config builder and parameters is present, but the abstraction level is high, so is possible to implement
a different set of own modules (for example if you want to manage the 2.5D in a different way, or if you want to add a default control to entities etc…).
For what concerns appstates in a normal way you should create a state class for each scene, but with default implementation this is not necessary,
infact every time you load a scene, a default app state is instanced and the initialize and update behavior are define inside a Groovy script (always referenced inside
the XML config).
In a nutshell… with the defautl configuration is possibile to create a 2.5D games only with Groovy scripts.
Inside the groovy script is also possible to call a set of common functions for some useful operation, for example creates new entities (from base defined in config)
add some GUIs, and switch to new scenes.
For this last point in particular I made the possibility to cache the scenes in asynchronous ways (using callable and futures), in this way the time gap between two
scenes is almost imperceptible.
Current State
This is the development state:
Core (Only Java)
- Core Architecture → 100%
Default implementation (Only java)
- Scene Building → 100%
- Default 2.5D management → 100%
- Default state management → 100%
Mid Level (Java and/or Groovy)
- Collision management → 50%
- Generic entities interaction → 0%
High Level (Mainly Groovy)
- Particles → 0%
- Entities actions → 0%
- GUIs → 0%
So, as you can see core and default implementation are completed, lets move through the high level now!
I will start to release the first version when I will solve some simple bug, and complete the Mid Level tasks.
Hope you can find interesting I’d like to keep this thread up to date with all latest news.
Ray
