f13.net

f13.net General Forums => Game Design/Development => Topic started by: pxib on June 18, 2009, 05:51:29 PM



Title: Cast time, Cooldown, Charge up, and Reload
Post by: pxib on June 18, 2009, 05:51:29 PM
Over in the SWOTR thread (http://forums.f13.net/index.php?topic=15047.1540) there was some discussion of long cooldowns and griping about MMO combat and it occured to me that there are at least two simple variations on the standard ability types that I haven't seen used outside of the FPS. By and large, MMO abilities either have a casting time during which the character is frozen in place or "cast" instantly with a cooldown period afterwards.

Why not reverse them? A cooldown period could be placed in front of an ability, charging it up so that it can be held ready to instantly cast, but only if the player actually uses it. Decide to do something else and the "charge up" is lost. Alternately a cast time after an instant ability would function like reloading. Rather than needing to stand still casting, characters need to find somewhere safe to "reload". Reloads would be just as succeptible to interruption as cast times, if not more so.

Is there some obvious procedural or gameplay reason the second two aren't more widely used?


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: IainC on June 18, 2009, 06:01:20 PM
DAoC Warlocks.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: DLRiley on June 18, 2009, 08:18:16 PM
Not a bad idea. Though lets say there is a precast ability then a "fire" when you want to, like loading a rocket, it makes the follow up really hard. You have to scale damage of said ability and you have to have a certain amount of active (preferably active) or passive defense in order to allow for said damage to be properly balanced. Then there is a shotgun idea where you have a few buck shots before you have to put all 9 bullets in the chamber. As a caster I want to be able to use an ability when I feel that it is necessary for me to do so, the reload will always be a problem even if a full round (all 9 bullets) on a target means dead. Think savage 2 lack of a range combat system where 1 full minigun round doesn't equal close to dead and having to hope you can find someplace to reload your gun.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Ingmar on June 19, 2009, 02:27:41 AM
I'm not sure the stand-still-to-bring-your-skills-off-cooldown idea has a lot of legs in normal MMO pvp. It would probably work in a game with little to no melee combat, like a modern or sci-fi sort of game with mostly gunplay - I can imagine getting behind an obstacle or whatever long enough to reload while your enemy circles around to get you in LOS - but in a melee-heavy game, like most fantasy stuff, it seems to me that it would be a major, major disadvantage against melee characters unless it also somehow let you kite - a snare type effect or whatever.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 19, 2009, 09:40:09 PM
Why not reverse them?

I'll be brief.

Quote
A cooldown period could be placed in front of an ability, charging it up so that it can be held ready to instantly cast, but only if the player actually uses it. Decide to do something else and the "charge up" is lost.

Can't be used situationally, largely negating the point of an instant cast.

Quote
Alternately a cast time after an instant ability would function like reloading. Rather than needing to stand still casting, characters need to find somewhere safe to "reload". Reloads would be just as succeptible to interruption as cast times, if not more so.

1. Worse assist trains than usual, dead in the width of a global cooldown with effectively no warning and no ability to interrupt individual casts nor AoE interrupt/CC until after you eat the nuke.
2. Easier to kite if range can be maintained, as you engage the target further out (instant cast rather than ~1-3 seconds from outer range limit) making slow/stun/snare procs more effective.
3. How do you handle interrupts and lockouts?  Completely disable everything they have until they finish their reload?
4. All told, melee dominate completely and utterly if they ever get to melee range without any recourse on the others part, otherwise the ranged wins by default.  Frustrating pvp.



I see a lot of potential in the "next attack" mechanic that WoW barely touches.  The intervals between incoming damage are fairly regular and it allows haste effects to be very viable, which is nice because it's significantly less bursty than the way most games handle critical strikes and +damage.  Personally I'd like to see the main damaging attacks be "next attack" with non-damaging buffs/debuffs being handled with instant casts + GCD/CD.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 20, 2009, 07:32:06 AM
Was this used in UO?  Precasting?  Mists of time....

Anyway, this actually was used in Arx Fatalis and it works much like memorizing spells.  You could have three precast spells that you could fire with a keypress (1,2,3) or you could cast any spell the manual way (Arx used mouse gestures to cast spells).  I don't see why this would not work, assuming you would store up something for general emergencies like CORP POR or whatever (mists of time!), or teleports, etc.  This would work great in a nice, complex magic system.  In a simpler one it could be seen as unnecessary.

Sheepherder, your comments are valid in the case where this system is forced into an existing game.  You'd want to design this into the game from the start, also maybe deviate from formula a bit. :oh_i_see:


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Nebu on June 20, 2009, 09:44:01 AM
DAoC Warlocks.

Great example.  This implementation demonstrated how stupid this mechanic can be in a pvp game.  

Step 1 - Warlock chambers up 3 dd's.

Step 2 - FIRE!  Kills enemy instantly (which sucks if you're the target of the attack.)

Step 3 - Run back to cover to chamber 3 more spells.  

It's a fun idea for pve, but increases downtime between attacks.  It's a terrible idea for pvp.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 20, 2009, 09:32:44 PM
Sheepherder, your comments are valid in the case where this system is forced into an existing game.  You'd want to design this into the game from the start, also maybe deviate from formula a bit. :oh_i_see:

How do you build a system where being able to frontload damage doesn't instantly turn into assist trains cropping up in organized pvp, just cut pvp completely?  Because even if you were to do something crazy like limit the amount of damage a player can take from multiple sources in a short period the problem of massive parallelism which is inherent to multiplayer games would make the fix untenable.

Case in point: (About the ability of a server to negotiate several actions at once)

Blizzard added a talent called "Shatter" to frost mages, granting them massive (near 100%) critical strike chances on frozen targets.  Simultaneously, the critical strike landing should immediately dispel the "frozen" proc, yet frost mages can easily combine a spell cast (frostbolt) and an instant cast (ice lance) to gain two critical strikes off of a single "Frozen" proc.  The combo is now worse because there's an instant cast stun on frozen targets which lets you draw the chain out even longer.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Samprimary on June 23, 2009, 07:18:35 AM
It is possible to balance this into games but it can't be how all spells work. You would still need to make most spells timed cast or instacast, and the 'have to stand still to charge it back up' would be an interesting way to create an effective nerf for some instacast spells, such that they can't really be used multiple times during a chase, etc.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Nebu on June 23, 2009, 08:28:35 AM
Insta cast spells should have very specific uses (like an interrupt) and have long cooldowns.  Being able to run and gun gives too big an advantage, especially to classes that already have huge ranged advantages.  

Kiting renders instas overpowered if they aren't tempered by cooldown timers. Especially when most ranged casters are also given some type of cc.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Glazius on June 23, 2009, 09:01:54 AM
Over in the SWOTR thread (http://forums.f13.net/index.php?topic=15047.1540) there was some discussion of long cooldowns and griping about MMO combat and it occured to me that there are at least two simple variations on the standard ability types that I haven't seen used outside of the FPS. By and large, MMO abilities either have a casting time during which the character is frozen in place or "cast" instantly with a cooldown period afterwards.

Why not reverse them? A cooldown period could be placed in front of an ability, charging it up so that it can be held ready to instantly cast, but only if the player actually uses it. Decide to do something else and the "charge up" is lost. Alternately a cast time after an instant ability would function like reloading. Rather than needing to stand still casting, characters need to find somewhere safe to "reload". Reloads would be just as succeptible to interruption as cast times, if not more so.

Is there some obvious procedural or gameplay reason the second two aren't more widely used?

Cooldowns give you time to assess the results of what you just did and decide what you need to do next.

If, immediately after you finish casting something, you can do something else, then NOT doing something else is cutting out your damage output/whatever, which can create undue pressure on people to just do SOMETHING. Especially if you have to lock yourself into charging something up, the delay's happening in exactly the wrong place for people to evaluate the results of their action and make a decision.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 23, 2009, 09:46:39 AM
Sheepherder, your comments are valid in the case where this system is forced into an existing game.  You'd want to design this into the game from the start, also maybe deviate from formula a bit. :oh_i_see:

How do you build a system where being able to frontload damage doesn't instantly turn into assist trains cropping up in organized pvp, just cut pvp completely?

Sure, cut it, which is what I meant by designing for it from the start.  I didn't realize you were talking about PvP; please see Nebu's post on this.

Because even if you were to do something crazy like limit the amount of damage a player can take from multiple sources in a short period the problem of massive parallelism which is inherent to multiplayer games would make the fix untenable.

I agree this is crazy and you point out why: it is a "fix".  You are still thinking of putting precasts into an existing system and then hammering it into working.  This is a mental trap, my friend.  The game has to be designed from the start to use this.

Your WoW example is merely an example of both bad design and bad programming.  I believe it's called a "race condition" although I'm not a CS major.  I'm also confident that PvP was added to WoW at the last minute, so it's not like Blizzard is the paragon of forethought.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Tarami on June 23, 2009, 01:07:33 PM
Things like Shatter are buggy because WoW's buff system is bent to do a thousand things it wasn't originally designed to do. This naturally results in some dubious behaviour.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: DLRiley on June 23, 2009, 02:56:36 PM
Over in the SWOTR thread (http://forums.f13.net/index.php?topic=15047.1540) there was some discussion of long cooldowns and griping about MMO combat and it occured to me that there are at least two simple variations on the standard ability types that I haven't seen used outside of the FPS. By and large, MMO abilities either have a casting time during which the character is frozen in place or "cast" instantly with a cooldown period afterwards.

Why not reverse them? A cooldown period could be placed in front of an ability, charging it up so that it can be held ready to instantly cast, but only if the player actually uses it. Decide to do something else and the "charge up" is lost. Alternately a cast time after an instant ability would function like reloading. Rather than needing to stand still casting, characters need to find somewhere safe to "reload". Reloads would be just as succeptible to interruption as cast times, if not more so.

Is there some obvious procedural or gameplay reason the second two aren't more widely used?

Cooldowns give you time to assess the results of what you just did and decide what you need to do next.

If, immediately after you finish casting something, you can do something else, then NOT doing something else is cutting out your damage output/whatever, which can create undue pressure on people to just do SOMETHING. Especially if you have to lock yourself into charging something up, the delay's happening in exactly the wrong place for people to evaluate the results of their action and make a decision.

Cooldowns don't give you time to assess the situation...


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 23, 2009, 03:44:39 PM
In Soviet Russia, situation assesses you!


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Glazius on June 23, 2009, 05:35:49 PM
Over in the SWOTR thread (http://forums.f13.net/index.php?topic=15047.1540) there was some discussion of long cooldowns and griping about MMO combat and it occured to me that there are at least two simple variations on the standard ability types that I haven't seen used outside of the FPS. By and large, MMO abilities either have a casting time during which the character is frozen in place or "cast" instantly with a cooldown period afterwards.

Why not reverse them? A cooldown period could be placed in front of an ability, charging it up so that it can be held ready to instantly cast, but only if the player actually uses it. Decide to do something else and the "charge up" is lost. Alternately a cast time after an instant ability would function like reloading. Rather than needing to stand still casting, characters need to find somewhere safe to "reload". Reloads would be just as succeptible to interruption as cast times, if not more so.

Is there some obvious procedural or gameplay reason the second two aren't more widely used?

Cooldowns give you time to assess the results of what you just did and decide what you need to do next.

If, immediately after you finish casting something, you can do something else, then NOT doing something else is cutting out your damage output/whatever, which can create undue pressure on people to just do SOMETHING. Especially if you have to lock yourself into charging something up, the delay's happening in exactly the wrong place for people to evaluate the results of their action and make a decision.

Cooldowns don't give you time to assess the situation...

Okay, cooldowns give ME time to assess the situation.

Or rather to do a quick incremental reassessment, based mostly on the question "is my target dead yet?"


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: DLRiley on June 23, 2009, 10:37:47 PM
Damn you must die an awful lot. The only time I am given the chance to make incremental reassessments is if the target is already dead and his buddies are a good 10 real time minutes away.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: ezrast on June 24, 2009, 12:40:39 AM
Damn you must think awful slow.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 24, 2009, 04:57:40 AM
I agree this is crazy and you point out why: it is a "fix".  You are still thinking of putting precasts into an existing system and then hammering it into working.  This is a mental trap, my friend.  The game has to be designed from the start to use this.

So, then since I'm the ignorant one here tell me how you create a system predicated on the assumption that precasts are useful without making normal casts inherently inferior, unless you're ditching normal casts, or making your precasts entirely situational little gimmicks (like instants) too?  Which is sort of what I asked, to which you responded with "but you're just fixing existing things, you need to burn it all!"

Quote
Your WoW example is merely an example of both bad design and bad programming.  I believe it's called a "race condition" although I'm not a CS major.  I'm also confident that PvP was added to WoW at the last minute, so it's not like Blizzard is the paragon of forethought.

No, actually, it's exactly the opposite of bad design and programming, although it is in fact a race condition.  The server, by it's very nature, cannot afford to wait on incoming action to construct a perfectly dandy linear series of events (frozen proc -> shatter crit -> remove proc) because it's negotiating several thousand connections at once, each supplying a multitude of packets with varying levels of importance, a number of which require extrapolation of data to factor latency which creates a further set of race conditions as well as problems with negotiating with the client where exactly they are.  The only way to handle my example with any degree of certainty would be to eliminate both the latency inherent in the internet and allow fairly trivial procs to have a high priority for processing, which means it's only viable if handled at the client.  We can all agree that this would be ridiculously fuckstupid to trust the client to, even by Mythic standards.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: DLRiley on June 25, 2009, 06:44:55 AM
Damn you must think awful slow.

I'm not the one who figures doing nothing for x amount of seconds allows me to reconsider a course of action against an opponent who isn't afk.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: NiX on June 25, 2009, 06:08:44 PM
Damn you must think awful slow.

Don't be a dick.

The problem with pre-casting is that without sufficient limitation, and as you said, you're only reversing it. When you get into PVP, even if you can only pre-cast 2, since in the warlock scenario 3 is a bit overpowered, when you get down to hammering buttons, it's the same thing.

I'm pretty much reiterating what everyone is saying, it's a bit too hard to implement for PVP. PVE would be great as it would add a tactical aspect to each encounter. Pre-load the wrong first attack and it could change the course of the fight.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 25, 2009, 11:37:09 PM
Just to stop being a total killjoy here:

(short) Cast -> Fire Ability -> Reload

Basically letting the player reposition after firing but before they reload, while simultaneously giving an interrupt window of opportunity in pvp.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Typhon on June 26, 2009, 05:56:42 AM
Sorry to be (another) nay-sayer, but I don't see how any of these methods add to the "fun".  I think they just create a different experience (with diffrent problems), rather then better experience.

The only thing I can think that would be better would be to change activation to a charge-up*, but I don't think net latency is at a decent enough point to allow this without frustration (or worse, if it's all client side, cheating).

* the longer you hold the mouse button down, the more juice you are putting into the power up to a maximum amount.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Famine on June 26, 2009, 12:24:05 PM
Sorry to be (another) nay-sayer, but I don't see how any of these methods add to the "fun".  I think they just create a different experience (with diffrent problems), rather then better experience.

The only thing I can think that would be better would be to change activation to a charge-up*, but I don't think net latency is at a decent enough point to allow this without frustration (or worse, if it's all client side, cheating).

* the longer you hold the mouse button down, the more juice you are putting into the power up to a maximum amount.

I think that's the best way to go about this. Charging up before battle has no value on spells or skills that either are instant or have a casting time (i.e.: charge up to use this ability). You might as well make any instant or timed ability have an insane long cooldown or just doesn't recharge until you're out of combat all together.

What most are forgetting here with the Warlock example is that it gave people the chance to combine spells I believe. This adds value to the whole "recharge" aspect of the ability in having choices on what to build for your battle. It's like a toolbox concept where you can bring a sideboard (i.e.: like MTG sideboards) and conform to the targets you're smacking down. The downside however is another story.

I do like the whole 'holding down mouse button to charge power in the ability before firing' idea. In a system where melee can disrupt the charging, it could lead to having more tactical game play on where you stand to use it while targeting a victim. Making the ability max_damage or affect balanced with all other abilities doesn't make the charging any more different than everyone elses potential. Then the point of having it is to have a tactical ability with no cooldown that has a player controlled casting time with varied affect based on the charge (i.e.: if you spam it, the affect output is useless but if you can manage to charge it up decent enough it's useful while having a perceived cooldown effect).


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 26, 2009, 03:19:25 PM
I agree this is crazy and you point out why: it is a "fix".  You are still thinking of putting precasts into an existing system and then hammering it into working.  This is a mental trap, my friend.  The game has to be designed from the start to use this.

So, then since I'm the ignorant one here tell me how you create a system predicated on the assumption that precasts are useful without making normal casts inherently inferior, unless you're ditching normal casts, or making your precasts entirely situational little gimmicks (like instants) too?  Which is sort of what I asked, to which you responded with "but you're just fixing existing things, you need to burn it all!"

I believe your "or" condition would answer your question, except I might make them something other than little gimmicks.  Big ones maybe, like an precast teleport, but little gimmicks are fine too.  They can definitely coexist, as can be seen in LotRO.  In fact, a third type is added: instant-cast without cooldown.  I did say "burn it all" without then posting a new spell system, but if you are asking me to come up with a fleshed-out one... that would take a while I suppose, unless I used LotRO, Arx Fatalis or thought of another system.  I'd like to know if you wanted a PvP MMO system, or something else, as well since that's important to the design.

Arx Fatalis does what you are saying, because any spell can be precast and not precasting makes it difficult to cast in tense situations; however it is still doable.  I didn't really need to precast the night-vision spell since I did not need to cast that one in combat, for example, so I would not waste a precast slot on it.  I usually had three fireballs loaded up.

No, actually, it's exactly the opposite of bad design and programming, although it is in fact a race condition.  The server, by it's very nature, cannot afford to wait on incoming action to construct a perfectly dandy linear series of events (frozen proc -> shatter crit -> remove proc) because it's negotiating several thousand connections at once, each supplying a multitude of packets with varying levels of importance, a number of which require extrapolation of data to factor latency which creates a further set of race conditions as well as problems with negotiating with the client where exactly they are.  The only way to handle my example with any degree of certainty would be to eliminate both the latency inherent in the internet and allow fairly trivial procs to have a high priority for processing, which means it's only viable if handled at the client.  We can all agree that this would be ridiculously fuckstupid to trust the client to, even by Mythic standards.

I think I must not be understanding what you are saying, but what I get is that the server cannot be sure that an instant-cast was done before or after a non-instant-cast.

Quote
Blizzard added a talent called "Shatter" to frost mages, granting them massive (near 100%) critical strike chances on frozen targets.  Simultaneously, the critical strike landing should immediately dispel the "frozen" proc, yet frost mages can easily combine a spell cast (frostbolt) and an instant cast (ice lance) to gain two critical strikes off of a single "Frozen" proc.  The combo is now worse because there's an instant cast stun on frozen targets which lets you draw the chain out even longer.

You seem to know a lot more about WoW proramming than me, so bear with me because I'd like to understand.
0) Frost mage has "Shatter" talent, 99.7% chance to crit on frozen target.  Assume target is frozen.
1) Frost mage casts Frostbolt.
2) Frost mage casts Ice Lance.
3) Frostbolt hits target. Crit.
4) Ice Lance hits target. Crit.
5) Frozen status is removed from target.

Seems to me that there's a problem in #3 where the Frozen status is not being removed.  No?  Even in a case where Ice Lance lands first (latency or keypress or whatever) it seems like the server is not removing the Frozen status properly.

Anyway, this may or may not be fun, as mentioned.  I'm just having an academic discussion, not voting Precast for President.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Ingmar on June 26, 2009, 03:57:25 PM
The issue is, I believe, that it checks for frozen status at the time the spell is released, so you can chain up a spell with a travel time first and then use an instant and they both get it.

It isn't clear to me that it isn't intentionally like that, since it wouldn't be difficult to change.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Tarami on June 26, 2009, 04:10:05 PM
Projectiles are only cosmetic so yes, that makes sense. The bolt damage gets evaluated on cast, then delayed to trigger when it's supposed to land. In the time between the bolt's release to the bolt's estimated landing you can cast additional spells that consume the same debuff because the bolt's effects haven't actually been applied but still computed.

I don't think they can fix it cleanly because it would mean the damage would be separated from the scripted effects. If the debuff was removed before the damage was dealt, it would be obvious that you did hit (the buff is removed, which it wouldn't be if you missed) before you actually dealt damage.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: eldaec on June 26, 2009, 04:22:11 PM
The biggest problems with all cool-down and mmog mana based restrictions are...

1) They give you 'free' resources, because your first cast is paid for with a cool down and mana recharge from before the battle.

2) They encourage you to use the big and impressive moves first, in the hope that they'll recharge.

3) battles get less interesting the longer they run for.

4) standing around doing nothing between fights is rewarded (to recharge)

5) battles are over faster (as they start with finishing moves, rather than build up to them)



MtG had all of this right.

Mana builds from zero at the start of combat.

Mana available per turn grows as the battle develops.

Some effects are one shot per battle, some are repeatable, some benefit from delaying use until more resources are available.


This means you have to balance building resources and using resources, you can't spam your most expensive spell first, and one shotting doesn't happen.

Running everything off of rage would be a big step forward. Rage is a much less retarded mechanic than either mana or cooldown.




Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Famine on June 26, 2009, 06:29:03 PM
I guess type 1 is being ignored from this example hehe :)

Always hated ending so quickly due to a series of combos being executed. This is very similar to some games today if you were to break down real time combat into turned based combat with certain systems. You're still balancing your resources but you don't start out with 0 mana or energy (stamina too). Pop off your combos, burn the target and go on your merry way waiting for all your good cooldowns to wear off for the next victim.

Just like MTG the skill was in the management of resources but also in the build of your deck (character) along with the execution (building combos with your spells/abilities). Then the interwebs came along making things a bit easier for casual players who only needed information to learn.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 26, 2009, 10:59:40 PM
In general response to eldaec's excellent summary, I have to go back to LotRO and specifically the runekeeper.  I'm playing a RK right now and it's by far the most engaging DPS-archetype I have played.  I'm not able to lead off with my big attacks precisely because it uses a variant of WoW's Rage, as eldaec used for example.  I played a Warrior in WoW also and I got into it pretty well, building up for big attacks.  The LotRO Runekeeper is basically the same thing only implemented as a cloth-wearing caster.  Which I often felt like as a warrior in WoW anyway. :why_so_serious:

I'll go ahead and dork out by telling you how this works (bear with me if you all know this) and my current mainstay casting order at lv32.  The RK has Attunement which can be either Battle or Healing; the way it is represented is you have X amount of attunement in either direction from Neutral.

Battle {----------O----------} Healing

Casting a Battle spell moves you to the left, a Healing spell moves you to the right.  Values are from 1-9 in either direction.  So, like Rage enough for this discussion.

I sometimes lead off with a spell that increases the target's susceptibility to ice which Attunes to Neutral (actually I can change this to fire or lightning but that is not in scope).  As ice, it works a lot like the example Sheepherder used, I think, but the percentage is a lot lower.  Next I use a quick-induction (induction is what you call a casting timer on the front end, yes?) ice spell which Attunes 1 Battle, and sometimes this crits.  The only reason I am able to cast this without any Battle Attunement is because I have a trait equipped to do so.  It always reduces run speed by 60% unless resisted ("60% of the time, it works every time").  Then I cast a long-induction DoT (another +1 Battle) since the target is probably moving very slowly toward me (assuming melee here).  It takes three or four seconds to fire after I hit the button.  It does some damage up front and applies a DoT.  At this point I have two Battle attunement, and so I only have to fire one instant lightning spell to get three Battle and then become able to cast my mid damage DDs.

I actually have two instant-cast lightning spells with similar damage ranges, and one of them has practically no cooldown.  The one with a negligible cooldown just recently had its damage reduced a bit, which I think was a good call because there wasn't much reason to use the other one.  I have three mid damage DD: one each of fire, ice and lightning.  Fire and ice have inductions and short cooldowns, while the lightning has no induction and a longish cooldown.  This gives me something to consider in any situation: how much time before the mob closes on me and can I get off one or both induction spells?  In heavy melee situations I rely on my lightning spells because induction is interruptible while cooldowns are not, but I usually do fire-ice-lightning.  In any case, I would have six Battle Attunement after this.  Time for something meatier!

This still suffers a bit because there is an optimal order and I get stuck doing that a lot instead of thinking about things.  I can only queue up one skill while another is inducting or casting, so I spend a lot of time looking at the hotbar instead of the action in order to get spells of as quickly as possible.  Then again, if a battle takes longer than my usual sequence of ice DD, fire DoT, fire, ice, lightning, bigger lightning, then I have to start thinking about things because of cooldowns!  I have a mid-length inducting ice skill, or both of the small lightning skills are probably up and I can get two more Attunement.

What does this have to do with precasting?  Not much, directly.  I kinda think it shows that you can mix spellcast types (and Rage) and end up with a workable and versatile system, and maybe you can work precasting into it as well.  Possibly precasting carries a penalty (longer cooldown or whatever) or perhaps you just let the bonus factor into combat.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 27, 2009, 12:21:17 AM
Precast would be significantly less unbalanced in a strictly PvE game, but I honestly don't think a MMO would survive without some token PvP, make of that what you like.

Quote
Seems to me that there's a problem in #3 where the Frozen status is not being removed.  No?  Even in a case where Ice Lance lands first (latency or keypress or whatever) it seems like the server is not removing the Frozen status properly.

No, actually, the frozen status will be removed correctly... twice... (near) simultaneously. :awesome_for_real:

The two spells fire at the exact same time at the client.  Is it a surprise that they probably end up in the same outgoing packet?  From then on it's just a matter of B beginning resolution before A completes its write to memory, where A and B are the two spells being resolved, which is which doesn't even really matter, and it's entirely possible that both spells will be resolved in complete lockstep.  Trying to program out every little wrinkle due to latency or multi-CPU processing is flat-out impossible, the shatter combo is one of dozens of silly little things that happen that really has no fix short of delaying all spells/abilities that go through the server, which would be bad.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 27, 2009, 06:15:45 AM
Precast would be significantly less unbalanced in a strictly PvE game, but I honestly don't think a MMO would survive without some token PvP, make of that what you like.

I agree with this, more or less, due to the LCD factor.

Trying to program out every little wrinkle due to latency or multi-CPU processing is flat-out impossible,

I disagree with this.  I am very sure it could be done.  Either the code would need to be rewritten to handle it better, or the design changed so conditions that the code could not handle do not occur.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Tarami on June 27, 2009, 08:18:10 AM
Sheepherder, I'm just curious, do you have any proof that the WoW server is asyncronous? I don't mean multi-threaded; it is, pretty much every networking application is multi-threaded or it wouldn't work. You're talking about the server being asyncronous, which is quite different.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: ezrast on June 27, 2009, 02:43:04 PM
Well occasionally you hear about even weirder spell interactions (http://criticalqq.wordpress.com/2009/02/23/awesome-things-and-things/) that can't be explained by the missile-travel-time thing. Though, I've never seen anything like that happen myself, and I've done a fair amount of pvp on my mage.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 29, 2009, 02:39:55 AM
Sheepherder, I'm just curious, do you have any proof that the WoW server is asyncronous? I don't mean multi-threaded; it is, pretty much every networking application is multi-threaded or it wouldn't work. You're talking about the server being asyncronous, which is quite different.

I have no clue what the fuck you mean by asynchronous.  Here's some code though:

Code:
var x : int := 1

process threads (y:int)
    loop
        drawline(x, (y * 15), x, ((y * 15) - 10), y)
        exit when x >= maxx
    end loop
end threads

for t : 1..16
    fork threads(t)
end for

loop
    x := x + 1
end loop


Runs in Turing 4.1.1.  It's supposed to create only vertical lines across the screen.  It doesn't.  It creates sloped lines as well.  If you can explain how it manages to have two separate values for the same variable (x) on the same line of code (5) the mysteries of how threaded processes on a server manage to not realize that Is_Frozen = true is now Is_Frozen = false will become a lot more manageable without having to ascribe unique and magical properties to the hardware environment.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Tarami on June 29, 2009, 07:49:56 AM
It proves my point, really. A large number of threads will create an incomprehensible mess to maintain. Asyncronous means the threads don't synchronize against eachother, i.e. for the lifespan of the thread it doesn't care what happens outside its context. Asyncronous is great for some things, like distributing large batches of independent work to run on multiple processors or kernels, it's not so great for applications where the threads share working memory. You just fire it off and it re-joins your main thread when it's finished. In all other cases, you need memory locks (synchronization) to ensure no other thread is tampering with the memory you're using while you're using it (as in your Turing example, above.) Context swaps (when changing thread) and memory locks have overhead, so you want to keep both to a minimum.

I can recommend these two articles. These cover Windows, but they describe concepts that are universal to all x86 environments. I dare guessing the WoW server does run on x86 hardware.

http://msdn.microsoft.com/sv-se/magazine/cc163726(en-us).aspx
http://msdn.microsoft.com/en-us/magazine/cc163715.aspx

To make my point - from the articles above:

Quote
So, on a machine with four CPUs, there really shouldn't be a need for more than four threads. Why? Because when more than four threads exist, the operating system schedules the threads to the CPUs in a round-robin fashion every few milliseconds. This context switching takes time and is more pure overhead. If the number of runnable threads is equal to or less than the number of CPUs then the operating system just runs the threads and no context-switching occurs; performance is at its best.
(The moral of that story is that threads in excess of the number of available kernels are bad.)

I think two things were considered when designing the WoW server architecture; robust and simple, due to the frequency of software updates it will get. A thousand threads means problems, lots of them. Not on the magnitude of "this spell might go before that spell", but "this thread is locking the entire server" and "that thread is going to crash and burn when it realizes that other thread has modified some memory."

There's somewhat of a saying when it comes to multi-threading; "If you think it's easy, you're not doing it correctly."


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Zetor on June 29, 2009, 08:01:01 AM
Well occasionally you hear about even weirder spell interactions (http://criticalqq.wordpress.com/2009/02/23/awesome-things-and-things/) that can't be explained by the missile-travel-time thing. Though, I've never seen anything like that happen myself, and I've done a fair amount of pvp on my mage.
I've seen that happen a lot, it's very apparent when you play a warrior with bad ping. As I understand it, what happens is (let's assume messages take 500ms to travel between player A and the server, while B has zero lag -- yeah, idealized situation, but single- or low-double-digit ping isn't all that rare)

- B begins to cast a 1.5 second crowd-control spell; A is notified of this 0.5 seconds after the spell has already started casting.
- A hits his interrupt, which, assuming human reaction time and perhaps waiting for a cooldown, will be sent to the server when the spell is at 1.2/1.5s.
- After 500 ms, the message arrives to the server (this is 0.2 seconds after the spell has already been cast).

In games with no lag compensation, the interrupt would never happen (A would be polymorphed before being able to use it), and A would be boned in such situations. This also means uselessness in pvp unless you have super-good ping; this issue is alleviated in pve by slower reactions and ability queues). WOW has some lag compensation, though, so when evaluating commands sent byl A, it tries to apply a certain 'grace period'. Of course it can't undo things that have already happened, so it takes a compromise and applies the interrupt AND has the spell go off. I've personally witnessed things like:
- me and another warrior charging each other at the same time (you could only charge if you weren't in combat, and charging put you in combat)
- me interrupting a spell that went off, but still ended up silencing the enemy because my interrupt was 'successful'
- a healing spell going off on a target (it used the mana, the cooldown, and displayed the UI effect), but the target still died to damage that was taken during the 'lag window'
- etc etc...

And yes, if BOTH parties are lagged, things can get comical and/or annoying. :p


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on June 29, 2009, 10:31:26 AM
Quote from: Tarami
In all other cases, you need memory locks (synchronization) to ensure no other thread is tampering with the memory you're using while you're using it (as in your Turing example, above.) Context swaps (when changing thread) and memory locks have overhead, so you want to keep both to a minimum.

Urf, brain hurts now. :ye_gods:  But fixing frozen/shatter would require that the variable controlling the frozen state be changed before the second thread accesses it, which means either the first thread runs to completion before the unlock or it preemptively writes (global) frozen to false and reproduces it locally before yielding to other threads.  However, if the locks only persist (roughly) for the length of the read/write functions and it doesn't preemptively change the global state in accordance with what it would otherwise eventually attempt to do you have a situation where if a second thread gains focus it will read in the same frozen state.

Yeah, I'm probably using global wrong.  Sue me or find a better word for "higher level state than this."

WOW has some lag compensation, though, so when evaluating commands sent byl A, it tries to apply a certain 'grace period'. Of course it can't undo things that have already happened, so it takes a compromise and applies the interrupt AND has the spell go off...

This isn't necessarily lag compensation, per my argument with Tarami about threading.  It's entirely possible that it's merely an artifact of several threads updating without the associated state variables also updating fast enough to stop freakishness.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Ingmar on June 29, 2009, 02:43:23 PM
I think you're making it more complicated than it needs to be. I am pretty sure that the server calculates the damage an attack does when the cast finishes, not when the actual spell projectile graphic lands; you could test this by casting a frostbolt and then popping a trinket while it is in the air or whatever. Or spell reflect, I am pretty sure I've never been able to spell reflect a spell once it is already flying towards me, I have to get the reflect up before the cast time finishes.

For whatever reason - very possibly because it looks better, given that being frozen has a graphic associated with it - the frozen effect isn't removed until the projectile lands. That's why you can toss an instant once the frostbolt is in the air, because the frostbolt's damage has already been calculated as if the target was frozen. I don't think there's any latency issues involved with it, its just a quirk of how they deal with spells with travel times.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on June 29, 2009, 02:57:48 PM
Oh, my head. :awesome_for_real:


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Lantyssa on June 30, 2009, 01:35:39 PM
For whatever reason - very possibly because it looks better, given that being frozen has a graphic associated with it - the frozen effect isn't removed until the projectile lands. That's why you can toss an instant once the frostbolt is in the air, because the frostbolt's damage has already been calculated as if the target was frozen. I don't think there's any latency issues involved with it, its just a quirk of how they deal with spells with travel times.
That makes more sense.  The alternative makes me wonder how they code it.  The only way I could see a spell that does damage and adds/removes a proc but can have additional damage happen between the original damage and proc is if the proc is itself forked instead of handled by the existing thread.  Doing that makes little sense to me.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Tarami on June 30, 2009, 05:52:43 PM
I agree, as I also said earlier in the thread. The reason I've been talking about threading is to explain just how god awful complicated it is compared to the alternative! :grin:

Frankly, my point is this:
Extensive threading has no functional, simplicity nor performance advantages. It spawns behaviour that's terribly hard to predict and maintain. Race conditions are bugs. Really bad ones - most of the time they'll eventually result in thread or process crashes. If there are any in the WoW server, some lead engineer at Blizzard is not getting a lot of sleep these days. :wink:


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on July 01, 2009, 04:37:05 AM
I think you're making it more complicated than it needs to be. I am pretty sure that the server calculates the damage an attack does when the cast finishes, not when the actual spell projectile graphic lands; you could test this by casting a frostbolt and then popping a trinket while it is in the air or whatever. Or spell reflect, I am pretty sure I've never been able to spell reflect a spell once it is already flying towards me, I have to get the reflect up before the cast time finishes.

For whatever reason - very possibly because it looks better, given that being frozen has a graphic associated with it - the frozen effect isn't removed until the projectile lands. That's why you can toss an instant once the frostbolt is in the air, because the frostbolt's damage has already been calculated as if the target was frozen. I don't think there's any latency issues involved with it, its just a quirk of how they deal with spells with travel times.

1. This doesn't preclude a race condition.  Remember, the instant + cast leaves the caster at the same time, which is likely when damage is calculated.
2. You don't need network latency to have a race condition.
3. The various numerical effects of a "frozen" proc and the visual effects can be disassociated from one another easily enough.

Assuming there is nothing inherently wrong with the way Blizzard handles things, it would be trivially easy to make a frozen buff that only allows one critical strike, the easiest way to my knowledge is being to replace the frozen effect on a spell target taking enough damage to break the effect (effectively all casts) with one that doesn't grant the crit buff as the cast is launched - because the damage will almost invariably be calculated as the cast is launched, or add a flag to the frozen effect to toggle whether a spell is in flight which will prohibit further crit bonii.  Both of these would, however, assume that the outgoing spell casts be handled sequentially and the modification of the frozen debuff as the cast is launched take precedent over another cast.  As I was saying, the race condition doesn't require asynchrnous computing or even overuse of threading, just a bizzare precedence for execution.

However something is broken, so either Blizzard has been studiously ignoring this since (before?) they launched TBC or it would indeed be very hard to fix.  And unlike the vast majority of the people who know of this I don't ascribe it to latency or travel time, because those things do not matter at all to a server.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on July 01, 2009, 10:48:59 AM
I'm going with "studiously ignoring" coupled with "hard to fix" because, in my own experience, you have to ask yourself if the reward you get for fixing a problem is actually worth all the effort to fix it.  But then I don't have end-users to worry about very much.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Ingmar on July 01, 2009, 12:26:36 PM
It goes beyond studiously ignoring, I've seen blue posts talking about ways to get 'shatter combos' to work more often in PVE (like on boss fights) to make frost more interactive to play as a PVE spec. I think they like that it works this way, it may be by design, or maybe just an unexpected interaction that they decided they like.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Yegolev on July 01, 2009, 12:53:17 PM
Accidental interactivity?  Now we are heading towards the "define exploit" conversation.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Ingmar on July 01, 2009, 03:42:16 PM
Accidental interactivity?  Now we are heading towards the "define exploit" conversation.

Naw, not really. A Google search for "ghostcrawler shatter combo" should provide enough evidence that they want it to work the way it does right now, if the fact that they've left it working this way since they added ice lance lo these many years ago wasn't enough.


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Tarami on July 01, 2009, 04:33:55 PM
It has been an awesome discussion then ;D


Title: Re: Cast time, Cooldown, Charge up, and Reload
Post by: Sheepherder on July 03, 2009, 04:47:05 PM
Naw, not really. A Google search for "ghostcrawler shatter combo" should provide enough evidence that they want it to work the way it does right now, if the fact that they've left it working this way since they added ice lance lo these many years ago wasn't enough.

The thing I guess he was referring to was Fingers of Frost (http://www.wowhead.com/?spell=44545), a talent which states that it makes your next two hits treat the target as if it were frozen (and applies even if the target it immune to slow/snare effects, allowing big shatter crits on bosses) the thing is, it can be exploited to gain three crits. :why_so_serious: