Building Levels in Unity – Part 1 of 3

This article was originally posted on

Hi! I’m Matthias Zarzecki, and I’m making the levels Looking For Group – The Fork Of Truth (among other things).

In this series we’re going to use Unity to create a game environment. The first part will deal with the basic landscape – the terrain on which the rest of the environment is built.

If you’ve seen our rockin’ trailer or kickstarter video (both now sadly no longer online) you can see the environment the characters fight in.

To make these videos, we set out to actually built a playable level. It serves as a prototyping area, to test the combat system and overall look-and-feel of the game. We wanted to use actual footage for the Kickstarter videos, so people would know what to expect. Ultimately this resulted in a fully functional game (albeit a rather short one).

Level overview

The gang starts in the lower right, they break into a village and get in the way of a goblin attack. Then they get a quest from a farmer (actually a goblin in disguise), and track down the goblin menace. They are lured into a trap, resulting in the final battle in the goblin camp:

The level takes about 10-20 minutes to play through, and is quite fun. So let’s talk about how we made this!


The entire level uses the Unity Terrain. It is a great way to create natural landscapes.

To get started with Unity Terrain, select “Terrain” -> “Create Terrain” in the menu bar. You start with a flat plane:
Unity Terrain lets you “paint” on this surface, using different brushes and sizes:
Using the Height painting tool (the first mode), you can paint height differences. Simply select the right mode, and paint your terrain on the plane in the Unity viewport:
Using the texture painting tool, it is possible to apply textures to the terrain.
Start with a base texture like grass or dirt, and take it from there:
Add extra textures to create rocks, sand, any type of ground you need:
Roads are easy to create. Simply paint a specific height, and assign a road texture to the terrain:
These are the textures we used for The Fork of Truth:
With these simple tools, you can create complex terrains that are convincing and interesting to look at. You can see the road texture painted on the right, and the height differences in the pool:
Unity Terrain is an awesome feature, and offers a wide array of options and ways to create a world. You can sculpt almost any kind of landscape with it. Create streets, rivers, canyons – all with a swipe of the mouse.


But you have to be careful not to overdo it. Things may look great, but a hilly terrain could give you all kinds of level design headaches.

Height differences make placing things a chore. You might end up spending hours adjusting the vertical position of the objects in the scene, so that they don’t float in the air or are stuck in the ground.

The basis for the LFG-game is a flat plane. There are still hills and depressions, but these are purely visual. You can’t actually reach them. You can see some of these non-flat areas highlighted in the picture below. They are inaccessible due to obstacles and invisible walls:

Another benefit of keeping your level flat is simpler attacks. Attacks and abilities become much more complicated when there is an uneven terrain. Does a summoned tornado move horizontally, or does it move along with the floor? If so, could it move up a cliff? If you are standing on a hill, does your fireball hit the enemies below or do they fly over? What about if there is a hill between you and the enemy?

Keeping the level “flat” gently sidesteps these problems. Games like Diablo, Torchlight and Magicka use a mostly planar environment as well. And with good reason.

Note that even though we kept the walkable areas flat, we did add uneven ground in some places to give the impression of depth. For the extended game we plan on using height in the levels. Height-differences and cliffs make for interesting level design, so we don’t want to leave it out for the real thing.


The characters can’t interact with water in The Fork Of Truth (yet). Should anything fall into the water anyway, like a goblin thrown by an attack, it is killed immediately.

The river in the level is a depression in the terrain, moving down to 30 units below the “floor-level”. Here you can see the river “canyon”, with some decorative objects placed within. All it needs is a bit of water:

There are different options for the water surface. The simplest version is a simple flat square with a  blue color and transparency:


Unity comes with several water shaders. This is the basic one. It has animated waves and simple reflection, but no transparency:

This one is a more advanced version (the coloring is a bit off at the moment). It is transparent, and has all of the wave-animations of the previous one:

The next one is just about perfect (it is called “Water4” in Unity Pro). It is transparent, reflects the environment, has animated waves, and nicely fits the cartoony visuals of the game. It also has an interesting “fizzle” area at the borders. Even though it has all of this great stuff, it doesn’t kill the framerate like some of the other advanced water types.


The level building process in Unity starts with the general terrain layout. Here is a summary of the tips:

  • Use the Unity Terrain for fast landscape sculpting and texturing
  • Keep the walkable paths flat for easier level design
  • Unity has several great water shaders, we used the Pro shader “Water4”

Running around in an essentially empty level with just the ground and water beneath your feet can still be satisfying. If that is indeed the case, you have built a solid foundation for the rest of the level.  

Next time: We’ll have a look at placing the objects in the level, and fill up the environment with trees, bushes, fences, and other doodads.

Curious about the The Fork of Truth? We are running a crowdfunding campaign on Kickstarter. Check it out, and if you like what you see, be sure to back the project and spread the word!


Unity and the Android Manifest file

Hey guys!

A few days ago I was finally able to port Unstoppaball DX and Vertical Void DX to Android. Reception has been good so far, and I’m glad it worked out :)

Porting and putting the games onto the GooglePlay-store was relatively straightforward. At least until I encountered this:

That is an all-encompassing list of ALL Android-devices (currently numbering 2414). Before publishing your app on the Store you have to manually check/uncheck whether each of these is supported or not. After all, any of these devices can access the GooglePlay-store (as far I can tell), and following that, any would be able to download your game.

Due to the sheer number of devices, testing all of them is ridiculously infeasible. Hell, even going through the list is infeasible. There MUST be a better way. Like “filter all devices without this feature”. That sounds doable.

So while researching a workaround I stumbled upon the Android-Manifest-File. This magical document lets you specify certain requirements of your app, like “Only run of devices with a camera”, or “only run on devices with an Accelerometer”. That’s sounds perfect.

…but unfortunately there was no documentation on how to use it with Unity. Where do I put that file? How does it look like? Where do I find it, assuming it is already present somewhere? No encompassing documentation is available for this problem. So I decided to write my own.


The AndroidManifest.xml-file

This “issue” pops up when you want to put your Unity-based Android-game onto the GooglePlay-store. I am assuming you have succeeded so far in building and testing your application, and just want to specify the store-requirements in the Manifest-file. Here’s how it works:

  • Build your application.
  • Luckily Unity creates a Manifest-File automatically. Go to the folder YourUnityProject/Temp/StagingArea. You will a file named “AndroidManifest.xml”. This is the one we are looking for.
  • In the Asset-Folder of your project (YourUnityProject/Assets) create a folder called “Plugins”. In that folder, create a folder called “Android”. Copy the AndroidManifest-file in there. It should look like this:

  • You can now modify the file from within Unity. If you open it, it looks something like this:

  • Near the end of the file, after the /application-tag, are the lines that specify which features are required by the app. Find them.

  • A typical line looks like this:
  • To make sure it works correctly, add the line

before the “/>” at the end. it should now look like this:

< uses-feature android:name="android.hardware.sensor.accelerometer"

android:required=”true” />

  • All the “hardware” features of your app are automatically listed in the manifest-file near the end. By adding android:required=”true” you make sure that only devices with this features can download and install this app.
  • If you add android:required=”false” on the other hand, devices without said feature can access it anyway (but get a warning that the app would access it, if it could). This is useful for apps where motion-controls (for example) are available, but not required.

The full list of settings is on the Android-Developer-Site.

Q: What happens if I don’t add “android:required=”true”” to a specific line?
The GooglePlay-store will assume that that feature is required.

Q: So all this stuff happens on its own? I don’t really have to do this entire procedure?
It appears so. The file is generated and included automatically.

Q: Then why are you writing this?
So all this information is in one place, which until now it wasn’t. Also I’m a nice person.


Thoughts on My Little Planetoid

Last weekend I competed in Ludum Dare and created My Little Planetoid in 48 hours. Read on to find out what I thought afterwards (a post-mortem, if you will).

What went right

This is both a science-fiction and city-builder game. The combination itself is rather rare.

Building stuff
It just feels awesome. And I love the “Build now on moon”-gag, which I think is quite good game-design.

According to people this video is “intense”. It might be due to the orchestral music, but probably because my facial expressions during Ludum Dare alternates between “frown” and “manic laughter”.

I composed this over the course of the 24 hours. The first idea of the music I had immediately after I decided on the idea, and it grew from there. It has been quite well received, with many people saying they like it and find it relaxing.

Also, the idea of a space-banjo is just awesome.

Having empty space as background meant I was able to concentrate more on the 3d-models in the foreground. And while they could be improved a lot, you’ll notice there’s a lot of detail to be found.

The combination of the sombre soundtrack and the space-y visuals worked quite well, which people also remarked positively.

What went alright

This time I actually prepared. I made a list of ideas for every possible theme. Tiny World was the one where I didn’t have anything brilliant ready, so threw in an idea I already had before. After the announcement I developed more of them, but threw them out when I saw others made them first.

Scope in fiction
My Little Planetoid has a somewhat weird range of buildings. You start out with houses and farms, which could position this game anywhere in the past or future. Then you quickly advance to Science-Laboratories and advanced-space-stations. So while it is a progression through technology, I feel it could’ve been more focused.

Scope in design
In design-terms My Little Planetoid is huge.  It has more unique features/elements than any of my previous games. It has multiple complex 3d-models. It has a somewhat extensive GUI. And, most importantly, a huge web of each other influencing resources and variables.

I was even glad when something emergent happened, but there was lot of potential for bugs and unforeseen combinations. Which led to…

Balancing & bug-testing
I literally coded in something 10 minutes before the deadline. There was no time left for dedicated balancing and bug-hunting, only what I noticed during test-plays myself. The resource-balancing now kinda works, but it does feel off sometimes.

In the end the basic resources become abundant, so you aren’t really thinking about them any longer.

I used a basic pixelated diffuse-map on all things. Sadly there was no time to take care of UV-maps, but it doesn’t really show unless you really look.

What went wrong

Failure to realize how bloody huge this project is
This led to a (frankly mental) development-speed in the last hours, and the incomplete balancing.

All in all

This was an awesome and fun gamejam. My Little Planetoid is right now one of the most-played games, and people really enjoy it. The general consensus is that this could be huge if further developed. And so I will :P

Play | LD-page | Mini-Review (at 9:50) | Review


In a flash

So I made a flash-game with Unity for the Flash in a Flash-contest.

The flash-build-feature is new in Unity 3.5, which is currently in beta. As the number of flash-players vastly outnumber the unity-players, this is an important issue. And while not all features are enabled, it’s a step in the right direction.

in Rubidium you control the flow and reactions of the elements, so that they can undergo reactions and reach their destinations.

Give it a try.


Steampunk Axebots!

So Ludum Dare 20 is currently on.

It’s a game-design-challenge to create a game in 48 hours to a given theme. The theme is “It’s dangerous to go alone! Take this!”

I made a game about Steampunk Axebots. They are on their way to destroy the evil Prof. Malevolent, but they will fail, if you do not supply them with repair-kits. By piloting rockets into them.

It’s fun. Go have a try. (or see the entry on Ludum Dare here)


Unstoppaball ranks in the top 6% in contest

Unstoppaball made the 37th spot in the Kongregate/Unity-Contest of 2011, against over 600 competitors. Seeing as I was up against professional teams of paid designers, I call this a success.

It also gave me a chance to see and study the works of my rivals, and while there were some really fun and amazing titles, the amount of amature-mistakes is staggering. So I compiled a list of dos and don’ts for creating games of that venue.

DO let me start the game.
Now. As in “right now, this instant, in 0.0 seconds”. DO NOT show me a cutscene. DO NOT show me credits (even before I figured out what this game is about). DO NOT have multiple, non-interactive screens containing exposition or tutorials. NOBODY reads the second screen. Let me start the damn game.

DO keep your interface clean
Let me find quickly what I want. I don’t want to have to spend 5 seconds (4.5 seconds too much) to comb through the clutter on your screen, which undoubtedly includes advertising for the iphone-version of your game, and facebook/twitter-buttons, to find what I am looking for.

DON’T give me an incomplete game
And then say “full version on iphone”. Well it’s not a game then. It’s a demo. An incomplete part of a game, given away for free, made specifically for marketing-purposes.

DON’T use any of these words or phrases in your title or description of your game:
“last one”
“chosen one”
“reinvention of the genre”

DO lay off the clichés
I have no interest whatsoever in playing “the last survivor of the whats-its-called, fighting against the undead hordes”. Or the terrorists. Or aliens. As soon as I’ve
read this cliché-rife introduction, the game already has a negative reputation with me.

DO try to get rid of all basic assets from unity
Seriously. Every terrain I recall playing used a basic texture already present within unity. Get a new one, it’s quite easy. And then replace all assets. Change the font. Avoid basic particle effects. Remove the “basic blue background” (which, funnily, is also the basic background for videos from the Windows Movie Maker).

DON’T include obstrusive in-jokes. Nobody but you alone will get them. Everyone else will be pissed.

DON’T make your game “bad on purpose”. It is still “bad”. There is a fine line between “so bad it’s good” and “plain bad”, and you will not be able to control it.

There will be games which are worse than yours, show less production-values, have glaring bugs and are blatant rip-offs, which will get more attention and be valued more. This will happen, always. There is nothing you can do about it. DO deal with it.

It’s not “failure” if your game somehow performs under your expectations. You just figured out a way that doesn’t work. DO it better next time.

Let there be a next time. DO start now, immediately.