The Queue: Waterfalls
by Adam Holisky 
Jun 8th 2009 at 2:00PM
(In my Casey Kasem voice) As for today's reading music, take a listen to the 1990's classic by TLC, Don't Go Chasin' Waterfalls. They totally turn into water elementals too, around 3:40 in the video.
Outdps asked...
"Is the gold cap per character or per account? Is there a gold cap for guild banks?" Bonus question: "What should the gold cap be?"
The limit is 214,748g 36s 48c. That number is magical, in that it's the maximum value of a signed 32-bit integer (which are used for just about everything in computers). While the limit was first discovered for characters back in January of last year, it likely is the same for guild banks, however I have no way of verifying it.
In my humbled opinion, Blizzard should recode things (hopefully the process wouldn't be too painful) and set the limit as an octaword. Making the gold limit 17,014,118,346,046,923,173,168,730,371,588,410 57s 28c. That's 17 decillion gold.
Hendrata asked...
"Is there a reason behind hit rating and hit cap mechanism? It feels unnecessary. Why not make raid bosses only +2 in levels?"
The hit cap, the hit mechanics, and the way attack tables work effectively make it so you have to advance in levels in order to kill more difficult mobs in order to obtain greater rewards. Think if as a level 1 you could successfully do 15 damage to a level 80 every time you hit the level 80 - you'd kill the 80 relatively quickly. While this does make some sense from a RP sense in that everyone can kill everyone with a simple knife to the back, it also doesn't lend itself to a playing environment founded in rules and predictable consequences.
Each "boss" level mob is 3 levels above the level cap. That means that Yoggy is a level 83 mob for purposes of attack calculations. The additional three levels can be thought of as a function of the attack (and hit) mechanics: you need to get better gear in order to kill higher level mobs that give you better rewards, and the best way to do that is through necessitating certain statistics on those pieces of better gear, of which hit is of prime importance. Hence you can look at the three levels as a function of hit, rather than hit as a function of the given mob's level (although a case could be made for this).
It's a good philosophical game design question, and one that I'd love to talk to Ghostcrawler about sometime. I imagine Blizzard has explored a lot of different options and selected hit as the best one. Knowing what some of those other options are would lend a lot of depth to the overall discussion.
Racer corrected...
"What is an 'oomkin'? Typo ftw!"
An Oomkin is a Moonkin Druid. He's an Oomkin because he's Out Of Mana a lot. It's an old school reference, although I thought more people would get it...
Aeire tweeted me last night...
"How come Varian over in Stormwind Keep doesn't have a custom voice?"
There's probably a few reasons. First, there's probably no real compelling reason to yet. Varian in Stormwind isn't a very active character. Only a few quests lead to him, and while he's really active in the battle for the Undercity, it doesn't take place in Stormwind. So no reason to add custom voices there.
I'm sure the WoW devs have thought about adding in custom voices for all the NPCs, but I'm strongly against such an idea and I'm sure there are a few people at Blizzard who are against it too. Including all those voices will add several gigabytes to an already large game.
But with that said... hopefully some of these key characters like Varian can be voiced in the future.
Have questions about the World of Warcraft? The WoW Insider crew is here with The Queue, our daily Q&A column! Leave your questions in the comments and we'll do our best to answer 'em!Filed under: The Queue
Reader Comments (Page 1 of 6)
jfofla Jun 8th 2009 2:11PM
Don't worry Adam, the old schoolers know what an Oomkin is.
vocenoctum Jun 8th 2009 3:54PM
OOMkin
Boomkin
Panzerkin...
all are amusing.
(Huntard, Locktard, Knightard, also amusing, though maybe not for the guy refered to.)
Sean Jun 8th 2009 8:16PM
Death Knoob. (Credit to BBB for that one)
pclar002 Jun 8th 2009 8:58PM
Retnoob, when only night-elf hunters outnumbered paladins.
nonexistentnick Jun 8th 2009 9:13PM
you forgot Mookin! (Tauren version)
best nickname = Failadin, imo
Leigh Jun 9th 2009 4:05AM
The Doomkin! :D
Mindreaver Jun 8th 2009 2:11PM
How many times is Adam going to answer the gold cap question? It seems like it gets answered every week.
And they'll never change it. 32-bit architectures are definitely still way too common, and certainly not worth the extra work of coding around it. Besides, who need more gold then that, on one character, at one time. Just create a second character and you've doubled the gold cap.
outdps Jun 8th 2009 2:23PM
You'll notice that he didn't answer my question. I asked if it was per account or per character.
Dart Jun 8th 2009 2:32PM
It is per character.
Mindreaver Jun 8th 2009 2:37PM
In MY defense. How somebody could not know that it is per character is crazy...
Why it matters to you, that's even crazier. Send me some gold if you are so worried about it.
Josin Jun 8th 2009 2:38PM
More importantly, is there a chance he'll answer the question that was asked? The question wasn't "What is the gold cap?" it was "Is the gold cap per character or per account?"
Sure, there was a follow-up additional question about the guild banks, but let's answer the first question first, shall we?
greenunicorns Jun 8th 2009 2:40PM
Wow that's completely wrong. The datatype they chose for the gold count has nothing to do with the architecture of the computer.
You have your database and you have your programming language. Both support "long" data types.
The fact that they made the data type "signed" is ridiculous, as you'll never have negative money in the game.
Though they may have done a 16-bit unsigned data type, but I would bet they just lazily chose to code "int playergold = x;" setting the stage for 16 unused bits and lame gold cap.
outdps Jun 8th 2009 2:51PM
@dart, thanks.
@mindreaver, I'm not crazy, I just couldn't find that detail in any of the news pieces I read about it. I read a fair few before asking.
Yeng Jun 8th 2009 3:12PM
Raising it would be a lot of wasted allocated space when in most cases its going to be nowhere near that cap.
Mindreaver Jun 8th 2009 3:59PM
I'm not completely wrong. Might have been a bit biased about windows boxes and performance, because I don't know how macs deal with 64-bit and above native types. But sorry, clients handle 32 int, natively, better then they do 64 bits. Even most languages do not support long=64 bit. Your compiler most likely does so CRAZY crap behind the scenes for languages to support it.
And who cares about database structures. They control that. They don't control the client environments. Thats the limiter.
Not the mention that anyone who can actually made an enterprise application knows that using "long" when "int" gets the job done, is dangerous. The compiler will frequently implicitly cast it if somebody accidentally passes an int, or does a compare. That can be VERY embarrassing if your function takes a long, and you display an int... Imagine if you had 2^63-1 gold, and it showed -2^31...
Mykeys Jun 8th 2009 4:06PM
@greenunicorn
Here is a good reason as to why the integer was signed.
Simple computes, being the easiest way to compute remaining Gold on a player, would be how I would code a program.(Keep in mind, I am not a game programmer just a simple mainframer)
So, logically my code would think in terms of this- I have 90 Gold and attempt to buy something off of the AH for 100 Gold. With my integers all signed the equation would look like this: 90 - 100 = -10 so my next line would be a check to make sure that the remaining Gold was not a negative(-) number. In this case that check would fail, and I would not allow the purchase.
If my integers were not signed it would turn into this: 90 - 100 = 10 and without doing some crazy check like the following the system would allow the purchase.
IF X < Y
DO-NOT-ALLOW-PURCHASE
END-IF
This not only looks sloppy but I would consider it horrible programming if I came across this in my work.
And again, keep in mind, I am a simple mainframe programmer and do nothing nearly as complex as WoW.
Warlock Jun 8th 2009 5:07PM
As a programmer, the comment about "just changing it" threw up an instant /facepalm (especially the jibberish regarding "octaword" - this is not "let's completely waste resources" hour, not even considering that it's non-standard - and is it even available in C++?). Seriously, just changing something as significant as the variable type of *gold*, the currency used for everything in the game? That's likely a change to almost every class file (read: hundreds if not thousands at this point I'm sure), let alone a massive database restructuring.
No, they do not need to change this. It's already a long, that should be enough. Seriously, if you have that much gold you need to.. I don't know.. buy things once and awhile. That, and you either have too much time on your hands and/or you are a gold farmer.
Also, nice job Mykeys in explaining the signed thing. There really isn't a reason to go unsigned here, it just causes more headaches.
One interesting thing to at least take from this, I hadn't seen the cap written out before. Interesting to see how they handle silver and copper programmatically ;) Not a bad solution - it's efficient.
Spazmoose Jun 8th 2009 5:59PM
@Murkeys
Ideally, you should program the function so that there is no crazy logic behind the maths, and that the result would be the same regardless of whether the variable is signed or unsigned.
This is why I personally would write the method like this (note the syntax is a bit different, as I work w/ C# day-to-day):
x = players gold
y = cost of the item
if (x > y)
x = x - y;
else
DoNotAllowTransaction();
Basically, the idea is that you check to see if the calculation can be performed before actually performing the calculation, whereas in your method, you perform the calculation and then check to see if the result is valid, which would indeed cause a problem depending on if the integer is signed or unsigned.
The octaword would probably be an extremly bad idea as far as datatypes are concerned, because: #1octaword is C (language) only, #2 octaword is non-standard, #3 octaword is compiler specific. If it truely became necessary to use a datatype that would hold larger values (while still being a 32-bit signed datatype), they could use the decimal datatype, which would allow for values up to 7922816251426433759354395g 03s 34c, which would most likely be much more than anyone would need for this game (where most people cannot even save enough to buy the 16000g Tundra Mammoth.
Spazmoose Jun 8th 2009 6:09PM
Just have to agree w/ Warlock here:
"No, they do not need to change this. It's already a long, that should be enough. Seriously, if you have that much gold you need to.. I don't know.. buy things once and awhile. That, and you either have too much time on your hands and/or you are a gold farmer."
I would just like to add that perhaps you should leave the basement as well...be careful though...that sunlight might hurt your eyes at first :-)
thevitruvianman Jun 8th 2009 7:49PM
They really don't need to change the gold cap..... 99.999999% of players will never approach that cap, and even if they do, an easy workaround is to just send some of it to an alt.
Just be grateful this isn't guild wars, where the maximum amount of gold carryable by a character is 100 plat (1 plat is 1000g), a value which is pretty easy to achieve. Since many rare items in GW sell for over 100 plat, most people use valuable items called globs of ectoplasm ('ectos') as an alternative currency, and it's common to see things in that game selling for '100k + 30 ectos'.