Milestone 3 is around the corner, with a proposed final presentation today, as well as the submission of our final project product. More info to come!
The project presentation and a working tech demo of Yggdrasil can be found on SVN in the link below.
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.
- No demo game
- More focus on working framework
- Time estimation is hard and requires practice
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.
Just a quick update on prefabricated rooms. A basic version is fully implemented and functioning, with support for the following:
- Layout controll, set distance to other rooms, placement modes and various other settings
- Predetermined room structure and layout, which can create for some very interesting rooms created by the developer
It has resulted in more varied dungeons that feel and look more dynamic. Screenshot below shows how one rooms has a very large room radius, which forces new rooms to be further away from it.
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.