Estimating Game Development

2024-07-23

The game eXoSpace that I am developing is supposed to be in a fully playable form (either early access or full release) in Q1 2025. That is still quite some time away, but it does not feel like that at all. There's SO MUCH to do and so little time to do it all. So how do I estimate how long features take, and how do I plan the development work on eXoSpace?

First a totally unrelated but cool shot of the new missile bursts:

Being a one-man development team makes some things harder, but estimating and planning is not one of them. Having almost two decades of experience as a software engineer, and some as a team lead and project manager, helps a lot. So, being an experienced solo developer means planning is easy and predictable, right?

Not really.

Things NEVER Go According to Plan

Any time I make a plan and start working on it, things go entirely differently. Some things take much less time (like, 99% less) than planned, often things pop up such as bugs that take a long time to fix, and usually, I work on features in an entirely different order than planned.

"No plan survives contact with the enemy."

(Actually, Helmuth von Moltke said, "No plan of operations extends with certainty beyond the first encounter with the enemy's main strength," in another language, and probably not like that, but you get the point. Or not.)

But that is the reality of software development we live in. That is, if you do not make easily repeatable products in mass production, I bet estimation and planning are quite doable then. But for new, complex, creative work, you should not expect reality to correspond to plans.

So, Are Plans Worthless?

This may make you think that planning is not needed or a waste of time. I strongly disagree with that; I think planning is critically important. Just do not expect reality to conform to your plans. And plan accordingly.

Without a plan, it is difficult to build a piece of software in a "straight line" to where you want to end up. You may end up wasting a lot of time on features that do not add anything that players may want. Or you may end up developing a great game engine, but not a game.

Planning for Focus and Flexibility

So how do I plan for eXoSpace? My totally scientific and empirically proven method is as follows:

• Write down a list of "milestones" where each milestone is a key feature for the product. Each milestone gets a title and around 10 bullet points detailing it. Milestones are what’s needed to get the minimum sellable product done.
• Create an "Ideas" list of things that are awesome, nice, or whatever, but not needed for the minimum product. See this as the "parking lot" for great ideas. Really useful.
• Choose a milestone and move it to a "ToDo" list at the top of your planning document. Choose whatever you think is best to complete first, e.g., because the preconditions are complete, to have something to show for marketing, or just to bite a tough bullet if you are in the mood. There can be many reasons.
• Now work on the milestone in ToDo until it is complete.
• After completing a milestone, go through the list of milestones and update them (some may be accidentally completed, others no longer needed or must be adjusted).

That is it in a nutshell. I cut up the work into large chunks, detail them just a little bit (not too much!), work on it chunk by chunk, and clean up the planning after each chunk.

How to Achieve a Deadline

So how does this help me complete all eXoSpace features before Q1 2025? Well, first of all, it helps me keep focus. I have a set of tasks I can work on that is regularly updated. And that helps me keep track of progress: does this still look doable in the time available? That's about the best I can do, and honestly, the best I have ever seen anyone do in complex software engineering.

So, What Does It Look Like, Really?

Here's some example milestones:

• Milestone: SteamWorks Integration for Ship Designs, Achievements
  • Create a set of achievements
  • Add code for unlocking achievements
  • Steam overlay shows unlock message if needed
  • Later: publish ship design to the workshop with a single click?
• Milestone: Modding
  • All mods are forwards compatible. New releases should never break existing mods.
  • Add mods directory to root folder
  • Each mod becomes visible as a game mode when starting a new game
  • Save mod name with saved game
  • Show error for saved games when mod is not available (“mod X is missing”)
  • Load files from game_data, then overwrite with files from mod
  • Each mod is contained in a directory
  • Directory has a mod.json: description of mod, minimum game version required
  • Directory has a mod_icon.png
  • Instructions for publishing mods in Steam Workshop
  • Subscribe to mods in Steam Workshop, become available immediately

As you can see it is all brief, sometimes a bit inconsistent, but it works for me.

What I Am Working on Now

After completing a "metagame" milestone, I am currently working on polishing the entire game, adding small new features, to get the milestone of "1 hour of fun," where a new player has a good and fun experience playing the game and will not be bored for at least 1 hour.

What this has meant in practice for the last few days:

Day 1:

• Lots of bugfixing (I fix any bug I encounter right away)
• Some refactoring to keep development speed high
• Change: missiles choose targets in a cone ahead instead of entirely randomly. Much more fun as firing missiles in a specific direction helps.
• Increased max speed for the ships a bit, for more dynamic fights
• Added "miss" effect for projectiles that end life or get destroyed

Day 2:

• Added development tool to "lock" ship designs so players cannot screw them up accidentally.
• Finishing touches for saving and loading of games
• Small fixes: a time slowdown slider in a development tool for editing effects, bugfixes
• Wasted a lot of time trying to improve particle effect blending, but that did not work out (yet), so I stashed that

Day 3:

• Burst fire for missile launchers. Instead of continuously spamming there's more an element of choice now, making missiles more interesting to play with.
• Changed flamethrower-like plasma thrower into a shotgun-like weapon using a quick burst. It looks better and is more fun.
• Laser blaster fires in 3-shot bursts as well.
• As you may have guessed, I implemented a bursting feature for weapon designs.
• An upcoming waves indicator on the top of the screen when in combat
• Indicator for offscreen enemies (glowing dot on edge of screen)
• Ship library filters on design cost and available blueprints
• Close button added to part selection popup in ship editor
• Debris no longer collides with starbase, which caused players to get stuck temporarily
• Made part replacement (repair) cost metal
• Renamed pirate faction to "Shapeless"
• More bugfixes

Day 4

• Added victory / defeat screen on game end
• Added "day" counter in-game and in end screen
• Polished a bunch of smaller fixes made while creating the reveal trailer video, e.g., added a new song, some development tools for changing background and hiding the UI
• Some refactoring and bugfixing

As you can see, different days have wildly different output. Some days I am more clear-headed, some days I have more time to work than others. Sometimes the work is just much easier than it sounds, sometimes much harder.

Anyway, I should get back to developing now!