I’ve always loved seeing posts on development breakdown from other devs, as it helps me see realistic examples of how much work is needed to not just make, but also market, deal with community and all other aspects of releasing a game an indie game. So as we’re just releasing our first Steam game SimPocalypse I wanted to share a sum up of our development numbers.
Often as new developers we underestimate certain aspects of running a studio and developing a game, and then delays, crunch and poorly released games happen, that can break a studio. So seeing actual examples can help you evaluate development better, but also help you gauge your own productivity vs. other games. Are we doing something right, and what are we doing wrong that other studios seem to do more efficiently?
Some context about us:
We make our games in HTML5, without any framework/game engine - mainly because it was a more natural shift from our past experiences, to be able to reach certain niche markets, and also as we want to focus on a specific genre going forward, and working on our own set of tools/frameworks can help us reduce development time for future projects. This game was in the same niche as our previous web game, but our first Steam game.
Not related to code:
| Category | What |
|---|---|
| Team | 1 Programmer/Game Designer, 1 Junior programmer, 1 Business/Marketing/Designer person |
| Development tools | PhpStorm, Illustrator, PhotoShop, Gimp, AWS (web hosting), Electron (app packing) |
| Other tools | Google Drive, Trello, Game Analytics, + a ton other little tools for marketing etc. |
Development time:
1 person slowly started research + prototyping in November 2019, the rest of the team joined in May 2020, and it’s been mostly full focus on the game for all of us since (so roughly 12 months of full time work for a team of 3)
Some code/project stats:
| Category | What |
|---|---|
| Lines Of Code | JS (~25k logic/systems, ~20k UI handling + dynamic html, 4k constants data) , CSS (19k - a lot of spaghetti due to several UI reworks, and decent responsive support) + other libraries |
| Translations | ~2k keys, ~18k words in each of 18 languages |
| Files/assets | ~700, ~100mB unpacked |
| Game UI | Quite UI heavy - 13 major different features/screens, ~25 major popups (settings, load system, achievements…) |
| Game features | 100+ mostly unique research upgrades, 25+unique buildings, 10+ game events, 11 resources, combat/inventory system, simplified hex world conquering, automation features, tons of QoL, Supply/demand market, game has to support at least x10+ speeds |
Main Design/Coding challenges:
- A usable and complex, but performant UI
- most game systems have to run while on any screen (a lot of performance optimization required) as it’s also an idle game
- Game balance and onboarding due to interactions between many features
Time Breakdown (6,350 work hours)
| Category | What |
|---|---|
| Development | 2,000 hours |
| Research/Prototyping | 200 hours |
| QA | 710 hours |
| Art/UI | 690 hours |
| Marketing/PR | 720 hours |
| Marketing (preparation, contact gathering) | 400 hours |
| Specs/Game Design | 390 hours |
| Community/support | 150 hours |
| Meetings | 435 hours |
| Team onboarding | 150 hours |
| App deployment/workflow preparation | 200 hours |
| APIs | 170 hours |
| Business | 135 hours |
Some further breakdown that can be easily forgotten about in estimations but adds up quickly:
- Preparing a translation system + managing & updating crowd translations for 13 languages: 100 hours
- Implementing Settings/Hotkeys/QoL: 200 hours
- Deployment workflow + updates on Web and Steam: 200 hours
- SteamworksSDK (getting greenworksSDK to work, achievements, Overlay, Rich Presence…): 140 hours
Money Breakdown
| Category | What |
|---|---|
| Steam App | $100 |
| Tool Licenses | $800/y |
| Assets | $500 |
| Marketing tools | $400 (e-mails, Wix, keymailer...) |
| Ads | $2k + $3k planned up to launch and first 2 weeks after. Mostly we used reddit + google ads to boost our EA and release traffic, and to keep some consistent external traffic trickling in to keep Steam algorithms happy |
Some context to why some times are (big) as they are:
The project was initially to be deployed on the web platform Kongregate, and finished 7 months ago. But the platform stopped accepting new games, and we had to revise a good chunk of our design goals, and scrap/rework some aspects of the game, as we had to shift focus towards developing for steam. Along the way, we realized that our game mainly aimed at incremental/idle game players, would not be very marketable on Steam, and we had to do several mechanics, UI and design reworks to make the game more approachable to a wider Steam audience. We also wanted to utilize our web platform experience and decided to make a demo version, which we would deploy to several platforms, and were regularly updating it with UI/game changes to be a part of the full game.
We also had to learn how to prepare the game for desktop, prepare a deploy workflow for Steam AND web (as we had web demos), figure out how to get Steam API working on all systems.
We didn’t have a designer, and one of our team had to pick up the job and learn a lot of things on the way. We later also got some help, and again reworked our UI to a more modern and marketable one.
As our budget was running thin at several points (our game development is semi-financed and also do other contractual work), we were setting short release dates. We managed to postpone these several times as we knew our game wasn’t ready, but this caused us to re-prioritize our goals several times, which caused a bunch of lost efficiency, compared to if we knew from the get go that we could afford (and plan better) another 6-8 months of development to finish the game.
That, along with with some of the things out of the way, learnt and prepared for future projects, we could probably shed off 40% of our overall development time for such a project now.
TLDR: Main things to take away:
Having the whole team employed, and “forced to find them efficient work at non ideal times” in development cycle can result in less efficient time usage. I.e. Having our member who is best at marketing fill in with design, testing, or finding additional work for our junior programmer, because it helps move the development further, but is not ideal spend of their time, if we had a bigger budget/less pressured goal deadlines. This is why working with freelancers for certain aspects of development can be more efficient on the short term, while the company workflow is still maturing.
Do whatever you can to give yourself additional room/budget and not be forced into an unrealistic release date. Not only because of making a better a game, but also to be able to market it more efficiently and for longer, before release (crucial for Steam!)
Identify things that take a lot of time and aren’t really improving your gameplay directly, but are crucial for a good release and better player experience, and that you can use them in your next game: Game settings, 3rd party APIs, Achievements, Localization, Community handling, deployment workflow, robust save system, marketing/press/youtuber lists & plan...