Unfortunately, I've decided to halt development on Deadhold. I've put in a ticket to remove Deadhold from the Steam store, and the servers will remain live for 3 months.

We've let our community and players down, and this is clearly not what we had in mind when we started Deadhold four years ago. Thank you everyone for the enormous amount of support and trust you gave us these last 4 years, and for the vision we had, I'm sorry we let you down. :(

Why we're ceasing development of Deadhold

Plain and simple, we can't afford to continue development. The cost for ongoing development exceeds revenue (and has for some time). Sales were well below our grimmest projections for a worst case. While I'm proud of the work we did, and the team we built, it still remains that we dropped the ball on the business side badly.

This, in conjunction with scoping too large, with some idealistic thinking sprinkled in, has brought us to the current situation.

Post Mortem

So, what the hell happened? Below is a brief post mortem on the last 3-4 years of development and how we ended up at this point. I hope this will help our community understand the sorts of pitfalls we encountered, where we think we went wrong, and maybe help other developers avoid some of the same mistakes.

Things we did Wrong

1. Marketing
We needed to put as much time and resources towards marketing and community building as we did on development. That's a bit of a catch-22, if you're a tiny team with a shoestring budget. We did put a significant amount of time and money towards marketing, but not nearly enough or in the right places. You need to have someone with connections to media, money to buy ads, or be able to put in enormous amounts of time and effort for grass roots marketing (or ideally, all three).

There's no getting around this, and with the saturation of amazing games on steam, its pretty brutal. (who doesnt have at _least_ 30 games they've bought that they're "going to play sometime")

2. The industry changes RAPIDLY
When we started development in 2014, steam and youtube were pretty different. Gaming on youtube was raining attention on games (at least it seemed so), and it was easy to think a really top quality and unique game could garner a lot of attention. We didn't assume we'd just have attention lavished on us, but we certainly were too optimistic in retrospect.

2. Scope
As seasoned game developers we felt we could punch above our weight. However, just because you can, it doesn't mean you can do so sustainably, or well enough to keep the company lights on.

We rationalized that single player, coop and competitive multiplayer were all requirements for a successful game. In retrospect, I felt coop horde was the core part of the game. So to other developers I say, hunt for the core of your game, and double and triple down on that, rather than expanding to do everything.

All the developers I know, work on games to make cool shit, with cool people. Reconciling the creative ambition with producing a product you can sell to people, and continue doing so ... is the true magic trick this industry constantly struggles with, _especially_ the indie sector.

3. Length of Development
The longer your development continues, the higher the chance some catastrophic project killing event will happen. While I'm listing moving to Unity was something we did right, in hindsight it was the right reason, but what we should have done is taken that opportunity to simultaneously scope it down agressively. (instead we did the opposite)

We continued through 3-4 years of development before launch, and were extremely lucky not to have life events impact us existentially before the launch date, but its a bit of a lottery. If your project is scoped correctly, you minimize that risk.

4. Over-Planning for Scale
This is a bit harder to list as a wrong, but specifically I wanted to point out that we opted for dedicated servers. The reasoning for this was to reduce latency, avoid disconnects killing whole games, and remove cheating as an issue for competitive games and tourneys. I personally feel (at least in retrospect) there's something to be said for starting using p2p and then building out a dedicated network given the resources.

We did some really neat things like writing bots using aws instances to stress test the login server and game server instances, but we never got to the point where that robustness was tested.

Things we did Right

1. Focusing on quality.
This is a double edged sword, but you really can't NOT focus on quality. High ratings are one of the best ways to ensure when people see your game, that they'll play it, and enjoy it. Why even bother making a game if you can't be proud of it?

2. Spending the time to solve hard problems
We took the time to really nail the formation system and pathfinding. The resurrection system was nearly a revelation when we first got it in. Don't be afraid to really drill down and tackle hard problems if they're core to your game.

2. Discord and having a hang out with testers
We dabbled with slack, and irc for a bit, but discord hit all the right notes. With discord we were able to grab crash logs, upload screenshots, have discussion channels etc. Simply put Discord was critical to building a support group around us to motivate us and inspire us.

3. Unity
The switch to Unity set us back, the game was completely rewritten, but the game was infinitely better for it.

4. Team
Last but not least, we had a really great team. We got lucky with our dev members being extremely talented, but we also had an amazing group of friends around us who helped us play, test, offer advice, and suggest crazy ideas that helped shape Deadhold into what it was. If you're making a game, I reccommend building a tight knit group of players and friends around you, its essential.

Last Words

There's no detailed map for charting indie development waters (and they shift all the time). When making decisions its rarely clear what choices are correct, and correct in what context. A lot of the above is going to seem stunningly obvious, but there's a difference between knowing something technically, and identifying situations by experience.

There's some regrets, but life's too short not to try.