Post-Mortem: Protect & Serve

 A couple weeks ago I participated in my first ever game jam! This is something I've wanted to do for over a year now, but in the beginning I didn't feel confident enough with my abilities in Unity, then later on when I had the confidence it never lined up with my schedule until now. I chose the Major Jam 4, since it seemed to have a decent number of participants without being huge, it had no prizes, and no celebrity name (i.e. no YouTube channel) attached to it, so the stakes were comfortably low. The participants all had up to 7 days to make a game with the theme "Cosmic" and the surprise limitation (announced when the jam started) of "The player must cheat." It was a stressful week, but I did it! I'll walk you through my process below.

Concepting

The jam started around 11pm my time on a Sunday, so when the limitation was announced I grabbed a notebook and started writing down everything I could think of related to the theme and limitation. I knew immediately I didn't like the idea of the player literally cheating (via cheat codes or meta-game mechanics, etc.) so the limitation would have to be diegetic. Some of the limitation ideas I wrote down included:

• Magic or psychic powers that let the player break the in-universe rules (i.e. you're the only magic user, or use magic for things other than just shooting)
  
• Financial cheating -- fraud/piracy
• Breaking the terms of a contract
• Drugs that enable rule-breaking hallucinations or powers

Meanwhile, "Cosmic" as a theme was easier. That word's first implication to me is a sci-fi setting, although it could easily be used in a fantasy or modern setting as well; I'm a huge fan of space fantasy, as the players of my D&D campaign can testify. Some of the terms I wrote down for Cosmic included:

• Spaceships
• Planets/stars
• Space Fantasy
• Lovecraftian (cosmic horror)
  
• Shattered World (the name of my D&D campaign, which takes place on islands floating in space)
• Drug trip
• Cultists ascending and/or plumbing the depths of insanity

The first idea I actually landed on was a tile-based roguelike type of game where you played as a cultist to eldritch gods in a fantasy world. You would have to either pretend to be a normal townsfolk while carrying out heinous rituals in secret, or pretend to sacrifice townsfolk to cheat your gods out of their powers. I began drawing some art and prototyping grid-based movement for this, before realizing that I had zero ideas for how to make it fun and interesting within the time limit. This brainstorming and prototyping consumed most of the first day, so I was feeling pressured to follow an idea that I felt inspired about instead of one I had to force, so I scrapped it.

Then it hit me, like a space-police car slamming into a smuggler at full speed. A corrupt cop simulator where you're both cheating at your job for personal gain, and cheating the corrupt social order when you do your job correctly.

Creation

The first thing I did was draw some top-down car sprites, then import them to Unity and write a simple driving controller. I decided to go for tank style controls (up/down keys to accelerate/reverse, left/right keys to turn) since it was thematically fitting and would raise the skill floor just a little bit. At first my thought was you would have a laser gun or a rocket launcher on the cop car that you would use to destroy criminals, basically in drive-bys, or to further emphasize the tank controls. But after prototyping this I knew that it was going to feel bad to use, and in any case by giving it a forward firing arc and limited range I incentivized basically slamming into things you wanted to shoot.

But then the solution became clear: implement ramming as a mechanic. When you collide with another car at high speed (indicated by a semicircular shield appearing in front of your car) that other car is destroyed. Around this time I also decided, mostly arbitrarily, that the player should be invulnerable to direct damage; ramming doesn't physically threaten you, and it's binary whether it works or not. This intuitively seemed like the simplest and easiest solution for a game with such a small scope.

Originally, I wanted there to be four ways you could interact with other cars on the space-road: ram them, arrest them, accept a bribe from them, or ignore them. The idea was, based on how they behaved and what their agenda was, you would benefit from these things differently. Arrest criminals, but not ones that bribe you; ram pirates, but no one else; etc. The police siren mechanic was going to be instrumental here: pull over cars with your siren on to arrest them, but pull up next to them with your lights off if they're offering a bribe to accept that bribe.

I ended up scrapping the idea of bribes being a mechanic that are explicitly offered to you and accepted or turned down. It seemed like it was going to complicate the code and my job as a developer much more than it was worth, since as the game progressed it seemed like bribery was implied in the game's story and themes. So now the siren just controls whether you arrest people or not, since you are directly penalized for arresting the wrong people. This also means a car's state never changes after it's spawned: before, I was going to need a state tree to represent criminals who offered bribes, then whether their bribe was accepted or not, and graphics and UI to represent all these things, and and and... Anyway, I'm glad I made this choice.

The car pathfinding is quite primitive, but something I ended up being pretty proud of. Cars spawn at a random (unblocked) spawn point, then try to turn and drive directly towards a random destination point. If they see an obstacle in front of them, they will brake; if their speed is reduced far enough, their destination will be overridden with a 'temporary destination' created at about a 45 degree angle in front of them. As they turn to face their temporary destination, it will move as long as they keep seeing obstacles in front of them and keep turning. When their view is unobstructed, they'll drive towards it. Once they reach it, the temporary destination is cleared and they start turning and driving toward their original, final destination.

Pirates don't reach a final destination; they just randomly fly around the map. So for their behavior I simply set their final destination to one of four invisible "pirate rally points" around the edge of the map, and I removed the code that causes them to despawn when they reach their destination. When they hit it, they'll overshoot it and fly back around in a circle. Every few seconds, a pirate will change its destination to a random, different one, causing them to move across the map. The missiles they fire are independent of direction; they just pick a random target and will explode on the first car they hit.

As an aside, the fact that pirate missiles don't hit the player is a bug I was never able to fix in time. The idea was you could intercept missiles by driving into them, causing them to explode harmlessly (since you can't die) and reducing your Suspicion meter a bit (since you're protecting the citizens), but this never panned out. It's probably not much of a loss to be honest, since the missiles are so small and move so quickly it's very difficult to hit them with your car anyway.

I was never certain how to explain to the player what criminals look like. In the end I wrote a sentence on the tutorial page saying to watch for cars that "look or act strange," but I received feedback telling me players had a hard time finding criminals. There are three types: loiterers, who drive at half speed and won't leave through exits (they just sit there, blocking the exits); speeders, who travel at double speed; and smugglers, who travel at 75% speed. Each one has a small particle effect attached to the car that gives them away, but they are very subtle. Speeders and loiterers are the easiest to spot by far, since their speed is very easy to discern. If I revisited this game I would definitely adjust this to make it easier.

Funny story: almost the last major decision I made was how the map was going to be laid out. I knew the cars had to travel from point A to point B for the concept to work but I was never sure whether it should be in one multi-lane highway; a sort of cross where they spawned at the edges and traveled to the center; or just a big old grab-bag of cars coming from and going to anywhere. In the end I just picked the simplest one (unidirectional highway with no lanes) and I think this was the correct choice. The other layouts would have made the map too big to keep track of easily.

Post-Jam

This was my first game jam, so I wasn't sure what to expect from the voting process. The Major Jam has no prizes, so the voting period is just 7 days of playing other peoples' games and rating them on a scale of 1-5 in four categories: Enjoyment, Presentation, Use of Limitation, and Concept. I played and rated about a dozen other games, and it was pretty cool seeing other people's interpretations of the theme and limitation. I also actually felt pretty good about my game after seeing others: though P&S is far from perfect, I felt I managed to get it into a pretty polished state, and I didn't feel like the limitation was tacked onto it.

That being said, the fact that I didn't upload a playable-in-browser version of P&S probably hurt its chances. Having to download, unzip, and run a file is a lot more of a pain than loading a webpage and clicking a button. Also, my submission page and the screenshots I chose weren't great. This is a game that's hard to really communicate in static images, so I should have recorded a short video of gameplay instead to entice people to try it.

In the end I got 5 ratings on my project, which was mildly disappointing but not too bad. I got mostly 3's and 4's, and placed 44th overall out of 149 submissions, so I'm in the top third! Not fantastic, but definitely not bad. In the end I'm just happy I finished and submitted a project that I'm proud of and didn't completely crash and burn.

What I learned

• I thought a 7-day jam was going to be easier than a 48 or 72 hour jam, and perhaps it was in some areas, but the prolonged stress and pressure was a lot worse than I was expecting. I spent probably 30-40 hours developing P&S over that week and was on the verge of burning out by the end. A shorter jam gives you less time to think and test, yes, but it's also a quicker burn and you're over and done with the project sooner.
  
  
• I'm glad I scrapped my original idea and went with my second or third idea. Although I think there's merit to the idea of a game about an imposter cultist, I couldn't make it work in the time frame and I'm glad I didn't try to force it.
  
  
• Your game jam idea is over-scoped. I knew beforehand how tiny game jam games are, and went into it thinking I would finish my game in 3-4 days and spend the rest of the time adding extra features. In the end I left about half of my original concept on the cutting room floor and still barely finished in time.
  
  
• It was such a relief knowing I wouldn't have to support my game longer than 7 days. Fading Light burned me out and I was getting sick of maintaining and remembering my way around huge systems that were months old, and constantly thinking of extensibility. A tiny, throwaway project like this was the perfect palette cleanser.
   
• Though primitive, my pathfinding system taught me a lot! I wouldn't use this exact system again, but it gave me a good opportunity to think through how I might do such a thing in the future. Before this game I had pretty much no idea on where to even start doing driving AI or pathfinding. 

Anyway, that's it for now. I had a lot of fun doing this jam, and I think I will do more jams in the future, but not for a little while. If you want to play Protect & Serve it's up for free download on my itch.io page; it's kind of a weird mix of classic Grand Theft Auto and Papers, Please. I may come back to it and update or expand it in the future, but currently have no plans to. Let me know what you think; I love to hear criticism about my games!

Fading Light Devlog 3: Cutting Room Floor

Activated Abilities

One of my personal least-favorite things about the tower defense genre is that it's usually about a minute of gameplay (choosing which towers to build where) followed by however long of just watching the game play itself as your towers attack the creeps walking down the path. Trying to avert this pitfall was one of my main goals with Fading Light, since reversing the roles doesn't automatically fix the problem. I knew I wanted Fading Light to always be a game that you actively played rather than set up and watched. Therefore, the spells you cast were always going to be in the game to some degree, though it took some thinking and iterating before I landed on which ones belonged where.

However, an idea recently occurred to me while brainstorming new creep ideas: add one-use abilities to creeps, activated by clicking on them (while not aiming an ability). Such as clicking on a fairy to cause them to phase shift for a second or two, letting them pass through bullets and pickups without triggering them. I started prototyping this and realized it would, however, be opening up a huge can of worms for the game. This example ability would require me to:

• Code the ability's core functionality (click on fairy; fairy becomes phase shifted; fairy returns to normal). This is something totally new that doesn't exist in the game yet, so it would require some experimentation or rejiggering of existing code to enable.
• Add some sort of cooldown or charge system so that you can't just spam-click your fairies for permanent invulnerability. This already exists in Fading Light for the spells you cast from the UI but it doesn't exist in the context of being bound to units, so it would essentially be an entirely new system.
• Add visual feedback. The easiest part of this would be implementing the graphics; the far harder and more time-consuming part is deciding how it should look. Not just so it looks nice aesthetically, but also so that it communicates whether the ability is ready to use, currently active, or on cooldown/out of charges. If it has more than one charge, or combines charges and cooldown, these also need to be differentiated.
• Add some tutorial or introduction to the concept of clicking on units to activate abilities. This is a brand new mechanic to Fading Light, and potentially one massively important to succeeding, so the player needs to know how to work it.

Additionally, there's the expectation -- whether self-imposed or from the player -- that this type of mechanic would be expanded to more than one unit. A system like that would feel wasted on only one creep, since each creep type is meant to be specialized or used in certain situations. This means the process would have to be repeated a few times; not necessarily for every creep type, but for enough that it feels like a core mechanic of the game. Not only does this massively increase the work I would have to do, but it also massively increases the complexity of the game, both under the hood and from the user's perspective.

I don't mean to make this sound like a herculean task, or like something that shouldn't be done. Rather, I lay this out to explain why I think it just isn't worth it to implement right now. I think if the system was done well it could enrich the game, but it's the sort of major gameplay overhaul that may necessitate a total rethink of level design or some other core system. And, though it's par for the course in game dev to spend lots of time and energy on features you end up cutting, I'm not confident enough in this feature's healthiness for the game to want to take that risk.

The risk that I foresee is that, by adding activated abilities to most creep types, the cognitive load on the player is increased to a point that doesn't fit the game. I'm not saying most players can't handle it, I'm just saying it would befit a game with more content that players get more invested in than a free tower defense on itch that an amateur made in his spare time in under a year. People are willing to master games like League of Legends, but less willing to master some random person's personal indie project. It happens for sure, but I fear a lot of people will play the game, see that it requires more investment than they are willing to give, and then stop playing sooner than they would otherwise.

Maybe I'm overthinking things, but in short, I think this feature is better saved for a future project. I still think it's valuable to discuss things like this because game dev is full of hard decisions and big challenges, and it's a critically important skill to know which battles are worth fighting.