all i can hope for is you dont write a book that just
flashes over things without the in depth detail these
things tend to need. please dont make it a ‘starters
guide’ to network programing!
I’d go with what Kev has listed- sounds great. but start
neat and go hard. it would also be cool to have info on
implementing clustering, load balancing along with
database managing for mmpog servers. love to get your
insite on that jazz 
where do i pre order?
[quote]all i can hope for is you dont write a book that just
flashes over things without the in depth detail
[/quote]
Me too. I assume the reader is already a competent or intermediate or expert java programmer - no way I’m writing 5 chapters on “OOP” and “what is a class” ;).
I also assume they are developing a serious game, or would like to know how to - at least you will probably try to develop one eventually. Goes into details of things like how to design secure servers, which would be left out of any beginner/introductory book.
FYI I’m currently estimating 300-400 pages, and will have a complete NIO-based network game written through the book, probably via “next part of the game” chapters interleaved with the main content chapters, so you can easily skip the game, or concentrate on it, according to whim. Then again, it might turn out very differently so no promises.
PS publishers want precise page counts, but I’m really suspicious of such estimates. I’d much rather say “it’ll be at least 300, and no more than 600” but they want a ten page range :(.
That would be a separate book. Trust me, if I put it all in one book it would be too heavy to lift ;). i.e. somewhere around 1000 pages and too enormous for anyone to be brave enough to read :).
Also have to wait for some patent stuff to run it’s course before I knew what I could and could not include re: MMOG servers.
Words to put a smile on the face of any publisher :).
Haven’t signed the contract yet - still trying to sort out my dead PC and get back to normal with work etc - although expect to imminently. I’m aiming to have the book completed in around 6 months, and in stores 1-2 months later.
well 1000 pages is cool with me- i have one of them
kids pull trollys around here someplace if it saves me
a few years on running around like a headless chicken
i up for reading it ;D
i’ve done a number of books dude- little tip for u:
say the page count is 600- u can always add more of
that needed source code examples we all lover to see.
and screen shots of server console look so cool- with
comments under them saying “see it works”!
main problem i have found over the years is that publishers
tend to panic that the contence of the book maybe wrong
and when u go hardcore its harder to get someone to
check it over and edit it. thats when the fun starts
it would be a top book and im sure it will go down very
well- shit put me down for 2 copys!
but if I only ended up with 350, then that would be 250 pages of source code examples! And if you’re providing a CD anyway…
You forget blah3, that we have seen your posts on here, I think that you reaching 600 pages will be no problems
Endolf
/me waits impatiently
HAHAHAHAHA! CLASSIC…
[quote]Are people more interested perhaps in the impl side (which includes implementing famous standard protos) or in the design side (which is more interesting and exposes various important high-level design issues in your game)?
[/quote]
Both, perhaps break the book into two sections, the first covering architecture and design and the second showing some examples of the tricker coding aspects. Thats just my opinion of course. 
Also, I don’t know if this is covered in your categories, but I am currently working through designs for scalability that include instancing, distributing data(protocols), data integrity, datastore design (#dbs? in mem obj caching?), etc. All of the issues you face when you go from MUD to MMO on the server side, ie out of one box/jvm and into many… There just are not a lot of references for this kind of information, especially as it pertains to games. The people who are working through it (you, Sun, etc.) arent really sharing the details of their solutions, understandably. Perhaps you want to break the trend ;D If you do you are welcome to my $49.99.
Chris
As mentioned above, that’s a separate book in it’s own right. For a start, it needs to cover quite a lot of history to justify why the more unusual things are done later on (otherwise it won’t make sense to anyone except the people who’ve written and maintained 500+ player MUDs before :().
Secondly, most of the advanced stuff (I say advanced not necessarily because it’s difficult - although it often is, very much so - but because it’s specialised and not really used outside a few niche industries) is pretty complex/tricky and takes some serious explaining. Unless you’re already a specialist, in which case you probably don’t need the book :). For reference, the main book on TP systems (transaction processing) weighs in at 3-4 inches - and that’s just one small aspect of MMOG development! Granted, it was written for a specialist audience, and I could extract the most relevant data for games devs into a mere 50 pages, but that’s a taster of what an overarching MMOG book needs to do.
The main problem is that there are very few people who actually know what they’re doing! My opinions on those that do and don’t are either well known or easy to infer from my various articles and postings, but as a rough guide I estimate approx 25% of those making a living working in MMOG’s still don’t really know what they’re doing. And if you include all those who are working on MMOG’s that aren’t yet published, that goes up to more like 50%. And if you include all the wannabe’s, like most of the open-source engines, you probably reach 60% ignorance. Many people have merely tried to jump on the gravy-train, often convincing themselves that their enthusiasm and knowledge of other games will make up for their ignorance. Unfortunately, it usually doesn’t :(.
Last time we evaluated it, we reckoned that about 40%-50% of the companies offering / developing MMOG middleware didn’t really know what they were doing either. Doesn’t mean they weren’t smart people doing good work - it’s just that there were several “solutions looking for a problem” and trying to convince themselves and the world that the problem in question was MMOG’s. Optimistically, all those that are left as serious contenders have now worked out what they’re doing, and have good strategies in place. But I’d still be very wary about picking a middleware provider…It’s not helped by the fact that no-one has a big-name game to point to using their engine :(.
Probably 12 months after this book I’ll go for it.
Then again, from what I heard, Jeff was planning to write a book on this himself - so maybe you should pester him ;). I asked him about it to see if we could collaborate or at least co-ordinate - discuss ideas etc (it seemed we were probably going to be writing quite dissimilar books anyway), but never got a response back.
Some contentious questions:
How would you feel about an entire chapter devoted to re-inventing TCP using UDP? The purpose being to provide a worked example of a TCP replacement where the two features which game devs hate become optional. This would be:
…which could be followed by a chapter on how to make a “better than TCP TCP”. e.g.
What about a chapter on the client aspects of game development that directly affect gameserver development? e.g.
How valuable would it be to build several networked games during the book, rather than just one? The only game I was intending to do was a multiplayer racing game (which conveniently uses a lot of the theory of protocol design etc, whilst being simple to build up iteratively into a full game). But perhaps it’s worth also doing a completely different game, e.g. a peer-to-peer game that uses a DOA (RMI or Herk’s HQ or CORBA or etc) - although in most cases that’s undesirable it tends to be quicker to get your basic game going (because the DOA acts as a partial 3rd party network layer)?
re multiple examples: personally just from an interest point of view it would be good to see examples of how different genre’s of games require different network stratagies. Problem I see is that it might end up with a few examples that are pretty superficial or one that covers the topic in more depth. Ok i just re-read and saw your NB
Would you really be able to cover re-writing tcp in just one chapter? and would the conclusion to the chapter be ‘don’t do it’?
Don’t really know much about the rest though so I can’t comment. Sorry.
DOA? the acronym esacpes me at the moment </silly question alert>
Dan.
edit typo - theres probably more…
Yes; No. Since the status quo is that “if you can do it, you really really want to”, but most people can’t do it, the chapter would be simultaneously by it’s simple existence be implying “don’t do it unless you have to / or have the time to” but also making the act of doing it a lot easier (assuming I get it right!). My hope would be that the publisher would let me start a sourceforge project for the code in that chapter, and then it would be an open source project that would gradually get the bugs fixed etc. But the book would always have this nice, detailed, clear full explanation of how it works and why (with errata published on the SF webpage).
DOA == Distributed Object Architecture
[/quote]
I have a feeling the chapter would probably end up acting being a really good example of why you don’t want to rewrite TCP
Having just been maintaining a TCP stack for a bespoke platform I’m suddenly keenly aware of how complex the actual behaviour is and how much of the solution is emergent and not engineered
Kev
[quote]I have a feeling the chapter would probably end up acting being a really good example of why you don’t want to rewrite TCP
[/quote]
Yes. The dilemma is that reproducing TCP is damned hard to do without introducting subtle, non-deterministic - yet fatal - bugs …but most non-simple multiplayer games need to do it sooner or later.
Recent research confirmed that none of the major free game-protocols have yet been converted to Java, nor is there much likelihood of it happening (and they aren’t that special anyway - their appeal is largely from the fact that they DON’T embellish with lots of extra features).
So, I thought that I could kill two birds with one stone :).
Exactly; I don’t think there’s any way of really explaining why you don’t want to do TCP short of actually showing how difficult it becomes.
NB: despite the aim to reproduce all of TCP in one chapter, I only intend to do so in a manual / user-guide kind of way - i.e. it has to explain problems and their solutions, but can skip a lot of the precise detail simply because once you understand how it all fits together and why, you are able to quite quickly scan the technically more detailed RFC’s and know what you are looking at and looking for.
Hi.
I replyed to your post on the gamdev forums. (Acount: Frank Henry)
I would love to answer the questions you posed in the thread as well but they are kinda unorganized.
Maybe make a list of all questions?
For me the book would be interresting if it not only showed how to design and set up a java game server but also desings for specific games, stuff to watch out for, determining what to send and how to send it etc.
Maybe three example games might do the trick.
Also one board on gamedev you asked in was the mobile game board.
I fear the answers you will get there are very limited since the networking is only slowly gaining momentum.
Thanks
[quote]Also one board on gamedev you asked in was the mobile game board.
I fear the answers you will get there are very limited since the networking is only slowly gaining momentum.
[/quote]
Yeah, not much response from there. However, a friendly contact at Nokia has put me in touch with some useful mobile games devs who’ve had a lot of useful comments, so I’m starting to get the info.
And they did not mention our comp? Tsk tsk tsk. ;D
Nokia is one of the few I would recommend atm since they are one of the few mobile developers that actually have java bluetooth support.
Bluetooth is defiently becomming more interresting for mobiles in the future. One big problem is our jar-size restrictions. 64k (Nokia S40) is not much to work with.
Drop me a line if I can help you out with anything.