Procedural Terrain Painting Using Noise Map Stencils in Chalo Chalo

We've changed to a different system for generating terrain. The new approach is to use noise maps (combined and modified in interesting ways) as 'stencils' for painting the different surface types onto an existing screen full of Voronoi cells. It's a far more powerful approach, allowing us to create all kinds of maps that weren't possible before. Like the one shown in the picture below.



In our previous map generation code each cell decided for itself what surface to take on, a decision it made independently from its neighbours. This meant that if clusters/patches of cells of a given surface type appeared, they did so entirely by chance - we had to power to create distinct patches deliberately. The result was fragmented looking race maps containing no high level order/patterning. Like the following one:



The new system uses a port of the LibNoise library for Unity. LibNoise is a library for creating coherent noise. In the gif below you can see a visualisation of how grass (the green surface) is 'painted' onto our map cells. The noise patterns are shown as red and blue images. Blue areas represent values below 0 (the darker the color the lower the value) and red areas are values of 0 or above (the closer to white the higher the value).

First Perlin noise is created, i'll call that p1. To p1 is added a noise pattern with a horizontal stripe of low values, and higher values at the top and bottom. I'll call the result p2. p2 has no red shapes in its vertical center anymore, and bigger red shapes at the top and bottom. To p2 is added a patten with low values on the left hand side of the screen. This gives p3, which now has no red shapes in the leftmost area of the image.

For each cell of the race map we retrieve the value of p3 at the cell's center point. If the value is 0 or higher, we 'paint' that cell with the grass surface. Optionally we can increase the 'sensitivity' of the sampling process, by sampling more points nearby and compare the maximum value returned from all those samples against 0 instead. This helps if we want more of the red areas in p3 to translate to grass cells in our race map. 

We combine noise in different ways to create stencils for different surface types. Often we want more tar in the middle of the map for instance. Here's a map from the 'Regular' biome that's been created with this approach.

The image to the left is another representation of the map building process. Thumbnails A to D show the process of creating a grid of points, randomly nudging them around, and then deleting points using a noise map, C,  to control the likelihood of any given point being removed.

Bright areas of the C image correspond to areas where fewer points will be removed, which will translate to areas of the final Voronoi diagram (G) that are more densely populated with smaller cells.

Previously we had to be careful about allowing too much lava to show up in a race map. We had no test in place to ensure that the race map could be completed. If the goal was surrounded by lava the players couldn't exit the race. Now we're using the A* Pathfinding Project to fix this problem.

After all cells have been painted, the map creation routine checks to see if there are enough lava cells to potentially block the exit. If there are, we use pathfinding. First a grid of pathfinding nodes is created, each node connected to its eight neighbours. For each node, the terrain type for that location is retrieved. The node is given a 'cost to pass' value corresponding to the surface type. If the node is on lava we assign a very high 'cost to pass' value and add to that a (potentially) large random number. We then ask the pathfinder to find the cheapest/shortest path from to the start zone to the goal. Once the path is returned, we step through it doing a spherecast from each node to the next one. We 'zap' any lava cells that the spherecast touches, reverting them to the most recent non-deadly surface they were previously set to (each cell has a memory of its previous surfaces for this purpose).

Because of the high 'cost to pass' assigned to lava node, the pathfinder will avoid lava if at all possible. If it does have to go through lava, the route it takes is made unpredictable thanks to the random component of the lava nodes' 'cost to pass' value. Here's a visualisation of the pathfinding. Green circles are points at which lava cells were neutralised. 

One of the nice things about this system is that by re-using the same noise maps (with different thresholds) to paint different surfaces you can very easily have a patch of one surface show up inside an area of a different surface. In the following example the grass painting routine uses the same noise module as the ice painting routine, but demands a higher noise value before it will lay down any grass. This gives narrow seams of grass within, and following the direction of, the larger flows of ice.



Here's one of Richard's biomes. He's combined noise modules to cut away more of the lava on the left hand side of the map, creating some dead ends that players need to watch out for. The closer to the goal we get the more grass and ice are introduced, making things more risky. The lava cutter routine guarantees that the goal is always accessible.



Our original Post It notes style terrain allowed large areas of one surface type to contain smaller ones of another, but the overlapping squares created an uncomfortable (to me) suggestion of foreground/background on a surface that should read as being flat.

Our next iteration, the cell-centric Voronoi maps, solved the figure/ground problem by visually flattening the race maps, but the algorithmic isolation of each 'dumb' cell also meant we no longer had patches within other patches and other interesting patterns.

Our new noise-based map generation approach combines the best parts of both our previous systems, and allows us to design spatial relationships between compound surface shapes, giving us many new possibilities for world-building.

Photos of Chalo Chalo at Radius Festival 2015 in Vienna.

We showed Chalo Chalo at Radius Festival in Vienna. The event took place in the Ovalhalle in the lovely MuseumsQuartier. Though not very crowded, enough people showed up for quite some very fun matches with some very enthusiastic and competitive crowds.

An earlier post talks about our reflections on the event. Now an impression in pictures.

  

Ludo-fundamentalism for the people

Chalo Chalo is a local multiplayer racing game in which planning ahead is more important than fast reflexes and skillful vehicle handling. You pilot a slow-moving dot towards a goal at the other side of an abstract landscape. Success hangs on your ability to figure out a faster route than your opponents.

We are Richard Boeser and Tomasz Kaye. Neither of us are prescriptive in terms of what video games should be, but when we’re making design decisions for Chalo Chalo we have our ludo-fundamentalist hats on. For us the game is primarily a contest between players that tests their skill at spatial analysis. We’re not striving for purity, but the space carved out for everything that’s not part of that core dynamic - such as the decorative elements, the suggestions of narrative and world lore - is shaped by the question ‘will this thing obscure the core mechanics of the game more than it clarifies them?’, if so then the idea gets dropped.

Transparency is very important to us. Chalo Chalo has a stark, minimal look. The game’s visual language is abstract geometry. Players and audience can see the whole race map from a bird’s-eye view. Any aspect of the game that could influence one’s odds of winning a race is made visible so it can be incorporated into players’ plans. Coloured trails make it easy to review the players’ routes, helping to understand exactly how the various terrain types affect speed and steering.

The control scheme is very simple: Any analogue stick to move. Any button to perform a context-dependent action. Likewise it’s quick to explain to a new player how to get started: Try to get to the goal first. You travel quickly on grass, slowly on tar, and ice is slippery. Don’t touch the lava!

We often see people who very rarely play video games ready to join in after watching only a couple of races. It’s very gratifying to see frowns of concentration followed by yelling - frustrated and then joyful - from people who apologised as we passed them the controller “I’m not very good at video games”.

We believe our approach avoids many potential barriers that could get in the way of new players enjoying Chalo Chalo. We’re keen to emphasize that we see this facilitation as a very different thing to design decisions that ‘de-game’ the project. For instance, we could serve up a series of flashy, superficially entertaining, events to enliven a race. But in our opinion the exciting moments of Chalo Chalo carry more emotional weight because they’re authentically the product of players’ struggle.

We’re designing Chalo Chalo as though it could be a sport. Aside from map generation, we don’t use randomness in ways that could affect the outcome of the race, minimising the importance of luck. We want the winner of a race to feel that they won in a fair competition, and losers have only themselves to blame for their defeat.

Encouraged by play sessions that attracted a broad cross-section of players, we’re respectful of the fact that non-gamer should not be synonymous with non-competitive or ‘casual’. We believe Chalo Chalo welcomes non-gamers while providing an experience deep enough for experienced players to also find a challenge in.

An appetite for competition and an appreciation for simple rule sets that allow a wide range of memorable play experiences are more widespread than contemporary game design might account for. It’s exciting to explore this territory as we make Chalo Chalo.

Reflections on Chalo Chalo at Radius Vienna

If you'd like to be notified when Chalo Chalo becomes available you can enter your email address into this form.

We had a fantastic time at Radius. I'll talk about some of the things specifically relevant to Chalo Chalo.

The responses to the game that we were aware of were very positive. There was lots of frowning and yelling and by the final day we had a group of regular players who kept returning to join in with new matches.

This was the biggest presentation of the game since we'd made a bunch of significant changes. Some of our players remembered previous versions and commented on the changes. The most significant among those:

• Landscape generation is now based on a voronoi graph rather than overlapping squares.
• Powers take the form of single-use pickups that can be collected during a race (and carried to the next). In older versions there was a power selection screen between races.
• We added the possibility to 'nudge' nearby opponents when no power is armed, an action which also works as an instantaneous brake, which can be especially useful on ice.

Looking through the folder of of automatic screenshots, we can see that more than 622 races were played. This kind of intense use helped us spot bugs we'd missed before. 

• Under certain conditions a player will always start a new race with Tar bomb armed.
• The Shinobi teleport power allows a player to teleport to the outside of the barrier around the edge of the map, locking them out for the rest of the race.
• Sometimes mysterious duplicate players will show up.
• A 'Drunken autopilot' bug was described to me in which a player couldn't steer any more, and instead their dot veered around as if under computer control. If this is really a bug (and not a result of watching the wrong dot) it's by far the most mysterious, because there's no AI in the game at this stage.

There were some moments that I expect to remember for a long time. At one point a match with many players, including Richard and myself, was underway. A young boy with blond hair and a green T-shirt sitting to my left was also playing. He was quiet throughout the game until half way through the match. He implored in a German accent "I'm yellow and I need help". The help wasn't forthcoming but he cleanly beat all of us adult players in the next race thanks to his deft deployment of the Blindfold power.

And there was the time when most of the racers in a very busy map careered down a grass path without spotting the lava dead-end until it was too late. The lone player slogging through the tar further down the screen won by default.

As usual, several people asked whether Chalo Chalo's resemblance to human reproductive biology was deliberate. The name 'Sperm Race' was suggested. We have no current plans to pursue such a rebranding.

We had some useful discussions between the two of us, and with others, about the direction of the game. Most of it validating the biggest decisions we've been making. There's still lots to do but now it's either polishing or implementing things we're very confident will improve the game, rather than things that feel risky like the recent big changes did. I have the idea that an early access release candidate isn't a million miles away any more.

Here are the bigger things we still have planned:

• Landscape generation: Switch to a system based on stacked noise generators to enable compound terrain patches and biomes that have a more visible, and distinct internal logic to them.
• Rare things: Implement some of the ideas we've had for things that happen very rarely in the game.
• Tournament mode: An in-game way of facilitating local tournaments.

The MuseumsQuartier is the perfect place for the festival. It felt very comfortable to step out of the Ovalhalle after the day's exhibition was over and straight onto the square to drink a can of beer with Vienna's friendly locals and visitors.

Chalo Chalo at Radius 2015

Chalo Chalo will be at Radius in Vienna. You can come and play on Saturday, 11th of July 2015 and Sunday, 12th of July 2015. It'll be in the Ovalhalle, Museumsquartier, from 10:00 until (last entry) 19:30.

Voronoi mock-up

Richard made this mock-up for the Voronoi scheme. I think it's looking great. Perhaps this is the moment it makes sense to finally buy Unity pro to get the bloom effects going.

Rationing rare occurrences in Chalo Chalo

I like when unexpected things happen in games. Better still is when the unexpected thing happens just when you feel that you've gotten to know the how the game world works. Its impact is maximised at that moment.

We have some unexpected things that happen now and then in Chalo Chalo, we call them rarities. They're designed to foster a sense that the game world has hidden depth and mystery, and to keep players on their toes.

The simplest way to implement these rarities would be to assign each rarity a likelihood. A random number would be generated and compared to the likelihood of the rare thing happening, if the likelihood was lower than the random number, the rare thing would happen. But given that the aim is to have the unusual things happening just as players feel familiar with the game, a better way to set this up is to arrange things so that the longer you've played without seeing anything out of the ordinary, the more likely you are to see something out of the ordinary in the next race (which would not be the case with the simplest set up).

Chalo Chalo is built to include a concept of 'rarity pressure'. You can think of it as 'something in the air' that influences how likely strange things are to happen. The higher the pressure, the more likely that a rarity will manifest itself. When nothing out of the ordinary is happening, the rarity pressure is incremented after each race. We want rare things to be more likely if you didn't see any for a while, and less likely if you did. so to complete the scheme, each rarity has a 'rarity_pressure_release' value. The rarity pressure drops by this amount after the rarity manifests itself.

We use a JSON file to describe all our rarities. In this file we assign likelihoods, we can also set up relationships between rarities so that they can be nested, and add directives to have rarities exclude or require one another. We have a class that's responsible for modifying/reporting rarity pressure, and another that's in charge of parsing the JSON file and selecting rarities for the next race. Because we want rarity pressure to persist between play sessions, we're currently storing it in playerprefs.