[DGD] DGD/MP 1.0

[Matt Holmes]

> The scale doesn't matter, if there's a point where your virtual world 
> game has too many players for the available content, then you haven't 
> done enough to address the problem of too many players.  What I would 
> be curious to know is if the limitation imposed by Blizzard is due to 
> game design issues or server limitations.  If it's simply because of 
> server limitations, then Dworkin's argument stands.
>
The scale does matter. I love how all of you assumed I don't know 
anything about large multi-tiered servers. Hint, I write multi-million 
dollar credit card process software for a living. My software runs on 
large clusters that process millions of credit card transactions per 
second. The session concurrency involved is insane, as credit card 
processing is not a one step process. I would dare say our software has 
to be significantly more robust and able to handle faults than any game 
server. We aren't dealing with someones entertainment, we are dealing 
with millions of dollars changing hands every hour.

>> Again, even if a MUD could support that many player sessions, you are 
>> still dealing with only text. Except in the most extreme cases, MUD's 
>> don't process and calculate millions of 3D calculations per game 
>> session. MMO's like WoW do.
>
>
> Two points here. 1. Text processing is one of the slowest things you 
> can do with a computer.  Have you profiled a couple of hundred 
> thousand sscanfs recently?  As a professional game programmer I can 
> assure you that we try our hardest to eliminate it wherever possible.
> 2. What 3d calculations are you talking about?  The server doesn't 
> display anything.
>
You really don't know much about 3D game servers do you? Everything that 
is rendered to you, is first calculated and checked server side. It's a 
security measure. Every time you move, the server first checks that it 
is a valid move. Prediction is used on the client side, but the server 
will snap you back if you're move is invalid. The server loads and 
'renders' (no, it doesn't really draw it, but the 3D data is calculated 
and stored, just like it would be on the client. Normals, 
transformations, etc) every map or tile in the game, so that it knows 
exactly what the area you are in looks like in terms of 3D data. To say 
the server doesn't do a ton of 3D calculations is highly inaccurate and 
leads me to question if you have ever written a 3D game server before, 
MMO or otherwise. This is all calculated and sanity checked server side, 
so Joe Blow Haxxor can't teleport his client around the world. For 
someone claiming to be a professional game developer, I would think this 
would be pretty common knowledge.

>
> Anyone can write that stuff, what's much harder is solving the in-game 
> MP problems like Dragon's Dinner, and I can almost guarantee that WoW 
> and most other MMOs don't solve this at all, so they will always hit a 
> scale limit sooner or later.  How can I be so sure?  Because your 
> wonderful super-programmers with their golden-auras have got producers 
> in charge of them, producers who need to weigh up the cost-benefit 
> between a) going pervasively MP with just one game instance with 
> hundreds of thousands of players on it and solving all the concurrency 
> nightmare issues that will crop up, or b) sticking to the tried and 
> true shards model at a fraction of the time & money development cost.
>
Anyone can write this stuff huh? I like how anyone with a differing 
opinion is a fanboy, nice maturity factor there. Funny, if anyone can 
write this kind of software, why do we turn 95% of the programmers that 
apply to write it at my place of work away? The dragons dinner problem 
is no more difficult to solve than concurrency across a cluster of 
systems. If you think it is, you're fooling yourself and being 
misleading to everyone else. Writing highly concurrent, high uptime, 
clustered software is not a joke, and it's not easy. In fact, I am 
offended you think it is. I emplore you to apply at my place of work if 
you think you can just waltz in and start hacking away on it. Oh, that's 
right though, I am just a fanboy who doesn't know what he's talking 
about, my mistake. You've never dealt with concurrency across a cluster 
have you? You actually think it's less difficult than concurrency across 
a couple of processors that are connected via the north bridge? What 
happens if one of your fiber channel connections goes down, what's your 
backup plan for communicating with the rest of the cluster? What happens 
if a server in the cluster crashes? Do you have a redundant one in 
place? Can any server in the cluster take over the responsabilities of 
another, taking all it's persistent state data and serving it?  The 
concurrency issues are no different then an MP situation, the only 
difference is, in MP, you can pretty much safely assume one of the 
processors isn't going to magically disappear on you. Oh, as a side 
note.. clustered concurrent software is still MP capable software. Each 
server in the cluster tends to be four or more processors. The smallest 
clusters our software runs on consist of multiple dual processor boxes. 
We also run on non-clustered large partition environments such as HP 
SuperDome's.

Point in case, just because your software is SMP aware and capable of 
utilizing the systems CPU's effectively does not mean that you magically 
won't reach a scalability limit. There is still a very real scalability 
wall to be reached, no matter how many processors you throw at the 
problem, no matter how good your software is at using those CPU's.

>> But to compare it to a multi-million dollar software development 
>> effort like the WoW server core is like comparing apples to oranges. 
>
>
>
> http://www.improb.com/airchives/paperair/volume1/v1i3/air-1-3-apples.html
>
>
Nice attempt at defuncting my argument, but it still proves you have 
little to no respect for countering opinions. You immediatley assumed I 
had no idea what I was talking about. At least Dworkin didn't attempt to 
assault my knowledge of the subject. Too bad I have extremely in depth 
knowledge of this kind of software, as I write it every day to pay my bills.