My original goal with the project was to eventually make a small, but functional demo game in Unity3D using the random dungeon generator. As it stands now, this will most likely not be the case. Time estimation for a project is a difficult task and takes quite a lot of practice to become adept at. Working with the project and getting the framework and all the base modules working properly with each other required far more time then was estimated at the start of the project.
The main focus was always to make a functional, modular and expandable dungeon generator framework, that later on could be usable in various other game projects. That has thus far been successful, even if the framework still needs a lot of work and polish. The project was, in the end, a very large undertaking and it would realistically have needed at least two more developers working on it to finish within a reasonable time frame.
An issue with the new prefab room system is clearly seen in the screenshot above. The two prefab rooms have a connected relation, where one is placed at a predetermined distance from the other using a random angle. While it works really well in most cases to create dungeons with consistent start/end rooms (or similar layouts), it also causes some issues sometimes, where there is a lack of rooms between them due to the random nature of the algorithms used.
I came up with the following solutions to combat this problem:
Placing a few rooms along a straight line between the two rooms and adding a slight deviation so the rooms do not line up perfectly. Since the distance between the two rooms is constant, a set amount of rooms can be created and spaced roughly equally along said line.
Placing a few rooms within a circle (or even better, an ellipsoid) that is based upon the two rooms. Same as above, the distance is constant, thus a set amount of rooms can be created.
As a side note, long diagonal corridors look really ugly and would probably appear as confusing to the player, especially in first person perspective. Long corridors should probably use L-shapes or even insert a new room somewhere along it to break up the length.
Portals where added as a way to simplify the process of generating corridors between rooms and it worked very well, as long as the rooms themselves had a portal on each side. This design flaw is now making itself very obvious and impedes the progress off creating interesting prefabricated rooms(more on this in a later post) with portals on only one side.
There are a few solutions to this:
Changing the graph generation process to work with the room portals instead of the rooms themselves. This could create a more tightly controlled graph, with the added risk of overlapping rooms.
Adding pathfinding based corridor generation. This would only be used for corridors which is known to overlap a room and would be run after the grid has been created. It would create some new interesting corridors, but at the cost of time. Pathfinding is not cheap.
Adding sanity checks when preforming the graph, or simply having special rules for the graph generation of prefab rooms. A possibility would be to force the creation of a room in conjunction with the prefab room portals.
(P = portal, # = void, F = room)
To the left: a room layout with portals on each side
To the right: a room layout with only portals at the bottom
This image perfectly outlines the current issue with portals. The left room is trying to connect with the prefab room “End”, which only have one portal posibility, which in this case unfortunately is to the right. The end result is a corridor which runs straight through the room and causes mayhem.
One issue that continually impedes the progress of the dungeon generator is the problem of generating walls. There are a lot of ways to do wall generation, but most of them use some form a grid format that is a huge time and memory sink, especially at larger dungeon sizes. This type of generation does not scale well and is not very flexible. A solution to this major issue should be researched and tested.
The room system thus far has been very basic and not very flexible. It only supports square rooms, with a portal on each side which is randomly placed. It works for debugging purposes, but now that most of the basic systems are functional and stable, it isn’t good enough. It needs an upgrade!
Here is a flowchart of the newly designed system to be implemented.
The room generation process simply handles the sub modules, which each handle the actual room generation and placement. There are 3 different types of rooms:
Prefabricated (or prefab for short) rooms that have the exact same size, layout and design every time it is created. Very useful for spawn locations, or important rooms to the game plot.
Ruleset rooms. These rooms are created out of a set of rules, which is defined by the sub module itself. These room have a semi random nature, where the room can look similar, but never identical. Layout, placement and size can differ.
Random rooms. These rooms are completely random and have no real rules that define what they are supposed to be or what they should look like. They are usually empty and mostly used as junctions in the dungeon landscape. Oh, and usually filled with enemies!
This new system is estimated to be finished by Wednesday next week, with decor being the next target to tackle.
Today has been spent trying to visualize the dungeon generation in 3D space. It is still very rough and only meant to get a peak at what the dungeons would look like further down the road. It will also make it easier to work on room decor and other similar systems that needs to be implemented. Disregard any and all graphical artifacts!
A few remarks where made when viewing the dungeon in 3D:
Corridors with a width of 2 look out of place, unless only really large rooms are used
A good way of determining what the game should render is a good idea. This will probably be some sort of algorithm where it renders 1 or 2 rooms away in the graph, including any connecting corridors.
A wall generation process that creates internal walls between rooms and corridors, otherwise portals are useless
Another issue that was worked upon today was that when using a corridor width of 1, the corridors created using Bresenham’s line algorithm are disconnected and creates corridors that are incomplete. To sort this out, it protrudes the last added cell so that it actually connects with the newly added cell. The difference can be seen in the screenshots below.
The interesting aspect of creating highly modular, adaptive code is that you can mess around with different settings and setups to create something that was not intended. Here is a perfect example of this, generating caves by simply tweeking some settings in the generation process. In this case, the corridor width was set to a very high number, which caused what you see in the screenshot below.
How this is used is then up to the developer, by adding specific room modules that are more oriented to cave designs (e.g. that the rooms most likely won’t have any walls).
The Relative Neighborhood Graph algorithm has proven itself to create some very interesting and useful graphs for the corridor algorithm to use. The graph is highly usable, even without the use of a Minimum Spanning Tree to reduce the amount of edges. Below are some screenshots of what the graph has resulted in. The final version will most likely use this graph, as it is fast and creates credible corridors in the dungeon.
A new type of corridor generation was also implemented, Bresenham’s line plotting algorithm. This one allows for more straight path corridors, as is outlined by the screenshot below. A combination of both Bresenham’s and L-shapes is now used to created even more varied corridors.