[vworld-tech] Some resources for MMOG server development

[ceo]

Firstly, let me just make clear that I wasn't disparaging Brian's 
article in any way; I was just critically appraising it in the context 
of the set of resources that Bruce suggested adding it to.

Any negative tones from my post should be read with an implied 
"(...compared to the other resources)". E.g. side-by-side with the SEDA 
papers. The page I'm maintaining is aimed at a particular audience, and 
I want to be fairly tightly focussed so you don't have to wade through 
too many links (i.e. sites where you are offered thousands of links, 
with groups of ten that are almost identical, take too much effort to 
find the ones containing what you want; we're busy people!)

Brian Hook wrote:
>>Having finally got a chance to read through this, I'm not sure what
>>to make of it; it comes across as being a sort of "multplayer
>>programming 101: the basic introduction". 
> 
> That is its goal.
> 

I was evaluating it in the light of Bruce's suggestion, and not having 
read BoH articles before, I wasn't sure whether I was interpreting it 
correctly :). Thanks for clarifying :).

> 
>>Most of the interesting
>>stuff is glossed over; the advice is good (e.g. "Just don't bother
>>using TCP, TCP + UDP hybrid, etc - use someone else's like ENet"),
>>but with almost no explanation of why.
> 
> 
> It is practically book sized at this point -- it's over 40 pages long 
> in its current "glossed over" format.
> 

This confused me a bit. It's only 8000 words (according to OO.org), 
which is about 20 pages in 12pt text (taking into account slight 
expansion due to formatting of section titles etc). Is there a "part 2" 
I'm missing? I went back and had another look for any links to extra 
parts, but couldn't find any (perhaps I'm just being incompetent)?

> 
>>I'm not sure, but I suspect if I read it without knowing much about
>>net programming, I wouldn't know whether to trust the author
>>because there's too little reasoning. 
> 
> 
> Well, a lot of the stuff isn't about reasoning, it just "is".  Yes, 
> there is some hand waving about the UDP vs. TCP stuff, but I don't 
> think I was that scant on the other, uh, 9500 words or so =)
> 

This is the implicit attitude that would make me disinclined to trust 
the article (if I didn't know anything about the subject; nb I'm playing 
Devil's Advocate here - I'm not trying to imply that anything you say 
*is* wrong, just that if I were ignorant I would have trouble *trusting* 
it...).

There are few absolute statements you can make in this field, so when 
you say "it just -is-", my immediate suspicion is that your experience 
and/or understanding is limited (again, playing D's A). UDP/TCP is too 
easy an example of this :) so I'll ignore it.

Some of your absolute statements on P2P are "wrong" in the sense that I 
can instantaneously think of counter-examples, all directly relevant to 
games-dev. e.g. in many ways, P2P is easier to secure than C-S (though 
this is a hot topic still widely debated, with many arguments involved).

The problem is that you don't really explain why P2P is harder to secure 
- you just wave a hand and state that it is. Without explanation, you 
don't give a reader much chance to verify your statement - I could write 
an entire book showing why P2P is easier to secure, and yet it would say 
nothing about your statement - because no-one would know what root cause 
you'd been referring to, and hence whether or not I'd actually addressed 
that.

> And I don't expect anyone to trust my paper just because I'm ex-id 
> (and, I might mention, I don't mention any relationship to id at all 
> at the site or in that paper, to my knowledge).

Sure; however, many readers will know who you are, and will trust you 
because of it. It's a consequence of fame that I know I'd be annoyed by 
(if I were a famous person :)) - that people would tend towards less 
sceptisism towards me, and would probably be more annoyed with me if I 
turned out (through accident) to be wrong on something (simply because 
their expectations were too high :( ).

I pointed it out because, unfortunately, it's relevant - unless you went 
to the extreme of using a pseudonym. I'd certainly not suggest that 
(rather extreme, isn't it?) although there are people for whom this is a 
motivation for doing just that.

> 
> If there's something you feel needs clarification, let me know.  It's 
> an overview that describes _what_ multiplayer network programming is 
> like, but no, I don't get into a series of rationales for every single 
> decision, but even so, the only real controversial one is the TCP vs. 
> UDP one.
> 

Without increasing the length, or changing the style to be much more 
concise (and hence more effort to read), I doubt you could further 
clarify anything. Personally, I don't think there is *anything* 
inherently "wrong" with the article; at the level it's pitched, the 
inaccuracies I noticed are not important. I was, however, evaluating it 
for inclusion in a set of resources that were mostly pitched as being of 
much more immediate practical use - more like "developer guide" 
material, whereas your article seems more "introduction" material.

> Just explain what portions aren't clear or are lacking proper 
> reasoning and I'll attempt to address them.  AFAIK, the only major 
> complaints I've received are that I gloss over TCP vs. UDP and that I 
> don't mention server-side optimizations such as not broadcasting 
> entity status for entities out of visual range.  But I felt the latter 
> was clearly beyond the scope of the paper, which is designed more to 
> deal with protocol level issues.

In conclusion, I think there are people who would take it too much as a 
developer-guide, rather than an intro. IMHO, I might suggest that a 
liberal peppering of citations for detailed (i.e. developer-guide level) 
discussion/explanation of each of the topics covered would make it an 
excellent introduction. As it stands, the "interested reader" wanting to 
make their own server still needs to ferret out further resources for 
everything. Your doc has provided little more (only in a practical 
sense!) than a set of phrases and words that they can now put into 
Google; when I got to the end, I kind of expected a couple of links to a 
few more pages, or an extensive set of links to other resources.

Adam