views:

235

answers:

3

I'm trying to nut out a highlevel tech spec for a game I'm tinkering with as a personal project. It's a turn based adventure game that's probably closest to Archon in terms of what I'm trying to do.

What I'm having trouble with is conceptualising the best way to develop a combat system that I can implement simply at first, but that will allow expansion and complexity to be added in the future.

Specifically I'm having trouble trying to figure out how to handle combat special effects, that is, bonuses or negatives that may be applied or removed by an actor, an item or an environment.

  • Do I have the actor handle all effects that are in play for/against them should the game itself check each weapon, armour, actor and location each time it tries to make a decisive roll.
  • Are effects handled in individual objects or is there an 'effect' object or a bit of both?

I may well have not explained myself at all well here, and I'm more than happy to try and expand the question if my request is simply too broad and airy. But my intial thinking is that smarter people than me have spent the time and effort in figuring things like this out and frankly I don't want to taint the conversation with the cul-de-sac of my own stupidity too early.

The language in question is javascript, although at this point I don't imagine it makes a great difference.

+2  A: 

Take a look at the book, Head First Design Patterns, by Elisabeth Freeman. Specifically, read up on the Decorator and Factory patterns and the method of programming to interfaces, not implementations. I found that book to be hugely effective in illustrating some of the complex concepts that may get you going on this.

Hope this helps to point you in the right direction.

Rich.Carpenter
I had a look at a few implementations of the decorator pattern in javascript and that does look very promising. I just got work to order the book you suggested too. Thanks :)
Steerpike
A: 

At first blush I would say that the individual combatants (player and NPC) have a role in determining what their combat characteristics are (i.e. armor value, to-hit number, damage range, etc.) given all the modifiers that apply to that combatant. So then the combat system is not trying to figure out whether or not the character's class gives him/her an armor bonus, whether a magic weapon weighs in on the to hit, etc.

But I would expect the combat system itself to be outside of the individual combatants. That it would take information about an attacker and a desired type of attack and a target or set of targets and resolve that.

To me, that kind of model reflects how we actually ran combat in pencil and paper RPGs. The DM asked each player for the details of his or her character and then ran the combat using that information as the inputs. That it works in the real world suggests its a pretty flexible system.

John Munsch
+5  A: 

What you're calling 'special effects' used to be called 'modifiers' but nowadays go by the term popular in MMOs as 'buffs'. Handling these is as easy or as difficult as you want it to be, given that you get to choose how much versatility you want to be able to bestow at each stage.

Fundamentally though, each aspect of the system typically stores a list of the modifiers that apply to it, and you can query them on demand. Typically there are only a handful of modifiers that apply to any one player at any given time so it's not a problem - take the player's statistics and any modifiers imparted by skills/spells/whatever, add on any modifiers imparted by worn equipment, then add anything imparted by the weapon in question. If you come up with a standard interface here (eg. sumModifiersTo(attributeID)) that is used by actors, items, locations, etc., then implementing this can be quick and easy.

Typically the 'effect' objects would be contained within the entity they pertain to: actors have a list of effects, and the items they wear or use have their own list of effects. Where effects are explicitly activated and/or time-limited, it's up to you where you want to store them - eg. if you have magical potions or other consumables, their effects will need to be appended to the Actor rather than the (presumably destroyed) item.

Don't be tempted to try and have the effects modify actor attributes in-place, as you quickly find that it's easy for the attributes to 'drift' if you don't ensure all additions and removals are done following the correct protocol. It also makes it much harder to bypass certain modifiers later. eg. Imagine a magical shield that only protects against other magic - you can pass some sort of predicate to your modifier totalling function that disregards certain types of effect to do this.

Kylotan
Thanks for the fantastic response. Makes perfect sense (although you lost me a bit in the final paragraph regarding attributes in place and 'drift').
Steerpike
Imagine: - In wearItem() you apply effects associated with an item to a character's stats, eg. actor.strength += item.sumEffects(STRENGTH) - In removeItem() you remove any such effects, eg. actor.strength -= item.sumEffects(STRENGTH)This sort of thing works fine until you add other ways for items to be 'removed', eg. by consumption, damage, being teleported away, confiscated by GMs in an online game, etc. You have to remember to strip the effects in each possible scenario you add, and can get subtle bugs that way, so it's safer to calculate the values on demand.
Kylotan
Sorry about the formatting there: pretend the hyphens before 'in wearItem' and 'in removeitem' are bullet points and 'This sort of thing' starts a new paragraph!
Kylotan
Ah, perfect explanation. I ran into that *exact* problem trying to write a disarm skill for a mud ages ago - I just couldn't articulate what the problem was. Thanks for taking the time to exlain it so clearly.
Steerpike