Welcome, Guest. Please login or register.
December 11, 2018, 08:04:27 PM

Login with username, password and session length

Search:     Advanced search
Donate! | Shop: Amazon
*
Home Help Search Login Register
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: Cast time, Cooldown, Charge up, and Reload 0 Members and 1 Guest are viewing this topic.
Pages: [1] 2 Go Down Print
Author Topic: Cast time, Cooldown, Charge up, and Reload  (Read 10713 times)
pxib
Terracotta Army
Posts: 4482


on: June 18, 2009, 07:51:29 PM

Over in the SWOTR thread 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?

"Busy day at the Dracula factory and there's only two of us on the assembly line, so I have to make every second count."
IainC
Developers
Posts: 6268

Wargaming.net


WWW
Reply #1 on: June 18, 2009, 08:01:20 PM

DAoC Warlocks.

- And in stranger Iains, even Death may die -

SerialForeigner Photography.
DLRiley
Terracotta Army
Posts: 1982


Reply #2 on: June 18, 2009, 10: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.
Ingmar
Terracotta Army
Posts: 19280

Auto Assault Affectionado


Reply #3 on: June 19, 2009, 04: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.

The Transcendent One: AH... THE ROGUE CONSTRUCT.
Nordom: Sense of closure: imminent.
Sheepherder
Terracotta Army
Posts: 5192


Reply #4 on: June 19, 2009, 11: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.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #5 on: June 20, 2009, 09: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. Ohhhhh, I see.

Why am I homeless?  Why do all you motherfuckers need homes is the real question.
They called it The Prayer, its answer was law
Mommy come back 'cause the water's all gone
Nebu
Terracotta Army
Posts: 17613


Reply #6 on: June 20, 2009, 11: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.

"Always do what is right. It will gratify half of mankind and astound the other."

-  Mark Twain
Sheepherder
Terracotta Army
Posts: 5192


Reply #7 on: June 20, 2009, 11: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. Ohhhhh, 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.
Samprimary
Contributor
Posts: 3850


Reply #8 on: June 23, 2009, 09: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.
Nebu
Terracotta Army
Posts: 17613


Reply #9 on: June 23, 2009, 10: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.

"Always do what is right. It will gratify half of mankind and astound the other."

-  Mark Twain
Glazius
Terracotta Army
Posts: 755


Reply #10 on: June 23, 2009, 11:01:54 AM

Over in the SWOTR thread 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.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #11 on: June 23, 2009, 11: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. Ohhhhh, 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.

Why am I homeless?  Why do all you motherfuckers need homes is the real question.
They called it The Prayer, its answer was law
Mommy come back 'cause the water's all gone
Tarami
Terracotta Army
Posts: 1980


Reply #12 on: June 23, 2009, 03: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.

- I'm giving you this one for free.
- Nothing's free in the waterworld.
DLRiley
Terracotta Army
Posts: 1982


Reply #13 on: June 23, 2009, 04:56:36 PM

Over in the SWOTR thread 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...
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #14 on: June 23, 2009, 05:44:39 PM

In Soviet Russia, situation assesses you!

Why am I homeless?  Why do all you motherfuckers need homes is the real question.
They called it The Prayer, its answer was law
Mommy come back 'cause the water's all gone
Glazius
Terracotta Army
Posts: 755


Reply #15 on: June 23, 2009, 07:35:49 PM

Over in the SWOTR thread 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?"
DLRiley
Terracotta Army
Posts: 1982


Reply #16 on: June 24, 2009, 12:37:47 AM

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.
« Last Edit: June 24, 2009, 12:39:32 AM by DLRiley »
ezrast
Terracotta Army
Posts: 1989


WWW
Reply #17 on: June 24, 2009, 02:40:39 AM

Damn you must think awful slow.
Sheepherder
Terracotta Army
Posts: 5192


Reply #18 on: June 24, 2009, 06: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.
DLRiley
Terracotta Army
Posts: 1982


Reply #19 on: June 25, 2009, 08: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.
NiX
Wiki Admin
Posts: 7770

Locomotive Pandamonium


Reply #20 on: June 25, 2009, 08: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.
Sheepherder
Terracotta Army
Posts: 5192


Reply #21 on: June 26, 2009, 01:37:09 AM

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.
Typhon
Terracotta Army
Posts: 2388


Reply #22 on: June 26, 2009, 07: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.
Famine
Developers
Posts: 61

Funcom


WWW
Reply #23 on: June 26, 2009, 02: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).
« Last Edit: June 26, 2009, 02:26:41 PM by Famine »

Glen 'Famine' Swan
Senior Assistant Community Manager
Funcom Inc.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #24 on: June 26, 2009, 05: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.

Why am I homeless?  Why do all you motherfuckers need homes is the real question.
They called it The Prayer, its answer was law
Mommy come back 'cause the water's all gone
Ingmar
Terracotta Army
Posts: 19280

Auto Assault Affectionado


Reply #25 on: June 26, 2009, 05: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.

The Transcendent One: AH... THE ROGUE CONSTRUCT.
Nordom: Sense of closure: imminent.
Tarami
Terracotta Army
Posts: 1980


Reply #26 on: June 26, 2009, 06: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.

- I'm giving you this one for free.
- Nothing's free in the waterworld.
eldaec
Terracotta Army
Posts: 10638


Reply #27 on: June 26, 2009, 06: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.



"People will not assume that what they read on the internet is trustworthy or that it carries any particular ­assurance or accuracy" - Lord Leveson
"Hyperbole is a cancer" - Lakov Sanite
Famine
Developers
Posts: 61

Funcom


WWW
Reply #28 on: June 26, 2009, 08: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.
« Last Edit: June 26, 2009, 08:43:48 PM by Famine »

Glen 'Famine' Swan
Senior Assistant Community Manager
Funcom Inc.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #29 on: June 27, 2009, 12:59:40 AM

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.

Why am I homeless?  Why do all you motherfuckers need homes is the real question.
They called it The Prayer, its answer was law
Mommy come back 'cause the water's all gone
Sheepherder
Terracotta Army
Posts: 5192


Reply #30 on: June 27, 2009, 02: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.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #31 on: June 27, 2009, 08: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.

Why am I homeless?  Why do all you motherfuckers need homes is the real question.
They called it The Prayer, its answer was law
Mommy come back 'cause the water's all gone
Tarami
Terracotta Army
Posts: 1980


Reply #32 on: June 27, 2009, 10: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.

- I'm giving you this one for free.
- Nothing's free in the waterworld.
ezrast
Terracotta Army
Posts: 1989


WWW
Reply #33 on: June 27, 2009, 04:43:04 PM

Well occasionally you hear about even weirder spell interactions 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.
Sheepherder
Terracotta Army
Posts: 5192


Reply #34 on: June 29, 2009, 04: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.
Pages: [1] 2 Go Up Print 
f13.net  |  f13.net General Forums  |  The Gaming Graveyard  |  Game Design/Development  |  Topic: Cast time, Cooldown, Charge up, and Reload  
Jump to:  

Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC