I didn’t have much to report in week four, but before I knew it I was all wrapped up in getting ready for the Philly Game Jam and recovering from the cold I got while I was there. A few weeks later, and here I am again. I’ll now report the progress I made before and since the game jam.
It’s fundamental to the gameplay and design, and in every significant way, it’s working. I’ve created a suite of classes to represent character data, item data, and their interactions. At first I was concerned with getting XML serialization working right away, so I could populate the character data and item data objects. I quickly realized that I could put that work onto Unity’s inspector. (See Screenshot)
Items, Player Characters, and enemies all use the same core data structures. I can give the enemies the very weapons and armor they will drop for the player to pickup. Items have “magic” bonuses to the character’s stats. Weapons have unique attack data and alternate fire projectiles.
I can create a new, fairly unique character, in the inspector in just a few moments.
Character Swapping
Since the character data is totally serializable, I’m able to quickly swap out the activate character data for the character data of a benched character. I’m really excited to see this core mechanic working so well.
Right now, there are three characters in-game. They each have a set of items, but the items can’t be changed out yet. Each of their weapons has a unique alternate/ranged attack.
Enemy AI
I have stubbed methods for several types of enemies; including brutes, rangers, and minions. I’ve developed a rudimentary AI for the minions. I’ve patterned them off the behavior of Diablo’s fallen. When an ally dies in their presence, they scatter and run away. Of course, this can only happen so often, and it doesn’t happen all the time.
Weapons and Ranged Attacks
There are three kinds of items. The first kind, weapons, are the most developed so far. Each weapon has a ranged/alternate attack, selectable via the serializable weapon data. The attack radius of the weapons has also been upgraded from an awkward collision box to a programmatic arc, just as I wanted from the beginning. I had to brush up on my trigonometry, but it was well worth it. With just a few variables changed in the inspector, I can change a weapon’s reach and arc. I will definitely be able to reuse that code.
Redesigned Movement and Camera
I just recently totally rewrote the movement code. The way it was before, it wasn’t able to handle where I wanted to take it. I was trying to add code to lock onto enemies, but the old version was having none of that. Now it’s much more flexible and extensible.
One very noticeable change from the last playable version is that I totally removed that variable movement speed. I did this for at least two good reasons.
- Technical ability for the player to control the character suffered.
- I foresaw a game design flaw stemming from one of the main reasons I had the feature to begin with.
To top all of that off, the player, data, and camera objects aren’t so tightly coupled. That was starting to bug me.
