Room Graph and Connectivity

Connections between rooms were originally added between a room and the room it was spawned from, with the result that the dungeon layout mirrored the random tree method used to create the dungeon.

I’ve made the graph structure representing the rooms more robust, and have moved the door placement process further away from the level of individual tiles.

What happens now, is that basically the rooms are placed in the usual manner, and afterwards a graph structure of Room objects is used to place the doors.

Traversing a graph to connect everything up afterwards is a lot more elegant than just plugging doors in as the rooms are placed, and it opens a lot of possibilities in terms of how the rooms are connected.

At the moment, I simply connect every room to every room that is adjacent to it. This makes the dungeon very easy to traverse in any direction, which is good for wandering around gawking at things while developing it, but leaves things a bit to easy for gameplay. Still, it’s a lot better. As mentioned in an earlier post, I intend to have a system for adding connection density in a more logical manner.

The beauty of basing things off the graph structure is that it’s not tied to the dungeon generation process. The graph can be recomputed from the placed tiles very easily, and can be altered to suit gameplay goals, then handed over to the door placement code. It’s also easier to do things like, for example, having special rooms with fixed entrance and exit points, like a bridge across a pit between two doors, or a type of room that always or has a high probability of being adjacent to another specific kind.

You can see the difference between the original tree structure (top image) and the modified graph (bottom image):

(The lines changes from purple to yellow as they move from parent to child)

 

I’m going to be changing the architecture for the shader soon. At the moment, it’s a simple single pass with one attenuated light, exponential per-pixel fog, and diffuse, normal and specular maps.

A management system for light sources, that keeps track of them and takes care of things like culling, will need to be designed in implemented concurrently with the revised shader.

I think it would be a good idea to have a pretty well thought out shader architecture designed before hand, rather than just cramming features in and hoping it doesn’t break. I haven’t really been thinking about optimizations yet, because the priority at the moment is to get clean systems in place that wont rot and need to be refactored ten times.

I have a good idea of what I’m going to do when the frame rate starts to drop though, and if the rendering system is well designed and self contained it can be optimized later without affecting any other code.

Advertisements

3 Responses to “Room Graph and Connectivity”

  1. Hammackj Says:

    Are you going to release the source. This is awesome!

  2. Just want to give you some encouragement. This is looking good! I’m looking forward to playing this one day 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: