Posted in Uncategorized on September 8, 2011 by sfahy

I’ve been back working on the game for a while now, so I thought I’d post an update with some of the stuff I’ve been doing.

I implemented a deferred rendering setup, which gave a nice framerate boost and would have been easy to hang the lighting system on, but I lost multisampling capability and the result was grotesque. I’m sure it’s possible overcome this issue, but for now I want to progress with other things.

There are still issues with the parabolic shadow mapping but I’m putting it on the back burner for now.

I’ve begun to develop the event system which will act as the backbone that joins all the subsystems together. Rather than have different systems communicate via nightmarish spaghetti code, they can send an event to the event manger, which then gets it where it needs to go. Events can be a simple symbol, like “Full screen mode on” or they can carry data, like “Open Door 132”.It provides a nice interface between systems and will be especially useful for implementing gameplay.

Another nice thing about the event system is that it’s easy to attach a simple scripting system to it. Scripts can be compiled into event objects and passed to the event manager, where no new special functionality has to be included in order to handle them.

I’ve started cleaning up the level generation system to make it as discrete and logical as possible. Higher level systems will need to be introduced on top of the existing functionality, to lay down rooms in logical areas and to handle special cases like corridors and non-rectangular rooms. Things will go a lot smoother if the low level algorithms in the generation process are all encapsulated nicely.

I’m reading up on animation a lot at the moment because I know that it’s going to go horribly wrong and knowing as much as possible beforehand will soften the blow a bit. I’m looking at various XNA animation libraries as well. The Microsoft sample doesn’t really cut it in terms of adaptability, so I’m hoping I can find something documented that imports in a sane format and performs well.

I can’t wait to get a few of the basic gameplay systems in place and see it start to come together as a game. Things are still a bit tech demo like at the moment, and the sooner I start implementing gameplay the more time I have to nuance it and make it fun.

I’m not dead

Posted in Uncategorized on July 7, 2011 by sfahy

I haven’t posted anything in a while, but the project is still well on track. I have college stuff to take care of at the moment which is unfortunately taking up a lot of my time, but once that’s out of the way I’ll be back to obsessive updating. The game has moved on a bit from the last time I posted, with a good bit of GUI architecture implemented and such, as well as some basic things like refactoring. In any case, I’ll be back to regularly updating this blog as soon as I can.

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.