How challenging is onboarding at your company? How about building a real-time strategy game from scratch in a fortnight? That’s what we did to a team of newly-hired community engineers from Improbable’s San Francisco and London offices.
Shortly after joining, the seven recruits – four from the US, three from the UK – were whisked to London to absorb the culture of the company’s HQ (and learn what a real pub is). The idea was simple – get to grips with SpatialOS at its “source” and learn the ways of being a Community Engineer. But we didn’t set them an easy task…
"“It was a pretty great way to start off because it was incredibly relevant to what we were going to be doing, and useful for those of us without full-on gaming backgrounds,” Giray Ozil, Senior Software Engineer."
The Community Engineering team at Improbable largely works on smoothing development pipelines for customers. They also create useful tutorials and features for developers, and maintain SpatialOS documentation. To replicate the new user experience, the newly hired engineers were given just two weeks to design and code a multiplayer real-time strategy game (RTS) made with the Unity engine and the SpatialOS Unity SDK.
It’s worth remembering that this was primarily a learning exercise to quickly pick up Improbable’s coding style. The “finished” game only needed to be playable and have the basic hallmarks of the genre, like multiple unit and building types; tougher elements like a mini-map would not be crucial. The task would also allow them to experience SpatialOS development like the external developers who they would be helping as Community Engineers.
Luckily, they wouldn’t have to begin the game completely from scratch. Improbable’s AAA department (‘Art, Animation and Audio’) had already created some fantastic assets (which you can see dotted throughout this post). These included barracks buildings for spawning units, and a few types of soldier – infantry, archers, and wizards (similar to those from the Wizards tutorial) – complete with the necessary animations to indicate movement and attacks. This enabled the team to focus on programming and game design from the outset.
What made this task so difficult?
Even if the engineers only needed to “gamejam” a few simple RTS mechanics, there was still a diverse set of technical challenges to overcome. Firstly, the team would have to sharpen their general game development skills. Most started with only a limited knowledge of Unity, but more than enough coding experience to get to grips with it swiftly.
Secondly, SpatialOS was new technical territory to them, with its own unique complexities when developing an RTS. The team found that whilst SpatialOS works naturally for tracking a single entity across a gameworld, like a player character in a MMORPG, it was less of clear fit in a strategy setting. This is because the client in a typical role-playing game only needs to be told about things that are spatially relevant to the player’s entity – that is, the things that become relevant or irrelevant as the player character moves towards or away them.
But in an RTS, the player controls multiple units of differing types. The client therefore needs to receive information about what all these different units are seeing but without needing to know about everything in the spaces between them. Additionally, with several players in the game, multiple clients on multiple computers would need to share information in real-time through SpatialOS.
Needless to say, the team had their work cut out.
Improbable’s team of new engineers imposed a couple of sensible limitations on their RTS to ensure they could deliver a decently-playable game. All terrain in the gameworld would be flat and the gameworld would be bordered by an indestructible wall. There would be four teams, each starting in a different corner, with up to three players per team. With the basic design drawn up, the coding could begin.
The team initially decided to write code then get it signed-off by the project’s overseers, which had mixed results. On the one hand, it made sure that the team was able to pick up the Improbable house style as early as possible and ensured a relatively high quality of code. As a result of this, they were even able to spot issues and inconsistencies in the code of some existing tutorials that they had used. This has lead to the creation of a useful programming “style guide” that the whole of Improbable’s Games Division can now refer to – a benefit of this project that no-one had originally anticipated. We’re currently bringing our existing tutorials in line with these improved guidelines.
On the other hand, this process of constant sign-offs created an approval bottleneck. This limited the ability of the team to really attack the game and implement the more complex features. It also had some effect on the playability of their final submission. Therefore, for future iterations of this onboarding task, we’ve decided to reduce oversight so the new engineers can focus on creating cool SpatialOS features for future platform users could copy.
At the close of the two-week project the team delivered a playable version of the RTS. Though the UI was minimal, players can click to direct their units, join teams, build barracks, and spawn units. The team was able to test out the game in a battle that sounded like a thousand furious clicks, where the winning team was the one most proficient at quickly building barracks and deploying troops.
Rome: Total War this ain’t – but that was hardly the point. Given the challenges they faced, this was a truly heroic effort. The team had received a thorough grounding in the technology they’d be using, and the job they had successfully interviewed for.
Though the team were happy with the project, we couldn’t just leave it alone. The rudimentary UI and ambitious mini-map were recently handed over for further jamming to more new hires. This new team successfully managed to integrate the intended control system and minimap. The game now sits in an internal repository and will quite likely see usage in further onboarding tasks.
Additionally, the team created tools and code with applications beyond the jam. One member of the team created a tool that works with SpatialOS to allow the visual placement of tree entities across virtual gameworlds. Features like this fit nicely with the Community team’s latest concept – recipes. These are smaller tutorials that explain how to implement specific features. Currently, more recipes based on solutions that the RTS team pioneered are being refined post-project. These will eventually be added to the existing SpatialOS docs and we’ll write about them here soon.
It must be noted that there were numerous other achievements that came from their efforts. For one, the team also was able to experience how some of the other Engineering departments work at Improbable. During the course of the project, they were asked to use some of the more experimental features that the GET team (Games Engine Integration) have been working on. This process of “dog-fooding” meant that the team uncovered some vital bugs that needed to be found before release. It’s hoped that the new engineers realise how much they have already contributed to SpatialOS as a whole.
As for the engineers themselves, they’ve headed back to our San Francisco and London offices. There, they’ll run other new hires through the same gauntlet.
Visit our community forums to discuss this article or find out more about SpatialOS.