Post Mortem - "Eldritch Legacy"
Now the Jam is almost completely over, it’s a good time to reflect on what went right and what went wrong with attempting to develop a tactical rpg game in 48 hours (plus a few hours on the Monday after work).
Development
I’d instantly decided on using a grid based approach for this game based on the RPG board games I used to play in the 90s (e.g. Heroquest) so the gameboard was to be a 2d array of grid square structures (walkable, visible, an array of what rooms the square is part of, and what object is on that square).
I’d decided on using a “Room” system to give an aspect of exploration; as you uncover “rooms” I could set their squares as visible and instantiate any objects/monsters inside, plus play any descriptions I’d provided. Uncovering a room was triggered by a player character stepping onto a square with that room in its array. The mechanics of this is pretty easy.
I’d coded the whole room and movement system pretty quickly on the morning of the first day.
The trouble came when it was time to try building levels. I’d assumed it would be easy to find some way of filling in the information on the grid (walkability and what rooms it’s part of) and overlay it on top of a nicely handdrawn background. It wasn’t easy… I wasted about 7 or 8 hours trying different approaches for making a tool to create a simple grid; watching Code Monkey tutorials for information about grid meshes, then about loading and saving json files, and finally using debug drawlines to try and give the outline of the walkable areas.
I ended up with a Unity scene where I could draw the walkable squares and add room numbers to them and then save this information out as a json file.
Then for each level I’d have to create a “scenario” object which loaded the grid data from disk. Then using altering the code for the scenario class to switch on something that allowed debug lines to remain in the editor mode. This debug line outline of the walkable tiles then let me place down sprites underneath and group them under “room” gameobjects (which in turn were linked in an array in the “scenario” object indexed by the room numbers from the editing scene). Once the entire scene was set up I could comment out the bit in the scenario class code that persisted debug lines into the editor.
By the end of the first day I pretty much had a prototype level I could move the characters around in.
On the second day I decided to tackle the “Game Master” component. This would be the bit that handled the story aspect of the level, showing the text and providing the options for the player to choose from. I re-used a bit of code I’d written last year which I’d called the Shard Engine; basically my own version of Ink that I’d done as an exercise when bored. I’d made a unity version of a potential UI for it which seemed to work in theory so I exported it as a package and imported it into my new project. Trying to hook this Shard Engine into the UI I’d only prototyped provided to be a massive time sink, with hours on the second morning spent debugging and tweaking until it finally worked.
By lunchtime on the second day I had a working prototype of the game where you could move characters around, end the turn, trigger rooms and start Shard dialogues. I took a couple of hours to create the enemy AI and the combat system.
How the movement / AI system works
A path list is generated for a selected unit by recursion. This essentially works thus:
if the current cost of the path is > max move, then ignore this square and return.
if the current square is not walkable, or is not visible, then ignore and return.
increase the cost of the path
if this square is already in the pool of possible squares to move to then see if this current path costs less than the one linked to that square already. If it is then switch that square’s path to the one we’re currently building.
If that square wasn’t already in the pool of possible squares then create a new node in the pool and set it to this square with the current path and cost.
Finally, recursive call this method again for the squares above, below, left, and right of this square.
This ends up with a pool of walkable squares within range of the selected character, each with a linked list leading back to the character. The system can reverse each list to find the squares the character has to move through to get to the chosen square.
The AI makes use of this pool. For each enemy it goes through each player character and works out the Manhatten Distance (x diff + y diff) to them (plus the attack range). It chooses the closest player, then goes through the pool of walkable squares to find the closest to that player. It then selects that and moves there. If the player is within attack range then it will attack them.
Design / Over ambition
Having spent a day and a half building the engine (and cursing the way I’d had to create a rubbish partial level editor), I was left with about 8 hours to knock up the content for the game. My initial dreams of constructing a Heroquest style Lovecraftian adventure with nice handdrawn rooms were pretty much scuppered, so I ended up using the crappy prototype floors and walls that I’d initially created. With the grid for each level on screen I dragged sprites in, scaling them as appropriate to roughly fit the outline I’d designed on the grid. Each of the 5 levels took roughly an hour or so to make and test, so by the end of the second day a completely silent version of the game was complete.
I’d hoped to have time to add some decent sound (e.g. combat noise, etc) in the evening of the third day after work, but I only had time to knock up some synth “ambient” sound in FL Studio for the in-level soundscape and threw some in-the-box FL Studio samples discordantly together for the title screen.
What doesn’t work well
The main criticisms of the “game” are about the UI and the mechanics.
The UI itself should have been set to scale with the screen, and also be more prominent. On higher resolutions the dialogue boxes were so small that the text couldn’t be read (I noticed that myself after testing the HTML5 verison on a Macbook) and it wasn’t clear that there was a box open (meaning that you couldn’t select anyone). In a couple of the levels I super-imposed text on the screen to act as a tutorial and these got confusing with the dialogue boxes; it would have been better to fade these tutorial texts out after a short while.
The mechanics issues came in two flavours:
When enemies are not present the game still requires you to manually end your turn after moving characters. What I should have done is allow the game to auto-end a turn after any character has moved provided there’s no active enemies on the map.
The other problem is in the combat system which works thusly:
Calculate a random number between zero and the attacker’s attack stat.
Calculate a random number between zero and the defender’s defence stat.
Take the defence value from the attack value and that leaves the number of hitpoints the defender suffers.
Because I didn’t balance the game properly (e.g. ensure that defence stats are mainly lower than attack stats) the defence value is very often the same or higher than the attack value resulting in combats where inflicting a wound is quite rare.
What’s next
I’m quite happy with the concept as a basis for a generic “boardgame” style RPG system, and the grid based system seems to work well. However, creating the levels is currently a nightmare.
Annoyingly, the day after submitting the game I realised that I could have made my handdrawn rooms and given them a polygon collider as an outline, along with colliders for the walls of that room. Instead of editting the grid directly I could have placed the rooms in Unity and put a grid system underneath which on startup would do a collison check for each square to determine whether it falls under a wall and what room polygon colliders it touched. This would allow much more flexibility in designing levels and would have saved me at least half a day during the jam.
What I think I’ll do is implement this approach and potentially release a post-jam version of this game as I do quite like the whole “Call of Chtulhu” vibe it has. I’d probably also try something in the sci-fi and fantasy genres as well as it’s quite a flexible system.
Comments
Post a Comment