Hey guys, my name is Robin and I used to go by “rpgking” here. When I used Verge/Verge2/Verge3 back in the day, I basically made a bunch of demos and didn’t complete many things. I think the only game I actually completed was a Balloon Fight clone called Balloon Ninjas in Verge 3. I took a long hiatus from game development after the Verge 3 days, but after playing around with Monogame, I got back into it.

I figured I’d post in the Gruedorf section here to motivate myself to actually make more progress on the game I’m working on. I don’t post this info anywhere else since I’m not really active on social media like many people are nowadays.

Before I get into what I’m currently working on in Monogame, here is a bit of my Monogame history in terms of demos I’ve created:

1. Sandbox procedurally generated overworld. I was thinking of doing something similar to Terraria but with an overhead view (Yea that’s Locke in the pic). I eventually lost motivation and put this on hold (indefinitely?).
   

2. Platforming adventure where I envisioned a game similar to Zelda 2 with a more modern feel. Again, I lost motivation to finish it…for the time being.
   

The current game I find myself working on is an evolution of #2 above. It uses Monogame with the Nez framework. I can only describe it as Metroid + Roguelite + Minish Cap conceptually. Hopefully it will make more sense what this means as I make more progress.

Currently I’ve got the following implemented:

• Basic procedurally generated rooms
• Platforming engine with:
• • Wall climbing
• • Ledge hanging/climbing
• • Dash/Air Dash
• • Free aim
• • Climbing, Dashing, Jumping while climbing consumes “Energy”.
• HUD with:
• • Minimap
• • Energy & Shield display

I’ve got a list of features I’m working on, and I’ll list them as I complete them. Hopefully this will be the game that breaks my cycle of starting things and never completing them!

Here is a screenshot/video of progress:

My goal is to post incremental weekly progress here.

This week my software engineering day job really took over my time because we had lots of all day planning sessions which broke my brain by the end of the day.

But despite that I did get some work done on the game. I’ve mainly been focusing on the “tiny person” inside the core (what appears to be the head/helmet). This is where the Minish Cap influence for the game comes in. The main character you play as is this “tiny person”, who I already have a rough backstory for.

The core is the main part of the “suit”, and it is piloted by the “tiny person”. That is why the main character can rotate the core in full 360 degrees…since they are actually just piloting it.

The player will be able to eject out of the core at any time, or they will also be forcefully ejected if they take enough damage…at which point they have to wait until it has repaired itself to enter it again. Outside of the core, the player is extremely vulnerable to damage and will generally die in one hit.

I’ve gotten the “tiny person” completely controllable, but am still working on getting the mechanics of the core working…which follows the player around. It actually compresses its mass down to the inner sphere while following the player. When fully repaired, the core will be able to shoot the same beam(s) when the player is outside of it as it does when they are inside…but when damaged it will shoot a very slow, weaker beam.

Here’s more info on the frameworks/tools I’m using:

1. Monogame - Might eventually create an FNA port…but so far Monogame has been working well for me.
   1.1 Nez Framework - This opensource framework is amazing and actively developed. It provides a very solid Scene/Entity/Component system, with several out of the box features that make game development a lot easier.
2. Pyxel Edit - This is what I use to draw all my character sprites, tiles, and animations.
3. Tiled - Used to create all the tile maps (using tiles built with Pyxel Edit).

On a final note, I’ve gotta say it’s really inspiring to see so many people who have posted about their own projects lately. Almost feels like the good old days of when the Verge community was livelier…even though we’re not all using Verge anymore nowadays.

So this week was ridiculous. Living in Texas, my wife and I were at the mercy of the epic failure of the Texas independent power grid during the winter storm (Most likely caused by greed/corruption/carelessness or a combination of these ). So we spent most of the week in survival mode since we had power outages from 6 to 8 hours at a time, and the temperature of the house would get into the low 50s. When the power came back on, we’d have to scramble to make food and other preparations within the 1 to 2 hours of power that we had. This was repeated for 3 days straight…and then things got better on the 4th day. I still feel more fortunate then some other people who were completely out of power for over 48 hours with the frigid temperatures! Hopefully some real change happens in Texas after this.

Before the snowpocalypse happened, I managed to fix some bugs and add a new animation to the main character of the game I’m working on. No screenshots to show, but a little progress is some progess!

This week consisted of more small gains. Not all my posts will have screenshots, videos, or art. Those will come whenever I feel like there is something worthwhile to show.

I completed the animation sequences for exiting/entering the core. These were done through a series of tweens and coroutines(as opposed to animation frames) so that I could control the associated rotations and displacements with smooth precision.

After completing this, I’ve established a lot of what I consider to be the base of the game. The gameplay will combine being inside/outside the core in interesting ways.

I switched gears and went back to working on the outline of the game. This time I was focusing more on story and the various areas…while the initial outline focused on mechanics. With this (currently) solo project, I went the route of using an outline and Trello board instead of a detailed design doc and something sophisticated like Jira. Since I’ve already got the game direction in my head, the outline guides me along a path to the end while Trello gives me a list of immediate tasks for the week.

So far this setup has worked well, and it allowed me to make more meaningful progress, and somehow helped me stay motivated. I think before jumping deeper into programming again, the immediate future is going to be focused more on further expanding the outline, drawing more tiles, and designing/creating enemies.

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!

This week I spent some time getting Nez working with FNA instead of Monogame. I’ll probably use FNA going forward, though if needed I can switch back to Monogame fairly easily.

I also played around with the Dear ImGui integration that Nez has for debug panels. This is a feature that I wished I had used earlier because it probably would have saved me a lot of time. It lets me change change scenes or update properties of various entities and components at runtime(or even add new components to entities), which allows me to instantly see the results of tweaking these values. Previously I’d keep modifying code and rebuilding to test out the effects of property updates…which seems really silly now looking back on it. Nez also allows wiring up custom ImGui windows which I probably will make use of for debugging.

My day job took up all my time the past week. And I also visited my sister-in-law and family in Colorado this weekend, so no progress on game development.

I ended up spending what little free time I had playing Horizon Zero Dawn some more. I can’t say exactly what it is about this game that draws me in. Conceptually it’s very similar to other open world games I’ve played in the past, but it could be the uniqueness in the setting and enemies. Also playing around with the override mechanic is fun.

I guess an important point is that more novel concepts can be a refreshing change in a sea of similar games.

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 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.

@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.

@bengrue I do get on discord every once in a while to see what everyone’s up to.

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

Screenshots:

Download:
https://www.dropbox.com/s/ff6z08fo7gs92hm/WalkToGrandma.zip?dl=1
(Sorry for the sea of dll’s in the zip. Just run WalkToGrandma.exe)

@slimehunter84 Thanks. Glad you were able to tell those were flies Probably easier to see in motion.

@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.

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!

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!

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.

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 .

Made quite a few updates to Troidly Troidal 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 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.