Citizenship++: An Intoxicated Postmortem

Check out Citizenship++ here! I hope you like terminals.

Well, this Ludum Dare was certainly different to the others we have done. Having participated in LD37 and 38, I was expecting this jam to go much like those did: stress, bugs and over-ambition. As it turned out, the experience was almost the complete opposite of this (well, not the bugs part, but what do you expect?).

Again, we had two people working on the game. Returning is me (Andrew), this time joined by Wisley rather than David who only helped with moral support and bug testing towards the end since his computer had spectacular hard drive problems just before the jam started.

It is amazing what being able to properly scope can achieve. On our last two LD jams, we massively overestimated what we could do in 3 days and tried to make a first person parkour game and a turn based strategy game respectively. Coming back a year later with some larger projects under our belts has seemed to have helped here: this time, we decided to make a hacking/puzzle incremental game with a not-so-subtle surveillance state theme.
Theme
We knew pretty quickly when we saw the final theme voting options which one would get picked. The ‘combine 2 incompatible genres’ theme stood out from the rest considering how far through voting it had made it. Both of us (Andrew and Wisley) liked this theme, and it was one of our preferred options from the list. As a result, we weren’t surprised when this was picked.

However, when it came to developing a game idea off the theme, we somewhat struggled initially. Our first idea was for a hacking survival game, in which a programmer would need to survive overnight in an office building from some sort of existential threat. While this sounded cool as a concept, we struggled to decide on exactly what the player would be surviving and how this would be accomplished. Wisley wanted the player to be surviving other hackers attempting to gain entry to their own computer, while I wanted to go with a more mysterious, unknown physical threat in the building that would travel through digital pathways. We found ourselves unable to compromise on our different ideas, so we decided on something new.

Our second idea was inspired by incremental games that got quite popular a while back. Wisley quite likes these sort of games, and it still had the hacking aspects that I found interesting. This was the idea we decided to go with.

Programming

The game was quite simple to program compared to our last few games. We used Unity, and the entire thing uses its UI system so we had a lot of flexibility out of the box. Apart from the UI, a lot of the code doesn’t use the GameObject/Component system, instead relying on a small command framework I wrote consisting of a input handler, command interpreter and then different commands stored in a table. Through a concerningly high number of singletons, we were able to quickly write systems that the commands could access, such as a shop, scripts, randomly generated bank accounts etc.

I'm going to hell for this.

For once, it wasn’t that buggy either. I expected to be tracking down obscure bugs through reams of spaghetti code, but a lot of the code felt pretty clean once we made it. Of course there were a few problems, such as having 2 enum types for almost the same data in 2 places in the codebase, but overall we were able to quickly add new features without breaking much.

Probably the hardest element to create was the scripting system. Even the final version is a bit of a hack - it just runs commands through the normal command interpreter sequentially. It’s very easy to break by just having a script execute itself (which outright crashes Unity), and doesn’t have as many features as I would have liked, such as being able to safely recurse or read from the output (which would make it FAR more useful for hacking). Even still, it is pretty cool to see it work in-game.

We needed more pictures.

Art

There’s very little art in the game. I chose the font (which is called Hack by the way) by searching ‘hacking fonts’. The wallpaper that can be unlocked was drawn by me in Photoshop in about 5 minutes, with several emblem variations being voted on by Wisley and David (our magical QA guy for the jam who can break anything). Deciding on a symbol was actually somewhat tricky, as we wanted something that looked unique and felt authoritarian without being too similar to iconography of any real groups or governments. We settled on something square and red, because red always says ‘AUTHORITY’.

There was some discussion about whether there is too much bloom in the game when we were finalising a release candidate, but I did bump it down somewhat before release. I personally like bloom quite a lot, and I think it really adds to the blurry retro CRT aesthetic of the game.

Music

This is the first game jam we made our own music. After sampling some authoritarian music and getting a MIDI file, Wisley modified and made two remixes off of it with FL Studio, which are the two main pieces in the game. For the NES feeling, Wisley got some soundfonts and kept mixing instruments. A few of the progressions are original compositions, others heavily edited sound files with specific frequencies cut out.

I did a remix of Wisley’s MIDI in about 45 minutes in GarageBand on my mac, mainly just for fun. I split the notes up into different instruments and cleaned them up a bit to sound right. It actually sounded decent, so we put it in the game.

EDIT: it turns out that it pays to be careful to check the source of your 'public domain music'. Not to go into details, but we had to change the ending music. Now the sound of bombs falling on the city plays. It's still fitting and gives a sense of dark humour.

Story/Theme

Our theme for the game, not the Ludum Dare theme. We don’t have much of a story, but we wanted the game to have an authoritarian feel to it and I think we captured that quite well thanks to some nice writing and music from Wisley. The idea was stealing citizen credits from people’s accounts in order to buy more stuff to hack faster. That’s basically it.

We were originally going to go with a more specifically Communist theme to the game, but we realised that a lot of the mechanics, such as stealing money and buying things from the shop wouldn’t really make sense in that setting. We made it a more general authoritarian theme instead and used citizen credits as a currency, while making the shop a behavioural reward scheme to reinforce the idea of a surveillance state.

I ended up adding an ‘ending’ to the game that costs 2 million citizen credits (which plays my version of the game’s music) and tells the player that the song they purchased online goes viral and starts a Communist revolution, but because the player earned so much money during the game they get executed. It was meant mainly as a funny easter egg for anyone silly enough to play our game that long.

Bugs

The fun stuff. There weren’t many super serious bugs this time, but a few were tricky to fix. Generating random types of locks for bank accounts took a long time to get working well, between bugs and just feeling very unfair. Initially you would almost always get a lock type higher than what you knew how to hack, so the game felt tedious and slow. Wisley ended up disabling this so you can only get locks up to the highest manual you have purchased.

Another bug with this system was that lockType (the variable we used to keep track of an account’s lock level) would occasionally generate a value of 0, when the lowest level that should be generated was 1. This would cause the account to display no lock type when scanned, and would only ever give 1 credit as a reward for hacking it. This single bug took about 3 or 4 individual commits to fix, since it was hard to test when values were randomly generated. Something that seems like a bug might just be bad luck, such as when about 10 Charlie locks in a row would only have 2 or 6 as their solution for me.

Uh, it's probably fine.

Reception

As it turns out, only programmers like command-line games. I showed a pretty complete version of the game to some game designer friends and an economics student and they all said (in quite similar words) “ew, it’s a terminal game” and refused to play it. Meanwhile, all three of us at While False Studios love this sort of game as we’ve been programming for years. I don’t really see this as an issue, as games like this do have their niche; just have a look at how well Hacknet did.

The people who did play our game seem to like it. Feedback seems to suggest it’s a bit light on documentation overall, which I completely agree with. It is hard to know exactly how quickly players will catch onto the gameplay in such a short timeframe and we misjudged it slightly. From some early Ludum Dare comments it also seems that people find the game very slow to play, especially for a game jam game. I think this is understandable, and was somewhat of a concern I had while developing. Perhaps a later version could up the rate at which money can be collected and add some quality-of-life features, such as the tab-completion of IPs that one comment and David suggested, but we stupidly chose to ignore.

What Went Badly

I think the worst part we did was the planning, since we had trouble agreeing on an idea to pursue. Wisley and I have quite different taste in games, so finding two genres that we could make work together was difficult. Even now, the type of game we made wasn’t exactly what I had hoped to make, since I prefer something with a story (doesn’t have to be explicit - environmental storytelling or even just atmosphere is enough) over gameplay.

What Went Well

This the first game jam we have finished significantly early. As in, almost 12 hours before the end of the jam. As I already said, I think this has a lot to do with having more experience than during our other jams and a better ability to scope a project. We even found time to do a bunch of other stuff: on Sunday (or Saturday for those not in upside-down land) we played Dying Light for some hours to take a break, and there’s a whole story about someone getting a little tipsy (he insists it wasn’t drunk) from being overzealous with the spirits in a lemon-lime-bitters.

The scripting system proved to be quite impressive even if it’s pretty limited: it has its own in-game editor, and you can save and delete scripts with a unique name. Multiple scripts can even be used together to perform a larger task since scripts can execute other scripts.

We also learned just how important music can be in giving a game a completely different feel. Once Wisley’s music was in, the game felt far more atmospheric and enjoyable.

Conclusion

Overall, this was the best jam we’ve done so far. For once we managed to scope properly and code our game in a way that avoided the eldritch clutches of spaghetti code that plagued our previous games. We’re both happy with it, and hopefully we can address some of the issues that have been reported so far in a future update.