Modular level design (and how preproduction can save you a lot of time)

Making games is all about rinse and repeat.

First of all, let me explain what the game I’m working on is, as that has a lot to do with its level design.

Strike Squadron Caracara is a mission-based 2D space combat game. It’s not a shoot ‘em up where you dodge bullet hell and kill thousands of enemies who happen to fly patterns. You fly missions like escort, attack, etc, besides your wingmen, like in Wing Commander, Starlancer and Freespace.

Now, the story is not about an unified Earth or an ultra tech government that reminds everyone of USA in space. It’s about an alliance formed by Latin and African countries making do with what they can. They operate out of loaned space stations, which means they have no mobile base of operations like in most space sims. Save that information for now.

Way before I decided to drop my job and freelance work to make my own game I made prototypes using Scirra Construct 2, including a number of missions using placeholder content. Fast forward to a couple of months ago, I had to define some best practices for production. The first one was to use modular pieces for level design.

You probably heard or read it before in some way or another: to reduce cost and load time you should reuse objects when building levels for you game. I had a similar experience before in other games, so I saw no reason why not to do that. Once I decided to hire a 2D artist for my project, I already knew he or she would have to build modular pieces for space stations.

My first step was making a list of such objects. Is I said, I had hands-on experience with that, so I had a good idea of what pieces I’d need. I searched for references on the internet, especially concept art and games that use modular-based construction of space stations and space objects. By the time the list was finished, it had about 10 items on it.

Once I hired the artist we had a quick chat about what I expected from those modular pieces. He did a quick pencil sketch of individual pieces, and I used the power of Photoshop to built a few examples of how I expected to use them.

The first thing that told me was that I’d need a few more pieces, especially a smaller dome/disk, and that my original idea of slicing the disk to use separately wouldn’t work as I thought.

It was also what the artist needed to understand my vision (never forget to show case uses to people you are working with, both artists and programmers!). After a couple more comings and goings, he send me a next step of the pieces, which included pieces of his own creation because, why not? In fact, I find this one of the best aspects of working with other people: they always have something to add to (and improve) the project.

A couple more comings and goings, and we had the final version of the assets! With those I built the first couple of space stations to replace the placeholders. There was, though, one big issue: The way I had built the game codewise made it impossible to use isolated pieces the way I pictured it.

I mean, yes, I could still build dozens of space stations that would look different, but I’d need to do that on Photoshop outside the engine (therefore reducing file size and loading time)..

The reason had a lot to do with how Scirra Construct 2 works.

The short version is, Construct uses Layouts (the level design, where you place objects and behaviors) associated with one or more Event Sheets (the code itself).

Now, in Strike Squadron Caracara I wanted each mission to have the player moving across many areas. Think of it like Starlancer: the mission starts out outside your carrier, then you’d jump to another area where you fight some enemies, then jump to another where there is a space station, then back to the carrier.

The problem is Construct doesn’t allow me to transfer an object between layouts. What that means is that I couldn’t have the player, any NPC wingman or ship they were escorting to another level and still maintain their instance stats (current hull, remaining missiles, etc). Yeah, I could work around it with global variables, but that would be what brazilians call gambiarra (sort of like that image below, but in code):

On the prototype level was built through code. So, whenever the player jumped to the next ‘phase’, current objects would be deleted and new ones would be spawned.

That worked perfectly with whole objects, but would be impossible (or, rather, extremely costly) to replicate using modular space stations, each with 10+ pieces that had to be in an exact position and rotation to look good.

After a few tests and sketches, I came up with two options.

First was just a variation of the former. Instead of deleting and spawning objects, they would all be set up on level creation, but each hidden in a different layer of the Layout. As phases progresses, the previous layer would be hidden and the next one revealed. It worked... but it wasn’t really more than a gambiarra. I’d still need to spawn enemies, turrets and mines, and there was a lot of risk of bugs that I’d need to address by adding more ‘ifs’ all over the code, like all stations showing up at once and causing space to look a bit overcrowded.

The second option was about changing game concept. Instead of building levels like in Starlancer, I’d do it like Wing Commander or Freespace: each mission uses a single level/layout. Now, you see, if the player’s base of operations was a space station, not a space carrier, space would need to be huge. That implied the risk of players getting lost while scripted missions tried to handle where they were and where they were supposed to be. It probably would also need a map, a feature I didn’t include in my original budget.

My experience with 3D space sims told me huge levels are dangerous. I remember watching physics fall apart when the player got too far from 0,0,0. But research told me that wasn’t an issue with Construct. It was in fact one of its strength: been 2D and built with HTML5, the actual level size was (almost) irrelevant. What matter is the number of objects displayed on the level. Now, if I’m building space stations with modular parts...

So I did it. While the original level was around 3,600 pixels by 2,600, I tried 100,000 x 100,000.

Let me put this in perspective: It took me 9 minutes holding down the max speed key to cross the map from one side to the other.

So, yeah, that’s a lot of space. And I confess I was tempted to rethink the game turning it into open world. But, hold! Not now. Next game. Yeah. Next one will have an open world and a bunch of other things I want to do. Not now.

Now I’m working on a mission-based military game, and we don’t want pilots going AWOL while the convoy they were supposed to escort get killed.

What if I tried a mixed solution? This is where I am right now:

The station is a separate layout where players interact with NPCs (much akin to Banner Saga’s city view). When they leave on a mission, they watch their ships launch and jump out. A new layout is loaded. This layout may vary in size and will contain everything the mission requires already built into it. New elements may change or spawn as necessary, but the game will be planned so that the player has some limited exploration liberty. Maybe he comes across smugglers dealing with pirates; maybe he finds enemies preparing an ambush. Who knows?

For now I’m building these new levels to see where I can go with it. Maybe I’ll end up creating a massive 50.000 x 50.000 pixel modular space station just for the hell of it.

I need to test this format, then rinse and repeat.