Archive for the Dungeon Generation Category

The Sacred Mechanisms

Posted in Dungeon Generation, Gameplay, Graphics, Rambling Tangent, Room Connectivity, Screenshots on December 5, 2011 by sfahy

At the moment I’m working on developing the basic combat system. Combat is largely predicated on player attributes and equipment, but I want to introduce a level of more immediate strategy. By allowing the player to execute resource limited special moves during combat, the focus is shifted towards the strategy employed in each encounter, rather than just a long term min maxing of stats.

Another area I’ve been doing a lot of work on recently, and am particularly excited about, is the variety of mechanical devices that will be littered about the dungeons.

The machines can be interacted with in different ways. For example, the Translocational Impeller pictured, at it’s most basic mode of interaction, teleports the player to a random location in the dungeon. More advanced modes of interaction are possible, such as teleporting an enemy, teleporting to a specified location, charging an item with a teleport spell and so on.

The advanced modes of interaction are opened up as the player’s character and the game progresses, and allow the dungeons to gradually increase their depth of interaction without dumping complexity on new players.

The machines create the potential for emergent interaction with the dungeon itself. For example, there could be machines that flood rooms with poison gas, or heal everyone in a certain radius, or enchant a weapon according to what item is fed into it, or really do anything that can be done within the bounds of the gameplay system.

The machines will also allow the game to add twists to existing mechanics, for example a machine that suppresses spell effects in a radius, that can be modified by the player to amplify them, or to only suppress enemy effects.

The temptation is to go full on dwarf fortress mode and create a vastly complex system with incredible depth that inspires fear and trembling in all who behold it, but I think that by gradually introducing new interactions with character progress, and above all presenting a clean and context aware interface, the depth can be captured without the complexity. I think the most important rule of thumb for this and all the gameplay systems is that the player should not need a wiki in order to use this.

Once gameplay becomes tied to specific areas in the dungeon, however, the danger arises that the player will attempt and fail to navigate. For example, with the spell suppressing machine example, an obvious strategy for a combat oriented character would be to lead spell-casting enemies to it and attack them. But the player doesn’t have the same high level overview of the environment as in a traditional roguelike, and the absolute last thing I want in the game is to have the player wander aimlessly through the level, endlessly searching for a visited area.

The level generation process uses square rooms as it’s unit of synthesis, maintains a directed graph of parent to child room relationships, and only connects, combines, populates and furnishes rooms once every room has been placed.

Structure could be introduced at the graph level, for example creating a chain of rooms with one entrance and exit at either end. At the moment, every room is connected to every room that shares a wall with it, which creates an environment that is relatively easy to navigate in any direction, but that is formless – It can be difficult to identify landmarks and backtrack.

A lower level solution is to attempt to introduce texture rather than structure.

2D Perlin noise is generated across the level and used to modulate the dimensions of any rooms generated at a given location. This results in a sort of compression and rarefaction of room size across the level, with smaller rooms clustering together and creating a kind of ambient structure in the level that makes orientation easier without attempting to impose rigid patterns.

A combination of both these approaches should hopefully make directed navigation  possible without encouraging it.

On the graphics side, I’ve been experimenting with the idea of using a simple directional shadow map that would anchor the scene together without being an accurate reflection of the lighting. This would save a lot of the resource and complexity overhead of omnidirectional shadows, but the downside is that it’s horrible and it looks horrible. Horrible.

I think after a lot of intense graphics programming I feel a lot more confident that I can get a decent implementation of dual parabaloid shadow mapping into the game. Light sweeping through doorways into the darkened rooms beyond is a really cool effect and adds to the vibe of being alone in a hostile environment. Also it resonates with the torchlight effect used in so many roguelikes, and if this game is about anything, it’s about heritage.


Animation, Character Rendering and Overall Progress

Posted in Dungeon Generation, Graphics, Screenshots on September 30, 2011 by sfahy

The animation system is now largely in place and a basic character model has been created. It’s pretty clean and well separated from actor data and game logic, and common functions like attaching additional meshes to bones can be done with a minimum of hassle.

Characters (and their equipment ) use a different shading model than the environment. The models are not normal mapped, and the diffuse texture is painted rather than composited  from photographs. A second diffuse texture is created from the first, with the colors shifted to cold colors, and these two textures are interpolated between by the diffuse lighting result, which is exaggerated.

The idea is basically similar to gooch shading, but with diffuse textures instead of solid colors.

There are a number of reasons why I decided to take this approach. Like in gooch shading, the models will not become more difficult to see when they are in shadow. Visibility will be further enhanced by the contrast in styles between the characters and architecture.

I want the game to have an otherworldly, dream like ambiance, and a rendering approach that verges away from realism, but stops short of being cartoonlike, is helpful towards achieving this.

The main impediment to realistic, normal mapped characters is the sheer time overhead. While it’s doable to an extent, it would greatly lessen the amount of overall content that could realistically be produced for the game (already a very small amount).

This expressive approach to character visuals will also help prevent the onset of grimdark.

My next target for development is to build a resource manager, and to extend the simple markup language used to define static game objects to cover the definition of characters and other asset types.

After that, I plan on implementing simple enemy behavior – A* to the player and attack. This should be enough to start testing and adding nuance to how the underlying game data interacts and to begin the process of slowly refining a tight combat system.

I’ve already created the process for adding new kinds of room to the dungeon, and specific types that are necessary or highly relevant to the core gameplay dynamic will need to be implemented.

The high level system which controls the density of specific room types will have to be created, as well as systems for populating rooms with enemies in an enjoyable manner.

While there will be some decorative cruft, such as statues or whatever, I don’t want to have meaningless detritus or crates full of nothing all over the place. Every object should have an obvious gameplay function, or obviously lack one.

Once the player can explore, fight and die, the game will have reached it’s first big milestone and will finally be at the prototype stage. After that, aggressive user testing and constant tweaking of gameplay dynamics, with the aim of reaching a simple, solid, fun gameplay dynamic, will bring the game to it’s second prototype. From there, the addition and balance of final enemy types, items, room types and gameplay dynamics, and copious amounts of polish, will get it to alpha. After that it’s just bug fixing and polish, as well as a period of larger scale testing in beta.

I hate to hang a time frame on development, because I’ve never developed anything of this magnitude before and any time estimate would be a complete guess. Things have been progressing very quickly, though. The codebase is showing no signs of blechery as of this point, the most difficult technical challenges have been solved to a decent standard and the whole things seems to comming together nicely. I would like to have the initial prototype stage reached before Christmas. At the current rate of progress it seems likely that I will.

Also, by a process so complex it verges on black magic, I’ve managed to create an ambient sound-scape  that fits the mood pretty well. I’ll write a post attempting to explain how it was made.



GUI, Gameplay Stuff

Posted in Dungeon Generation, Gameplay, GUI on June 8, 2011 by sfahy

I’ve started developing the data structures that will underpin the gameplay. At the moment I’m trying to keep things as flexible as possible and I’m only implementing simple things like health and basic attributes.

Iv’e developed a root Actor object, which the Player object inherits from and Enemy and NPC objects will inherit from. The Actor object contains an attributes object, which will be common to all game entities, as well a gamestate object that keeps track of information that relates a specific instance of that actor (with stuff like inventory, current health, effects applied and so on). Actor objects will be handled by an Actor Manager system.

It’s very important to the game that all game entities share common data and inherit from a single class. Not only does it make for a more elegant system, but it makes it a lot easier to do things common to roguelikes and RPGs, like gain a monster as an ally through magic, or raise them as a zombie or whatever. It also means that things like effects can be handled a lot more elegantly as well.

There will be a very robust system developed for simple effects (such as strength +1, fire damage etc) as well as for effects that require more nuance (polymorph, walk through walls). The plan is to have effects agnostic to to how they’re being applied.

So for example, lets assume an effect, weakness,  that temporarily lowers strength. A potion of weakness will act as a poison that lowers strength for a period of time. A sword of weakness will temporarily lower the strength of whatever it hits. Armor of weakness will be cursed armor that lowers strength until it is removed.

In each case, the exact same effect data will be used by the item. It is left to the item itself to handle the effect. This makes it easy to do some cool stuff, like let the player enchant items with specific effects, or for example, combine a poison of weakness with a sword, with the result that the sword temporarily conveys that effect.

Effects will be modulated with a balancing variable, so for example an agility reducing effect will be far less potent as a sword enchantment than a one shot spell.

Spells will also employ effects in a similar manner, for example a fire damage effect can be applied as a bolt spell that damages enemies, or used with enchant weapon to temporarily give fire damage to the player’s sword.

(I’m just using random examples here, I’ve always found “elemental” damage types wearying and pointless and I have no current plans to implement such a system).

As I am now starting to work with the underpinning data, I have also been developing GUI elements to provide feedback. You can see the basic debugging information outputs in the screenshot, as well as a bar indicating the players health.

The bar inherits from a UIElement object that all GUI elements will inherit from. It is agnostic to the data it’s representing, it merely shows a bar representing the relationship between a maximum and current value, in this instance set to the player’s health. This bar is neither in it’s final position nor using it’s final graphics, it’s just there to be tested and provide feedback on the player’s current health.

One other cool little feature that’s been implemented is the ability to generate levels from text strings. The idea is to have special portals, spells or magic items were the player “speaks an incantation” that creates a dungeon. Text strings that lead to particularly interesting dungeons can shared among players … assuming there’s more than one of them.

Room Graph and Connectivity

Posted in Dungeon Generation, Room Connectivity on June 1, 2011 by sfahy

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.


Posted in Dungeon Generation, Screenshots on May 28, 2011 by sfahy

The dungeon now features nicely rounded corners. This was added through the tile query/replacement system, a use I hadn’t anticipated for it, and it worked without having to add any crufty code. It uses the same objects and processes as any other element. I’m really glad I took the time to design a robust system for using assets procedurally, as sprouting new systems every time I want to add a new rule would really stink up my codebase.

I’m going to force myself to move on to more gameplay oriented aspects for a while, like room connectivity, because I could literally spend forever adding little architectural variations that don’t directly relate to the gameplay, and the game must ship. Still, it’s really cool to see things come together visually a bit more.

I’m really excited about the gameplay- I want to combine the things I love about rougelikes with a more action oriented style of interaction and a few trippy ideas about progression. The high level of proceduralism and clean division of the game code into separate systems means that experimenting with different gameplay ideas should be feasible, and implementing sweeping changes in response to testing should be possible in a short space of time. I really want to have the magic system integrated to the point where it can operate in natural but unexpected ways.

For example, arrows are controlled by a simple physics system, and one really cool thing that happened while I was screwing around was that when using a spell that causes objects to be attracted to you, arrows that come near your character are pulled into orbit around you, meaning that you can collect a swarm of arrows and walk up to an enemy, or release them all in the middle of a crowded room. This is an emergent quality of the physics, magic and projectile systems and to me is a lot cooler than a “swarm of arrows” spell that your character craps out on command.

On an utterly unrelated note, I think i’m going to replace the small coble stones with flagstones, as they’re too noisy and don’t read well when moving the camera at speed.


Posted in Dungeon Generation, Room Connectivity, Screenshots, Uncategorized on May 27, 2011 by sfahy

Just a random screen dump from the game as it now, the dungeons are still bare, I don’t want to start adding “furniture” until I have a robust system for distributing it logically in appropriate rooms, as well as a good design for the game logic that underpins it’s use.

Below, you can see a directed graph showing how each room is connected. The overall connectivity forms a tree structure that fans out from the center. The next stage in dungeon generation will be to examine this graph and connect branches of the tree to each other in a manner that results in an easily navigable dungeon. I’d like to have this happen in a manner I can easily control, for example to specify the optimal cycle size in the graph and the generation system approximate this. The important thing is that I end up with a variable or small set of variables that I can tweak, because only testing will reveal what level of room connectivity will be most fun to play.