Level Game Production: Lonely Mountains Downhill

Introduction

We are Megagon Industries, a small game development studio based in Berlin, Germany. We (Jan and Daniel) founded the company six years ago. We already knew each other for a few years and had worked on a bunch of games together in the past. While we mainly worked as individual freelancers at that time, we also created the two premium mobile games “… and then it rained” and “Twisted Lines”. 

During the summer of 2015, we started working on the prototype of Lonely Mountains: Downhill. When we began to show some gifs of the game on social media, the feedback was so amazing that in 2017 we decided to go all-in, spent our personal savings and concentrate full-time on the project.

We were lucky to get some government grants from the Medienboard Berlin-Brandenburg and we also ran a successful Kickstarter campaign which allowed us to continue working on the game full-time. Noah, our artist, joined the project at the end of 2018, and also Syndrone came on board to take care of all the sound effects. Around that point, we realized that the game became way too big for our small team, so we partnered up with Thunderful, who took care of the distribution and marketing side of things, as well as the console versions (which were done by the awesome folks from Retroid Interactive).

The idea of the Project

One big inspiration for the game was a small mobile skiing game called Skiing Yeti Mountain by Featherweight Games. The game is simple but has incredible tight controls. Jan is a big bicycle and mountain bike fan and came up with this very simple prototype for a biking mobile game. It was already really fun, even at an early stage. Over time, the concept evolved from a small mobile game to a full-fledged PC & Console game.

Prototyping and Mechanics

Being impressed by the feeling of flow and precise control in the above mentioned “Yeti Skiing Mountain”, Jan tried to create bike physics & controls which are simple, fun and - although not necessarily physically correct - feel “real”. We always tried to keep the complexity on the input side (number of buttons, so to speak) to the absolute minimum. This made it easy for new players to learn the controls but also helps to focus on the flow of trails later on.

For a game like this, good controls are key - if they are no fun, the game is no fun. Therefore, the first phase was dominated by endless iterations of controls and physics. We didn’t spend much time on the environment or meta gameplay until we were happy with the core gameplay - riding your bike. And although this felt almost finished in early 2017, it was revisited over and over again throughout the whole development - even into our latest update.

Physics of the Game

Over the years, we talked to many other developers and those who tried agreed: Bike physics is surprisingly hard! Starting out with the standard physics engine, we had a bike with two-wheel colliders - which was tipping over all the time. Simulating all kinds of forces to keep it upright, we soon realized that it would be easier to get stable bike physics by faking them. This worked out quite well most of the time but in a lot of edge cases, it didn’t behave as intended at all. 

So, the next approach was to have the core movement based on real physical rules. Simulating inertia, drag, gravity, the friction of the ground, etc. lead to a solid and stable, however, not really believable movement. Faking the influence of some of the previously unstable aspects - for example, the lateral balancing of the bike and the suspension of the wheels - and the help of multiple blended animation clips and those satisfying MTB-wheel-digging-into-gravel sounds the overall impression was finally pretty convincing.

Collisions were a different topic and caused us a lot of headaches. Having moved away from the “normal” physics engine, we had to find ways to mix both worlds. We ended up having a combination of raycasts and some rigid bodies moving along with the bike just for collision detection. Once the player crashes the bike, and rider is handed over to the physics engine, and the ragdoll setup is taking over the now the following calamity.

Working on the Style

We decided early on that we wanted to go with a detailed low-poly style for the game. The decision was not mainly driven by production reasons but more for the sake of aesthetics and gameplay. Our initial visual inspirations for the game were Lara Croft GO and Monument Valley. But with time, the visual language of LMD evolved, and we believe it’s now standing on its own feet as we added a lot of things which make it very distinguishable from other low-poly games.

One of the reasons we chose this was that Lonely Mountains: Downhill is a pretty fast game with a nearly open-world approach to the level design. So gameplay-wise, we wanted our graphic style to be very readable. A style that would allow a player to understand the trail design at first glance. If we would have gone with a more realistic approach, then the mountains would have turned out very noisy, as you need more complex foliage and terrain assets to pull it off. A simpler look also makes it easier to create memorable landmarks and trail sections as people have to remember fewer elements. 

From a production standpoint, it might have been even easier to go with a more realistic approach, as the standard workflows of Unity’s PBR pipeline are well established. However, we had to experiment a lot with different shading approaches to achieve the look we wanted. In the end, the game heavily relies on a whole bunch of custom shaders.

A big challenge with our approach is that it's way harder to “fake” details. We don’t use classic textures, normal maps or sprites/billboards in the game, which means every leaf on a tree is actually geometry. This makes it also way harder to build LOD assets for things that are already pretty low-poly, to begin with. So although it’s a “low-poly” game, several areas in the game have well over a million triangles on the screen. For this reason, performance optimizations took up quite a large chunk of the development, which included developing our own terrain-, pooling- and LOD-system.

Level Production 

When we started the development, we build the first levels with the standard Unity terrain which was then automatically converted to a low-poly mesh. At that time, each section of a trail had its own Unity scene which was then loaded and unloaded at runtime. But at some point, it turned out that this workflow was really impractical and had a lot of restrictions on the level design. So, we decided to build our own terrain system and level building tools.

The way it works now is that one whole mountain is in one Unity scene, which makes iteration times much faster as you don’t have to switch between different scenes anymore. Optimal workflow for a mountain looks like this. 

1. We begin with a flat terrain divided into small chunks (a few hundred of them). The chunks are important as each chunk has its own LOD mesh. 
2. We normally start by using a spline tool, which automatically sets the height of the underlying terrain. We use this to block out the basic trail design. Afterward, we use our own sculpting tools to sculpt the terrain around the trails or to sometimes sculpt whole sections. 
3. We then do a basic layer of texturing. Mainly to separate the main trails from off-road sections and to mark cliffs, riverbeds, etc. 
4. We add a lot of standard Unity cubes and capsules as placeholders for rocks and trees. 
5. We set the basic lighting for each trail.
6. We set start, finish and checkpoints.
7. At this point, the mountain looks ugly as hell but it is completely playable, and we do a lot of playtesting at this stage. We then refine the trails and terrain with each playthrough, adding more shortcuts, blocking ways that are too obvious, adding possibilities for jumps, etc. We also add some camera modifiers if we feel that certain level sections need a higher zoom level or a slight pitch of the camera. This stage takes quite some time during production.
8. When we’re happy with the blockout stage, we start to fully decorate just a few sections of the mountain to get a feel for the different vegetation zones we want to have. Even though a mountain has four trails, we want each of them to feel unique. 
9. During that step, we also make more detailed paint over on the terrain grounds to make them blend in more naturally. 
10. When we feel satisfied with the small visual slices we decorate and paint the textures for the rest of the trails. Although each of our mountains consists of several hundred thousand assets like rocks, flowers, trees, etc. we place every single one of them per hand. For this, we’re using a plugin called PrefabPainter2 by nTools, which allows us to create groups of objects and scatter them with random rotation and scale. 
11. Normally, we’re doing another round of playtesting and iterating now. Often, the trails feel very different from the actual assets in them. Something which might have been easy and readable during the blockout stage is suddenly way too hard or not understandable anymore. 
12. In the final visual polishing phase, we do some adjustments to the light and color grading, as well as adding fog, particle effects, and birds. Also, our sound designers from Syndrone are now placing all the sound emitters.

This whole process normally takes between 3-4 months or longer. While Daniel is doing most of the blockout phase in the beginning, Noah is taking care of the actual level art and placement of the assets, particle effects and birds.  

Creating Multiple Paths 

As mentioned, a full mountain and every trail on it is built by hand. This also true for every shortcut. In terms of planning, we normally have a broad idea for a mountain and some very, very rough concept for the trail design but most of the actual level design happens through playtesting and iterations. 

We always design one main route for each trail - the scenic route. It leads the player through all checkpoints and along with all the important landmarks and vantage points. It’s most of the time the easiest way down but, of course, it also takes a long time to follow it all the way down to the valley. 

Along the main route, we have several types of shortcuts. The first one is a kind of “official” shortcut. These are the ones that are clearly visible (often indicated through small muddy paths) and, as a player, you know that you’re supposed to take them. 

The next level of short cuts is kind of “semi-official”. These ones do look like they are just a natural part of the terrain and they are way harder to find and ride but they are deliberately designed by us, and the players need to find them in order to achieve the harder challenges.

At last, we have “unofficial” shortcuts, which were not actually intended in the original trail design but that are made possible through the physics system. These are the shortcuts used by competitive players or speedrunners. We didn’t even know a lot of them before release.

We start the actual trail building very early as it is easier to actually just start building a mountain than trying to draw more detailed sketches. It also allows going into playtests with the team early on. The biggest challenge level design-wise is the camera, as it only works with certain angles, and you always have to be careful that the terrain doesn’t suddenly block your view. 

But the camera also works in our favor a lot of times. Knowing ahead what the player can see allows for a lot of nice level design techniques. 

• We can use the camera to foreshadow later parts of a trail - or even trails the player hasn’t unlocked yet.
• We can use it for flashbacks to show the player what she/he has already accomplished.
• We can hint at shortcuts in the background, showing that there is something you missed on an earlier ride. 
• We can hide shortcuts behind objects or away from the main trail. 
• We can make sure that important landmarks are clearly visible. 

Texturing

We use several textures, but not in the “classic way”. The environment objects get their primary color via a lookup texture, which is basically a small texture with lots of small color patches on them. This way, we can swap out colors and work on the whole color palette in one single place. Slight color variations are applied to those colors per object, so none of the trees looks exactly the same. On top of that, a fine noise is mapped onto all objects to give it certain materiality (some call it paper look). A rough ambient occlusion pass is painted onto the vertices, which often helps to define the volume a bit more. Last but not least, to get a bit of shading on the otherwise perfectly flat-shaded triangles, the normals are automatically blended between a smooth and a flat-shaded variant.

The terrain, however, uses a different approach. Individual ground types define the ground color, but also all attached physic and audio properties. Those types are painted directly onto the terrain and are stored in two splat map textures. Two different noise textures and a special offset map create irregularities and a unique “triangulated” look.

About the Camera Work

The way the camera works is a very important part of the game, for which we had to solve quite some challenges to make it work. The core is rather simple: it follows the player with a certain vertical & horizontal angle and distance. Those two values are modified based on the current velocity and movement direction. To show a bit more of the trail ahead the camera doesn't focus exactly on the rider, but on an imaginary future position of the rider. As the rider changes direction and speed frequently, the main challenge here was to find the right balance between a fast enough response and keeping jerky, distracting movements to a minimum.

To be able to guide the player's view, we sometimes use manually placed triggers, which then have an additional influence on those values mentioned above.

We use several post-processing effects to complete the look. Depth of Field is probably one of the most obvious ones and helps the player to focus on the area in front of the rider. Screen Space Ambient Occlusion, Temporal Anti Aliasing, Color Correction, fog, and a custom Heat Haze effect work together to finish the overall look.

The Biggest Challenges

Every stage of the development had its own challenges and difficulties. The Kickstarter was probably the hardest one in terms of overtime but it was also very motivating and rewarding. 

The least fun stage of the development was definitely the end. The last few months where you just spent all your time on bug fixing, console requirements, performance optimization, etc without adding anything new or fun to the game. At the same time, everyone is already powered out, finances are running low, and a lot of time has to be invested in marketing and PR stuff, while the final deadline comes closer every day. So one advice for starting indie developers might be to make sure that you actually have enough power and resources - mentally and financially - to not go bankrupt or insane after your game is finally released.

The Audience’s Reaction

Although, in general, most people seem to enjoy that the game is very challenging, the difficulty is definitely the most polarizing aspect of it. Especially, when it comes to unlocking new bikes and new trails. We now know that a lot of players just want to enjoy the riding and game-feel without being pressured into too difficult time trials. We’re currently thinking about ways how we can make the progression easier without taking away the feeling of accomplishment for players, who are looking for a challenge. 

The game is available on Steam, PS4, Xbox One as well as on the Windows PC Store for $19.99. It’s also part of the Xbox Game Pass at the moment and will come out on Switch in Q2 this year.

Daniel Helbig and Jan Bubenik, Founders of Megagon Industries

Interview conducted by Ellie Harisova