Anatomy of a Level

Over the past few months we spent quite some time iterating on levels in preparation for Early Access. Most of them now feature improved graphics, a dedicated music track and countless gameplay improvements. But how does a level in Guntastic come to be?

The workflow we currently use is the result of our past work experience with 3D shooters and experimentation done in the early production phases of Guntastic. If you’re only interested in the actual workflow, feel free to jump to the final section of the post. Otherwise, read on.

In The Beginning…

When we first started working on Guntastic we didn’t know much about what the game was going to be, apart from the fact that it would be an arena shooter at its core. We decided to go this way in part because we love shooters and we believe that going indie should be about building the games we love (take this you cold, number-crunching business people!), but also because most of our past work experience involved building shooter games. With so many things that can go wrong while developing a game, we felt that a shooter was our safest bet (reality check!).

One of the fields in which we benefited the most from our background was level design as most of the guiding design principles for 3D levels can be applied to their two-dimensional counterparts. In particular:

1. Gameplay and visuals should work in tandem. Always design for gameplay first, but having an idea of how the level should look like in the end makes the final result feel more natural.
2. Using a modular approach based on grids and reusable assets makes it easy to think about, prototype and build levels. It also promotes visual clarity, aiding players navigating the world in an intuitive way.
3. Each level should look and feel unique, both from a visual and gameplay point of view. Players are more likely to remember how to play a memorable level rather than an uninteresting one. (Plus, memorable usually means more fun at the design stage!)

Prototypes! Prototypes! Prototypes!

Guntastic, however, was still our first 2D game – and a very particular one. A whole level needs to fit on a single screen and have enough room to accommodate four players at the same time: two prerequisites that immediately enforce severe constraints on the level design. We also had character movement to sort out: how high could a player jump? Were there going to be special movements such as dodges or wall jumps in the game at all?

Since the best way to figure things out is through experimentation, we started creating rough level shells to play with. The following is the prototyping kit I originally put together in Photoshop back in 2016 and that we still use today to block out level shells. It includes tiles of various sizes and shapes that can be combined in a wide variety of ways. The idea of having half-tiles came a bit later, and proved crucial to deal with the very limited amount of space available on screen.

We spent several months iterating on an handful of levels as we tweaked the movement mechanics to our liking (more about this in an upcoming post). Dynamic environmental elements such as moving platforms, lifts, jump pads, areas with lower gravity, teleporters, destroyable elements, death pits, traps and more were gradually introduced into the mix. Working almost exclusively in Blueprints proved invaluable at this stage, enabling very fast iteration times (although most things were later moved to C++ for additional flexibility).

During this time we also started investigating the production of tile sets and environment pixel art. The first environment we envisioned was an underground sewer. While definitely not the fanciest way to start, it provided us with a good amount of artistical challenges in a small and controllable scope. It gave us a chance to practice with different materials, rounded shapes, backgrounds, lights, decorations and more and proved a great learning experience overall.

Of all the levels built during this stage, only two survived in the long run – with the rest being discarded because overly complex, difficult to navigate or simply boring to play.

Summing It Up

As we built new prototypes we found ourselves relying more and more on dynamic elements. Doors, jump pad, lifts and destroyable elements not only helped players move faster around the level and created unique gameplay opportunities by encouraging players to be creative with their surroundings, but also made levels far more unique and memorable. Some elements simply didn’t work and were cut. Moving platforms, for example, required way too much room to work, leaving no space for anything else. We also realized that having traps and death pits that killed players on touch (which counted as suicides, resulting in a one-point penalty) was frustrating and often left players wondering as to how and why they died and lost a point.

The turning point with environmental traps was the lift in what later became the Sawmill level. The lift needs to be activated by a player and has buzzsaws underneath that kill opponents on touch, rewarding the player who activated the lift with a point when that happens. This was a big paradigm shift. Players were now in charge of activating the traps found in the level and could actively exploit them to their advantage without risking penalties. This gradually pushed us into implementing dynamic elements that were more audacious, to the point that new levels could be built around a main dynamic element which also set the overall visual theme of the level.

The Actual Process

This brought us to the process we currently use to create levels. We first envision a strong dynamic environmental element and then block out the level around it. During this stage we search the internet for reference images and prepare mood boards to help later on in the process. The first sketches of both the layout and visuals are carried out using pen and paper. Things don’t need to look pretty at this stage (and in fact they don’t).

Once the layout looks promising we rebuild it inside the editor using the prototyping tileset. Dynamic elements are implemented at the same time. We test and iterate on the level until we’re satisfied about how it plays, changing the layout and the way dynamic elements work as we see fit. If we don’t like where things are going we simply throw everything away and start over.

The next step is what we call the mood pass. I take a screenshot of the final level layout (this is one of the few cases where having levels that fit on a single screen actually helps 😄) and do a paint over in either Photoshop or Pixel Edit blocking out the main foreground and background elements. Things don’t need to look pretty yet, but it’s important to discern what’s what. Special care is also put into making sure everything is tidily aligned to the grid. A base color palette is also defined at this stage to set the overall mood.

The level now pass on to Simone who uses the mood boards and additional references to perform the main visual pass.

Once the visual pass is complete, it’s my turn to break everything up in an easy-to-use tileset. This is important to rationalize the graphics and helps in case we need to do small adjustments to the layout later on (which we try to avoid, but things happen!). The level is then reassembled into the editor, where we add all the final bells and whistles such as lights, eye candy and visual effects.

The whole process usually takes a month from start to finish. Naturally, it isn’t always possible to follow this workflow to the letter, but the price paid in terms of additional strain and time needed to complete a level in those cases can be pretty high. Game development is a messy business! 😄