After several days of reflection, I have reformulated my ideas to comply with the required guidelines. As I stated before, I have a strong preference for using a general algorithm that does not rely on Unity tools, to be able to take it to re-use it on other platforms or programming languages without having to export it with the mentioned engine. This is getting complicated!

Avoiding engine dependance is possible?

Continuing with the solutions to set up the foundations of this new challenge, I decided to perform the following exercise:

To create a dungeon (aka the Lunar Base) that serves the purposes of this game must take into account that:

• Have a Start and an End.
• Generate a clear path between these two points.
• Get a closed dungeon.

Most of the solutions I have found in the literature or through tutorials can be divided into two main categories: those that only offer a theoretical approach to the problem (usually in pseudo code) and those that are completely dependent on the facilities offered by a particular engine (Unity, Unreal, GameMaker, Godot, etc) to solve the problem.

Since I am working in Unity, it is easy to get carried away by pragmatic approaches that in a few minutes offer acceptable results (more than enough in any case for this exercise) but of which I am not very adept, especially when it comes to adopt the procedure to other platforms (I’m not talking about exporting the builds to PC, Mac or Switch) but to take the logic to operating systems such as the Spectrum Next, Pico 8, Playdate, etc..

This hybrid way of working (half in code, half ‘by hand’ using the Unity editor) really makes me very annoyed, but I must admit that it is a fast way not only to create prototypes in a short time but a whole project.

Trying to maximize the amount of C# code that makes the game logic work and minimizing as much as possible the use of the editor I try to reach a compromise that is as satisfactory as possible.

All that being said, my current attempt to create the main dungeon now is this:

Square rooms: I know, I can feel those!

As you can see, this week I completed the creation of the procedural scenarios (each room in the dungeon is generated in such a way that it connects to the next, from the first to the last room through a minimum of one door and a maximum of four). I still maintain a clear indication of where the first room is located and where the last room is located: green is the starting room, orange the final one.

It should be noted that these doors allow the characters to pass from one area to another freely, and are mere conduits that open or close.

Later I will include the airlocks that will allow the release of all the contents of a room to the outside.

For the sake of ease, all the rooms are the same size, the idea will be to learn enough to intersperse rooms of different dimensions to bring more variety to the whole. Not happy with the rectangular shapes I start working in this version:

References