For April, I wanted to focus on a genre of games that has been pretty much nonexistent in the AAA game industry in recent years, but that indie developers have been slowly reviving: the turn-based RPG. I've been working on my own turn-based RPG for about a week now, and it's been a fun challenge. This article will cover my progress thus far.
I've never made an RPG before, so naturally, I didn't know exactly where to start. There are so many things that make up a great RPG, and I really could have started anywhere. However, I decided to start with the battle system because that part excited me the most from a developer's perspective.
The requirements sound pretty simple on paper: the battle system just has to support turn-based combat. Basically, it will be your turn to attack (everyone in your party chooses an action and does it), and then it will be your enemy's turn to attack (everyone in the enemy party chooses an action and does it). Repeat that until either the enemy is defeated or your own party is defeated.
It may sound simple on paper, but I've found this to actually be a very challenging problem as a programmer. There are so many details underneath the surface of that simple game loop that need to be fleshed out. For example: how do you know who gets to attack first when a battle begins? The simple answer is, base it off of a speed stat. Whoever has the highest speed level gets to attack first in battle. Well, hang on... We don't have a player or enemy stat system yet. So, we need to implement that before we can even decide who gets to attack first. Developing the battle system has been a lot like going down a rabbit hole in that respect. Every simple step in the battle requires the implementation of yet another sub-system. Turn-order required implementation of a speed stat, attacking required implementation of an attack stat and health point system, the player taking their turn required implementation of a selection-box text system, the list goes on and on.
That might sound like a nightmare to you, but this is the sort of thing that I live and breathe for. It's blown up pretty quickly, too. The battle system isn't finished yet, and it already contains more lines of code than the entire project files for POLYPAINT, my game from January.
RPG's are extremely data-heavy, meaning there's a lot of code that just specifies the properties of various objects in the game. For example, so far, a simple enemy has a name, flavor text, speed, attack power, and maximum health. Each different enemy type will have different values for those, and I decided to separate this from the game's code itself.
Each enemy loads a stat file when it's initialized in the game world. This is nice because if I want to change any of the stats of any of the enemies, players, or whatever during development, I won't have to change any of the actual game's code. I'll just have to change a simple, easy-to-read stat file. Here's an example stat file for a test monster:
Thus far, the battle system is really data-heavy and code-heavy. A consequence of that is that I haven't been able to focus as much on the actual content of the game. The more time I spend on the battle system, the less time I have for artwork, coming up with enemy ideas, sounds, music, etc. Nevertheless, here's a little preview so you can see what I have so far:
The question marks are placeholder images. They will be replaced by enemy portraits whenever those are completed. I know this is pretty bare-bones stuff, but it's taken a lot of work to get this far, so go easy on me!
This month, I thought I might try collaborating with my brother on the game's content. He's got some really freaky artwork, and I think it would be a great fit for this game. He may have some enemy portraits that will be a part of the game by the time next week's article rolls around, so stay tuned!
<= Back