🌑

Jason Storey

Home Email

PocketHunter - Devlog #3: Refactor and Sprite animations

I took some days off from coding and in the meantime did a lot of thinking and reading about various aspects of game design and development. The time away let me refresh after spending several days diving deep into DragonRuby. During this time away, if I’m being honest, I also wavered on my choice of engine (don’t we all?).

After having spent several days building out this proof of concept in DragonRuby I caught myself again looking at other engines. Would it be easier to use Defold? Or Godot? Maybe GameMaker?

It was an interesting revelation for me actually. Here I was, someone who typically feared code-only game engines/frameworks and yet, as I continued to look at editor based engines all I could think was: It doesn’t support that? Or This? Wait I can’t do that in there either? To my surprise I had really grown to love how DragonRuby was built and the way it allowed me to code. So I said right then and there, this is it, I’m sticking with DragonRuby… yeah, as if.

Since I can never make up my mind I even started to look at other code-only engines like MonoGame, Heaps, and Love2D. But the same thing happened again. All these other engines just reminded me of the parts of DragonRuby that I’d grown to love didn’t exist in other engines or at least were vastly different and needed myself to implement the remaining pieces. That’s not to say those other engines are bad, just that I had grown to really appreciate what DragonRuby was and finally decided I wanted to continue working in it.

So we’re right back where we started

After some days off, and a bit of the usual indecisiveness I’m back to my DragonRuby project with renewed confidence in my ability to create a solid game. As soon as I realized I would be sticking with DragonRuby I started to think about refactoring my code to set myself up for the future. Up until now I really only had one file for all my game logic with everything hardcoded values for things like the level images.

Initially I know I will have two main types of scenes in my game:

  • Map Scenes
  • Encounter Scenes

Map Scenes are what I am calling the scenes where most of the gameplay happens. Walking around the map looking for animals, going inside buildings, etc are all what I am classifying as Map Scenes. Encounter Scenes are the scenes where you attempt to harvest the animal that you have encountered. Think of those as the fight scene in retro Pokèmon.

To handle this I created two higher level classes: World and Encounter. Each class has the code needed to manage the player and interactions within these two types of scenes and spawning a World for a specific level is as easy as:

$world ||= World.new('level_0')
$world.args = args
$world.tick

The World takes in the args and handles all the World based logic within it’s own tick method.

I coupled this refactor with Scale which I found to be a fantastic piece of code. Adding in just the right amount of helpers and base functionality without forcing you into something like ECS or a more opinionated framework. If you have not seen it before I highly recommened checking it out.

At the end of the day yesterday I felt that my game code was much more stable and futureproof and ready for me to begin adding in all the other pieces.

Bonus content: Sprite Animation

Up until now my Player has been a blue rectangle gliding along the map. After my refactor work yesterday I felt I needed to give it a little love and test out doing a simple sprite animation for walking. So I grabbed a free character asset and setup the animation to change my Player from a gliding blue rectangle to a spiffy walking little pixel person!

, , , , , — Jan 17, 2024