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)
This week was mainly focused on improving the json format, loader, and editor design.
At first the json supported what visually looks like this:
While this would take care of the job of laying out the overall world design in terms of scenes, it doesn’t look very interesting. It just looks like a bunch of boring rectangles that could be linked together. These scenes would directly correspond to a Tiled map which would have a more interesting design…but it’s still hard to plan out what that design of interconnecting scenes should look like from a higher level when you can’t really visualize what the actual walkable areas will be like.
So I modified the json format to introduce a collection of “mapTiles” in each SceneNode. This is a set of autotiling blocks that will be drawn over the encompassing rectangles for each SceneNode. So then it supports something that looks like this visually (the slope tiles are a special case):
Now that looks more like typical maps of the M-word style of games.
With these enhancements, I think I have everything needed to bring this to life.
Hopefully my next update will be a shot of this in action.
Made some progress on the editor this week.
I’ve done something others have already done a million times in the various map editors out there. I’ve got the tile grid for the ScreenGraph displayed, and it can be panned around using the middle mouse button. Also the currently selected grid tile(underneath the mouse cursor that isn’t shown) is highlighted. Although done a million times before, it’s a first for me, so I’m happy.
Should be a good foundation for adding scene drawing and map tile placement within scenes.
And then once that’s all done, I plan to link individual Tiled tmx maps to the scenes and hopefully launch them from the editor. I’m also aiming to display the tmx maps in the editor for the selected scene to add metadata for various things.
Made more incremental progress on the scene editor in the little free time I’ve had lately.
Now I’m able to draw scenes of any size, at any location. There’s still a few features missing with scenes like being able to drag/drop them anywhere after being placed…or deleting scenes.
Once I’m completely done with scene creation/placement, I’ll move onto drawing the walkable areas in a scene.
I don’t plan to add too many UI elements to this unless required. For now I’m using shortcuts to switch between various modes like scene creation or selection. I don’t want to lose sight of my main goal of creating a very simple editor to draw the layout of the world along with its metadata. I will probably have to add some level of UI elements eventually though.
I know the current color scheme isn’t very easy on the eyes. I was focused more on function over aesthetics for now.
Made lots of progress on the editor since last time. I also gave it a name…Troidly!
It currently supports the following features:
- Drawing scenes (These are shown as purple areas)
- Drag and drop of selected scene anywhere on the grid
- Drawing walkable tiles within a scene (These are currently all blue tiles). As described before, this allows for easily showing the high level layout of the scene’s tilemap so that you can see the walkable areas. It’s basically what every Metroidvania out there shows in their maps. Overall, this step is still optional and doesn’t add any functional value to the overall map, since it is the scene that is directly linked to the TMX map.
- Saving and Loading the overall “ScreenGraph” as JSON.
Even though this is coming along nicely, the UI part of it is still not very nice to look at, and probably never will be. And the different modes (“Create Scene”, “Select Scene”, “Create Tile”, “Create Scene Links”) are all switched by using function keys.
I recreated part of the beginning area of the Castlevania SOTN map as a test of what’s possible so far:
I still want to at least add the following features before moving on to the scene metadata editor portion of it:
- Creation of Scene Links to link 2 different scenes together by connecting their edges. This would be where doors or other scene transitions happen.
- Auto-tiling for the walkable areas (would make tiling these much quicker than just using the palette on the right)
- Generate empty TMX maps with a relevant collision grid for any scenes that don’t already have a TMX map assigned. This way it would be easy to test out the overall game layout by just using this editor. I would probably create an exporter that does this in a plugin-style, so that it could be extensible to other types of maps.
Made quite a few updates to
TroidlyTroidal since last time.
- Added auto-tiling of walkable areas via a toggle. It’s much easier now to design scenes.
- Added right-click selection of tile on canvas for even easier editing
- Save/Load Dialog is better now since it uses Winforms (though this makes it constrained to Windows for now)
Before creating SceneLinks, I’m working on generating “Collision Tile Maps” of all the designed scenes. These are simple TMX maps with a light background and black collision tiles, and it would directly correspond to the type of walkable tile plotted on the Scene. A “walkable tile” in the Scene actually represents an entire screen. This gives the benefit of quickly generating a set of traversable tile maps that represent the designed scenes so that one can get a feel for the overall flow of the game early on. Of course this would have to be fine tuned with more ledges and interesting shapes, but this would give a much easier starting point than doing everything manually. The more visually appealing tiles that represent the actual world can then be drawn on top of this.
Once this is in place, it would be easier to create scene links between maps.
And then I could finally get back to working on the actual game again…
Made more progress this week on the editor.
I am able to generate collision tile maps now for any scene that doesn’t have an associated map. Luckily the TMX map format is plain text and super easy to write. There’s still a few things I need to adjust, but it’s mostly working.
Also I replaced the ugly UI with a nicer looking Dear ImGui interface. I used Dear ImGui earlier but didn’t fully explore what it was capable of. I see how it allows non-UI people like myself to easily create great looking interfaces for tools with minimal effort.
Since I’m using Dear ImGui now, I was able to remove the WinForms code I had in place for Save/Open dialogs. So now in theory this should work on other OS’s too .
Yet more editor progress.
In the past week, I’ve mainly added scene link creation/deletion to the screen graph editor, and the beginnings of the scene editor.
Pictures are worth more than a thousand words so I’ll keep it short.
Now my proof of concept SOTN map looks more like an interconnected map.
Minor update here, regarding updates.
I’ve been making consistent progress on several things, like the scene editor and being able to run through generated black tile maps (which required an overhaul of my previous scene format).
But I’ve determined it would be best if I posted high-value updates going forward versus a bunch of small low-value updates like I’ve been doing in some cases. I did remove the “gruedorf” from this blog afterall. I realized I really don’t need the gruedorf concept anymore to keep me working on stuff…because due to how I work, there’s always something happening weekly regardless.
Anyway, I’d rather not look like a commit log of a bunch of small things that should’ve been rebased into a larger commit. So my updates will probably have much bigger gaps, but be more interesting.
In the meantime, good luck to the gruedorfer’s out there!
Almost 2 months later, I have a Christmas day update, though this has nothing to do with Christmas.
I’ve been working on the game at a consistent pace the past 2 months. It has generally been a mixture of pixel art, map making, and code updates.
The in-game map system is overhauled to where it does not function like a roguelike anymore. It has the following features:
- Minimap that scrolls dynamically with the player
- Large map that is scrollable and shows all covered areas
- Improved map transitions that now scroll out the entire map while scrolling in the new map seamlessly.
Creating the editor has helped tremendously in making a seamless experience going from one map screen to another.
I also refined the core concept of the game, which deals with reviving a dead world. The scope of the game has also been narrowed quite a bit in terms of the overall goal and what the player can do. I’m trying not to fall into a trap where I keep adding more and more features, until the goal becomes unattainable.
A big part of the game is turning areas that look like this:
Into something like this, by using the core abilities of the player.
That’s it for now. Until next time, Happy Holidays!
@Robin Haven’t posted here in quite some time, but I’m still working on this game.
I kept getting confused on the overall direction of the game, but I think I have a better handle on it now. I’ve also been working on a design doc, which I didn’t have before, so that should help things along greatly.
The design has changed somewhat significantly too, and these modifications were mainly geared towards having a realistic goal when factoring in all things related to life/day job. My goal is still to finish a game, and sometimes that means cutting out lots of planned ideas.
Another big change is the overall art direction. I think somewhere along the line, I lost sight of the feel I was going for. Things looked a bit too bright and happy like something you might see in an old Mario game. After some experimentation with different pixel art styles, I’ve settled on one that’s simple and easy on the eyes, while being closer to what I originally envisioned.
slimehunter84 last edited by
@Robin Nice art on the cave tiles. Also the giant bat looks very distinct and memorable. Are those flies hovering around the big bat?
@slimehunter84 Thanks. Glad you were able to tell those were flies Probably easier to see in motion.
bengrue last edited by
@Robin I eagerly await your next post. Also… are you on the discord?
Glad to see this place is back up after being hacked!
I’ve been really busy with family/life stuff lately, and I’m preparing for a move so I haven’t had much time to work on my main game. Though I do intend to get back to it as soon as I can.
In the meantime, I’ve used what little free time I had during nights to do an exercise in simplistic game design/development, and it took roughly a month and a half of working on and off to make this. I attempted to make an infinitely scrolling game where the only thing the player can do is move the mouse around, or click the mouse, to protect a boy who is walking to his grandmother’s house. So the game is tentatively called “Walk to Grandma’s”.
I made this mainly as a development sandbox to get more familiar with aspects of the Nez framework that I haven’t explored much, and it allowed me to see some inefficiencies in the way I did things before. But it turned out to be…kind of interesting?
Currently there’s only one enemy type and there’s no real objective other than to see how long you can protect the boy from the creatures that are stalking him. The enemy spawning rate increases for every mile walked. If I decide to continue this as anything more than a sandbox, I’ve got other interesting features I would add.
There is a download link below if anyone wants to try it.
Controls are simple:
- Move mouse over an enemy to attack them or move them while they’re stunned
- Move mouse over dropped gold to pick it up
- Hold down left mouse while moving over enemy to knock them back depending on accumulated power level. This is intended to do something else in the future, should I continue on this.
- Enter to pause game
(Sorry for the sea of dll’s in the zip. Just run WalkToGrandma.exe)
@bengrue I do get on discord every once in a while to see what everyone’s up to.