Click image to watch prototype video
This phrase; One step at a time, really sums up this article but it also pertains nicely to the success Melvin Kwan has had thus far. Enrolling at VFS, Winning at the Entertainment Software Association of Canada’s Student Video Game Competition, invited to E3 and landing a job in the industry as a designer is all because he took that chance, that first step. Here is a peek into the process Melvin uses when developing his own game, enjoy.
At the start of September, I was ecstatic to be starting my first job in the games industry. I got my first real step in and was enjoying what I was doing, but I kept having this gnawing feeling that I shouldn’t just be satisfied by what I’m doing at my job. This resulted in a flurry of new game ideas for me. I had been working on a game idea I started prototyping previously, but these new ideas got me really excited for the first time in a while and I decided to shelve the previous project for now.
For many of these new ideas, I wrote small concept docs and prototyped basic mechanics to see which ideas I’d like to pursue further. It was around mid October that I decided I needed to stop flirting around with so many ideas and pick one to focus on. There was one thing in particular I wanted to challenge so I chose to try programming a turn-based combat system, something I had largely no idea how to accomplish.
The idea I decided to pursue was a turn-based RPG with card game elements. There were a few different games I was drawing inspiration from when I began fleshing out the concept. One was my final project at VFS, Zeta Busters, as well as Steven Universe: Attack the Light. Both of those games helped inform the structure of combat that I was trying to achieve. I particularly enjoyed the way SU: ATL used action points that allowed players to use moves for characters (points allowing) as often as they wanted. How the player decides to use or save their action points made for interesting decisions and I liked that idea rather than the traditional turn-based RPG where each character had one action each.
Unsure of how to even tackle this kind of combat system, I chose to start small and build it up one feature at a time. The first mechanic I started with was the character positioning stuff since it seemed the easiest to prototype. Four characters on each side and the characters closest to the center would take the most damage. I started with basic position swapping and the idea of a drag and drop style system appealed to me. Simple enough. I watched a great YouTube video on how to do that in Unity and in no time I had the first drop in the bucket.
Next, I started creating basic character classes with placeholder stats. I hadn’t done much character work before as far as creating complete stats or formulas for damage and whatnot, but since this was a prototype where I wanted to test functionality, I wasn’t too concerned about having solid stats here yet. I just needed data there I could work with. After that, I started playing around with uGui and getting a framework set up for the action cards players use for moves. I gave them some basic functions to test with, like having them print out to the debug log “hello”. Once I had loadouts changing for each of the characters, I tackled the harder part, the actual combat of the game.
I knew the actions were going to be one of the big things I had to tackle for combat so I just focused on getting them functioning first. I separated the moves the player could use in the game into a few different categories such as Attacks, Buffs, Heals, etc., and then into the range of their attacks, so single target, two targets, three, and four. There were other actions that were more unique like the Counter action or Knockback attack that I had to figure out how to make those work. Although I intended to make the combat system modular and flexible, I ended up just hardcoding the functionality for the prototype so that I could start testing the gameplay instead of spending too much time on the system. It ended up being the largest script I’ve written to date, and probably way larger than necessary.
The last big hurdle was enemy AI. Programming the player’s actions wasn’t that scary because I took it step by step, but AI was this big scary mountain of a challenge. One day, I just sat down and chipped away at it. I started getting the enemy characters to take turns saying “hello”, and then split them up into different classes to determine behavior. They were Attackers, Buffers, Debuffers, and Healers. I used the actions I had programmed for the players as a base for the enemy’s behavior and gave them all secondary behaviors as well so they weren’t always using the same move, but because of the way I programmed the actions, it didn’t translate perfectly so I basically had to repeat a lot of the code with some changes in the references. This is kind of why the script handling actions ended up so huge.
Once the AI had been implemented, there weren’t many other major features I wanted to get in for the prototype at this stage so I just added a few things to display information to the player and then called it. I did some QA to find bugs that would make it hard to playtest for feedback, but no extensive testing as it was a prototype anyways.
It took me roughly three weeks working on weekends and at night after work to complete this prototype. As soon as it was completed, I got a bunch of friends to try it and give me feedback. The feedback I received helped me make some important changes to the design of the combat system and so when it comes time to prototype the combat system with the new changes in mind, I’ll be starting over from scratch, but what I learned from this prototype gives me a much better idea of how I should do it. I’ll go over more in depth how the feedback I received affected the design of the game, but that will be for another day and another blog post.