Robin's Devlog

[Robin]

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.

[bengrue]

@Robin omg rpgking! Welcome back, and welcome to Gruedorf!

(you can never escape)

[Robin]

@bengrue It’s good to be back and glad to see some familiar folks are still around!

[Robin]

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!

[Robin]

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.

[Robin]

This week, beyond more bug fixes I also added the animation sequence for when the player ejects from the Core. I’m still working on the reverse of this for when the player goes back into the Core.

The Core currently hovers above the player when they are outside of it. I plan on adding a more fluid “bobbing” animation (using tweening) when it’s hovering, but for now it is more stationary. The player is more floaty when in “tiny person” form outside of the Core.

[Robin]

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.

[Robin]

So far this week I’ve done the following:

• Further refined overall game intro, basic story, and goal.
• Refined/Simplified planned game mechanics. I cut out some features that seemed low priority. A focus of the game will be to combine a handful of skills to solve increasingly more challenging scenarios.
• Implemented “momentum transfer” when swapping between inside core and outside core. Normally outside the core, powers are very limited, but this should add some interesting new ways to get past obstacles in tiny person form.
  Vertical Momentum
  
  Horizontal Momentum
  

[Robin]

Not a lot to show for this week’s work, but I mainly did tile art and planning, with a bit of gameplay/animation tweaking to get a smoother feel.

I drew more tiles for the intro area of the game, and I also decided to drop the roguelite idea that was originally planned(that aspect was only in the early stages anyway). I did this because it really doesn’t make sense within the main context of the game, and I think a deliberately designed world/screen layout will be more interesting for this game. If I actually finish and launch this thing, I may bring back the roguelite aspect as an extra game mode post-launch. But it’s on the cutting room floor for now.

The main goal of the game is to save a bunch of tiny people who have been captured. There will be one to save on every screen, and the obstacles/enemies that are in the way may get progressively harder. The path through the world will be non-linear, and the player will easily be able to go back to previously visited screens in an instant. The sub-goal of the game is a creation/destruction aspect that I’ll describe in a bit.

The focus of the game will not be to obtain abilities that allow for progression (I wouldn’t consider this a “Metroidvania”). Instead, most abilities will be available from the start. The goal will be to combine all the various abilities to reach the tiny person on each screen. There will also be a measure of creation% or destruction% on each screen…which contributes to an overall creation/destruction rating.

So what do I mean by creation and destruction? This is basically 2 different modes for the beam that the player shoots, which has impacts on the environment and lifeforms on each screen.

• In creation mode, shooting enemies enough times will make them friendly. Any dead lifeform (whether it is a plant, enemy, or animal) can be revived if shot (even if previously killed/destroyed with the destruction beam). The creation beam has a very short cooldown, so rapid fire will not be possible. It will be a harder more to play in overall.

• In destruction mode, shooting life forms enough times will kill them. If an enemy is friendly, it will become hostile when shot. The destruction beam has no cooldown and can be fired rapidly…making the game much easier. But there could be consequences to this.

That’s about it for now!

[Robin]

This week was PI planning at work (a scaled agile framework concept), so I didn’t have much free time this week.

But I did manage to do some tile art

[Robin]

This week was another week of pixel art and tile art. More tiles mean more graphics variety which means the player will get less bored looking at the same patterns! Nothing to show yet…because it’s all just a bunch of random tiles that will eventually come together.

Lots of non-game dev stuff happened that took away more of my time. One of which was interviewing at and getting a new job for various reasons.

[Robin]

The pinnacle of my development this week was drawing a … drumroll … dead tree! (Maybe it’s a visual representation of my free time this week ).

There will be some weeks where I get a lot done, mainly when I get a boost of inspiration. And some weeks where I just draw varying amounts of things. So goes the timeline of a hobby project.

[Robin]

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.

[Robin]

This week I finished a slime animation that looks really squishy (what I showed a pic of last week).

Other than that I mainly took a break and played Horizon Zero Dawn since it was a free download and something I’ve been meaning to try out but never did. I tend to rarely finish open world games due to the time commitment required, but it was fun and interesting.

[Robin]

This week I drew more pixel art. Mostly trees and shrubbery (ones that look nice and aren’t too expensive!).

I’ve also been working on various ways to get plants to sway in the wind. One possibility is a vertex shader, and the other is using rotation/scaling along with tweens. I’m trying out the vertex shader approach first. I have yet to get anything working, but hopefully soon.

[Robin]

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.

[Robin]

Looks like it’s been 18 days since my last update. I’ve removed the “Gruedorf” from my dev log since I haven’t done weekly updates. But I’ll continue to post on this devlog.

A big part of the reason I haven’t updated in a while is because I was focusing on my day job a lot. The company I joined about a month ago is heavily focused on microservices, so I had to spend lots of time getting up to speed on various technologies on their large tech stack. I think part of the problem was the previous company I worked at was on relatively older technology(not to say it’s bad though) that’s becoming more of a niche. Regardless, I think I’m at a much better spot now in terms of knowledge gained and keeping up with modern trends.

Started back up on game dev again but nothing interesting to report yet. I’m picking up tasks from my Trello board which is mainly some enhancements. One of which is to fix an issue with the minimap disappearing during a room scroll transition, due to the way I coded it as a component attached to a map. This ruins the sense of progression from one room to another.

[Robin]

So…I did a rough mock-up of an RPG battle system idea that is partly from a dream I recently had. This has nothing to do with the game that the majority of this blog has detailed, but I felt the need to do this so that I don’t lose track of the idea.

This combines a classic turn-based battle system with an embedded platformer/auto-runner.

The basic idea is that the characters and monsters(or opponents) in the turn-based battle system have auto-runner counterparts in the embedded platformer display. Whoever is the next to reach the flag in the center gets to do a turn-based action.

Powerups may appear and be retrieved along the way, and several other realtime actions can happen too prior to reaching the flag (some of which could disrupt the opposing runners). After reaching the flag and performing an action, the runner gets sent back to their group’s starting position and runs towards the flag again.

I’ve got the urge to do a prototype of this…so I might just do that. I know this is the game dev equivalent of being distracted by a shiny object, but right now I do this stuff for fun.

[Robin]

Had a busy work week, but I managed to squeeze in some time to draw tile art for the prototype I mentioned last week. I found an old overworld tileset that I once made with 8 x 8 tiles, and I redid them in 16 x 16. I focused on tile art that has a simple, clean look to it…and I’ve been sticking with the “Dawnbringer 32” palette that I’ve used on my other game. I find that my tile art and pixel art tends to be a lot better when I work with a limited palette, since it prevents me from going overboard with colors. The target resolution for this is 320 x 180, which scales well to HD resolutions and covers an area that the images below show (It won’t be this small though!)

While trying to complete a game, it’s generally a big mistake to work on something else in the middle of development. I’m mainly doing this diversion to make myself feel better about not passing up the chance to do something new and potentially fun.

[Robin]

Since my last update I’ve traveled outside the country for a few weeks (to India). After coming back and focusing on the day job for a while (mainly getting up to speed with more microservice principles), I decided to switch gears back to my main game.

I still intend to revisit the RPG/battle system idea I had one day since I think it could be a fun game, but for now I am trying to finish what I started again.

This time my focus is on creating a scene editor. So far outside of using Tiled for tile maps, I’ve been creating all scenes in code…which can get tedious. I just got comfortable with it and never thought about making an editor. Also in the beginning this started out as a Roguelite, which really didn’t need any comprehensive editor to put scenes together since they would have been procedurally generated. But now I realized I will most likely never finish this game in its current form if I can’t see how all scenes fit together.

So far I’ve designed the editor on paper (sometimes I need a break from the screen, so I still use paper for stuff!), and also implemented some of the basic classes. The editor will support the creation of Scenes, which can have Entities and Components added to it (The standard Nez ECS system). Scenes can be linked to other Scenes. Entities can have any number of components added to them, including tile maps, sprites, colliders, state machines, etc. The resulting collection of linked Scenes can then be output as a JSON file that the game can load.

I don’t intend for this to be too fancy (I am not a UI designer in any way). It will just be a tool to use to visually put the game together…and then leave the non-world-building stuff to be written in code.

Hopefully I can keep up my motivation/momentum this time.