Let’s Pivot
Lessons in scope creep
I sat down to start working on this pirate game called Trade Winds in January of 2023. Even though I have been working on this game for almost a year I am starting over but not really. I am pivoting. I have been working with Unity’s tools for making games for three years and had not released a game until last week. (Wild Trails) In that time, I have come to follow two rules/lessons for finishing projects.
See the Bridge
See the bridge. Its a metaphor. I imagine projects like building a bridge over water. It would suck if you built half of the bridge and then realized that you do not have the materials to finish or that the bridge only works if it is anchored three feet to the right of where it currently is. Basically this rule means that you need to understand what needs to go into implementing every part of the game. If you intend to ship a game, you need to have every step roughly figured out. If you are thinking: “I’ll learn that when I get to it.” That’s okay but, you need to realize that you are still in the learning phase of your journey, not the ship-to-production building phase of your journey. Like I said, I started working with Unity around 3 years ago. Each project, and there have been many, I was confident I would ship as a working product. Most gamedev YouTube channels recommend you ship something bad before you attempt to make the real project. I think that is good advice but I have a hard time getting motivated to work on an example or a test project. You should also make sure that the bridge can even stretch to the other side. Which takes me to my next rule: Complete Pass Development.
Complete Pass Development
I am sure there is another name for this but in short: build a working game as fast as possible that implements your core game loop & embodies the spirit of the game. You have to make judgement calls on what should go in each of these, but I have three phases:
Core Game Loop- Can I beat the Game?
Feature Complete- Is there anything that a player should be able to do but can’t?
Polish- Quality of life and presentation
What is good about finishing the game’s core game loop before implementing everything is that you no longer have a moving target. It is much easier to extend or flesh-out a finished game. You should get a good idea of what systems you are still missing and how long it will take you to do phases two and three. Also, you should be able to realize if your game sucks earlier rather than later. No amount of polish is going to make a bad game good so, its important to realize if your core loop is fun or not. I have also recognized that it is much easier to redo work that I have already done. I find that taking a second pass at something won’t take as long as I thought and you can probably do it better and more simplified than you did the first time. For example my enemy NPC ships & the environment fall apart slightly differently than the player’s ship does. That is due to some different things I have done with the assets and a more simplified destruction algorithm.
The Pivot
What killed Lethal Options in 2022 was animation. I spent over 6 months working on this project but what really got me was the first person animations. I had spent the last month making 70+ custom animations for each of my five guns in the game. All 70 looked anywhere from passable, to awful, or straight up physically impossible. I was so uninterested in working on the game that by the time the calendar year came to an end, I was ready to do something else. I decided January would be a good launching point to set up a timeframe for my next game. When I started working on Trade Winds it was going to be an MMO. You would gather resources and then sail around in your ship to the different trade ports to sell your cargo based on a real time bidding system with real world economics to support it. Hence the name, Trade Winds. I worked on the basic sailing stuff, created a player that ran around, and then I started to implement the trading UI. I realized around May that this game was going to be insanely boring. It basically was a stock trading simulator… which already exists IRL! Aside from being economics 101, managing unique item identifiers & keeping track of giant player inventories in MongoDB got insanely complicated. As someone who does not do any of the art in his games, I was not leaning into any hard technical challenges where my programming and systems design could shine. So I pivoted.
Next I decided to do an extraction shooter. I love playing Hunt Showdown and I love shooters way more than MMOs so it made sense. From early May until yesterday I was working on Trade Winds 2.0. (This game needs a new name since it has nothing to do with Trading.. “Sea Dogs”?) I implemented ship and environment destruction. I created a giant crab boss enemy that drops all of the awesome loot. I have AI logic for enemy ships. The sailing is basically perfect. The water looks amazing & the sails on the ship flap in the wind. The crew all have animations. I have enemies on the islands that attack you- fully animated. What was not fully animated was the player. I had bought this animation asset pack on the Unity marketplace and it has a bunch of generic animations for humans like walking, running, swimming, etc. What it does not cover are the specific pirate guns I have in my game. I currently do some smoke and mirrors programming tricks to get the rifle to be held right and aim down the sights but there is no real way to reload this thing without a specific reload animation.
Animating shooters is extremely hard in my experience. They involve this super complex blend tree that only gets an order of magnitude more complicated each time you add a new weapon. Think about it. Holding the gun and aiming are technically two different animations unless you are always aiming like Fornite. Each of these also needs to take into account if the player is running or walking. Reloading has all of these same criteria and then on top of all of that, you need to block other systems via animation events to keep the player from switching weapons for example. So I started to animate this reload animation and I was not happy with the way it came out. It looked weird when I blended it with my character’s idle animation. So now do we make one of those? I ran through so many scenarios in my head before I just decided I cannot animate shooters. Realistically, I really need a full time artist/animator. I am good at most other things with Unity but the animation kills me. It stopped me from finishing Lethal Options and now I was seriously considering just never reloading in Trade Winds. I tried several different gimmicks to work around it but it all just seemed noticeably wrong. Your audience will not notice some things but a hand twisting the wrong way is such a hard thing to overlook.
So here I am, in mid September, and I am wondering how to keep moving forward. I decided this morning to drop third person combat altogether and just focus on the ships. The ships where my favorite part anyway and there are bound to be plenty of third person extraction shooters coming out over the next few years as Hunt and Escape from Tarkov are working proof of concepts of that genre. I am going to make a capture the flag game where you do so on boats. A few things clicked for me this morning that lead me to think this was a good idea. For one, my ship destruction is awesome and not even AAA games like Sea of Thieves or World of Warships are doing physically accurate ship destruction. That will be new and should stand on its own merits. Another thing that clicked for me: How to solve the crew members/players moving in local space on deck while the ship moves in global space on the ocean. That is a tricky problem because Unity studders if you are using character controller components on a player that is a child of a GameObject that is moving. I had the idea this morning to recreate the ship’s deck and characters somewhere else in global space but having it remain static as the duplicate moves. This will allow me to use Unity’s navigation API to move the characters on the duplicate ship deck and then just sync their local positions with the characters on the ship that is moving frame by frame. Cutting down the scope to just ships sailing rather than a whole 3rd person shooter + vehicles is going to cut my project scope in half. I can also lean more into the ship’s features like repairing it when it gets damaged and interacting with the steering wheel and the sails. The crew will look more alive now that they are not locked in space and I can give the ship more dynamic systems for the player to engage with that they will not have seen before in many games.