Crafting the rooms and levels of Bombslinger feature

When we started working Bombslinger we didn’t anticipate how hard it would be to reinterpret a classic gameplay like Bomberman’s. Especially when it comes to level design, the “rigidity” of the classic grid-based gameplay brings a lot of implications.

This article focuses on our level design process iteration history, the tools we’ve been using and all the level design guidelines we figured out along the process.

In case you’ve never heard of Bombslinger, our baby is a Bomberman-inspired Spaghetti Western action game with rogue-like elements. It’s focused on single player but there’s a hectic 4-player battle mode to keep all Bomberman fans happy. Mode4 has been working on it for two years and it’s currently on Steam Early Access. The core team is made of 2 people, Ferry Keesom and myself, plus wonderful collaborators at various stages in the development

I refer you to this previous article for more general insight on the project.

Level design: from then to now

We always wanted Bombslinger to be a replayable and non-linear experience. Procedurally-generated content seemed like the way to go, not least because of our team size and composition (two people, with no internal artist for “set-piece” style levels). We figured that although the initial investment to produce the mighty algorithms might be higher, it would pay off in the long run, with us being able to churn out way more content. I know procedural content 1-0-1.

So, on to procgen (that’s what I’ll be calling it from here on)!

Our first public test, three months after starting the development, involved going to a major local event to gather feedback on fully-procedural rooms that looked like the pictures below.

For this, Ferry created a room generation editor (all in-Unity) to input some parameters and see the output. The coolest thing about the editor is that at any point, pressing F5 would allow us to test the current room/level seamlessly and go back to editing mode by pressing ESC. This is something that was maintained throughout all the development and it was a huge timesaver!

The way the algorithm works is roughly this:

• Generate a rectangular room of random size (capped for minimum and maximum values)
• Pick a corner of said room
• Generate a new room of random size and make it intersect with the previous room. The rooms could intersect “a lot” or “just the corner”.

The reason why everything is very rectangular and regular is due to us just starting the project and not knowing yet what the actual level design constraints the game would require.

Although primitive, the system generated enough variety for us to get a first sense of what worked and what didn’t, which was the goal of the prototype.

And the first impressions were not so great.

Bomberman-style gameplay involves dropping bombs and waiting for them to explode. Huge rooms meant a lot of waiting, leading to a general lack of pacing and moving around felt like a chore with little in the way of regular payoffs.

Last but not least, Bombslinger’s gameplay in very wide spaces didn’t feel challenging. The bomb gameplay is all about anticipation and space awareness…too much space makes the gameplay dull.

We could have explored this further by adding more irregularities and rules but I guess both Ferry and I felt like that was not going to go anywhere. So we unanimously decided to scrap it and split up the space in smaller chunks or “rooms”.

Hand crafting the rooms

At this point we decided to create our own tools to craft the rooms, make them interesting and connect them together to form a level. So Ferry frankensteined the original procgen tool with new room and level modules. This is what they looked like:

The room editor is a classic tile based editor. Nothing major to see besides the “padding”, which is the outside solid wall the room needs to fill the camera view. This is because some rooms are small and leave a lot of free space around them.

We didn’t feel like dynamically modifying the zoom level would benefit the game so we chose this approach but it has some drawbacks like vast amounts of padding walls looking boring and static (we mitigated that with moving cloud shadows, very handy!). Also, since in-game we trigger the room change when the player reaches the border of the room (padding included), the connecting paths are (at least) always as long as the padding is. It’s not great and it’s something we still hope to improve.

By trial and error we figured out a good value for it but on very wide screens (> 16:9) we display lateral black bars to somehow limit the length of paths.

Still, we’ll probably try to improve this, maybe by automatically generating the padding required to visually fill the outside space.

Rooms crafting guidelines

When it comes in comes to creating the rooms in a Bomberman-style games, having Bombslinger tested every month at local events was super effective (no events near you? Start your own like we did!). While testing, we quickly noticed several block patterns that didn’t quite work.

Hard blocks, soft blocks and the space around them

A Bombslinger room grid is made of indestructible “hard blocks” and destructible “soft blocks”. Considering that bombs explode in a cross-shaped fashion, the core gameplay of Bombslinger revolves around observing your surroundings and finding an efficient bomb-drop spot that allows you to hit your target and gives you enough hiding/retreating options.

If no “soft blocks” are present near the player, nothing should impede the movement around hard blocks and bombs. For instance, occurrences like what you see in the picture below should never (NEVER) be in Bombslinger.

We ended up breaking the grid in a few spots like the start rooms, but these have no enemies and pose no immediate threat to the player (it’s always possible to blow oneself up though!).

One-tile corridors

This is a big no-no, as it breaks the grid gameplay and makes it impossible to hide from bombs. Taken to the extreme, if your bomb is powerful and the corridor is too long, you don’t have time to move away from the corridor and you’re guaranteed to lose some health, nothing you can do about it.

The exception to the rule are the bridges, where we allowed for more narrowness…for no real reason now that I think of it…I guess it just made sense (also, you can shoot stuff on bridges from afar, which makes up for it, somehow).

Entry safe zones

Bombslinger features some enemies that can gang up on you pretty fast so we wanted to give the player some time to figure out the surroundings when entering a new room. To this purpose, we place soft blocks to shield the entrance.

This comes with the downside of requiring at least one bomb drop to exit the safe zone and enter the action. We tried to figure out a better way of handling the room entry but they all kind of revolved around the idea of an arbitrary time or enemy-freeze when coming in. In the end, we feel it’s an ok tradeoff as it is right now.

Small rooms get same-y fast

I personally like the action of Bombsinger in small spaces but these tend to look alike very fast. Since creating wall-blocks takes a 3x3 tile-block and one-tile corridors are forbidden, there’s just so much you can do in a small room. A valid alternative we came up with is to have very big rooms, fill them with walls and “carve” small rooms inside them. I think that gameplay-wise it works pretty well and it looks nice.

Testing and moving on

The first test of this new approach was at Gamescom 2015, five months after the previous event. Since putting the tools together and working on the game took us a few months, we didn’t have time to start implementing anything procedural but after the first day of seeing people playing, we clearly felt that handcrafted rooms were definitely the way to go.

Back from Gamescom we decided that we would procgen the levels (a collection of rooms) and handcraft the rooms. There was not much discussion about it but we also brought back one new criticism. Player experiences visual fatigue as the only level in the demo was the desert and it was boringly yellow all the time.

Working with tilesets

At this point we started working on different environments and thinking of ways to bring diversity.

At first we worked with one simple tileset per level, with all the floor tiles looking alike and being made of ground. Since Bombslinger is top down, you never really get to see the sky, which is a giant missed opportunity for color contrast and composition (and me being a huge SEGA fan, having no blue in my levels was OMGNO, NO!). For instance, the desert would be all yellow-ish, the ranch all brown-ish etc. We decided to integrate tiles painting into the editor with two main goals:

• Painting different floor types.
• Painting water FLOOR tiles that would lead to fancier color contrast.

Water tiles would break up the grid, creating a different form of gameplay “wall” and eventually they also led to the creation of bridges.

Funnily enough, we always intended to have water (‘cause blue water is the coolest blue thing after blue SEGA skies), as can be seen in the early concept work below.

At this point we felt we had enough to play around with, but getting to this point while at the same time working on the game in general put us at the end of 2015.

But everything stated looking pretty cool.

The tools themselves took some time to get comfortable. Since all the tools development and heavy coding duties rested on Ferry, he was (and is) spread thin. We got a breather when a programming intern joined us for a few months (hello Gilles Beaucarne!). Gilles focused on getting the editor to a decent usability state and (finally!) started working on the actual procgen…

Procedural, at last!

Now that we had a good idea where we wanted to go with the procgen, Ferry and Gilles got the basic implementation working very fast. The added yet another module to the editor to input the generation parameters and cycle through generated levels.

Here again, it took some time to get everything debugged, usable, stable. It was worth it though.

The handcrafted rooms are saved to .json files, we split them up into several folders according to their type “standard”, “items”, “boss”, “shop”, “secrets”, etc. The generator looks into those folders to find the appropriate room it’s looking for when populating the level.

The generation parameters themselves are also saved into a specific .json file. There’s one for each “chapter” in the game as we want each of them to feel different.
Furthermore, the first and last levels in the game have specificities that need to be hardcoded, like the first level always starting with a fancy “burnt ranch” room.

The actual generation is not totally random. Every level has a min and max room count from which to pool from. It goes like this:

• Place a start room.
• Create a critical path to the boss room. This will place one of each type of room on the critical path (the path length is a parameter).
• Place rooms adjacent to the critical path until the set number of non-critical-path rooms is reached.
• Create connections between rooms that are outside of the critical path (% of creating a connection is a parameter).

The generation rules are pretty straightforward but being able to leverage the critical path min/max length and the % of connections allows us to output levels that are linear or levels that are more spread out and maze-like.

*note: the connections that seem to lead to the void actually lead to secret rooms, it’s just missing some tile “art”.

We’re pretty happy with the choices we made there. We noticed that other rogue-likes choose the same approach and for good reason, as it strikes a fine balance between progen and hand crafted content.

The system still requires some refinements when it comes to the critical path definition. At the moment the algorithm can still pick two rooms of the same type and put them next to each other: that’s ok when it’s a standard fighting room, less so when it’s a special item room.

On top of that, there are some things we’d still like to do but after two years of working on Bombslinger, it’s probably time we let it go and see what the audience response will be.
…
…
BUUUUUT, if we had more time, we’d probably investigate:

• Procedural enemy distribution (placed in the room editor right now)
• Making the outside padding walls more diverse
• (Randomly) Adding 3X3 3D props in the rooms to make them unique.
• And why not…trying to actually procgen the rooms for good (let it go already!)

Conclusion

Hopefully this gave you some insight on the path that brought us to what Bombslinger’s levels are today. The current Early Access release features three environments and a few hundred rooms already, many more will be added and there’s still a whole new level / environment that is planned before released.

One thing we learned the hard way is that a Bomberman-inspired gameplay needs careful pacing and enemy design. This sounds like a truism but when compared to jumping and shooting, the core action of dropping bombs is not as inherently fun and the game needs to accustom for that.

Another takeaway is that working on tools is very time consuming and having one programmer who’s in charge of both the tools and the game can be taxing on him/her, can be risky and can create dependencies with the rest of the team. It worked out for us in the end but it’s still not optimal.

In hindsight, there’s not much we would have done differently when it comes to level design. Maybe we should have started the other way around though, with hand crafted rooms to help understand the dos and dont’s before moving on to procgen.

There’s always a sense that we could have explored the procgen of rooms further but we smelled the prototyping-hell from a distance there so I’m glad we played it safe.

If you have any questions about all this, comment away!

Thanks for reading!