[Note: I'm still looking for an artist/art director to work with on this project. If you do 2D art and what I'm working on sounds interesting to you, drop me a line at pykretegames@gmail.com.]
I made progress on a lot of components this month, although they're mostly things that run under the hood and don't make for very good screenshots. The biggest thing that's been added is character classes, which I'll get to in a minute. I also finalised (I think) how the combat model is going to work. I also want to briefly touch on some of the smaller things that I've worked on that might not be as exciting, but are pivotal to making the game play well. In particular, I did a lot of work on the interface so that important bits of information (like how many hit points an enemy has left) are easy to find. Up until now almost everything has been in my head and it would have been impossible to play without a bunch of knowledge that only I had.
The Combat Model
The most important thing I've been trying to figure out with the prototype is exactly how combat is going to work, so that I can start implementing abilities and do a bit of balancing to make sure it all flows smoothly and is fun to play. I knew I wanted to do something that involved action points, but I had a few ideas that I wanted to test out to see what worked best.
I've gone through a number of different ways of divvying up action points for movement and combat. My preferred model initially was for each character to have a fixed pool of AP which could be used for both movement and abilities. The Divinity: Original Sin games do something like this. Combat was initially coded to work in this way, which allowed you to do any combination of movement and attacks that you wanted as long as you had AP remaining. However, even though I went through a number of permutations, I kept running into problems.
The crux of it was this:
- I want the combats to generally take place in somewhat enclosed spaces (a barroom brawl was the example I've given previously).
- If you're combining movement and abilities into one AP pool, you need to have a lot of AP available, which means the areas need to be fairly large, otherwise you either run out of AP from movement or you can only ever move at a glacial pace.
- Trying to do a combined AP pool in small areas meant it was far too easy to run into a situation where a character would move, then wind up with too few AP to do any attacks. Alternately, if you wanted to do an attack it was often implausible for you to also move.
So after a bunch of work trying to get the combined AP pool to function in a way that was fun and challenging, I was forced to admit it didn't work for the game I'm trying to make, and I had to search for other ways of organising combat and action points.
What I've settled on, which is pretty fun to play right now, is quite similar to how the recent Shadowrun RPGs work, and not too dissimilar from older games like Final Fantasy Tactics. Here's a run-down:
- You get two action points every turn.
- Characters have a movement range. "Movement" is now a 1 AP ability that allows a character to move any number of tiles, up to their movement range.
- Most attacks will cost 1 AP.
- Some attacks, which are more powerful (and often inflict status effects), cost 2 AP. That means they can only be used on a turn in which a character does not move.
- Movement can only be done as the first action of a turn. If you perform an attack, you can't move, even if you have an action point remaining.
- Picking up and equipping items, which used to cost 1 AP, is now free.
This has turned out to be a lot of fun, and allows me to do some fun things in terms of balancing 1 AP and 2 AP abilities, especially once I start working in unique class abilities. Speaking of which . . .
Character Classes
I don't want to get too deep into the character classes right now, because:
- I'm still working on them.
- It would be difficult to explain them without going into the game's theme and setting, which I'm holding off on for now.
But I have done an initial pass on the character classes. There are (at the moment) five character classes that will be available to the player. Enemies will have their own separate classes, for reasons that also tie into the story, so I'll leave that out for now.
The important thing is that the code to implement classes is largely done, and I've programmed some of the unique class abilities too. For example, one class has an ability where it can steal an equipped weapon from an enemy, which could really turn the tables in a fight because the equippable items are such a big part of the combat.
Since characters don't have their own weapons, most of the abilities are tied to equippable items rather than individual characters. Each class will have 2-3 abilities that it can use, and the idea is to give each class something totally unique to do that messes with the game rules a bit (for example, the character that can steal weapons, which no other character will be able to do).
I'll write more about the classes once I've said more about the story at some point in the future, and once I've done some more testing to really nail down how each class plays.
Tooltips, Odds and Ends
Tooltips have been added in a few places to help make it easier to understand what's going on. You can now see how many hit points each character in a scene has remaining at any time by hovering over their sprite. In the future I also plan to add a button that will show the HP tooltips for every character on the screen at once.
There are also item tooltips now. As I discussed in the last dev blog, one of the key ideas of the game is that characters don't have any weapons equipped when a combat sequence starts; instead, there are items placed around the level that can be equipped by anyone who can reach them, but it was difficult to know what you could actually do with any given item, so now there's a tooltip that explains what abilities you can execute if you equip any given item.
I also made a number of smaller changes under the hood to improve ability targeting, movement, and so forth. I also added code for handling status effects, although that's not interesting enough to delve into here. All of these things make the game better to play, even if I can't show them off in screenshots.