So, unfortunately, due to the numerous issues with the site over the weekend I fell out of the habit of posting anything to my log over the course of Sunday. Given that this was certainly not the case for last LD, I am going to try and make up with a huge post instead, with sprinklings of hastily drawn drawings of things.
What Went Well
Oh boy did I ever improve on planning from last time. In LD20 I planned basically nothing and made it up all as I went along, reasoning that I’d find better use for the time actually making things. This was a mistake.
The time I spent on planning was 2 hours total (not a solid block), and for every minute I spent planning I saved two having to come up with things later on. I can’t emphasise enough the advantages of planning, but it’s one of those things where it’s obvious if you already do it and seems a waste of time if you don’t.
I did spend a lot more time on planning things I eventually had to cut, but without those plans in place I would have never known what I could have cut. I had to excise things like multiple species of guards and individual chatter lines simply because I didn’t have the time, but as stated, if I had never planned to add them in the first place, I could have never decided to omit them knowing I had more important things to work on first.
As my scanned-in plans are far too big to post here, you can find them here if you’re interested.
Code first. Code first is the most important rule you can adhere to for a competition this intense. It felt disheartening seeing a bunch of other entries being so much further along in terms of graphics when I was stuck with boxes with arrows on them, but with perseverance I ended up with a game that was more complex below the surface than Throwbots was. However, Throwbots had a few easier gimmicky things, which spiced it up a little. This game was a little lacking in gimmicky things, but it ended up spiced a little by something else.
Making the Guards Relatable
This I managed to hit spot on. I went into this with the idea of making the guards you’d otherwise treat as faceless enemies in a video game less faceless. I added a profile of stuff for each of the 20 guards in the game (which ate more time than I could ever have predicted) but knew there was one thing more I could do.
Give them friends.
In retrospect, “is fond of” was a bad phrase to use when the friend of a guard was meant to be any sort of positive camaraderie with another guard, and it made it look like the entire station was filled with courting couples or something similar. What was more interesting was I added individual messages to each guard if they saw their friend possessed or killed, but due to the frequency of random chatter it almost never showed up. It all helped to make people a little more hesitant to start gunning the guards down.
In initial playtests before submission, people were asking if I could make it so that guards could move into other rooms so they could unite the pairs of guards. I figured I’d won at making the guards relatable at that point.
What Could Have Gone Better
Guard AI & Controls
The guards don’t really HAVE an AI. Considering the initials of the game are “AI”, this feels a little more of a lacking feature than it should be.
Having never tried any sort of decent AI implementation in a game before, I had no idea what I was getting myself into. The state machine was simple enough, as was setting up an array of reactions based on certain stimuli.
But the main problem was a lack of good platforming AI. Having detection of pits and walls to turn away from was pretty simple – just check the tilemap to see if there’s a pit or a wall the guard is about to step into, and if that’s the case make them turn around. But then came a problem of the guards climbing jumpable parts of the map. I limited the jump height to such an extent that they couldn’t overshoot the block they were jumping to. For some reason, I decided to make that the jump height for the player too.
The kicker is that I later added code for the case where a guard falls too far away from their patrol point and made them pick a new patrol point based on where they were, so there was no reason to be so defensive about keeping them near where they started. That was an honest mistake on my behalf.
The transitions don’t always make sense either, and guards have no persistence of memory. If they see the player and the player ducks behind a corner, that’s it. The player has ceased to exist for them. If I had pathfinding code in there, I’d probably have made them chase the player while they were within a sensible range, but I sure as hell was not writing my first platform pathfinding AI during a Ludum Dare.
All in all, a host of niggling issues that I would definitely like to resolve.
I’ve heard people coming back to me saying they memorised all the guard details in case they had to use them. With more time, there would have been social interaction puzzles, because while it’s fun to take over people’s actions why not also meddle in their affairs while you’re at it? Unfortunately, I couldn’t think of a streamlined way to do this, nor a way to get the relevant reactions and such done within 48 hours. A future version, perhaps!
The UI and Tutorials
Quite simply, there was no tutorial. I ran out of time to add one, and so tried to make up for it by sticking the controls in my entry text. Not only that, but I ran out of time for custom keybinding. For everyone not using a US/UK English keyboard, I am so, so sorry to force Z/X/C on you guys like so many other inconsiderate devs, but when it came to getting the game finished or implementing custom keybinding, I knew I had to focus on the former.
As for the UI, well, I didn’t get any of the graphical elements done so most of them ended up hidden. It’s a confusing mess at the moment, but believe me when I say it’d be more of a confusing mess with a bunch of squares that don’t do anything on it. Once I get the first post-compo release finished, you’ll hopefully see what it should have been.
Critical Bugs At Release
The first version of the compo release had a critical game-freezing bug if you managed to get shot while controlling a guard (a case I never encountered during my own all too brief testing), as well as a duplicated terminal and a missing terminal. The first was due to another instance of a variable being null when I didn’t expect it to be (easy to fix).
The second, though, was the worst damaging typo of the compo. Each terminal had a numerical ID. Terminal #16 ended up getting 10, so there were two terminal #10s and one terminal #16. Now, this might sound meaningless, except the doors are locked according to terminal IDs and whether they’ve been used or not. Terminal #10? That’s the terminal that unlocks the door to the teleporter room. If you were confused by the earlier comments on my entry about finishing far earlier than they expected, that’s why. Whoops. My bad. It’s fixed now, though.
What To Focus On Next Time
Sounds and Music
I managed to miss this out this time as well, much to my disappointment. I had such neat ideas, too. Oh well. Best to have an okay working game that looks passable instead of a broken game that looks terrible with annoying screechy sound effects, right?
Although the extraneous bits this time around may have elevated my entry from mediocre platformer to something with a bit more depth, I still think the control mechanics could have benefitted from a little more love.
I skipped it this time around due to lack of preparation. In future I am going to do my research to find out what programs to use and more importantly how to make my reams of coding look a little more interesting.
I had an amazing though hectic weekend working on this thing and there is no doubt in my mind that I’ll be entering LD22. This time, I intend to work on a post-compo version of my game and perhaps even carry it into the October Challenge if it’s on this year. Regardless, I’ll see you guys at LD22. Keep being amazing.
(Let’s see if we can break 1k entries next time!)