Archive for the Graphics 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.

 

Interface

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.

 

Targeting, Combat and Colours

Posted in Gameplay, Graphics, Screenshots on November 3, 2011 by sfahy

Boom !

 

Things have progressed a lot since my last post, and it’s really starting to take shape as a game.

I’ve added a targeting system, which takes into account both proximity and what direction the player is facing. So if you’re closer to enemy A, but looking right at enemy B, you’ll target enemy B. unless enemy A is right beside you.

It will be possible to switch targets quickly when this system fails to target the enemy you want.

The targeting system is critical because it’s the mechanism for engaging in combat. Combat will be abstracted – you target an enemy, and hold down the attack button. The frequency of attacks, whether you hit or miss etc. will all be functions of your character data.

The idea is a kind of pseudo real time that won’t be dependent on reflex but won’t be immersion breaking. I think turn based gameplay works best when the gameworld is largely abstract. When you see textured 3D models just standing there looking at each other, your mind automatically asks the question “Why?” and the immediate answer is that it’s just a game and they’re just textured 3D models.

Also, a roguelike that requires reflexes for combat is blasphemy, and I’ll have no truck nor traffic with such travesties.

I’ve added hue shifting to the shader, so armour and weaponry can have their colours changed with a shader update. There is a mask texture which allows regions of the textures to be exempt from hue shifting which is good for preserving skin colour and specific materials.

I am undecided as to whether an item’s colour should be a reflection of its game properties. It looks really cool to see a bunch of people with different armour colours, but making colour a purely aesthetic attribute would be passing up an opportunity to provide great intuitive feedback.

Enchanted equipment would be comparatively rare, especially at first, which would mean that a lot of armour would look similar. This would put more weight on different texture variations as a means of keeping things interesting. Also, there will be a lot more variation in the kinds of enchantments than colour can reliably express.

I think a viable solution may be to create several textures for each armour type that correspond to its function, so it’s easy to identify enchanted chain mail by the runes inscribed on it or whatever, and keep colour variation across everything.

The animation system is largely developed and integrated and I can spawn a bunch of enemies to stand around the dungeon doing nothing. At the moment I can have more enemies on screen than are likely with no framerate impact, so all is well in that regard.

Animation objects are fed Actor objects, and update themselves to reflect the Actor’s state. Actors have Controllers which update their state – an actor can be assigned a controller which updates it based on player input, or AI, or conceivably network messages. This system keeps state, logic and rendering code nicely encapsulated away from each other.

I’ve added a resource manager which does a pretty good job of keeping resource fetching abstracted from game logic.

Every game resource is marked up in a textfile, and is basically marked up as a keyword (“stone_block”, “padded_armour”) and the resources it uses (“diffuse:  stoneTex2” etc).

If the game needs an iron sword model, it can call something like GetStaticModel(“sword_2”) or whatever. Everything the game needs to load from disk is reduced to a text key, and the messy interrelations between assets are contained in the textfiles.

This can be extended to game data objects as well, for example items and enemies can written directly in mark-up, with all the data objects necessary to render them specified by a single keyword.

It’s very easy to change the look and feel of a level by simply loading a different textfile which maps keywords like “stoneBlock” and “floor” to different assets.

I’m resisting the urge to overgeneralize this system, it already covers the games needs so far and what’s important is that it remains flexible and extendable rather than catering to every possible necessity.

Anyway, that’s it for now, I’ll try to update this blog a bit more frequently. Thanks for reading !

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.

 

 

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.