Archive for June, 2011

More GUI stuff

Posted in Graphics, GUI on June 21, 2011 by sfahy

Now that the rendering system is a little cleaner, I’m focusing on implementing a lot of the GUI controls.

Creating the data back end to gameplay (i.e. stats, leveling etc) is a mostly architectural and conceptual problem –  the only engineering question is how elegantly it’s encapsulated in the code. I’m keeping things pretty narrow and simple at the moment, with possible room for expansion as things progress. I think there’s an important balance to be struck between simplicity and user friendliness, and providing sufficient depth for strategy and divergent character progression.

It makes sense to have the GUI come together at the same time because it allows proper testing of the data.

GUI objects all inherit from a UIElement root class, and each has a list of children that are updated and drawn when it is. This tree structure makes a lot of sense as most GUI elements are composites of smaller elements, for example, Scroll Bars contain buttons, and text panels contain scroll bars.

So far I’ve developed a simple scroll bar with drag functionality, that alters a value between 0 and 1, which can be used for whatever.

I am always striving to minimize the static content in the game, and from this perspective it would make sense to have a scroll bar that could have varying length, so it could be slotted in anywhere without having to make any new assets.

However, the GUI is the one area where I am willing to accept a large overhead of time spent making content. GUIs are a constantly under emphasized aspect of game development. A good game with a bad GUI is a bad game.

The graphical user interface in Baldur’s Gate II goes beyond just functioning well, it’s beautiful and it adds hugely to the game, making icons and numbers seem almost like they’re part of the game world.

The inventory management system is going to be nightmarish to get right, and I really want to set up a system to render icons of 3D item models, because items will have changing textures, and hand painting icons and changing the colors programatically will take forever and look crap. I guess that making render parameters (such as distance and camera angle) for each type of carry-able 3D model wont take that long.

You can see a hueg picture of the scrollbar bellow.


Shadows (Mark II)

Posted in Graphics on June 16, 2011 by sfahy

Dual paraboloid shadow mapping. Now to rebuild the rendering system.


Shadows (Mark I)

Posted in Graphics, Uncategorized on June 15, 2011 by sfahy

I’ve spent the past while attempting to add shadows to the game. Unfortunately, what should have been the work of an afternoon became a protracted war of attrition with grave consequences for my sanity.

I began by attempting to add dual paraboloid shadow mapping, which is a cool technique for omnidirectional shadow mapping. After some initial hiccups, I arrived at the point where I was getting relatively correct shadows If I only rendered the player’s depth onto the maps.

I rewrote the shader. I rewrote the shader. many. times.

Eventually I decided to just implement a standard shadow map and be done with it, I needed to move on to other things.

I ran it, and the shadows were still garbage. Directional  shadow mapping is pretty simple, and after the horror of the dual paraboloids, I had made sure I wrote the shader with clinical exactness, so I realized that this was one of those bugs.

After staring vacantly at the code for a while, I realized that after I drew the UI, I was drawing the depth map before I re-enabled the depth buffer, and that the shadow maps being generated were basically in random z order.

So, I literally moved a line of code further down the damn page and it worked.

This happened because I really wanted to see shadows as soon as possible, and I delayed implementing  a decent rendering architecture. If the rendering code had been systematized earlier, this bug still might have happened, but it would have been easier to track down. If I’d been in a position to reason with more clarity about what was happening across each draw call I could eliminated other possible sources of error a lot faster.

Even with simple directional shadows, the jump in quality is huge. There’s a much better sense of space and perspective, everything seems more solid. Omnidirectional shadows with depth of field should look very nice.

I’m going to put dual paraboloid mapping back in, then revamp the rendering architecture before the madness of the past few days repeats itself.

Dummy Models, Improved Meter Bar

Posted in Graphics, GUI, Screenshots on June 9, 2011 by sfahy


The ‘@’ symbol was mildly amusing for a while, but I got sick of looking at it, so I made a dummy model for testing purposes. I didn’t bother unwrapping it well or making a proper texture or anything like that, and the mesh isn’t that detailed – the model is really just for development purposes. The actual game assets will be much better, I swear to god.

It came out at ~1000 polys, and I subdivided it to ~6000 just to push the polycount a bit more. With a 2048*2048 diffuse texture I can render about ~100 of them before the framerate starts to dip. I realize that to assume that animated models, with gameplay logic, will run anything near this is dangerously optimistic, but as far as I can judge there’s plenty of performance leeway left. I’m using a GeForce 7900 gtx, a five year old card, which I recon is a relativity accessible standard to tune performance to.

The actual assets will probably for the most part have a much lower polycount than 6000, with a lot of the detail baked into normal maps. I think it’s important visually, because the models will be viewed from far away, that they have strong flowing lines in their topology, that exaggerate and strongly delineate the human shape they’re representing. There’s no point in spending polys on elements that will only ever register as noise.

I plan on making the armor and weapons in the game pretty colorful- I’m bored to death with seeing Grimdark the MurderKing’s bloodstained brown platemail in every roleplaying game I play. I know that most of the screenshots so far have been pretty dark, but the game overall will be more colorful than they would suggest.

The meter bar can now interpolate between two bar colors as the value it’s representing changes. I made this exponential, so as, for example, your health, starts to come close to zero the bar starts changing from gold to red. A gradual, linear shift towards red beginning the moment you start loosing health would lessen the impact of the feedback.

I plan on implementing shadow mapping soon, maybe even just unidirectional at first. You can get the sense from the above screenshot that the models appear to be floating – the eye can’t make an exact judgment about where they are in the scene. Shadows ground the models in the scene very well and give everything a more integrated appearance.

I really don’t want to jump into the graphics programming too much yet though, because it obsesses me and I need to be spending time on other systems at the moment.


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.

Placeable Nodes

Posted in Uncategorized on June 5, 2011 by sfahy

I’m working on getting the dungeons furnished at the moment, and I’ve added code to identify all the tiles around the outskirts of a room that can have a placeable added to them without obstructing doors or the path through the room, and create a placeable node for each one.

I use the term placeable to refer to a non-architectural element of the dungeon, such as a chest or alter or whatever.

This terminology is a holdover from my misspent youth with the Neverwinter Nights toolset, which is one of the big influences on this project. I had more fun playing with that toolset than the actual game, and I’ll probably write a filler post about its influence when I’m dry on actual content.

The nodes contain information such as rotation and offset, and when a placeable is added to a room it will be “plugged in” to a node.

The placeable nodes are added on a room by room basis, rather than across the tiles. This is because some rooms may not permit the placement of items, or may have special requirements as to where they can be placed. Also, I find working from the graph rather than the grid is much more elegant and flexible.

A reference to the node is added to the tile it’s located in, which means once the actual placeables are added it’ll be possible to use the tile grammar system to do some pretty cool things, like for example, combine several bookcases in one corner of a room into a single one that curves around the corner naturally, or combine a container into the stone wall behind it.

It can also be used to do things like offset the node so it’s flush with the thinner walls. You can see a few examples in the screenshot where there is a gap between the checker marker and the wall behind it, and it looks a bit unnatural.

Since this post was written I have experienced some internet down time and I’ve added the code to adjust the offsets:

I’ve also made the rendering system a bit more efficient, and I plan to do a post specifically covering that.

Also, I’ve added a model to show the position and rotation of the player 🙂

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.