On Sticking With It

I’m back to working on Adventure Delivery Service after working on a different project for a couple of weeks. Here are some of my thoughts as I’ve struggled to figure out whether to continue working on the project.

One of the great things about doing solo dev is that you’re not stuck to any particular plan or schedule. I can wake up in the morning and work on what I feel like working on. If I want to prototype some new mechanic, or model a new enemy, or make a new sound effect, I can do that without having to run it by a producer or triage it against a task list. That sense of adventure, possibility, and productivity is one of the reasons I decided to do a solo dev project.

For the past couple of weeks I felt pretty strongly that ADS wasn’t what I wanted to be working on, so I put together a prototype of another game that had been floating in my head for a while, which was a MOBA-style capture the flag game in the browser. I learned a lot about WebSockets, TypeScript, and NGINX, and I’m pretty proud that I was able build a playable multiplayer game and deploy it to the web.

In the meantime I had a chance to reflect on ADS, and my mental and emotional relationship to the project. And I decided that while taking a break for a couple of weeks was a perfectly healthy way to clear my head and gain some perspective, the best thing for me to do now is stick with ADS, even though the honeymoon phase is over.

Over the course of developing ADS so far, the direction and scope of the project has changed a lot. It was originally going to be a multiplayer, open-world, procedural, open-ended ARPG. Now it’s a single player, much more linear, roguelite procedural death labyrinth. I’ve ended up prototyping and then cutting more features than I’ve kept. I’ve spent a lot of time dealing with leftover complexity from features that aren’t important anymore, and refactoring code after underlying assumptions about the direction of the game changed.

So progress has been slower than I hoped it would be. My expectation for how much longer this thing will take to finish has been growing and growing.

One of the things you hear over and over about game development is that success stories are almost always preceded by many failed attempts. I only have so much runway, and I had been planning to make several attempts at success before my runway ran out, so that I could learn from failure and then do better. When I realized that this was going to take a lot longer than I thought, I started seriously thinking about starting a new, smaller-scoped project instead.

I have a philosophical belief that indie games should cut corners wherever possible in order to focus on the core differentiating aspects of the game. The advantage an indie studio has over a better-funded team is that it’s able to take risks other projects aren’t willing to. In order to succeed, you don’t want to compete on traditional metrics of quality like graphics. Instead, you want to give the player an experience they’ve never had before.

At the same time, I have a practical, cynical belief that traditional polish on things like graphics is what sells games—even a savvy indie customer will form an immutable opinion of a game based on the first few seconds of gameplay that they see.

On ADS, I found myself not living up to my indie philosophy. The gameplay was shaping up to be a lot like existing roguelites. A lot of the reason my projected timeline was expanding was because I was spending time on traditional presentational polish. Was I failing to adhere to my motivation for making an indie game in the first place? What if I quit ADS and instead made a game that was intentionally super lo-fi—I would be able to cut a lot more corners, avoid a lot of this extra work, and ship a finished product way faster.

There’s no easy answer to this question of balance between core gameplay innovation and presentational polish, given limited time and budget. Getting people to notice your game is impossibly difficult. The internet is full of people working on indie projects, and a person only has enough attention for a couple of them. To be honest, if I were someone else and saw my game right now I probably wouldn’t be that interested in it.

It’s incredible the weight a single piece of feedback can have on your opinion of the game. A suggestion about aesthetic direction can result in a total change of course. A piece of negative feedback can make you question entire mechanics and systems. Even positive feedback can make you wonder if the person just didn’t see enough potential in your game to give you real criticism. And a single tweet that doesn’t get any likes can make you wonder if anyone will ever care about your project.

I found myself comparing my project to whatever indie games were getting the most press or retweets on a particular day. Comparing your own partly-finished thing to someone else’s finished, polished thing is a great way to convince yourself that you’re on the wrong track.

In order to make the game worth playing, you need to be open to critical feedback. In fact, the more critical the feedback the more useful it is. You need to be open to criticism without becoming defensive in order to understand the project’s flaws and figure out how to fix them, while also maintaining a healthy distance from the criticism so that it doesn’t impact your morale. You have to understand that you are not your project; your project’s flaws aren’t your flaws.

All these factors together—the realization that this first project was going to take too much runway, feeling like this project was too conventional and would never be really notable, that the best course of action might be to abandon ADS and work on something else, meaning months of work would have been a waste—became too stressful for me. At the worst I was having minor panic attacks and nights of no sleep.

So I think it was good that I took a couple weeks off of ADS to work on something else. In retrospect, maybe that was my way of transitioning from the early, eager stages of the development cycle into the mundane grind of finishing a thing.

I’m incredibly grateful to my friends and acquaintances who have taken the time to show interest in ADS, played early builds and given me feedback, and shared their own experiences making games. Many have gone through a similar experience of becoming disillusioned with their project partway through. It’s an open question whether the lost excitement from the sheen of a brand new project ever gets replaced with confident satisfaction that you’ve done a good job. It may be that once you feel underwater you’re just going to be swimming until the thing is done.

The sources of comfort I have now are:

  • The trough of despair is normal. It doesn’t mean I’m doing anything wrong, or that I should stop working on the project.
  • Every day I work on the project it gets a little better. If I keep making it a little better every day, after a lot of days it will be a lot better.
  • I may never have a better shot at finishing an indie game. Whether or not this thing ends up being a “good” game, it will be a reflection of my work at this time and place, and as such it will have value.

This has been a learning experience, but not in the ways I thought it was going to be. I guess, what’s the point of a learning experience if it only teaches you what you thought it would?

New Project

About two weeks ago, I put Adventure Delivery Service on hold and started work on a new project. I’m very proud of the work I’ve done on ADS and I’m not thinking of it as cancelled right now, but for a variety of reasons I decided it was better to work on other things for a little bit.

The new project is called (tentatively) Team Flag, and it’s live at http://teamflag.io. In a nutshell, it’s something like Fat Princess in the browser—a multiplayer capture the flag MOBA with simple gameplay that’s easy to drop in and play.

It’s using Fleck for WebSockets, Nancy for web logic, Linode for hosting, BEPU for collision detection, with TypeScript and Phaser.js on the client side.

Cars and Fire Hydrants

Today I modeled a car and a fire hydrant. The streetlight I had modeled already but today I added code to place it in the world.

I realized I don’t really know how streetlights get placed in the real world. I need to take a walk around the neighborhood and figure that out.

I tried to prevent cars from parking in front of fire hydrants, or parking too close to the intersections. There’s a longstanding bug where stop signs just get placed wherever there’s a corner, which is fine at 4-way intersections but it doesn’t look right at T intersections.

I think at some point I’ll add parking meters. I have this idea that some streets are going to be bigger than others and maybe have extra features like four lanes and stoplights instead of stop signs. Maybe I’ll put the parking meters on those streets. Then I’ll have to change how the cars get placed — right now they pick a random legal position on the side of the road, but if there are meters I’ll have to place the meters first at regular intervals and then place cars aligned with the meters.

I’d really like some annoying street signs like “2 hour parking 7am-2pm M-F except holidays.” Street names on the stop signs would be cool too. This is all kind of a distraction from working on gameplay but I think it’s probably important to make the environment fun just to be in.


Weekly Video #2

This is the second week in a row I’ve uploaded a gameplay video. Let’s see if I can make this a weekly thing.

Some of the changes since last week:

  • Moodier lighting in dungeons.
  • New models for dungeon floors and walls.
  • Added torches to dungeons.
  • Dungeon rooms and hallways get wiggled a little bit so they don’t line up right on a grid.
  • When the player is in a dungeon room, the camera keeps the room in frame.
  • Removed stamina and weapon durability.
  • The player can only hold two weapons instead of four.
  • Elemental effects aren’t tied to a particular weapon anymore — you pick up items that give your weapons those effects.
  • Added pickups that boost player stats.
  • There’s only one kind of grenade (removed fire grenade and proximity grenade).
  • You can only hold one consumable item at a time.
  • Roads and sidewalks are wider.
  • One block in the city is a park with a fountain.
  • Changed controls (see below).
  • Removed a lot of custom physics code, using more Unity physics now instead.
  • Performance improvements.


Some of things I’m thinking of working on next:

Force the player to fight the enemies in the overworld. I’m thinking there could be blockers in the street that wouldn’t go away until you defeat all the enemies on that block. That would work kind of similarly to how the dungeons work. At the moment it’s way too easy to just run past all the enemies in the overworld.

Add parked cars to the streets. Maybe make some streets wider than others, and give them a solid yellow line instead of dotted. Maybe give them traffic lights at intersections instead of stop signs.

Add more consumable items. Right now the only consumable is a health potion. I’m thinking temporary effects could be cool, like invincibility, super speed, super damage, etc. Consumables could also be spells / special attacks.

Figure out the shop situation. Right now a bunch of the buildings in the city are shops, which means they have NPCs in them that will sell you health potions. I don’t really like how open-ended that is, I don’t want the player thinking they need to go into every single building in the city in order to play optimally. So I need to think about that. I also need to figure out what items get sold in the shops, and what makes them different from items that get dropped or are found in chests.

And of course eventually I need to keep making more content. I want to try more enemy designs, like enemies that have projectile attacks, stationary enemies like turrets, enemies whose movement patterns are unrelated to what the player does, enemies that don’t have attacks but just deal damage on collision. Also more variation in interior spaces, so like rooms that have lava pits, or sculptures, more miscellaneous junk lying around, different tiles for the floor and walls, different lighting fixtures, better layout for houses and shops, etc., etc.

Dungeon Lighting

Today I did some work on lighting. I added a system that keeps track of whether you’re outside, or in a building, or in a dungeon, and then changes things like light color, intensity, and position to create the right mood. I added torch models with point lights on top, which give a little more lighting to the scene. I had to turn down the shadow resolution to Unity’s lowest setting in order to keep performance reasonable on my laptop. According to Fraps I’m getting about 45 FPS at 720p.

I got rid of the custom physics stuff I had written, so now I’m using Unity physics to handle movement, collision resolution, raycasting, etc. The main reason for that was performance. I liked having control over everything. For example I still need to figure out what I’m going to do about pausing physics when the game is paused. I’m losing some control by using Unity physics, but the performance has improved so I guess I’m sticking with it.

Right now I’m using a ton of little cubes, one for each cell on the map that’s blocked. I have a feeling that might be a performance problem, and I might need to do some smart stuff with joining adjacent blocked cells together into a single physics collider. For now I’m not going to worry about it too much though.

dungeon lighting

Gameplay Video

This is from the build I’m submitting to the Seattle Indies Expo.

A few of the major changes since the last video:

  • Revamped overarching game structure: you always have a single delivery assignment to complete, instead of exploring the world and collecting quests.
  • No more menu diving to equip items.
  • Sound effects.
  • Improved visual polish.

There have also been a ton of smaller tweaks.

Plus some new screenshots!

six sc 1

six sc 2

logo 300

Goodbye Toon Shading

Today I put some work into visual polish.

First I turned off the toon shader and added a little smoothness to everything to get a hint of glossiness.

I added a fill light in addition to the directional light and ambient lighting. It’s a wide-angle spot light that hovers above the player, so it gives a similar effect as putting a vignette on the camera. It turns out it was a little tricky figure out exactly where to put it and how bright to make it because of how building go up toward it. You don’t want the buildings to be super bright, but you also don’t want the fill light to be under the buildings’ height so the tops of the buildings are filled at all.

Now there are three lighting colors to play with: ambient, directional, fill. The ambient color is sky blue, directional is lime green, and fill is peach.

Finally I added screen space ambient obscurance and a little depth of field to the camera. I’m not sure how obscurance is different than occlusion but Unity’s manual page said it’s newer, better, and maybe faster, so I’m running with it.