Welcome, Guest. Please login or register.
December 13, 2018, 06:15:26 AM

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 10715 times)
Tarami
Terracotta Army
Posts: 1980


Reply #35 on: June 29, 2009, 09: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."

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


WWW
Reply #36 on: June 29, 2009, 10:01:01 AM

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.
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

Sheepherder
Terracotta Army
Posts: 5192


Reply #37 on: June 29, 2009, 12:31:26 PM

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. ACK!  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.
Ingmar
Terracotta Army
Posts: 19280

Auto Assault Affectionado


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

The Transcendent One: AH... THE ROGUE CONSTRUCT.
Nordom: Sense of closure: imminent.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #39 on: June 29, 2009, 04:57:48 PM

Oh, my head. awesome, for real

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
Lantyssa
Terracotta Army
Posts: 20848


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

Hahahaha!  I'm really good at this!
Tarami
Terracotta Army
Posts: 1980


Reply #41 on: June 30, 2009, 07: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! Oh ho ho ho. Reallllly?

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

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


Reply #42 on: July 01, 2009, 06: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.
« Last Edit: July 01, 2009, 06:43:02 AM by Sheepherder »
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #43 on: July 01, 2009, 12:48:59 PM

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.

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 #44 on: July 01, 2009, 02: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.

The Transcendent One: AH... THE ROGUE CONSTRUCT.
Nordom: Sense of closure: imminent.
Yegolev
Moderator
Posts: 23913

2/10 WOULD NOT INGEST


WWW
Reply #45 on: July 01, 2009, 02:53:17 PM

Accidental interactivity?  Now we are heading towards the "define exploit" conversation.

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 #46 on: July 01, 2009, 05: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.

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


Reply #47 on: July 01, 2009, 06:33:55 PM

It has been an awesome discussion then Grin

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


Reply #48 on: July 03, 2009, 06: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, 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?
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