I recently picked up a copy of Frozen Synapse and have been playing it with my friends. Unfortunately, many years of first having a real job then running a startup has divorced me from video gaming enough that I’m rather terrible at it. So, rather than be defeated I’ve turned my energies into an exploration of the level editing system for a more positive outcome.

At the time of my writing this documentation for the level editor is neither non-existant or very well hidden. As a result, I did some trial and error work and drew a few conclusions about how level editing works which I share below. I also provide images demonstrating many of these points further down. As time goes on I’m sure two things will happen:

1. The editor (which is currently in beta) will get better
2. Proper documentation will start existing

As a result, don’t be surprised to find this full of obsolete, inaccurate data. I am not responsible if your computer kills a kitten as a result of inconsistencies between this and reality.

Level Editing Basics:

• The built in level editor is unstable and laborious. Instead, the optimal way to create levels is to import .pngs with level data within the editor
• Most graphics editors save as .png. mspaint on windows is a good solution. For the tests below, I used Gimp
• To import a .png it must have a white background and at least 1 pixel of white all the way around the border. Images with colors on the border will hang the editor.
• The UI only lets you browse to folders within the Frozen Synapse folder. So I created a new folder inside the psychoff folder named “maps” and put my images in there, so they would be accessible in the game
• Red pixels make up solid walls, blue pixels make up cover.
• The colors don’t need to be perfect. I.E. 0xFF0000 is all red, but 0xAA0000 also works
• 1024×768 is a good starting size for a 3 or 4 man game
• Circles and diagonals are allowed. But I’d be wary of their impact on pathing
• A shotgun can aim through a 1 pixel hole or 1 pixel of cover
• A unit needs at least 23 pixels to make it through an entryway. However the rules are not consistent (i.e. not every 23 pixel entryway works).
• It is easy to test level pathing in the editor

A blank room to start with

Here is a blank 1024×768 room to get you going:

An empty room, ready for editing

Rendered version of empty room (with an added unit for scale)

Test 1) Scale

The first thing I wanted to establish, was the scale. How many pixels do I need for a reasonable level? So I created two rooms, one 320×240 one 1024×768. I gave each level a red 6 pixel border (with a slight gradient). Below are the source .pngs and the results as rendered by my game. From this it’s clear that 320×240 is a bit small, 1024×768 is actually quite good, and 6 pixels is a bit much:

The starting point for most of my tests	Rendered version of basic 320x240 room w/ unit
A basic 1024x768 level	A basic rendered 1024x768 room w/ unit

Test 2) Circle

Every map I have seen so far is made up only of corners. After reading Mode 7′s blog post on path finding I would highly recommend avoiding anything other than corners in your maps because as you can tell from the images below, the circle ends up being rendered as a many-edged shape (Priests from Flatland!) which will cause a lot of extra work for the pathing algorithm. That said, I intend to put rounded edges in the first map I make. As a side note, to anybody from Mode7 who ever reads this: Please write more blog posts like the above. I really enjoyed it!

A circle

A rendered circle

Test 3) Diagonal Lines And Intersections

For something a bit more reasonable, I tried diagonal lines and a 4 way intersection. Diagonal lines are also something I haven’t seen in any maps and after looking at the results it is pretty clear why. Like the circle diagonal lines cause a very large number of edges which will impact the speed and reliability of the pathing algorithm. You also don’t come across too many diagonal shaped rooms in your day to day life. (Anybody ever been to Microsoft’s main campus? A number of the older buildings are shaped like X’s and contain many diagonal walls. They are very disorienting. So it’s probably best not to use diagonals in that dream house you are building)

An hourglass demonstrating jagged edges and intersections

Rendered Hourglass

Test 4) Color Gradient

This was just for fun. I do not believe there is any reason ever to use any colors other than 0xFF0000 (red) and 0x0000FF (blue). But I was curious how the editor would handle a gradient from red to blue so I created the scenario below. To its credit the result was solid wall in the reds, cover wall in the blues and the area of extreme overlap in the middle was left out. You guys win this round!

What happens when we fade from red to blue?

The rendered gradient.

Test 5) Small Squares for Scale

Not a test so much as a reference. Below are 7 squares. The is a single pixel, then a 2×2, 3×3, up to 6×6. Then, for no explicable reason I skipped 7×7 and created an 8×8 square with the inside hollowed out. Unsurprisingly a hollowed out square works the same as a regular square. Based on these results it’s pretty clear that pretty much any width wall will work so it’s best to choose what makes the most sense from an aesthetics point of view. If you are trying to give a specific room the feeling of being very strong, make the wall a bit wider. Similarly, tenuous cover zones might want to be made smaller.

Squares ranging from 1 to 8 pixels wide

Squares going from 1x1 to 8x8

Test 6) Minimum Doorway Width

Hopefully somebody who knows more about this than I do will read this and explain to me what I did wrong here. Possibly insulting all that which I hold dear – I deserve it. A common problem with maps I have tried is that units can’t move through doorways because they are too small. The test for this seemed simple enough. I figured the minimum doorway width would be around 25 pixels so I created a bunch of holes of increasing size starting at 20 and ending at 28. I put a unit on one side and double clicked the other side. The result, however was that the auto pathing was only able to go through the 23 pixel hole. I couldn’t even get my unit through the larger holes (hehe) by manually pathing them through it. In a fit of rage I closed off the 23 pixel hole and now the unit just stayed on its side of the level, unable to progress. So the takeways here are curious enough they are worth calling out:

1. The minimum hole size a unit can go through is not a constant. 23 worked on the same map that 24-28 did not.
2. It is the responsibility of the map maker to test every doorway. Don’t release a glitchy map.

Holes ranging from 20 to 27 pixels wide

The strange path between the holes in the wall.

Test 7) Minimum Cover/Hole A Unit Can Fire Through

Spoiler: the answer is 1 pixel. I created a wall and put a single pixel of cover in it. Then a 2 pixel cover, 3, etc. Then put a unit on the other side and decided to see at what point my unit would get shot. Turns out a shotgunner can shoot through a 1pixel opening just fine. There was no delay or any other measurable change between the 1 and larger pixel holes.

Same image as test 6.

Shooting through a 1 pixel hole

Hope this helps

After doing this work, I’m ready to try and create a fun level. It is still a bit odd to be creating a level with an image editor and not some crazy level software (anybody remember the D-Zone level editor for Doom?) but I’m excited to do it. In the future I expect the built in editor will become more stable and quicker to use and it is possible the image importing will fall by the wayside. Until then, I hope this helps!