[JRPG Idle] Dev Log #3 - Ready, Set, Godot!
/Hello friends, and welcome back to the JRPG Idle Dev Log. Up until now we’ve done a lot of planning about our approach to getting this project off the ground - but now it’s finally time to dive in, and start building that first prototype!
This brings us to everyone’s favourite question - What engine should I use?
Traditional knowledge is that deciding on an engine basically comes down to 2 things:
How well suited the engine is to the type of game you want to make
How accustomed you are to working in said engine
For this reason I, like so many others, have often found myself defaulting back to Unity3D. Most of my past experience is in Unity - and so when I want to build something, it feels like Unity is the engine that gets me there the fastest.
A look at the fledgling JRPG Idle prototype, at home in the Godot Editor
However, following the “The Incident”, it felt like a good time to jump on the Godot bandwagon and see what’s up. Trends aside, for a relatively small 2D project like mine, Godot has a lot of attractive features. It’s lightweight, easy to iterate in, and its UI toolset is nice for the type of game I’m making (which is mostly UI).
What’s more, Godot proponents claim the engine is fully featured and has a lot of community support - two of the biggest feathers in Unity’s cap. If Godot can really deliver in these areas, why put up with the bloat of Unity? In the end of the day, at least a prototype is a low-commitment way to learn the engine.
So having made the perhaps-questionable decision to build my prototype in an unfamiliar engine, I tried to break down my immediate tasks, and start with the smallest elements first. One nice thing about learning as I go, is that I didn’t have the same desire to polish and nitpick the way I would if I was using another engine. That little bit of extra friction allowed me to focus a lot more on only building the things I need.
Looking at the gameplay loop we established last time, I determined that for our prototype to be feature complete, the player has to be able to:
Complete Combat activities to earn loot and Combat XP
Complete Harvesting activities to earn materials and Crafting XP
Visit the shop and purchase items using gold
Craft items using materials
Equip gear to increase Combat / Crafting stats
Level up to increase Combat / Crafting stats
Perform Combat / Crafting activities more effectively when the player has better stats
Progress through the game (unlock requirements, consume materials in crafting, etc)
A look at JRPG idle in action! The player harvests Iron Ore, earning materials and Crafting XP as they go.
With this list of tasks in front of me, I found it relatively easy to put my nose to the grindstone and work through one after the next. I had a good picture in my head of the total scope of what I was building, and working incrementally helped me break down the tasks into manageable chunks. Without the worry of implementing wide-sweeping systems, each task was a pretty small job that just built upon the task before it. Of course we want to keep in mind the things we may need to support down the road, but right now we’re trying to go fast and find all the “unknown unknowns” - so to speak.
As I added additional screens and gameplay, I started to get a feel for traversing the game, earning rewards, and using those rewards to perform other actions - but already I can feel myself falling into the trap of scope creep.
The player has to earn something from completing these activities, and as much as they should probably all be placeholder items for now, I can’t help myself from giving them names and thinking about what this crafting system should look like long-term. I end up sinking a surprising amount of time into designing items, where they come from, and what they are used for.
However, part of the point of a prototype is to learn how to make your game, and this little distraction taught me pretty quickly that the full game will need a robust way to add, edit, and visualize game data; defining things in code just aint’ it!
Trying to define all of the data in code very quickly becomes difficult to manage, and add to.
Building a snapshot of the game has helped us see issues that we couldn’t see before, and forces us to think about how it all works together. Right now the game balance is awful - but even without putting time into creating smooth progression curves, we learn a lot about how the player interacts with the game, and what kind of affordances they need.
For example, how should stats work? Right now the player just has a single “Combat Power” stat, which linearly increases the speed at which the player completes Combat Activities. This is perhaps the simplest way to implement it for now, but this pattern doesn’t really serve the player that well. As a player, I want to understand the effect “+500 Combat Power” has on my gameplay. And if that gain turns out to be something like completing Combat Activities 0.001 second faster - this isn’t really a satisfying or perceivable gain for the player.
So now thanks to this prototype, we understand that one of the challenges we need to overcome is creating a stat system that is more granular. We need a language for communicating the result of activities, and a way to explain why it will turn out that way. The player has to be able to understand what stats will allow them to accomplish their goals, and why they want those stats.
Once we have a better understanding of the full scope of what we’ll need to communicate to the player, we can spend more time coming up with what that language looks like.
JRPG Idle has a fully functioning crafting screen! This is where all the magic happens.
All told though, things really start to come together as we approach the end of the list of prototype functionality we need to build. Once I started enforcing unlock requirements for crafting items and performing higher level activities, we can really start to feel a sense of progression through the game.
As a player, I can decide I want to improve my ability to fight enemies, work towards crafting a Copper Sword, and then feel more effective when I finally manage to craft and equip one. I can feel myself strategizing my next move, clicking around the game to acquire information, and just generally playing the same way I would any other Idle Game. It’s pretty basic, but our simple gameplay loop is a fully functioning little game!
We’ve barely even begun to satisfy the gameplay pillars that we set for ourselves, but we’ve learned a lot, and now we have a solid foundation upon which to start adding complexity. So far Godot has served us well, and this first prototype came together quickly despite it being my first time using the engine. I can’t imagine any of what I’ve made so far will survive into the full game, but Godot has allowed us to make lots of ugly mistakes really quickly, and that’s ultimately what we want out our prototype!