Behind the Scenes with BBI

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 one of three.

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

Culture is both intense and amazingly open at BBI. Everyone is hard-working and ready to offer help and support if it’s ever needed. A lot is expected of you, but you have the same expectations of those around you. This fosters one of the most collaborative and creative atmospheres I’ve ever been a part of.

All that being said, we also know how to have fun from time-to-time! From taking trips to a summer camp, to having dance competitions, to watching a total solar eclipse first-hand!

The culture is one built around caring for the product and the quality of the work we do. We provide honest and direct feedback to each other and we all take a stake on the project. We always help each other where we can and we understand that the quality comes from all disciplines combined.

For example in the code team, we always do code reviews, so that all coders have at least a passing knowledge of what goes on throughout the whole code base, and we make sure that the code is of the highest quality we can afford to create. Sometimes the realities of production have to be acknowledged though, but that also speaks of commitment to the project!

We have a good time at the office, there’s a lot of joking and laughing, but we’re all professionals too, and passionate about doing a good job. There’s a lot of mutual respect across the team, both within and between the different disciplines. We’re always sharing links and videos about science and space stuff, we have a boardgaming group, some of us go out for a run once a week, and we do some meals and pub nights together from time to time. People work hard, but they get away from the office too and generally have interesting outside hobbies and activities.

Our original plan was modeled on some of the things we saw happening with Facebook gaming, in which players could interact with each other and a shared world asynchronously.

We imagined a massive ongoing world in which players would interact with the environment and each other through both asynchronous and real-time encounters. Hardware was always intended to be a ground-based game inspired by gameplay elements from the RTS genre, but simplified for mass-market appeal, and with a rich visual aesthetic that would separate it from typical Facebook games of the time — remember this was 2010, so Mafia Wars and Farmville were massive, and we thought we could do something much more interesting and attractive.

Hardware focused on the social aspects of gaming; persistent elements tie players and their actions to each other really well. DoK is a true Homeworld title, so the driving force behind Hardware’s design needed to be course-corrected in order to be more faithful to the source material.

The exceptional art of Terran Trade Authority is a popularly-cited source of inspiration for Homeworld’s ship designs, however DoK looked to more terrestrial sources of inspiration, such as NASA’s Hans and Franz crawlers, used to transport spacecraft from the VAB to the launch complex.

Of course past Homeworld games had a strong influence on our work. Most of us at Blackbird are also very much into space exploration and extraterrestrial science, so we’re always following the latest news out of NASA and Space-X. Speaking as a programmer I can’t say cultural references were a big thing — I dunno, Office Space??

Frank Herberts “Dune” was a big inspiration for DoK. The desert planet in both are quite similarly, and also serve as a sort of forefront character in the narrative. The concept development folks are big fans of Lawrence of Arabia, so you definitely see some of that coming through in the cinematic imagery and subject matter. Those stories deal with a lot of long treks across unforgiving deserts that force the characters to be incredibly resourceful and resilient, which is a narrative through-line in DoK.

We originally planned for Hardware to have a persistent universe and Facebook-enabled gameplay. This was a venture into new territory for us as developers and Facebook gaming in general. As such it was pretty uncertain, and we didn’t know exactly what it would take to make it happen. In the end, the Facebook gaming bubble popped before we were able to release.

During this early period we kept experimenting and trying new things and didn’t really have a long-term schedule. Once we signed on with Gearbox and decided to make a more traditional RTS game the plan became much more crystallized. We needed to implement core gameplay mechanics such as resourcing, combat, weapon targeting, pathfinding, abilities, buffs, and so on, as well as build the user interface and implement Steam-based multiplayer support, then use these technical capabilities to create core gameplay and campaign mode.

After a few months of prototyping and experimentation we had a pretty clear plan for the rest of the project. Of course some things took longer than we expected and some new requirements were discovered along the way, so the project did take longer than we first anticipated, but we always had a good picture of what we were working on. For task and project management we used scrum-based development with monthly milestones and two-week sprints, with a mix of Excel and JIRA to track the work.

I think JD’s (our executive producer for DoK) incredible leadership was fundamental. But overall our biggest asset was that the whole team had a very strong vision for the project and a huge love for the IP.

The key was a combination of everyone being as diligent as they can, and having awesome producers managing each part of the team. Other key elements were good task and bug writeups, on-point prioritization/triaging, and lofty goals so you’ve always have something to strive for!

Matching visuals (and the very strong art direction) with game design is trickier than you might think. For example at some point the AAV and the Railgun had swapped chassis, since having the railgun be armored was too strong, but having it be delicate didn’t match the visuals accordingly. This kind of struggle to match art direction, visual cohesiveness and in game behaviour was a frequent theme.

Initially, the factions were extremely similar, and the faction differentiation came very late in development, only a few months from launch. Kudos to Piero, who was hired to handle just that. It was a very tough challenge and a lot of risks were taken in order to get there. I distinctly remember the day the assault railgun was born. It was just completely opposite at how we had thought of railguns, but it worked really well.

I for one had very little faith in the future of carrier to carrier combat, but one day, suddenly, carrier to carrier battles were the highlight of each game I played during playtests. It was just too fucking awesome! But it was a very long road to get there, and the vision of our game director and designers had to endure.

By the time we were making the DLC factions, the core gameplay was so strong (yes we, or at least I, think the multiplayer is top notch) that it was easier to think of wild experiments and try them out. We had more confidence to make diversity apparent.

Another thing that came late but turned out to be a fundamental feature was the height/line of sight blocking system. It gave the mobile combat so much [life]. It made the game really fun. From there a lot of options opened up: smoke screens, indirect fire, height advantage system. We kept evaluating what would be cool to add against how much we could afford to implement, so in a way we were very disciplined, but also made a lot of very deliberate choices in that regard. We made the game we wanted to play.

Broadly-speaking, this was done both top-down and bottom-up. On one hand, we’d look at what we’d like to see in the game from a lore, story, and IP perspective: “Soban are awesome, you should be able to play as them!” From that, we try to suss out what the Soban (for instance) are good at, what mechanics they might bring to the table, and whittle it down to the elements we feel fit the game the best.

On the other hand, we also look at what the game needs from a gameplay perspective: “player’s don’t have enough options when it comes to ____.” We’ll come up with elements that try to solve those problems, and find out where they best fit in Homeworld’s universe. Of course, sometimes these don’t line up, requiring compromise and a bit of creative ingenuity. In the end though, it’s about what plays best in order to deliver a fun and engaging experience

I’m not a designer, so I can’t speak to the details of how the design evolved. For the programming team, we always worked really hard to make systems data-driven so that designers could experiment with ideas and have a lot of flexibility. Nothing about the way the four factions play is hard-coded, it is all the results of different data-driven characteristics and abilities of the units the designers created.