Level design from the developer's side

Level designers in game development teams tackle a set of tasks, with the most significant and apparent being the creation of an environment that maximizes the potential of game mechanics and expertly combines and showcases game assets.

From a level design perspective, the foremost task for a developer is to provide the level designer with an editor that allows them to efficiently and swiftly implement game levels/environments with ease.

If your game is quite straightforward, you can come to an agreement and opt for any available solution that suits your task. For instance, if your level is flat and non-interactive, you might seat your level designer in front of a drawing tool like Photoshop. Once, I was tasked with level design at a gamejam and assembled the level in Excel since our game was a platformer structured on a grid of square tiles. It was quite convenient for a small demo game, but what if you have hundreds of levels with thousands of tiles?

A team brings on board a level designer when there's a need to craft intricate interactive levels that require thoughtful placement of game elements. We're all familiar with mobile games in the match-3 genre and similar ones, housing thousands of levels. For such games, dedicated teams of level designers are formed alongside separate teams of developers who create specialized editors for their convenience.

Example from mobile game

The choice of an environment editing tool, with which the player will interact, directly depends on the requirements of game design: the game's genre, its mechanics, level, graphical style, and so forth.

"Standard" Level Design

If your game involves a full-fledged three-dimensional environment for player exploration, you'll likely desire a level editor where you can place three-dimensional objects, customize their appearance, and define interactions with them. Fortunately, modern game engines offer suitable functionality that covers most of your needs.

Unity's philosophy envisions these as 3D/2D levels or Scenes. One of its primary windows is aptly named the "Editor," resembling interfaces of 3D editors like Blender or 3DMAX. Here, you can not only position, rotate, and scale objects but also adjust their appearance, select materials, and much more.

This is the clearing where our magicians will fight

Major game engines strive to cover the bulk of your level setup needs. However, every game is unique. If you're crafting something beyond the basic template, soon you'll require custom tools. Implementing your ideas might seem time-consuming, inconvenient, or even unattainable.

For these purposes, engines provide the ability to expand functionality through plugins or your freshly programmed tools tailored to accomplish specific tasks.

A few years ago, game companies used to write their level editors, complicating development and consequently escalating its cost. I should note: every game is unique, and many projects are still crafted from scratch in some programming language without relying on ready-made solutions. It all depends on your project requirements.

Runnable Editor for Level Editing

There might be instances where you need to play through and edit your level simultaneously. You can create an in-game functionality a special sandbox mode that won't be visible to players but, upon game starting, provides administrative tools alongside gameplay logic, allowing you to modify the environment and save your level changes.

For instance, if you're creating a board game like chess, editing game objects within Unity's editor window and then launching the game to test specific levels might not be convenient. You might prefer implementing additional 'admin' functionality within the game itself. This functionality could allow you to launch the game, edit the initial position of pieces, and immediately start playing a match.

This approach also streamlines the lives of content developers for your game. For example, you could release a separate map editor for your strategy game or implement a 'creative mode' directly within the game. In this mode, there are no set rules—only a playground with customizable settings and environments."

Generated Levels

But what if you're envisioning a game where absolutely every aspect of the environment must be generated from code at the moment the game launches and the world is created? In this case, your focus would indeed be on coding. Yet, even in such a scenario, you might still require an editor where you can quickly and visually review the results of your generation algorithms.

Moreover, a game engine isn't solely about level editors and writing code for them. Even if many parts of your game are generated from code, you may still need ready-made textures, 3D models, or other assets. Engines assist in efficiently managing various assets and handling them during gameplay.

An example of an editor that previews an algorithm-generated surface

In the past, supporting, loading, and managing different assets often required additional bespoke solutions. Nowadays, major game engines support most asset file types you might need, enabling immediate usage and manipulation of these assets both within the editor and in your code.

В general, it can be beneficial for small or novice teams to abide by these principles:

• If there's a suitable tool available to bring your idea to life, use it instead of starting from scratch. It'll save you loads of time. However, keep in mind that you'll likely need unique functionality to solve your distinct challenges, so the tool should be expandable.

• Your game's editor should be highly accessible for non-developer team members. Specifically, developers should create or modify such a tool to enable level designers, game designers, and others to build your game without delving into code. Developers should focus on writing code rather than placing barrels in levels or managing game balance.

P.S. There's a practice where level designers/game designers write code themselves using scripting languages like Lua during game creation. 

This approach is sometimes employed for complex games with intricate mechanics because, at times, it's easier for a specialist to learn a simple scripting language than to describe volumes of game design documentation for a programmer.

TOEMS

In my tactical game, I'll be implementing a hexagonal battlefield and aim to use convenient and swift tools for shaping the terrain, texturing, and placing various environmental elements during its development. I'll be adopting a combined approach. In one scene, I'll create a clearing to configure the environment as seen by the player. In another scene, I'll transform it into an editor for the hexagonal grid, capable of preserving hex placement relative to each other and their types.

In the future, I'll probably merge these two scenes to allow hex grid on the map in Editor. For now, it'll be sufficient to quickly sketch the level and save it to a file for use in the code.

Unity Tilemap is an excellent tool for the hexagonal map editor—it automatically divides the plane into hexagons and enables the creation of a "palette" containing selectable hexes that can be applied to our field.

In my editor, green hexes represent empty cells for unit movement, while red ones are blocked for traversal. Yellow and purple hexes denote player spawn points.

While Tilemap enables saving the hexagonal field and displaying it in the game, I'll be using it solely as a map editor.

And this is a scene with the editor which cells of our hexagonal grid will be playable

The convenience of the Unity approach lies in the ability to write a script that executes both in the editor and during game runtime. For instance, we can add a button to the inspector panel that, when clicked, generates a file—eliminating the need to run the game. However, the same functionality can be called from within the game if necessary. Consequently, we write the same code used in both the game and level building.

I've written a script that "scans" this field and saves the necessary information to a text file. This file will be read from the code to display the hexes in our initial scene.

We'll be saving the position of each cell using two integer parameters, x and y. For this purpose, the Vector2Int type suits us perfectly (I'll delve deeper into the mathematics and data structures in another post).

The only aspect we'll edit when saving coordinates is the y-coordinate direction. Tilemap uses a coordinate system that moves right and up, but in our game code, it'll be more convenient to work with coordinates moving right and down.

Next, we'll simply write code that will take this file and generate our cells in three-dimensional space. Since Unity's three-dimensional scene involves three coordinates - x, y, and z - we'll put the y-coordinate from the file as the z-coordinate (Since the y-axis of the scene points Upward while the z-axis moves Forward). We'll keep x unchanged since it represents the rightward direction.

As you can see, the Y coordinate decreases towards the bottom

So, we've connected the editor and the game level!

There's a lot more work ahead. Our next step will involve hex grid mathematics and pathfinding within it. Also, we'll discuss why a hexagon is the bestagon. Stay tuned!