Archive for the GUI Category


Posted in Gameplay, Graphics, GUI on November 25, 2011 by sfahy

I’ve been working pretty constantly at the game and I’m starting to make progress on the gameplay systems. My current plan is to have three high level attributes – Power, Grace and Will, that direct the gameplay in different ways. The idea is not to have particular strategies hinge on the these attributes, but rather to affect the style of play. For example, a spell caster who is powerful and willful will have a significant boost to the power/ duration/ effects of spells, but due to the lack of grace, spells will be cast slower and be less accurate. A combat oriented character can be a swift duelist or a tank.

This will hopefully allow the player to define their own style of play intuitively. The attributes that dictate success at a particular action will be controlled by secondary attributes, probably a skill system.

I wanted to come up with a cool way to display the three characteristics, rather than the standard stack of integer values.

The idea here is that each color corresponds to an attribute, and each time you increase it another ring is added.

The cool thing about this is that it gives you a visual indication of the ratios between attributes, and also it records the history of  what order they were increased in. For example, in the above picture, the red attribute was the last to be increased, and was increased four times consecutively.

It couldn’t hurt to provide integer values as well, but hopefully this will be a cool way of recording and display character growth over time.

Other than this, I’ve been working on some AI stuff like path finding and steering, as well as making some better quality character assets. I’m arriving at a pretty clear overview of everything left to be done and I think I’m successfully avoiding feature creep.


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.

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.