It’s been a couple years since I initially came up with a concept for this game. The concept is pretty simple: You are a hunter adventuring across North America attempting to complete the North American Super Slam which entails successfully harvesting 29 Big Game Animals throughout the North American Continent. The game would play similary to the retro Pokèmon games; there are 5 total Regions to explore, within those 5 regions are sub-regions totaling 19 total areas to explore and hunt for these animals. Each sub-region hosts 1 or more of the Super Slam animals along with a host of common animals typical of that locale.
Encounters work similar to Pokèmon as well. Walking through the tall grass (or forest areas, this part is a bit TDB) has the chance to trigger an encounter with an animal. There is a base rate at which common vs super slam animals appear with super slam animals having an extremely small chance at appearing initially. The player’s level, weapon (and weapon level), gear (camo, deer call, etc), and consumables (attractants that buff encounter chance for certain animals) are all taken into account in raising the super slam animal encounter rate in any particular encounter area.
Taking the animal that is encountered is not as simple as lucking into an encounter. Each encounter that is triggered displays a percentage change of successfully harvesting the animal. Calculated similarly to above, think of it as the chance system in Octopath Traveler, if you attempt to harvest the animal and that fails your Poacher Status will increase. Poacher Status reduces your overall encounter/harvest chance as it increases, it also increases prices for items you can purchase at the local Outfitter, as well as making the items you craft to sell worth less. You can reduce your Poacher Status by successfully harvesting lower tier animals or by paying a fine to the Game Warden of that sub-region.
Among these core ideas I also have planned out the ability to harvest parts from the animals like fur, teeth, claws, feathers, etc for use in crafting items/consumables for buffs and to earn money selling to local vendors. Each animal regardless of how common has a sub rarity attached to its parts allowing even a common squirrel to give you higher value levels of fur for example.
I’ve gone back and forth what seems like a dozen times on which game engine to use for this. Bouncing between GameMaker, Godot, Defold, Love2D, Heaps, the list goes on. My ultimate goal for this game is to release it on Nintendo Switch. Because of this I kept wrestling with the fact that if I am going to pick a game engine it might as well be one that already has support for publishing on Switch.
Defold, for the longest time, felt like a good fit here. I have always wanted to try to make a game in it, and it’s ability to export to Switch made it seem like a good time to give it a go. And I did, I coded a proof of concept in Defold around the core encounter logic of the game. Let’s just say I have some opinions on Lua. I really just found Lua clunky to work with after having spent most of my career writing Javascript and Ruby. I do like that Lua is a complete language, and working with it in Defold you are not restricted to some propriety engine/editor language subset. But at the end of the day I just didn’t find Lua pleasing enough to continue with even though I personally liked how Defold itself worked.
Godot seems amazing. I’ve been intrigued by it for years. I’ve coded a few proof of concepts in it for various game ideas including this one. But by this point I have started to really want to write this game in an engine thats purely code based and doesn’t require working with an editor system. Part of me feels like for a game on the simpler side like this, I surely am good enough to be able to code it without the help of all the tools and built in pieces that come with an editor based engine like Godot. So then we come to DragonRuby.
I stumbled across DragonRuby a couple years ago while browing Itch.io. By that time I had spent the majority of my software engineering career in Ruby on Rails and the idea that I could use Ruby for a game seemed bizzare but also kind of nice. It seemed interesting, FPS locked at 60, no delta time to worry about. Utilizes mRuby which isn’t as fully featured as the Ruby I’m used to writing but contains enough of the usual suspects that it was intuitive to just start writing logic. And at the end of the day, the game I want to make is not complex in graphics so any half decent game engine would be able to power it at 60fps without much trouble. The downside? It cost money to get started. So I went away from it for a while, until one day the folks behind DragonRuby sponsered a Game Jam and were giving away the basic license for free.
With the DragonRuby license in hand I went forward and started building a proof of concept for the game. I stuck to the same idea as all the other POC’s I’d done in other engines. The core encounter area logic:
To accomplish the above is simple, you’re just using a mix of standard programming ideas like file loading, loops, conditionals and some random number generation. Needless to say all of that was easy given I was working in Ruby for which im most familiar with.
The engine specific APIs I also found the be simple and intuitive. Obviously I did not go very deep into functionality but for the basics of rendering a simple map with a player object and trigger area along with the code to allow movement of the player it all felt very simple.
I’ve merely scratched the surface of DragonRuby but so far I feel comfortable given my familiarity with Ruby and the simplicity of DragonRuby’s API that I intend to continue with DragonRuby as my engine of choice and see just how far I go and whether I end up regretting the decision to not use a editor based engine.
development, devlog, dragonruby, gamedev, proof of concept — Jan 9, 2024