Developing a Ski Open-World Game for Mobile

The team of Toppluva AB, the developers of a mobile game Grand Mountain Adventure with a top-down perspective, talked about the development of their title, its idea, technical decision, camera work, and more.

Introduction

80lv: Could you introduce yourself to us? What projects have you worked on and how did you actually get into game development?

We are three brothers from Stockholm, Sweden – Viktor, Sebastian, and Alexander – who founded Toppluva and created Grand Mountain Adventure. Viktor, who wrote the graphics engine, has worked with medical visualization and audio software. Sebastian works on physics and has a background working as a software consultant and data scientist. Alexander who joined the project a bit later works primarily with modeling and has a background as an environmental engineer.

Gaming has been an interest for all of us since we were children, however, we have no prior experience in game dev and got into this industry literally by accident. In 2015, Sebastian broke his back and Viktor his kneecap in two unrelated snowboard accidents. During the sick leave we started prototyping a ski game without no clear aim, but as the years went by the project has continued to grow and a real skiing game started to unfold.

Sebastian breaking his back on a jump in Les Deux Alpes, France (filmed by his girlfriend)

Sebastian in a corset

Viktor enjoying a wheelchair after breaking his kneecap in Gressoney, Italy.

Grand Mountain Adventure: Idea of the Game

80lv: Let’s talk about Grand Mountain Adventure. What was the main idea that guided you? The visuals make the game look like a shot from a TV broadcast. Could you tell us what were the main references and inspiration points here?

Being skiers since childhood and looking at snowy mountains with ski lifts puts us in a good mood in the same way turquoise water and white beaches might affect other people. With this as a starting point, our basic idea was simply a game where you could explore a mountain in the same way you explore a ski resort. Moreover, as no one had tried to recreate that “real” mountain sensation in a game before, we felt that it would be a sensible start.

The top-down perspective, rather than a behind the player third person perspective, came quite early. The top-down perspective makes the landscape feel more like a miniature world but still catches the depth of a massive drop, for example. A lot of people use a view from a drone as a reference, and it is quite a happy coincidence that drones became a common tool for filming skiing competitions/videos at the same time as we were developing the game. We did a lot of experimenting with the camera behind the player rather than in front of the player but came to the conclusion that it reduced the sensation mountains have.

A lot of people seem to reference the old Windows title “Ski Free” when they see our game, but if any skiing game has inspired us it would be the downhill level in the 1990 game “Ski Or Die” by Electronic Arts (if it wasn’t for the fear of copyright infringement we would put a replica of that level in the game).

The fact that it was a skiing game also relieved us from a few hassles with limiting mobile controls as we did not need to reserve an explicit button to go forward.

Custom Engine

80lv: You’ve mentioned that you’ve developed an entire engine for this project. Why did you decide to move in this direction? Why was your solution a better fit than Unity? What advantages of working in your own engine would you point out?

Making our own game engine was not a conscious decision. The very first prototype with a skiing cube on a tilted plane was made in C++/OpenGL. The idea was to switch to an established engine at a later stage, but as the prototype progressed it would take more time to rewrite the game than just to go on. At the time, GMA was still something we worked on in our spare time, so we didn’t really feel we had the energy to rewrite the prototype or to familiarize ourselves with Unity/Unreal.

Technically, as with any other custom engine, we were able to tailor everything for performing well on the mobile platform. We are not sure if we would have been able to fit the whole game on a mobile device, especially older devices if we hadn’t built our custom engine.

Beyond the technical aspects, using our own engine has had some artistic consequences. This might sound a bit hazy, but we think it inevitably makes the game a bit more unique as you constantly work around the limitations. For example, the engine lacks advanced scripting so in order to make each challenge feel different, we have had to rely on the design of curves, jumps, etc. rather than scripted events.

Snow

80lv: The game really shines in motion but first, I want to understand how you figured out the look of the snow. What way is this material rendered and how do you work with all the tracks, snow dust and so on?

We get a lot of questions from fellow indie game developers on how the snow is made. As with everything else, we experimented with a lot of techniques such as building a mesh for the ski tracks, putting our decals, or modifying vertices of the height data before settling for the current solution.

Basically, it is one large texture which is constantly updated with ski tracks. The texture is then used as a bump map for snow and as a lookup table for other materials (in the current version only asphalt and ice are rendered this way, but internally we have soil and grass materials which will be used in upcoming levels). To gain depth, we experimented with parallax mapping, but as most of the game is viewed from a top-down perspective, we switched to the less performance-demanding bump mapping which looks good enough.

Using one large texture gave us the luxury of being able to quite easily generate and blend various types of snow textures, for example, Manchester snow in pistes, wind-blown snow, and marks for rolling snowballs at steep sides.

The actual shading of the snow is a homemade shading model, different from the rest of the materials which uses regular Phong lighting.

World Production

80lv: You have an open-based structure where you can explore all the vast spaces. Could you talk a bit about the way you’ve crafted them? Did you use some peculiar real-world data or did you just generate stuff in World Machine?

The foundation of all mountains is made in World Machine. Initially, we thought that we could just generate some Perlin noise in World Machine, add snow, objects, and challenges and be done but when trying them out we found they always came out pretty dull (too wrinkled, uninspiring, rough, flat, boring).

I guess we eventually recognized what a huge task it is to create an interesting 3D landscape that fits with the game mechanics and that it is impossible to just auto-generate it. The solution was to improve our own map editor so we could sculpt and alter the mountains ourselves and quickly toggle between editing and playing. Then we just spent a lot of time testing different mountains trying to find out what is fun. In the end, we probably had around 50 mountains that didn’t make it to the game (and 5 mountains that actually did). For the ones that we did keep, every jump, bump, and drop has been fine-tuned manually.

Of course, we’ve also tried importing real-world height data from some of our favorite ski resorts and in the future, we really hope to get the chance to collaborate with ski resorts to bring real mountains into the game.

Building a railroad:

Camera Work

80lv: Could you talk a bit about the way your camera works? I love how it moves in a very organic and smooth way, gliding along the winter hills. Can you tell a bit about the way your camera system works, how it moves, follows the user, and shows the world around the player so that he/she knows where to go?

Working with the camera is often an unrewarding task. When it works good players don’t notice it, but as soon as the camera behaves badly, it’s really annoying for the player. The camera is made to slowly adapt to the direction of the player in free ride mode, but in challenges where you follow a track, it subtly adapts to the track hinting at where to go.

At first, the game was in portrait mode, as it gave more screen space downward. The camera then followed the player direction very tightly so that the player always headed straightly down screen-wise. This made it hard to follow turning tracks though, so we changed the game to landscape mode and relaxed the conditions for the camera. Most often, the player moves approximately at a 15-degree angle with respect to the screen. In landscape mode, there is very little view space below the player but going at an angle gives more view space.

Asset Production

80lv: What way did you decide to fill your space with assets? It seems like the majority of props is very low poly and stylized. How did you produce them and how did you reuse them during production? 

Like everything else, the low poly design was not an initial design decision, we had some prototypes with textured objects and even pixel-art style objects. Eventually, as the game evolved, we decided it would make a good contrast between low-poly untextured assets and smooth textured snow.

Although barely noticeable, we came up with a simple technique for faking ambient occlusion for low poly models which pushed us further in this direction. Basically, it’s a single texture divided in triangles with different shading. Every triangle in each object is then assigned to a part of this texture depending on their neighboring triangles.

All assets are made in Blender, and no texture mapping is used at all.

A house and a tree model made in Blender

Screenshot showing traditional Swedish houses in the mountain “Dalarna”

Challenges

80lv: Overall, from a technical standpoint what was the biggest challenge in this project? How did you solve it?

In particular, four parts have been technically challenging: optimizing the graphics engine, combining the editor with the game, the physics of the player, and unfortunately, all the scaffolding required to run the game on Android.

1. Optimizing an OpenGL pipeline for mobile GPU is, as graphics programmers know, a lot of work. The inner operation of OpenGL is an asynchronous enigma, and as a programmer, you always have to be prepared to reorganize everything in order to reduce draw calls or changes of state, for example.
2. As the editor is built into the engine, a lot of architectural work was required to make them cooperate since the editor mode is designed to change things, whereas the game engine assumes that objects stay fixed. The engine is multithreaded, but for the sake of simplicity, multithreading is completely disabled when the editor is enabled.
3. The skier physics is something you can calibrate forever. As we wanted to have a sense of real skiing we initially had the idea that the ability to control the skier becomes less precise the faster you go, plus, the jump length had to be realistic as well as crashing due to external forces. However, from a player’s perspective, this just made the game feel random and annoying so we ended up aiming for a middle way between realism and fun.
4. Unfortunately, making a pure NDK/C++ application for Android gave us a lot of unwanted trouble which could have been avoided if Google provided just a few helper utilities and better examples. I don’t even want to think about how much time was spent debugging weird library crashes, mounting and reading OBB files, wrapping stuff via JNI as well as fiddling with the build system (Gradle/CMake).

Distribution

80lv: Finally, where can we find and try out the game? Are you going to release it on PC and iOS?

Right now it’s Android only and can be downloaded via Play Store. We have started porting it to iOS and hope to have it out in the middle of the summer. Here is a sign-up form for those who are interested!

If everything goes well we really hope to port it to Switch as well. The game actually runs on PC right now, but the controls need to be reworked before we consider releasing it, including adding controller support.

Toppluva AB, Developers of Grand Mountain Adventure

Interview conducted by Kirill Tokarev