Targeting, Combat and Colours

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 !


3 Responses to “Targeting, Combat and Colours”

  1. Good update – look forward to seeing more! 🙂

    The stat-based, non-reflex, yet realtime combat approach certainly sounds interesting.

  2. Awesome! As always 🙂

    It’s good to see a new post, keep it up!

  3. Nice work – really good to hear you talk about your lower-level systems, in particular the separation of logic, rendering, etc..

    I’ve been bouncing back and forth these issues in my current project and trying to tread the line between over-specialised and over-generalised.

    Thanks heaps, lovely to read your blog – good luck!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: