The making of Rugged Rovers

By Jon Reid, How we did it

Over the course of the past year, we’ve been busy creating an interactive installation for the Science Museum’s Engineer Your Future exhibition which opens to the public on the 17th December 2014 and will run for the next three years. The result is Rugged Rovers, which asks players to design an exploratory space rover that can navigate the rocky and diverse terrain of another planet!

Prototype to find the fun

We always prefer to prototype the core concept of our games to test how well an idea works before we start creating the full game. With Rugged Rovers, we created a “grey box” prototype – which simply means we’re focusing on the mechanic and interactions only, with no slick, polished art involved – which was tested both by our internal team and with real visitors at the Science Museum.

Like all the best prototypes, ours was quite crude, a little ugly and full of temporary art! But, it was super fun to build and helped prove that our intended audience enjoyed the game and also understood the wider learning objectives. The goal was to create a simple, networked prototype that allowed people to draw a vehicle and send it to a communal terrain space. This is a lot to create for a prototype, but it is the core experience of the game and we needed to validate whether the audience was receptive to it.

As soon as the initial prototype was complete, I invited others in the studio to play and it became a huge draw for attention, with everyone crowded around my desk, competing to create the best rover!

After this initial internal playtest, we knew we were on the right track and we were confident that we were building the right game. It also exceeded our goals during visitor testing, as we soon found out kids didn’t want to stop playing, designing and improving their rovers.

Letting the players produce the content

As all the content in the game is user created, we had to create an intuitive drawing tool that would take any possible shape drawn, and convert that into a rover that as closely as possible resembled the shape the user intended to draw.

When you realise this is an open tool that anyone can use and through which almost any shape can be drawn, it became clear that there would be some non-trivial problems to solve. Examples of problems we knew we’d need to tackle include unfinished shapes and shapes with loops and crossing points.

We managed to handle loops in the shape by analysing the line looking for any intersections that had occurred. When an intersection was found, we would identify the line segments that formed that loop and remove them from the line. We then do that across the entirety of the line data and the result is a loop-free shape from which to make the rover.

Demonstrating the technique used to eliminate loops

Handling the end points proves to be a bit more difficult – for the system to work, the shape the user draws needs to be ‘closed’. When a shape is drawn by the user and it isn’t closed (e.g. a simple “V” shape), we have to work out how best to close that shape while also interpreting and respecting the user’s intended design.

We do this by extending the start and end points of the line by some distance, then checking to see if these new start and end points overlap. If so, then we know we’ve created a fully closed shape and the rover chassis can be created.

Demonstrating the technique used to ‘close’ shapes

If the new points don’t overlap, the shape has to be rejected as we won’t be able to determine what kind of shape the user was trying to draw.

Demonstrating a case where we can’t automatically ‘close’ a shape

As you can see from the image above, trying to determine what kind of closed shape the user intended would be a tough task, so instead we simply ask the user to draw another shape instead.

The rover chassis is created in Unity by building a custom 2D mesh based on the point data generated by the user drawing the outline. I use an open source library called Poly2Tri to help triangulate the point data into a meaningful shape. Poly2Tri works well as it can handle both convex and concave polygons which allows us to handle any shape a user may draw.

We then apply some extra effects to the resulting shape, adding outlines, glow and structural lines, to create the final mesh that represents the user drawn chassis.

The advantage to making heavy use of meshes is that they allow you to do lots of graphical tricks. For example, we couldn’t turn on antialiasing to get a crisp, vector style line that we had wanted, as if we did, it would have resulted in a massive performance hit that would render the game unusable. So instead, we add extra meshes as outlines to any shape that gets visually affected by aliasing.

These extra meshes contain simple vertex colours which blend from the interior meshes colour to clear. This creates the illusion of 8x anti aliasing on all our meshes, but with much less overhead. It’s actually an old trick that we normally do with textures, add an extra pixel of transparency to the edge of the texture, you can’t tell anti aliasing isn’t on. But in this game, there are barely any textures in use at all, so I replicated the same visual trick inside the mesh itself.

Extending outside the exhibit

One of the aspects of this project that we’re most proud of is that any player who enters the museum can connect and interact with the exhibit through their iOS or Android mobile device.

To achieve this, we used the Smart Fox Server plugin for Unity that allows easy cross platform network connectivity, as well as server management so that we can look after and customise how users connect to and interact with the exhibit.

The general approach to networking the game between mobile and museum is to create a single app that just connects to other instances of itself. we wanted to avoid creating a different version of the game for each platform, and preferred to have a single game that knew which platform it was running on, and takes care of platform-specific settings itself.

With this approach, building and deploying the game became very simple, and there is only one code base to support and debug.
The way the museum exhibit is networked and communicates with the outside world versions can get a bit complicated to explain, so let us show you through diagrams!

SciMus

In the museum, a hidden Mac Mini server is running an instance of both SmartFox Server and the game which is projected onto the big screen. This acts as the host computer, which facilitates and manages the communication between all clients.
The Microsoft Surface tablets built into the installation, which are the primary means for players to use the game, are connected directly to the Mac Mini via ethernet cables.

Mobile users in the museum connect to the same Mac Mini too, but instead of directly accessing the network like the Surface tablets, they connect to an external server and we bounce the data back into the museum over a secure VPN. While this adds some complexity to the infrastructure of the exhibition, this is required for security reasons as we can’t allow devices not specifically controlled by the museum on to their local network.
By utilising network capabilities like this, it allows us to create a unique museum game that extends past the confines of its own physical space, allowing for more players to take part in the combined social experience of the game.
Singleplayer users also connect to this external server, but instead of sending game data to it, they connect to the highscore portion of the server. This is a shared external space on the server that is segregated into single and multiplayer spaces.

Going beneath the Surface

During initial talks with the Science Museum and based on both their and our experience, we quickly found that the iPad and other similar tablets couldn’t stand up to the daily abuse of the many thousands of small hands we were expecting to visit our installation. As well as robustness issues, we also needed tablets that had ethernet capabilities as they would be communicating with each other as part of the experience.

While some Android tablets do have the ability to connect over ethernet while simultaneously charging, our tests indicated significant stability issues with those tablets we tested, and the iPad doesn’t have this option at all.

For these reasons, we chose the Microsoft Surface Pro 2 to be our tablet of choice for the museum installation. It’s robust, has direct ethernet capabilities through a USB dongle and can also use ethernet while charging. And, because its running a full version of Windows, we can easily lock it down to one app through Kiosk Mode, add startup and shutdown timers and all the rest of the good things that come with running a full OS.

We’ve been building games that run on iOS, Android and web for a long time, so making sure the game ran smoothly on those platforms wasn’t new territory for us. However this time, due to restrictions around kiosk mode we also had to build for and support Windows Metro. This is the mobile version of Windows 8, and as it has only recently started being supported by Unity, it had some drawbacks that made it quite complex to work with.

One of the issues we faced was that animations wouldn’t quite work as we wanted. The majority of our animations would work, but due to the construction of each screen, it meant that certain animations would have to be implemented through code instead, which is less flexible.

Theres also other restrictions, such as Unity’s quality settings not being supported yet, which means I had to create workarounds to the lack of antialiasing. It also didn’t run full screen effects, so all effects either had to be camera post effects or created in the meshes themselves. This lead to some unusual workarounds, but happily these also meant that the effects could be used on all of our target devices.

The Microsoft Surface is certainly a good bit of hardware, but due to operating system differences and the limitations imposed by Windows Metro, it ultimately had to be treated significantly differently than developing for other mobile platforms. It was definitely a journey of discovery, but like the plot of a coming of age movie sponsored by Microsoft, we feel that we learned a lot not only about the Surface tablets, but about ourselves as well along the way!

Rugged Rovers is available now in the Science Museum’s Engineer Your Future exhibition as well as on iOS, Android and web. If you have the chance to play the game on the big screen in the Science Museum we’d highly recommend it, as theres nothing like playing this game with competition.

Jon is a Game Developer at Preloaded with a passion for physical interactives, camera and motion sensor technology.

Previous post

Maintaining presence - virtual reality developers’ responsibilities

Next post

Museum Next 2015 - the playful museum