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.

Fading Light Devlog 2: Public Launch!

Hey there! It's been longer than intended since my last update, primarily because of non-dev related stuff.  I'm now fully vaccinated against Covid-19 and since in my neck of the woods the vaccination rate is quite high I've been meeting up with friends and going outside and things like that.  My development pace has thus been a bit more leisurely than usual (although I'm pleased to report I never had a zero day) and writing fell by the wayside. But I hope to be more frequent and regular from here on out.

Anyway! Onto the game. The newest build (#3) is publicly available on my itch.io page, totally free, so give it a try and let me know what you think!

Fading Light Devlog 1

Welcome to my current project, my second game, named Fading Light. I started working on Fading Light in November, roughly around the time I finished Containment Breach and it's now in a playable state, if an unfinished one. A lot of the names and terms are subject to change, including the name of the game itself. You can download and test out an early pre-release build (PC only, for now) from my Google Drive here. If you do test it out, let me know what you think! It's still incomplete in many ways but it is fully playable on its one map. I would also be happy to hear any suggestions, ideas, or bug reports you might have.

Fading Light is a reverse tower defense: you customize waves of units and the path they follow through the gauntlet of towers that the AI builds every round. Gameplay is split into distinct phases, during which you either prepare your wave by buying units, upgrades, and abilities, or you cast spells to assist them as they travel.

The idea has been floating around in my head for years, with the theme inspired by my recent games. I didn't want to make another sci-fi game in a row, so Fading Light is a fantasy game. Furthermore, it keeps with the theme of playing as the "monster," which also feeds into the reversal of the typical tower defense formula, by having the player's units be themed around fey and druids. The enemy towers are currently stone structures that could be of human make, though I'm interested in doing an art pass later on to add some flair and personality to them. The concept started life as a sort of fantasy solarpunk world with an ecological message, and though this may emerge later as I add polish, this idea is currently all in my head.

Development so far

The first thing I did was port over and rework my code from CB that handled target acquisition, bullet firing, and destructible units. I also started with the enemy patrol code and refactored it into a path-following script pretty quickly. Within a day or two I had units moving through the path and towers shooting at them, but to make it a game with interactivity I needed to start writing brand new code.

Right from the start I knew there were a few systems in Unity I wanted to learn how to use: Scriptable Objects and the Observer Pattern. So I set about researching these topics and implementing them as I went. In a nutshell:

• Scriptable Objects are lightweight containers that hold data which you define once in the Unity editor and then can read later at runtime. They're handy for defining things like different types of units, weapons, power ups, terrains, etc. You have a generic base prefab that reads the data off the Scriptable Object and customizes itself based on what it finds. This saves time and space by reducing the need for totally separate prefabs for every different enemy type, for instance. It also makes IDing objects easy: just compare which Scriptable Object they're reading from.
  
  
• I mentioned the Observer Pattern in my Containment Breach Postmortem. It allows you to write very self-contained and disentangled code by having objects called publishers fire off events that other objects called subscribers react to independently. Publishers don't keep track of or care about who subscribes to them, they fire the event regardless without needing references to the myriad of objects subscribing to them. You can think of an event like launching a flare into the sky: any observer can see it, what color it is, and where it is, but the launcher doesn't need to specifically notify any one observer to shoot the flare. It just does it and forgets about it.

I use these two systems all over the place in Fading Light, both because I'm deliberately practicing using them and because they are genuinely so, so useful. My code is still far from perfect but right from the get-go it was so much easier to expand and refactor scripts compared to CB. The code is just easier to read, write, and understand, especially a few weeks or months down the line if I need to refactor something. In coding your past self is usually your own worst enemy and you need all the help you can get figuring out what the heck you were thinking two months ago or whatever.

It was clear from the outset that Fading Light was going to require a much more extensive user interface than CB did, particularly during the Planning Phase when you are buying things from a shop and arranging them in a specific order. Unity's UI objects aren't complicated but everything about them works slightly differently than manipulating GameObjects in world space, which took me some getting used to. But once I got over the hump I found it surprisingly easy, if a bit tedious, to put arrange and hook up all the buttons, text fields, icons and slots, etc. Implementing drag-and-drop was a pain, and it's a system I'm still unhappy with so I'm dreading having to inevitably go back and refactor it to allow for dragging units from slot-to-slot (instead of having you sell and rebuy them to move them). But it works for now and has a decent enough if imperfect user experience so I moved on.

Currently, there is one static map that you can play on, but in the future I'd like to add procedural map generation to Fading Light. Likely this will take a very restricted form, but it should add some replayability and variance to the game. Failing that it will contain probably 10-20 handcrafted levels by the time it's finished, or perhaps some combination of the two. I will go into more detail on how this works in later devlogs as I'd like to chronicle my proc gen journey as I undertake it.

Coding the AI for Fading Light has also been an adventure. CB barely had any; enemies would patrol along their route or rotate in place until they spotted the player, then stop, pivot towards them, and shoot in a straight line. Truth be told, Fading Light's isn't that much more complex, but it's very different. Towers are easy: if they lack a target, they search for all units within their weapon's range and line of sight, then pick the closest one as their target until their line of sight to it is blocked. They shoot at their current target until they run out of ammo, at which point they lose their target and begin regenerating ammo. However, determining where towers get built took a bit of headscratching and iterating upon. The approach I've gone with is still somewhat naive, but it works okay.

How it works is that each round, the AI gets a budget of points. It then figures out what tower types it can afford with its current points and picks a random one from those. Then it looks at every unoccupied tower slot on the map and awards it a score equal to how many path segments are within line of sight and within the tower's weapon range or area of effect. Path segments that units have walked on in the last 3 rounds are weighted more heavily, and tower slots near other towers of the same type are considered less favorable (Frostbite Towers will almost never be built such that they overlap, because their auras don't stack). It then builds the tower on the slot with the highest score and repeats this process until it can't afford any more towers this round. Its budget increases slightly each round (affected by what difficulty is selected) and unspent points carry over, creating a little bit of variance from round to round. The only other limitation is that the AI knows which towers deal damage and which don't (currently only the Frostbite Tower), and it needs to have towers that deal damage on the map before it will consider building non-damaging ones. Otherwise you could get a map full of slowing Frostbite Towers and nothing that can actually destroy your creeps!

In the future I may look into deepening the building AI somewhat, for instance by telling the AI which towers synergize well and allowing it to build "bundles" of towers. However, not only is this more work, but I'm not sure it's even needed. The point of AI in a video game, after all, is not to actually win as often as possible, but rather to present interesting gameplay to the player. Some genius could code an AI that's brutally smart and beats almost every human it fights, but aside from people who specifically enjoy conquering very difficult opponents that will probably turn off the majority of players from the game.

Going Forward

I want to emphasize right now that Fading Light is not my "dream game," nor is it my forever project. I have a few big updates I want to give it before I shelve it and move on to other long-term projects and I fully intend to complete the game to my satisfaction, but this won't develop into a $20 Steam release or anything. I may charge $2-3 for it on itch.io when it's done, but for now it's purely a hobby project.

That being said, here is my high-level To-Do List, itemized in no particular order:

• Add a map generator. This will be the subject of at least one devlog by itself, I imagine. I've done some research into procedural generation and although it is easier than I feared it's still something entirely new to me and will take a lot of work to get running. But if I can pull it off I think being able to press a button and get a new, unique map to play on will really boost the longevity and depth of the game. I expect this to be the biggest item on this list.
  
  
• Add a story. Not so much with characters and dialogue, because I don't think this genre lends itself well to that. But more environmental storytelling that really sells the idea of invading humans destroying this magical forest and its denizens carrying out a last-ditch escape. I don't expect that I'll be able to work on this much until the map generator (and/or set of handcrafted levels) is done, since I won't know what maps will look like until then.
  
  
• Add more content generally, referring mainly to types of creeps, modifiers, abilities, towers, and pickups. The game's skeleton is basically done, I just think it could do with a bit of fleshing out. I have to be careful not to go overboard with this, however. I wouldn't want to drown the player with too much choice or complexity, nor would I want to burn out trying to wrack my brain for 50 different creep types that are all unique, interesting, and balanced.
  
  
• Do an art pass. This means looking at all the art I've made and touching it up. Adding animations to things that lack them; making the map look less monotonous and boring; making the towers more obviously distinct from one another, and so forth. I intend to add a cool background to the main menu and post-game screens, and maybe spruce up the UI with some vines and leaves. Art really does make your game "pop," both on a website and in players' memory, and having ugly or dissonant art will make a lot of people pass on your game even if they might really enjoy the gameplay or story. I don't think Fading Light's art is terrible right now, it just needs a bit more love.

Anyway, that's it for now; I'll see you in the next one. Thanks for reading, and if you play it, thanks for playing!

No Zero Days

There's no one easy trick to being successful in a creative endeavor like game dev. But one thing I strongly believe is that doing work and having finished projects is incalculably better than not doing work and not finishing anything. Even if all your work is terrible, you're still light-years ahead of all the people who say they're going to make things and never do.

So the first step to success is to just sit down and make something. This is much easier said than done, though; believe me, I have more abandoned projects sitting in forgotten folders than I could count. I'm sure the same is true for everyone who makes art (or anything, really). Starting things is easy, of course; you're enthusiastic and motivated for your project in the beginning. But after a while things get hard -- or you just get to the boring parts -- and you slow down. How, then, do you stay motivated and power through when the creative process feels more like a slog?

My personal solution to this problem is a principle that I think of as "No Zero Days." All it means is that, every day, I have to do at least one thing on my game. It doesn't have to be at a specific time or on a certain topic. It doesn't even have to be a big thing. I've had my share of personal struggles during the Covid-19 pandemic, as I'm sure you have as well, and some days I couldn't muster the will to do more than draw a box on a tilemap. Some days I resolve to fix only one bug; animate one frame of a sprite; or hook up the components to one GameObject. On better days I do much more, of course; on average I spend probably an hour or two on my game per day. But when I'm busy with other things, or stressed out, or depressed, I push myself to sit down, open the project, and do just one thing, no matter how small.

The reason why this matters is that it preserves your momentum on the project and it keeps the project fresh in your mind. If you let yourself slack off and miss a day it becomes exponentially easier to skip each subsequent day. Cruelly, falling off the wagon tends to be easier than getting on it in the first place; so stay on as long as you can. Plus, once you look back on the small, incremental progress you've made over the last, say, month you can really feel good about what you've done. It all adds up surprisingly fast, even if you only do a bit at a time.

You can apply this to any medium. I'm beginning to apply this principle to writing this blog: right now I have a personal goal of writing 100 words per day (about a paragraph). This is deliberately a nice, low bar so that when writing feels like squeezing blood from a stone I can still accomplish a little bit, but when I feel inspired I can crank out many times that in a single sitting and feel extra good about it.

Of course, there are some limitations to this approach. It works best for hobbies that one does by themself. If you have deadlines, for instance at a job or for a contract, this strategy falls apart somewhat. Likewise, if you're collaborating with other people who might rely upon your work being done before they can do theirs properly, you may run into problems with some people outpacing others and getting frustrated.

I should emphasize that I did not invent this; I learned it from other creators and adapted it to my own situation. Yahtzee Croshaw of Zero Punctuation fame writes novels on the side and has a personal rule of writing 1 page a day. In his case, he also limits himself to 1 page a day so as to avoid burnout. He describes this in his Dev Diary series here. I've also watched dev logs on YouTube and read advice from artists and game devs on reddit and elsewhere that describe a similar strategy.

So if you, reader, are putting off making a game, writing that novel, learning to draw, or whatever, I urge you to simply start. Write a single line. Make a rough sketch. Code a box to move across the screen when you press keys. Take your first baby steps, then tomorrow take a few more baby steps. Don't worry if you look at what you've made and hate it; if it completely sucks, you can always remake it later. And don't sell yourself short; art is hard, and finishing things is hard. Don't call yourself an "aspiring game dev" or an "aspiring writer" or whatever; if you write, you are a writer. You might not be a professional writer, but that's nothing shameful. The more you make, the easier it gets to keep at it and stay on the wagon.

Post-Mortem: Containment Breach

 The first game I published was a little 2D top-down stealth puzzler I called Containment Breach. You can download and play it 100% for free from my itch.io page. CB was a huge step-up in complexity and quality from my first foray into Unity and as a result I learned a lot from the experience and expanded my boundaries quite a bit.

I expect the first two sections of this write-up to be more general design and conceptual stuff whereas the final two sections will deal more with the technical side of things. My goal is that this entire post is accessible to you regardless of your coding knowledge but if you're violently allergic to computer jargon you might want to check out after we get to the Nuts & Bolts section.

 

This article will spoil much of the game, so if you want to experience it the way I intended I recommend playing it before reading. The game takes new players about 30 minutes to complete.

 

 

Introduction

 Hello! My name is Timothy and I’m a hobbyist game developer. In this blog I’ll be writing about my journey and process making indie games, as well as talking about game design in general and examining specific games that interest me. 

My aim is for my writing format to be accessible to you if you are not a game developer or enthusiast, 

My Game Dev Journey

I’ve been interested in game design for as long as I can recall; when I was a kid I remember drawing scenes from imaginary games I wanted to make on paper with pencil. I got started actually putting functional prototypes together when I was around 11 or 12 when I started learning the WarCraft 3 map editor. After several years of making custom maps for me and my internet friends to play together, I took a lengthy hiatus and focused mainly on tabletop RPGs. During this time I became obsessed with Dungeons & Dragons as well as indie RPGs like Fiasco and Microscope. Although I did develop a few systems of my own, I was never happy enough with any of them to call them finished.

It was only during the COVID-19 pandemic that I finally returned to video game development. I had bounced off of the Unity game engine once or twice in the past, having found it labyrinthine and intimidating, but with nothing but time on my hands due to quarantine I followed some tutorials on YouTube, dusted off my Computer Science education from college, and got to work.

Heeding the advice of pretty much every game dev out there, I started very small. My first project was a side-scrolling shoot-em-up that never got a name. It had one type of enemy, one type of healing pickup, and a boss that was just a bigger, faster version of the normal enemies. It had no AI beyond the enemies bouncing from one end of the screen to the other, shooting blindly once per second. It had no audio of any kind and could be beaten in about 2 or 3 minutes. But most importantly, it was a completed project under my belt and, for my first non-mod game project, I was even proud of it.

With that all-important first hurdle conquered, I was hooked. I dove into a more ambitious project which I eventually finished and published on itch.io under the title Containment Breach. I will be writing a post-mortem of Containment Breach as one of my first few posts on this blog, because I have a lot to say about it and the things I learned while making it. It’s free to download, so give it a shot and tell me what you think!

The main function of this blog is to keep me motivated and to chart my progress, both for myself and for anyone who is interested. I hope you enjoy reading my ramblings as much as I enjoy making and talking about games. See you ’round!