Along the path to your right, through the pastoral village, past the sleepy village, next to the aged wooden cart, two adventurers are blasting magical beams at each other. You ready your sword. Three bloodthirsty player characters have been pursuing you for several minutes. They are starting to catch up. To your left, another hooded adventurer attempts to herd some squirrels. This is life inside a SpatialOS game called Quest, and it’s running on an iPhone.
What are we questing for?
Quest is not simply a SpatialOS-powered Unity game that runs on mobile, although there’s plenty of fascinating stuff to unpack from just that. It is also an “io game”. This a genre most people know from Twitch-friendly, blob-eating simulator Agar.io or perhaps Robin-Hood-em-up Arrow.io. Typically, io games on mobile are addictive, massively multiplayer, and easy to pick up, reflecting their origins as browser games. They also have simplistic graphics and usually a top-down or isometric perspective.
So why are they on our minds? For one, developing a successful example could make an excellent business case for SpatialOS. Mobile io games are popular, but hard to monetise. This is partly because, in spite of all their appeal and addictiveness, they offer players little in the way of progression, gameplay variety and density to warrant long-term investment. This is where SpatialOS comes in.
With SpatialOS, a developer could look to add all of these things inside a much larger game world, with more concurrent users than previously possible. This is also a good opportunity to show the many applications of SpatialOS. SpatialOS doesn’t just make high-fidelity, graphically impressive 3D experiences like Worlds Adrift or Chronicles of Elyria. It can revolutionise many types of game, by opening up new game design possibilities.
Improbable’s goal for Quest was to do just that – to make a SpatialOS io game that would bring new design elements and a more “mid-core” sensibility through high-quality art and audio, without losing the simplicity and appeal of a traditional io game. We also wanted to show that SpatialOS could allow for a huge number of simultaneous connections within a single, persistent game world. For this, we set ourselves the target of hosting 1000+ concurrent mobile connections in a single shared world. Finally, Quest was conceived as more than a tech demo or starter project. We wanted to produce something that we could use not only to show off our tech’s ability to sustain large numbers of concurrent players and our working iOS integration, but also how game design decisions enabled by the additional capabilities of SpatialOS could build into a functioning and fun game experience.
The quest begins
The AAA (art, animation, audio) team’s role at Improbable is to create demos that demonstrate the capabilities of SpatialOS and inspire the games industry. For example, they recently made the demo game DUSK that we used to demonstrate our working integration with Unreal Engine.
For Quest, AAA was tasked with designing a mobile game as well as an io game. This necessitated a bold, clean art style that would be readable on a small screen. Equally, assets would need to be lean and mean in order to keep the game’s overall file size down. However, with SpatialOS capable of maintaining a game world that could host their target of 1000+ players, some variety would also be needed. Impressive tech would not be best shown off in a bland world of repeated textures.
A medieval setting was chosen, bearing some similarity to the their work on our recent RTS project. This approach featured clean lines and was illustrative rather than photorealistic. Strong use of colour gave character to game objects and places without being too busy.
In order to scale this world, the team needed to find a workflow that allowed them to reuse as much as possible whilst still providing variety. Procedural generation would have been one approach, but without significant work on balancing the results might not have been visually appealing or playable.
Instead, the team developed a workflow that began with the modelling tool Maya as a content builder. They devised a custom process to import the Maya files into Unity prefabs which could be put into the game as tiles. SpatialOS would then interpret each tile as an entity.
This tile-based approach not only kept things lightweight but was also modular, meaning that is was quick to implement, easy to iterate and simple to modify. Themes for these tiles included towns, mountains, forests, lakes and shorelines. These could be chopped and changed to add variety to the world where needed.
This was also useful for working in parallel. For instance, the design team could create a whole area of tiles long before the art for them was finished. This meant no production halts for art to catch up and no all-nighters for artists!
There was still only a set number of prefabs the team could feasibly make in the set timeframe. To solve the lack of variety this might impose, the team applied after effects like shader tinting to finished tiles. This made areas feel more varied and also helped with landmarking. Players of Quest could now communicate their locations based on the colour of objects in neighbouring tiles. For instance – “I’m in the blue town” or “meet me by the red farm”. A snowy region, complete with a “wobbling tree” animation was also created. This fostered a sense of a varied, living world.
Characters and other game-world objects were initially created as high-polygon models. A future PC port of the game could be made with higher-quality textures using these models, but for a mobile game data-efficient models mean more simultaneous object on screen. So. mobile-friendly, low-polygon models were then created for Quest by following the shape of the high-polygon ones, much like a mould.
Additional animations were created for the various attack types and also for character movement around the game world. To optimise this, the animation team used a limited number of bones (i.e. the model has arms and legs but no fingers) for the main character. Additional optimisations for mobile included using VFX for hits rather than animation.
With art finished, the game still had to be made to run. This was a perfect test case for the SpatialOS integration with iOS that we had been working on for some time.
The quest ends
The resulting game is a working io-mobile hybrid with heavy influences from multiplayer online battle arenas (MOBAs) like Dota 2. Initially, you pick from one of two starting playstyles for your character – melee or magic. Player-versus-player (PvP) victories earn you experience and level you up. At certain levels you unlock additional abilities or gain buffs for your attacks.
An additional activity, squirrel herding, has been introduced to make the world more dynamic and diverse. Wandering groups of squirrels have their own basic AI, and can be chased and grouped together to gain experience bonuses. This invites players to interact with each other in a different way from PvP. It also demonstrates the potential of SpatialOS to create a living world with a diverse NPC ecology.
What did we loot?
In short, it worked. Quest has been tested on various iOS devices. At its height, we managed 1100 concurrent player connections in the game’s multiplayer, SpatialOS-powered persistent world. We used AI-driven “players” to test the player count because there simply aren’t enough people on hand at Improbable to reach the maximum. The game uses 12 SpatialOS workers.
We were also able to learn a great deal, and improve our Toolchain and Snapshot tools for world building. Building on our own tech helps us to replicate issues external developers might encounter, and so anticipate and de-risk future projects. Specifically for Quest, we discovered just how important the entity interest radius number is to a SpatialOS project. This number sets certain game design limits for things like character movement, speed, attack range, camera angle, and the number of other clients that can be seen. If this number were to change, it would have ramifications across all parts of the technical design and game design documents. For instance, the whole art pipeline would be affected.
Going forward, we’ll look to ensure that SpatialOS partners and external developers consider setting a realistic entity interest radius number from the outset of their project. If you’d like to know more about the technology used to make Quest, why not ask one of the SpatialOS Engineers who worked on it?
The road goes ever on and on…
Future improvements that are being considered for Quest include more hero variety (including new character types) and eventually PvE against NPCs with AI. Some NPCs have been added to a test build but, while this offered an alternative activity for players, they were monstrously aggressive. We found that once player characters were in a 20-metre radius they would be relentlessly chased across the tiles and murdered. So, some tweaking is called for!
Another standard feature of io games is a leaderboard, typically visible on the sign-in screen. This has already been created for Quest because it’s an important aspect of the kind of persistence offered by a SpatialOS world, but has yet to be hooked up.
The team are also eager to add a greater variation to terrain tiles and possibly add teleporters for getting around the large game world. Currently, we have no plans to make Quest publically available to play, but we will certainly be using it to demonstrate SpatialOS in a variety of different events and contexts.
We hope you enjoyed being part of our adventuring party for this one. Be sure to check out other game design posts on the SpatialOS Games Blog.
Liked what you read? Join our community forums and discuss this article.