An Interview with Blackbird Interactive, part two

We had a slew of questions about the making of Homeworld: Deserts of Kharak, and the BBI team was awesome enough to provide answers!  Part two of three.  You can read part one here

Meet the BBI team that participated in our Roundtable (with special thanks to Iain Myers-Smith, Communications Manager):

This is a combo effort; we wanted DoK to have unique and interesting units, but we also needed to stick to a few of the Homeworld staple archetypes as well. This leads to easy and familiar translations, such as Interceptor → LAV (fun fact: these used to be called “Escorts”), some amalgamations, such as Support Frigate + Resource Controller → Support Cruiser, and some creations unique to DoK, such as the Baserunner (another bit of info, we originally had a “Support” variant of the BR as well). As for the people involved, this ran the spectrum, from designers to artists to programmers; units are the bread and butter of RTS, so nearly every discipline is heavily involved in their conception, creation, and implementation.

This is a big one. In broad strokes:
Concept art -> Modeling and rigging -> Design pass on systems (movement type, weapons, abilities) -> Playtesting -> Repeat

Units were incredibly labor intensive to create and a lot of the technical effort went into creating the pipeline for them. We actually had a lot of cool prototypes that sadly could not make it into the game, like more detailed destruction, or a more elaborate driving presentation layer. This is where I feel a sequel, if we ever get the opportunity to make one, would get the most bang, since we learned a lot of hard lessons.

On the technical front, we built data-driven systems for defining unit attributes, behaviours and abilities, and attaching models, animations and effects. Design-wise, unit creation was a combination of design requirements for unit capabilities and interactions, concept art to inspire the look, initial proxy models to get units into the game and playable, and then final content for models, animations and effects. The bulk of the work was an iterative process involving the art and design team, with programmers involved when new capabilities were required.

I made the original decision to use Unity. At the time — back in 2010 — Unity was on version 2.6. We wanted to bring a rich visual aesthetic to Facebook gaming, and at the time Unity’s web plugin was the best way to bring 3D visuals to online gaming. By the time we hooked up with Gearbox and switched our focus to building a traditional standalone RTS game for personal computers, we had learned a lot about Unity and C# and felt confident that we could build the game we wanted using the engine we had become familiar with.

Unity games are sometimes criticized for looking “the same” — but this is really all about how you use the toolset. With a talented art team, custom shaders, and creative use of Unity’s rendering, effects and physics systems we were able to create a unique look and feel. We did have performance issues during development, but by repeated optimization of core algorithms and aggressive use of level of detail rendering we were able to get to a pretty good place for performance. Unity does support native plugins written in C++, which we considered using for performance reasons, but in the end we were able to do everything we needed to do in C#. Garbage collection in C# was a performance issue, but we were able to mitigate this by minimizing our use of dynamic memory allocation during gameplay.

For some features we had to write a lot of code from scratch. Still, Unity does give you a lot of advantages even then: you don’t need to worry about rendering, or input handling and such. I recommend seeking out the various talks by Yggy on how the multiplayer works.
I think art and modelers were the most affected, and it was often questioned whether Unity was holding us back in terms of visual target. So we had to work around it at times, but in the end I think the benefits provided heavily outweighed any limitations.

We wanted a really open, unfettered feel to the world, with a strong vehicle fantasy of these giant vehicles racing (or lumbering) across a vast desert. Stitching tiles together would not have provided the organic feel we wanted. We did use Unity’s terrain system for prototyping and initial map design, but terrain based on heightmaps had undesirable artifacts along dune ridges and didn’t feel organic enough. Instead the art team used tools like Z-Brush, Mudbox and World Machine to sculpt worlds and set decoration that feel natural and real and non-repeating.

There is some more information about our terrain creation process in the talk I gave at GDC 2017. The slides for the talk can be found here — or you can see the full video on the GDC Vault here.

We wanted the maps to be lifelike, authentic and organic. Next to our units, the terrain is one of the strongest and most important aspects of the game, and it was quickly determined that ‘building by hand’ was the only way to achieve this. It was certainly an arduous process!

The why is mostly for artistic purposes as far as I understand it: hand-crafting the rolling sandscapes results in a level of beauty one simply can’t replicate with a tile-based editor. The extreme zoom offered in the Homeworld series also meant we needed our terrain – our world – to hold up next to the detailed vehicles of DoK. How is a bit of a mystery to me as a designer, however lots of sculpting was done in organic modelers like Mudbox, then exported and “batched” into clusters of meshes for rendering efficiency at runtime.

In game development, sometimes you just have to let go 😀