After some major bumps in the road during the development of Darktide, I thought I would highlight some of the key mistakes that were made and what led us to rebuilding the game using Unity. We’re still deep in development, although now at a much improved pace as switching over to Unity has been extremely beneficial and a very positive experience for the members of our team.
In the early days of development, we chose to build our own engine and tools. We were using some fairly unconventional techniques in order to get the exact look that we wanted to achieve across multiple platforms, and we feared that existing technology might not play nicely with some of those ideas.
Oh, what a tangled web we weave.
In the beginning things moved along quickly and without issue. Our initial prototype only took a few weeks to have up and running which allowed us to validate our gameplay very early on in the process. During this time the art style was being shaped and defined, and basic lore was written, which gave the characters and races an identity rather than being named sticky notes full of stats and abilities.
At this point we moved full swing into production and that is when the troubles started to emerge. Being a tiny development team left me with writing the code for the engine, tools, and game; along with overseeing the production this didn’t exactly leave a lot of time for support and debugging.
Our initial problems were regarding tools and the asset pipeline. Since we were starting from scratch, I had to create the tools as needed, and it was akin to putting out fires as I had to build them on demand when we needed to test something and give an artist feedback. Not only did this take a large amount of my time by pulling me away from building the actual game, but since a lot of the code was being written quickly we started to accumulate a lot of technical debt that we just never had the time to go back and refactor. There were also times when art production was completely blocked or time was wasted pursuing something that didn’t work out in the end, all because we were lacking the proper tools. In hindsight, if we had started with an existing toolset like Unity none of these problems would have occurred and we literally would have saved hundreds of hours on both code and art production.
The art tools were only part of the problem as we had to manually edit a bunch of text files defining character animations, stats, abilities, maps, campaign flow, dialogue, and pretty much everything else a designer could tweak. In order to change anything in the game you had to manually edit the text files, which would not hot-reload so you would have to close the game and restart in order to see your changes. As you could imagine it bogged down the process and made iteration on gameplay absolutely painful, especially the times when you made a mistake in one of the files and had to track down a convoluted bug.
We needed to rectify our situation with tools, and it had to be done quickly as there were now so many moving parts that it would have ground development to a halt. I decided to bite the bullet and build our current and future tools in the Unity editor and then export to the formats we were using in our codebase. This was a fairly large undertaking and took a lot of development time while slowing down progress on the game, but in the end our pipeline was much more efficient and tools were greatly improved, especially in comparison to editing text files. This still wasn’t an ideal situation as we couldn’t pause the game and tweak values or hot-reload, but it was a vast improvement in comparison to what we originally had.
Now this is the part of the story where I pause and let you ask “Why didn’t you switch to using Unity completely rather than only for tools?”. There were many reasons for this, but the main issue was that I would have to convert the entirety of our existing game code from C++ to C# and I still had the notion that without the source I would get stuck hitting a problem with how we’ve built our assets. Our codebase was quite large and with the technical debt overhead it seemed like a mountain that was too high to climb.
So we continued on with development and eventually reached a state where we could invite some people to test and give feedback. It turned out to be an incredible experience and we received a ton of great feedback that I am extremely thankful for, and we also found where we should be spending more of our time on the game. Right from the beginning, we’ve basically had two campaigns where you could play from the viewpoint of both factions, but we also had some dynamic elements that changed the world and future decisions. This went over extremely well with the majority of players and they wanted more dynamic elements and storytelling and so we pivoted to really focus on that aspect. Fast forward to today and both of our campaigns are entirely dynamic within a living world and the story plays out along the lines of a choose your own adventure book but with hundreds of variables. For example, you may have to choose one of three battles to attend and both your attendance and outcome of the battle will affect your reputation and the storyline. Meanwhile the other two battles will still occur and the results will change the course of the campaign. This has given us an extreme amount of work in campaign and story design, but I believe in the end it will really make our game stand out in comparison to others in the genre.
The technical debt is strong with this one.
At this point the codebase was so large that I had to keep hopping between the engine and game code working on features and fixing bugs. I wasted so much time fixing core bugs and then refactoring things that counted on the behavior of those bugs. There was no way I could continue without making a change and getting rid of the technical debt, otherwise I likely would have been in development perpetually. I tested swapping out our engine code for a nice clean, open source engine, as that way I wouldn’t have to rewrite all of the game code or make drastic changes to the current assets, but it left me having to build a lot of features on top of it and our tools were still isolated in Unity. It was a 3-4 week process, but I don’t count it as wasted as it drove me to my final decision, which was to evaluate rebuilding the game in Unity.
In just under six weeks I had the majority of the core functionality ported and running in Unity, gained hot-reload and live variable tweaking, and our tools were finally united. Absolutely none of my fears about hitting unsolvable problems were valid (this must have been a hangover from working in tech & tools so long), and now development is moving along faster than I ever could have imagined. Envision going from tweaking response timing for attack/defence in a text file to using mechanim and animation callbacks to do it visually in seconds. Also the built-in 2D tools and asset bundles really streamlined our entire process and we were able to get rid of all third party applications we were using for things such as sprite sheet generation.
Now that we have a stable foundation we’re back to spending all of our time on what matters most, our game. Right now we’re polishing the UI, tweaking game design, and working on the campaign storytelling. There is also a good amount of work left to do with the online multiplayer and tournaments which I haven’t ported over yet, but I don’t see any major issues and really just count it as time I need to spend. Our current goal is building a gameplay trailer and site so that we can launch our Kickstarter campaign in order to fund the completion of the game and hopefully get a lot more discussion and feedback. We didn’t want to approach crowdfunding in an early stage as we wanted to be in a state where the shell of the game is working and majority of assets built, that way we could literally mitigate all risk for backers and we know that we’ll hit our target dates.
Development has been an absolute roller coaster with a lot of ups and downs, and one thing I can’t stress enough is for small teams to leverage every piece of existing technology that you can. Considering I had worked in game tech & tools for other studios in the past you would think that I would follow that advice, but unfortunately we took the long route to get where we are today. In conclusion, I really wish we had built the game with Unity right from the beginning, but rather than crying over spilled milk I’m just happy that we’re here now. If you take anything from this story, it should be that if you’re a small team you need to seriously evaluate using existing technology as otherwise it can be quite costly down the road.