Dev Diary – Level Construction Process
Greetings and salutations, friends!
We’re hard at work on our procedural map generation system, and as we get nearer to having its fully functional first iteration, we figured we could give you a little glimpse behind the scenes and show what the entire process looks like. I’m Maciej, the level designer/loremaster on Zodiac Legion, and here’s my approach to this part of the game.
The whole thing begins with a pencil and paper. I try to think of an arrangement that either feels interesting to me or which we don’t yet have in the game, and then I draw it, keeping in mind the level design constraints and a few gameplay considerations. At this stage, my thinking is only: “is this layout a good point of departure?”, and not “what will this map be?”
Suffice to say, some of my ideas are better than others.
After I get a satisfactory result, I draw a bigger picture, where I do the first major adjustments on things that are immediately obvious when viewed from a larger perspective. This entails switching around rooms, resizing them or changing the access points to get a layout that would be better in terms of the gameplay. Only after this is done, do I proceed to giving the map a “theme,” and assigning various environmental functions to individual rooms – that is, only at this stage does a map become e.g. a prison, with a guardroom next to a detention area by a torture chamber, and so on.
The process becomes both a little bit easier as well as harder with random maps. The start is the same – with pencil and paper followed by the big picture. However, I can no longer shape the arrangement of the map entirely to my liking. That’s because we use a separate collection of preset rooms to populate the procedurally generated levels. This puts a new constraint on the layout – since they have “standard” sizes that have to fit together – and also prevents me from figuring out the content of the map on a “micro” level. The most I can do is give it a theme that will then determine what types of presets can be spawned. But on the flipside, I no longer have to fill out every room by hand.
All the green plots in the map below are spaces reserved for presets:
The presets themselves are divided into a number of categories, for simplicity’s sake let’s name four: small, big, outdoor, indoor. Small ones are meant to be intermediate building blocks with less tactical significance whose chief purpose is to make the map less “geometrically uniform.” The big ones are the meat of the game – with the actual objectives, obstacles, collectables and all the rest that makes a good gameplay experience. Outdoor presets are surface areas, while indoor are individual rooms – for use in dungeons and outdoor buildings alike.
Some presets, like the one below, can even hold other smaller ones. I’d call these “fractal presets” if I were more pretentious.
Since we don’t have a custom level editor, the software we use for building our maps is Tiled. With that, we can fill out the maps with both automapping based on scripted rules, as well as with the manual placement of features. For example, putting a “wall” token on the ground type layer and letting Tiled handle the automapping immediately generates the appropriate wall sprite together with tokens for line-of-sight and movement obstruction as well as floor sprites. It’s a great tool that takes a while to get used to, but once you’ve learnt it, it makes your job a lot easier.
An example of the end result of working in Tiled is this guarded vault with riches to be plundered:
Once the presets are done and the map is laid out, all that’s left is to put it in the game for testing. This is the part that we’re focusing the most on now, because as you can imagine, the results of the procedural generation process are
very
susceptible to bugs. Presets don’t match, doors open into brick walls like in a cartoon, props vanish and leave behind gaping holes into oblivion... But apart from that, there are also mechanical considerations that can only be adjusted after a practical inspection. These include the numbers, types and locations of enemies, the number of “dead ends” that lead to long and unnecessary backtracking, or the distance from the starting spot to the main objective.
The bugs are easy to fix, because they’re usually just oversights in the map files. But the gameplay-related issues can be more tricky, especially since they need to be addressed on a few different planes. For example, the unit count available to the enemy is assigned to the map itself based on its difficulty, but the spawn points and class preferences are defined in the presets. Meanwhile the rules governing the dead ends and objectives are global to prevent anomalies.
A procedurally generated level, as viewed in the game. Please ignore the issues:
As we continue working on the random maps, we’ll be adding even more features to make them more coherent. At the very least, we’d like to have faction-based colouring on props such as banners, broader classification among presets to better determine what can spawn where, and a more robust mission system, where the randomized levels could be matched with appropriate objectives and narrative texts. However, right now our paramount goal is to lay down the foundation and make it function reliably.
We’ll be sure to come back with more news in the near future, and you can also expect to see the results of the process described in this diary for yourselves soon enough. It’s right there in your horoscope!
