Space, space everywhere but no place to build
Real time strategy. Resource collection, base building and indirect control of units. Using space as a setting for an RTS has been technically challenging and some of the biggest hiccups came from the most unexpected places. A testament to this is the months since the last devblog. Yea, it took months to solve this problem.
The first Deepfield design didn’t have any base building. You were dropped into a sector with a mothership, some material to build some units with and that was it. Go find some asteroids and destroy all that oppose you. It was focussed on unit management and resource collection.
After play testing it was pretty clear that this approach lacked depth and after the initial rush to build an army there wasn’t much motivation to keep finding resources. Both sides would just be throwing waves of units at each other until one or both got bored.
During early discussions around how the MMO aspects would come about Toby suggested that the player avatar was the mothership. So over time you could add to and customise your mothership. Like a fantasy character collects armour and weapons to create a unique look, the mothership would over time become an epic monolith that jumped from sector-to-sector leaving destruction and fear in it’s wake. I initially rejected the idea, one because the plan to build a MMO wasn’t concrete yet and it conflicted with the Sim-Ant style of expansion where you would have many mothships (queen ants) and use them to take and control additional sectors. And two, the engine was half built and the concept of units being fixed at spawn time and defined using a 1-to-1 config to entity relationship was at the core and already established as a pattern throughout the code. To allow for dynamic changes to entities arbitrarily and at runtime would require a massive change to the way network updates and entity spawning were handled. The possible disruption to the engine build was the final strike against the idea and it was put to bed never to be mentioned again.
Until this document.
You can see where this is going.
Seeing how people were playing the game it was clear that base building was needed. My first thoughts were that buildings were just static ships that you would move around with tug boats. You could build a fleet of turrets and move them where you needed. If you needed to expand unit production you would build smaller ships that were dedicated factories, other ships that would store resources, and so on. This was a terrible idea. I played with the tug boat idea and found it to be tedious and awkward.
Why not make the motherships the base?
Because the engine won’t support it and forcing the engine to do it would introduce so many bugs that I would burn all my dev time just trying to keep the thing stable.
It was such a great idea though. There were so many game play problems that it solved. I seriously considered the move and how it would be implemented into the engine. Motherships would become custom, purpose built units. If you needed force multipliers to take control of a sector you could build a mothership with a huge storage and production capacity so once you enter the sector you could crank out units quickly and get them by surprise. Or if you had control of the sector you could load a mothership with turrets and cargo ports so resource collection was fast and secure. This would also allow for a rudimentary tech tree where you needed to build components on the mothership to access more advanced buildings. It would allow so much depth that it moved Deepfield from a generic RTS to something unique.
After running the the idea past some of the testers I was confident that Deepfield would not only benefit from this feature, but Deepfield needed this feature to distinguish itself and have any position in the market. Turns out Toby was right and I should have listened earlier.
The solution was to create a special unit that was a grid built up with cells. Each cell was a functional block on the ship. So blocks for thrusters, blocks to build units, blocks to store cargo, etc. You would build these cells as you would any other unit and then drag them onto a grid to build the shape of the ship and it’s function. These grid entities would become capital ships and be the base of operations. Regular units would no longer be required to build. Everything happens on capital ships and only capital ships can jump between sectors. Capital ships become the base building component of the RTS.
This is what prompted the TCP/UDP change and what was essentially open heart surgery on the engine. It took me a month to allow entities to be dynamically configured at runtime, another week to allow for this in the physics engine, a month to build the user interface and get it all talking to each other, and then another month to fix the design mistakes I made in the previous two months. A week or two for bug fixes and the “Grid system” was done.
What seems like a small change took longer to build than the entire network stack and physics engine. Was it worth it? Yes. Will this be the last time consuming engine pivot? Probably not, but I will try to avoid it.