I’ve been working on how to define the game world that the editor will help to piece together. This picture shows the design I’m working towards.
The grid in the background is what I call the “ScreenGraph”. A “screen” represents a unit of space that is equal to the screen resolution of the display. Every box on this grid represents a single screen.
A SceneNode is what describes a scene.
- The “ScreenSize” is the x/y dimensions of the SceneNode in screens, which ends up being equal to the number of boxes that the scene takes up in the ScreenGraph.
- If a SceneNode has a ScreenSize of 1x1, that means it’s a single screen (or single box on the ScreenGraph). So while the player is in such a scene, it would never scroll. The entire scene will be viewable at once since it’s size would be equal to the display resolution. Otherwise the screen would scroll horizontally or vertically as needed.
- The ScreenGraphPosition is the x,y coordinates of the ScreenGraph that the SceneNode is located in.
- A SceneNode also contains a list of Entities and their Components
- I’m calling this a SceneNode (or scene), instead of “map”, because a TileMap is just another Entity in the scene. If I wanted to I could display multiple TileMaps in a scene, but I have yet to find a reason to do that…so for now I have the map in a separate attribute since it would be useless to have it in the Entity list.
- All SceneNodes exist independently, and it should be possible to reposition them in the ScreenGraph at any time.
- By using a combination of the ScreenGraph and SceneNodes, the map that will be displayed in-game is naturally defined.
A SceneLink is a Component that links 2 scenes together. The source SceneLink will be in SceneA, and the destination SceneLink will be in SceneB. If the player collides with a SceneLink, they will be transported to the scene that the destination SceneLink is in, at the position of the destination SceneLink. This is obviously useful for doors or passageways. I’ve already got doors/links working in the current engine, but this is a cleaner way to define them than what I’m currently doing in my procedurally generated world.
With regard to the editor, I’ve started off by defining the Json format for the concepts I’ve described above, which is mostly done. There will be more attributes added in the future though for things like music played in a scene, effects, etc. I’ve also created a loader for it that can load the Json into a strongly typed object model (backed by unit tests!).
With the Json format defined, and the loader working, the editor is just a front end on top of this.
On another note, I really really really dislike the term “Metroidvania” so I will not refer to this game as that. Even though conceptually it looks like it could be categorized this way, there is a whole lot of default expectations that are attached to this term that I’d like to not be bound to. (Clarification: I really like games in this style like Metroid(s), Castlevania(s), Axiom Verge, Hollow Knight, etc…it’s just the term I am not a fan of)