On The Assembly - Planning for the Unknown

When we decided to jump headfirst into VR development in 2013, we knew that it would be a learning experience. What we didn’t necessarily expect was for VR to break a lot of well-established game development rules. We needed to unlearn what we had learned, to paraphrase Yoda. Now, as The Assembly fast approaches its final beta phase, we thought it’d be a good opportunity to share some of our unlearnings with you.

Measure twice, cut once (…but cutting is more fun than measuring)

The challenge we set ourselves with The Assembly is different to taking a game design and developing it for a next-gen platform, or even taking a regular game and adding motion controls (e.g. for the Wii). Using a flat-screen to display a game is familiar to us devs - VR, on the other hand, completely surrounds the player. This requires its own, unique way of making things, as we explained in our EGX developer session.

On top of that, we knew that when it came to the hardware, essentially we’d be developing for a moving target. Prior to their public release, the capabilities and requirements of new platforms exist in a seemingly perpetual state of flux. This however, is a known unknown, as several key staff here at nDreams have experience developing for pre-release hardware platforms and launch titles for new consoles.

With this in mind, we applied some tried-and-tested tactics for videogame development. First of all, you always need to plan for not knowing. As with any creative project, the problem is not being aware of exactly what you don’t know when you start. On paper – or a design doc, in our case - a project can look relatively straightforward. It’s not until you start developing that specific issues become apparent. Until then, you can’t anticipate what they might be.

Our solution is twofold. Firstly, iteration and shrewd editing – these are the strongest weapons against a continually evolving environment. Design, implement and test. By iterating early and often, we can tell whether a feature holds up, if it needs more work, or if it ought to be cut. This can be a time-consuming process, which is why our second solution is to bake in enough time to our production schedule from the get-go to account for these unforeseeable eventualities.

HOW TO MITIGATE UNFORESEEN EVENTUALITIES, by nDreams (age 9 ¾)

1. The first rule of VR development isn’t not to talk about it, but rather to base decisions and lines of development on empirical evidence. How did we do this? Simple. Lots and lots of focus testing! By getting people from outside the studio to play elements of the game, we’re able to check their viability while still early enough to course correct. This is an ongoing process.
   
   
2. It’s essential to identify and flag risks early on. We continually (and honestly) monitor risk throughout the course of development. This way, we’re better able to assess various aspects of the game, pick our battles so as to avoid putting a strain on the team or affect our ability to deliver it on time.
   
   
3. Say you know that a useful feature for your game engine (in our case, UE4) is on its way, but has yet to be released. Rather than waiting for it to come online, we hack a preview together ourselves. We can then determine whether the game really requires that particular feature. This enables us to make an informed decision before we've even got the technology that would enable us to realise it.
   
   
4. Stay fluid. You have to allow every technology, art aspect, story change and development in team skills to impact the game's design without throwing it off course. This could be said to apply for developing a game for any new platform launch.
   
   
5. Kill your darlings, by which we mean never be afraid to cut features, even if you’ve grown attached to them. Holding on to them because they once seemed like a great idea or trying to shoehorn them in somehow only slows down progress and impairs overall quality.
   
   
6. Communication, communication, communication. This may seem obvious, but synergy between teams means that if something changes in one area then it doesn't come as a surprise. This is a good thing™ as it’s preferable to avoid surprises when it comes to a game's development. Proper communication enables us to maintain a unified direction across teams, while still allowing us to stay fluid.
   
   
7. Don’t start by scripting the minutiae of a game’s narrative. Focus on that when the game’s flow and overarching player journey have been established instead. As we’ve tried to convey, shifting realities are intrinsic to game development (best laid plans and all that). If - or, more likely, when - a game changes in scope, so too will its narrative. Composing a new narrative leads to changes in the game’s structure, which will have knock-on effects on the rest of the game, from code through to art. If story beats follow gameplay, these issues can be avoided.

So there you have it – our philosophy as a studio on how to plan for the unknown when making a new game.

In the coming weeks and months, we’ll be going into much greater detail about The Assembly. You can look forward to us shining a light on the game’s look and feel to its mechanics, characters and moral dilemmas.

In the meantime, feel free to pepper us with questions about the game via The Assembly's Facebook page, tweet us using the hashtag #TheAssemblyVR, or pipe up on our dedicated subreddit.

You can also find nDreams on Facebook, see our games in action on our YouTube channel, or check out our board on Pinterest for screenshots of all our titles.