Please check out The Fairy Garden MUSH !

Member Discussions

terms
Coding and Mud Design (Advanced)  

Jump To Board:

It's Not Just a Game |------[ http://www.retromud.org ]------| It's an ATTITUDE
6 Planets. 60 Races. 1,000 Skills & Spells. Infinite Possibilities.

[Previous] [Next] [Post] [Reply] [Topics] [Summary] [Search]

1. Non-Automated Combat Tue Feb 1, 2005 [3:51 PM]
Aidan_RoD
immortal@realmsofdiscordia.com
member since: Jun 24, 2004
Reply
Maybe this goes here? If not I'll move it to the other forum, but it is game design so I thought...:)

I am starting on a new project to move our combat system from automated combat to non-automated combat, however, I am at a loss as to where to start on something like this.

Do I add in skills and commands to take into account each and every hit, spell, parry, etc?

Any ideas and suggestions would be appreciated.

Thanks
Aidan
Realms of Discordia


2. RE: Non-Automated Combat Tue Feb 1, 2005 [5:24 PM]
Nym
NymiethePooh@gmail.com
member since: Jun 13, 2000
In Reply To
Reply
There's a couple of practical examples out there on ways this has been done. One is the Gladiator codebases done up by Kavir as examples on how the combat might work for Godwars II. You would have to do some work to get this to work however, but it's great for getting an idea on how it could be done.

Another codebase you may want to look at is DBArena2. It has a non-automatted combat system as well. It's less involved that the gladiator one however. It doesn't worry about body locations and such.

One thing that I have found with the non-automatted combat systems is that they seem to take more time for each fight. They can be great for encouraging PK since they cause combat to be much more involved. Just be preparred to spend at least twice as long per combat as you do now. I've spent as much as twenty minutes in a single combat with a mobile before bcause there is a lot of posturing and maneuvering that tends to occur with this type of combat. I haven't had many combats last that long, but it has happened.


3. RE: Non-Automated Combat Tue Feb 1, 2005 [7:04 PM]
Aidan_RoD
immortal@realmsofdiscordia.com
member since: Jun 24, 2004
In Reply To
Reply
That was another question..how do the NPC's handle the combat? Just scripted to react a certain way?


4. RE: Non-Automated Combat Tue Feb 1, 2005 [7:21 PM]
Xenophon
Email not supplied
member since: Oct 31, 2003
In Reply To
Reply
I've been debating changing our turn-based combat model into something greater, but I see going completely towards manual combat as problematic. Unless I'm willing to write a custom client, not every player is on equal footing, as some can use alias'd/trigger'd/macro'd clients, while others are forced to telnet. What I thought about was a less intrusive automatic combat system. You'd begin the fight with some form of initiation, a push, a shove, a punch, a kick, an uppercut. Depending on your position and theirs within the local-area, (i.e. If you're standing back to back, an uppercut would be uneffective where kicking backwards(Mule kick?) may be quite effective in knocking out their knees.) Then the combat goes into semi-automatic combat. You previously specify which attacks you'll do in a fight, this can be up to three individual moves where the mud will choose. Based upon your first attack, your second attack should(Although it's set at your choice) follow up with a complimentary combination. (To get technical and complicated, if you could pull off a 10-hit combo, you'd be doing good ;) Now, your amount of attacks is based off of some static calculations of your attributes(force/agility), your weapon(size, weight, twohanded?), your skill(Proficient vs. newbie), etc. How often you attack is based off of another set of static calculations(Mainly time to get back into an attacking stance, as you just swung a 50lb axe, etc, but also depending on weapon stats and your force, etc). So a player may hit once every 3/10ths of a second, while another may hit three times every 2 seconds. This makes things interesting when one weapon can do 20 damage and gives you two extra attacks and weighs very little, while another can do 50 damage with one extra attack and weighs moderately. So you choose for your fight. As well, even if I only receive 1 attack every 3/10ths of a second as opposed to your 3 attacks every 2 seconds, that means at the initial 'start' of the fight, if you attack me, I get hit 3 times and you have to wait another 2 seconds before you can hit me again 3 times. All of a sudden, in the 2 seconds between now and then, I can get almost 7 attacks, as I attack every 3/10th of a second. (With better more complimentary numbers, this example would've went smoother ;) Now, while fighting, you may alter your fighting technique, stance, or add an extra attack. Altering your stance in the middle of the other guy doing a 6second 9hit combo may throw it off, giving you an advantage(Example he then misses his next attack round, or some-such). If my fighting technique's skill is less than a chance against your force and your weapon's weight, my parrying your weapon wouldn't work and I'd still receive partial damage. As for the extra attack, this is your fight-driven attack. An example would be punching, kicking, hair pulling, tripping, leg sweep, kicking a kneecap, grabbing their tail and attempting to throw them(If they have a tail :P), etc. Each attack would do damage, as well as hurting the percent-health of that persons attacked-region. An example, if you continually slammed on a persons wrist with a hammer, it'd break fairly quickly and then the other person would be unable to wield a weapon nor parry attacks with that arm(Unless the arm itself was used and that'd be gone quickly). Depending on how indepth you brought this, and how much "lag" or waiting time was associated with each attack or stance change or fighting technique, you could make this more automated, or more manual. If you the fastest (automatic)attacks every second, with a maximum of 2 attacks(as an example) but made the fastest (manual)attacks every half-second, your system would be more input driven. Or if you made manual-attacks do more damage or cause more health-related negativity(Broken bones affecting automated combat etc), they could still take longer to do, but have a much more noticeable effect which would give better results than slamming the guy with a wooden stick. I'll leave the time-specific things up to the person that implements the system though, because to be fair, you have to take into account the playerbase that will be using the combat model(If they're all going to use your custom client or not, if they all have the same typing speed(Unrealistic, but used as an example), etc), the size of combatants(Mice being hit with hammers may do more than Dragons being hit with hammers), and a multitude of other mud-specific designs.
Xenophon


5. RE: Non-Automated Combat Tue Feb 1, 2005 [9:15 PM]
Nym
NymiethePooh@gmail.com
member since: Jun 13, 2000
In Reply To
Reply
How do mobiles fight with automatted combat systems? I don't think Gladiator has a mobile setup to start with. You might want to check out DBArena2 first if you want to see how it could be handled. I think it even has a couple of specs utilizing the sytem as well. I don't rightly remember however.


6. RE: Non-Automated Combat Wed Feb 2, 2005 [2:03 AM]
KaVir
Email not supplied
member since: Aug 19, 1999
In Reply To
Reply
> How do mobiles fight with automatted combat systems? I
> don't think Gladiator has a mobile setup to start with.

Version 2 doesn't, no. Version 3 uses fixed sequences of techniques customised for each mobile (based on its weapons, skill and fighting style) - a sequence is then selected at random during combat, then once it's complete another sequence is selected, and so on.

The results are passable; a well configured mob can beat an average player of the same power level. However it doesn't allow the mob to adapt or learn tactics, and because the strategy (and setup) is fixed it allows smart players to deliberately create countertactics for each specific mob.
God Wars II: http://www.godwars2.org (godwars2.org 3000) Roomless world. Manual combat. Endless possibilities.
MudLab: http://www.mudlab.org


7. RE: Non-Automated Combat Wed Feb 2, 2005 [3:46 AM]
Dodinas
Email not supplied
member since: Apr 7, 2001
In Reply To
Reply
Here are my suggestions for how to go about designing a non-automated combat system...

1. Completely non-automated or automated with a manual overlay

Your first decision is to choose between these two options.

By "completely non-automated", I mean that every attack and action requires the user to type something in.

By "automated with a manual overlay", I mean you type "attack " to start combat off, and your character automatically does some combat things, but you type manual commands on top of this.

These manual commands can either work in addition to the automatic attack, or replace it, or both.

Personally I prefer the latter system, as I think it works better if any of your players lag and makes triggering less of an advantage.

2. Fixed round time or variable

Do you want your combat to come in fixed rounds, where people queue up an action, or have it variable?

I find that clumping everything in one go in a fixed round makes it easier to follow, but having things variable means you can more easily make different attacks take a different amount of time to execute.

Another option is to combine the two, where you generate action points or similar each round with abilities using a different number, so slower attacks may go over multiple rounds, or you may be able to do more than one action in one round if they are low-point actions.

3. Decide what sort of actions are a part of this system

Obviously attacks are a part of this system, but what about other things a character might do, like casting a healing spell, or fleeing combat?

4. Come up with some actions to incorporate into the system

Some basic attacks should do - come up with what variables will influence the ability. Some example are:

- damage
- energy/stamina/point cost
- when does it execute? Examples: next round, immediately, in 5 seconds
- is there a cooldown? Ie. If you do this attack, you can't do it for another 15 seconds, or can you do it right away?

5. Depending on your answer to #1, code your queue system

So create a system where you can queue attacks (or at least specify your next one), and a timer to then execute that attack, work out if it hits etc, and go from there.

Hope these initial thoughts help you get started, anyway!

- Thomas.


8. RE: Non-Automated Combat Wed Feb 2, 2005 [3:48 AM]
Dodinas
Email not supplied
member since: Apr 7, 2001
In Reply To
Reply
One option is to have them choose random actions.

Another one is to build a finite state machine...

...where each round or before each action the NPC assesses its current situation and decides what to do based on how you've programmed it.

A site like this might help ...

http://ai-depot.com/FiniteStateMachines/FSM-Framework.html

Or alternatively search for something like "finite state machine game ai" :)


(Comment added by Dodinas on Wed Feb 2 5:49:16 2005)

Clickable link - http://ai-depot.com/FiniteStateMachines/FSM-Framework.html


9. RE: Non-Automated Combat Wed Feb 2, 2005 [4:24 AM]
KaVir
Email not supplied
member since: Aug 19, 1999
In Reply To
Reply
> 1. Completely non-automated or automated with a manual
> overlay

What about manual with an automated overlay (eg non-automated, but with a weaker automated option for newbies)?

> By "completely non-automated", I mean that every attack
> and action requires the user to type something in.

You may also want to consider partially automated (eg attacks are manual, but defences are automatic).
God Wars II: http://www.godwars2.org (godwars2.org 3000) Roomless world. Manual combat. Endless possibilities.
MudLab: http://www.mudlab.org


10. RE: Non-Automated Combat Wed Feb 2, 2005 [8:29 AM]
Aidan_RoD
immortal@realmsofdiscordia.com
member since: Jun 24, 2004
In Reply To
Reply
Thanks for all your help guys! Its been very informative and helpful, and I believe I know which route to take. I'm thinking that the automated/manual combination routine will be best so that the players arent totally overwhelmed with the new system when its put in. That should also make it a tad easier in combat when queing up the different attacks you want to go off.

Again, many thanks to everyone.

Aidan
Realms of Discordia


11. RE: Non-Automated Combat Wed Feb 2, 2005 [3:19 PM]
Nym
NymiethePooh@gmail.com
member since: Jun 13, 2000
In Reply To
Reply
Good point KaVir. DBArena2 wqas a partially automatted system. You actively put in attacks and manually position, but the defences are actually automattic.

The MMORPG Wish also used a partial system. You manually attacked, and the defences happened automattically. It was poorly implemented for counterattacks though.


12. RE: Non-Automated Combat Wed Feb 2, 2005 [5:57 PM]
nephos
Email not supplied
member since: Jan 14, 2001
In Reply To
Reply
I've been debating changing our turn-based combat model into something greater, but I see going completely towards manual combat as problematic. Unless I'm willing to write a custom client, not every player is on equal footing, as some can use alias'd/trigger'd/macro'd clients, while others are forced to telnet.

Not quite.
I had successfully coded a manual combat system that would save a character's "move" for when they're ready to attack again. Of course, depending on what happens within the next four to six seconds, the player can always change their next move. It worked out quite well.

Unfortunately, I've never coded for any projects that simply didn't die out (my fault in some cases). Nonetheless, I was impressed with how that combat system worked.


13. RE: Non-Automated Combat Wed Feb 2, 2005 [6:05 PM]
nephos
Email not supplied
member since: Jan 14, 2001
In Reply To
Reply
Manual combat can be implemented to not be fearsome at all.

The principle is that every character gets a certain amount of time between their moves. A character doesn't really have to do anything on some of those moves either. And sometimes, such a strategy could work out. I think a lot about pk personally, so that's why I try to look at this from how I would want to play it.

Anyway, the way I implemented manual combat on a codebase I was modifying was that every player had a timer. Every time violence was 'updated' (I was working on a Diku-derivative obviously) all characters had their timer decrement, towards zero. If you were fighting and your timer hit zero, you could attack, cast, flee, etc. This wouldn't work out so well when thinking that some people would have an unfair advantage with triggers or timers on their mud clients. So I implemented a next_move sort of variable for players. If you input a combat command while waiting for your next move, that command would be saved and used when your timer hit zero. The command could be changed at any time before the timer hit zero, so you may at first want to attack, but suddenly some bear comes in and starts beating the crap out of your mom, so you'd rescue your mom or something. That sort of idea.

I personally thought it was way better than the conventional hack-and-slash Diku style.

And npcs would pretty much just attack over and over again. Some simple AI could be done to allow mage or cleric npcs fight as if they were mages or clerics, as opposed to really weak warriors.


14. RE: Non-Automated Combat Wed Feb 2, 2005 [6:35 PM]
Xenophon
Email not supplied
member since: Oct 31, 2003
In Reply To
Reply
That doesn't sound like a bad idea, however that would restrict the speed of the fight, right? I don't want to jump aboard a tangent, but in order for a fight to be exciting, it requires some kind of "edge" or risk(Completely my opinion, but basing this around a mud which is played purely for the fighting aspect), while slowing things down too much may actually hinder any excitement. I'd compare it to a roller-coaster and a kiddie-ride at an amusement park. I'm not saying it'd be impossible to make it fun, or fast, or what have you, but to me, the idea of a manual-combat model has always been to keep the player involved in the action, encouraging them to do more than just type 'kill bob', and watch the automated fight spam. I just don't see how involved I could get with a slow fight :-) Probably about as involved as I get with a regular fight, and simply macro everything. (Kill mob; kick; punch; cast 'fireball'; get all.coins corpse;) Would the speed of the fight affect you? Is a 4-6 second buffer enough to keep you attracted, but enough time to use a "chess strategy" in the fight? (By Chess strategy, I mean thinking ahead, basing your next moves off what you feel your opponents next moves will be(Or what may limit his next moves), etc. Using your head ;) I'd think on a more fight-driven mud with a manual system, the entire excitement of it would be the fast-paced input/involvement driven combat :) Although, if you thought about keeping that 4-6 second buffer, but also added in defensive moves in the combat zone(and even magic casting), and allowed someone to type in defensive moves or stance changes/etc while they're waiting for their 4-6 second attack command to go through, that might be a neat idea. I don't know, tied and quartered on the subject I guess.


15. RE: Non-Automated Combat Thu Feb 3, 2005 [12:04 AM]
nephos
Email not supplied
member since: Jan 14, 2001
In Reply To
Reply
Actually, part of my idea was to reduce the speed and put a disclaimer that you'll need a decent connection and ability to type to even bother playing.

I still think that would be awesome. If combat were based on responses made every, at most, 2 seconds, it would make everything a lot more exciting to me. But I'm still thinking on a pure-pk system. I don't think fighting mobs would be exciting at all, and simple botting would probably occur from it. The possibility of allowing players to turn on automatic combat for fighting against npcs crossed my mind.


16. RE: Non-Automated Combat Thu Feb 3, 2005 [1:15 AM]
Dodinas
Email not supplied
member since: Apr 7, 2001
In Reply To
Reply
If you're going to make combat fast, I'd recommend allowing quick aliasing (so letting the player set 1 = fireball, 2 = charge, etc) so the players without triggers aren't at a huge disadvantage. :)

On a side note...

One element you could include in a combat system is having the effectiveness of attacks be partially influenced by the time since it was last used, rather than having a static effect.

A possibile implementation of this is to use an 'fatigue' system where the player starts with zero fatigue, and each action increases fatigue up to a certain threshold.

Fatigue naturally regenerates over time (quickly), and you can still do actions once above the threshold, but while in this range the attacks can have lower effectiveness or a greater chance of failing.

Eg. You start with 0 fatigue + have a threshold of 10. You do a few attacks (with appropriate delays to execute) and you find yourself at 12 fatigue. Now as a player you have a choice to pace yourself or to keep up the flurry of attacks hoping to get it over with quickly, which you may do if they're near dead, for example.

Incidentally, this 'threshold' system can be incorporated into other systems to add variability to the outcomes -- you could use it for "wounds", for example, where below 100 wounds you're definately ok, and every hit above 100 wounds gives you an increasing % chance of dying... So when you find yourself on 110 wounds, you might die next shot, or you might just get lucky.

Anyhow, just some more thoughts... :)


17. RE: Non-Automated Combat Thu Feb 3, 2005 [2:43 AM]
KaVir
Email not supplied
member since: Aug 19, 1999
In Reply To
Reply
> If you're going to make combat fast, I'd recommend allowing
> quick aliasing (so letting the player set 1 = fireball, 2 =
> charge, etc) so the players without triggers aren't at a
> huge disadvantage. :)

All of the combat commands in my mud are two letters, with the first letter representing the location (left hand, right hand, feet and head) and the second representing the action (eg, for a longsword you have defend, pummel, slash, thrust and whirl). Thus you might simultaneously perform a headbutt (hh = head headbutt), a front kick (fk = feet kick), a sword thrust (rs = right trust) and a shield bash (lb = left bash).
God Wars II: http://www.godwars2.org (godwars2.org 3000) Roomless world. Manual combat. Endless possibilities.
MudLab: http://www.mudlab.org


It's Not Just a Game |------[ http://www.retromud.org ]------| It's an ATTITUDE
6 Planets. 60 Races. 1,000 Skills & Spells. Infinite Possibilities.

Jump To Board:

[Previous] [Next] [Post] [Reply] [Topics] [Summary] [Search]