Developing Java Gameservers

Networking & Multiplayer
#1

As I’ve mentioned a few times before, over the last year I’ve been putting together notes for a book on developing java gameservers.

If I’m to find someone to publish the book, one of the things they need is evidence of what people want from the book, and what kinds of people would buy it (so they can check it fits with the audience they normally aim their books at, and can work out how they are going to market it).

If you’re interested in seeing this book get published (because you’d use it), you can help by answering the poll questions. If you’d be willing to give me some additional information (e.g. demographic data on things like your general experience with java, why you write games, why you’d find such a book useful etc) please contact me on ceo at grexengine.com - just to avoid clogging up the forum with lots of similar posts. None of your personal details will be kept, I just want statistics e.g. “80% of people have less than 2 years commercial java experience” and if I get enough responses I’ll post a summary of the data.

If you have ANY things you’d like to see in the book that are not included above, just post and I’ll add them as options!

Thanks!

#2

I personnaly can’t wait for the book :slight_smile:

As someone who writes games for fun (but who does by books to feed my addiction :)), i’m interested in all but the business side of it :). Especially interested in NIO, partly because my special interest is in networks, and partly because I find blah3’s documentation on NIO brillimerent :). If the rest of the book is as good then it’s one for my shelf asap.

Cheers

Endolf

#3

A classification of game server types could be useful.

I often have the impression that talking about MMOG automatically implies gametypes like adventures, RPG or RTS. Jeffs new stuff again seems to go to that direction.

But there are other aspects like the more dynamic one necessary for the free simulation stuff, imitating systems like DIS or HLA. For games like Warbirds.

#4

[quote]A classification of game server types could be useful.

I often have the impression that talking about MMOG automatically implies gametypes like adventures, RPG or RTS. Jeffs new stuff again seems to go to that direction.
[/quote]
Actually not at all. Unline many oher systems otu there it is NOTa game engine but merely an execution environment. It is very purpsoefully game design neutral.

Any simulation that needs the proeprties of persistance, scalability and reliability can benefit from the logic layer. Even a P2P game that just needs to do organized communciation can benefit by going thorugh the comm
layer.

Its just the easiest and msot complete examples to explain are typically the RPGs :wink:

#5

For those that voted for it, what do you understand by “Game Server Architectures”?

#6

For me, the next step up from object design. A discussion of the different places that the module boundaries could be drawn.

E.g.
a) Whats a good way to split the code out?
b) Single thread vs Threading Pooling vs Thread per client.
c) Handling input (Polling, Event Based)
d) Client <-> Server synchronisation considering
e) Maybe even the dreaded TCP/UDP/Mixture/Other protocol debate

Maybe some case studies of certain types of games and there respective suitable architectures (Tradition RPG, Flight based, stats based).

Kev

#7

Hi
I read it the same was as kev pretty much

HTH

Endolf

#8

[quote]Hi
I read it the same was as kev pretty much
[/quote]
Great; that’s the same definition I’d been working to :). But I realised that there are other quite different interpretations - like focussing exclusively on low-level aspects, or focussing exclusively on particular genres, e.g.:

“For an MMORPG, you do this. For an RTS, you do that. For an FPS, you do something else”.

…which is almost suicidal for an author, given how meaningless such boundaries are in practical, technical terms.

#9

Just to be clear: in the context of a chapter which has already concentrated on the other bits Kev outlined, a discussion of how those apply to particular genres works well: they become illustrative examples, instead of proscriptive rules (which is what I was referring to in my previous post).

#10

As someone who’s new to game development in general, I would say that every one of the items in the poll would seem important to treat in a Java game development book. The game architecture stuff I’ve had to mostly figure out on my own by looking (from the player’s perspective) at how other games work and then trying to deduce how that would work. Networking protocol issues are important too, both for in-game performance as well as for reducing bandwidth costs if you run a game server. I imagine that NIO would be an important component of that though I’ve not used NIO yet. So anyway, yeah, sounds like an outstanding book. If you decide to put parts of it out for public comment and feedback I’d be very glad to read it and help out in that respect.

#11

p.s. At least some of us are interested in game development for profit. (I know I am.) So even though the business model item isn’t strongly represented, for some such as myself it would be great to have.

#12

[quote]p.s. At least some of us are interested in game development for profit. (I know I am.) So even though the business model item isn’t strongly represented, for some such as myself it would be great to have.
[/quote]
Thanks. All feedback at this stage is really helpful. I’ll probably take the final results of the poll in about 2 weeks time, when I put together the full pitch for publishers. I think it’s now pretty obvious that the demand exists and what things people are looking for :).

#13

I’m a bit late on this one, but I would be very interest in scripting languages for a game server. I assume all game logic and events would originate at the server so basically the server is where most of your actual game play would be handled. I’d also prefer something/language other than xml.

#14

[quote]I’m a bit late on this one, but I would be very interest in scripting languages for a game server. I assume all game logic and events would originate at the server so basically the server is where most of your actual game play would be
[/quote]
EDIT: it’s dependent on the architecture, but yes it’s often the case.

The chapter starts IIRC explaining how and why over time the majority of your dev time is spent on game-logic, which implies that this is where you should be most careful to save yourself time and difficulties.

Thanks for the info.

Rest assured, I will be assuming XML (by which I assume you mean XML + Xpath + XSLT) is not a viable scripting language. IIRC I was planning to cover:

  • Jython
  • beanshell
  • java (since so many people try it), and exotic stuff like using multiple JVM’s at once
  • a few others, briefly

However, until I get a working PC and all my files back, I can’t check :frowning: and I can’t remember all that well.

#15

Frankly, I’m a bit surprised how many people want to know about protocol design & impl; I’d assumed most people these days used 3rd party solutions rather than roll-their-own.

Any comments on this? 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)?

#16

For my own part, I’m interested in protocol design and implementation because I haven’t yet taken the time to look at existing third-party solutions. (We’re talking application-level protocols, right?)

#17

[quote]For my own part, I’m interested in protocol design and implementation because I haven’t yet taken the time to look at existing third-party solutions. (We’re talking application-level protocols, right?)
[/quote]
The plan was to cover both wire-protocols and app-protocols, since more often than not they are merged into one (inextricably linked) protocol, despite what the OSI 7-layer model might suggest.

I was also intending to cover some of the most common app protocols, and go into some detail on how you can re-use them in novel ways, and get the benefit of all the existing tools and clients/servers that can help you avoid spending months just debugging your own protocol. One particularly obvious example is HTTP, which can be put to lots of interesting uses without actually breaking the protocol, or twisting it much. It may seem strange to think of using HTTP as a low-level protocol for a game, but it can save a lot of money/time.

Perhaps I should have asked whether the protocol interest people have is more towards wire prots or app prots? (or both, if you’re not sure of the difference ;))

#18

Yeah, I was thinking that it would be pretty straightforward to use HTTP for communicating with a login server (log into server, get announcements, terms of use, list of lobbies, whatever) because those operations are all client-initiated request/response, and the model for doing such things over HTTP is pretty well-defined. (Game client can accept cookies, have a servlet on the server, can use HTTPS to hide password if so desired, etc.) I think talking about that a little could be useful.

I have very little experience with game development, so pardon me if this is amusingly noobish (it isn’t intended to be), but would anybody really want to implement a wire-level protocol? (You mean on top of IP, right? I guess it has to be on top of IP if you want to support Internet games.) Aren’t TCP and UDP good enough?

Willie

#19

See the sticky thread. Neither is good enough for most online games, although you can often “just about get away with” one or the other. What gamers want is something that lies exactly halfway between both, hence the proliferation of protocols that are UDP with a few extra things layered on top. In C/C++ there’s no need to roll your own, you can just get 3rd party (free) libs for it, but it’s not so easy in java.

#20

UPDATE

Submitted proposal to publishers, had some good responses, and it looks like one of them might be about to pick it up.

If you have any more requests, comments, etc, then now would be the time to get in touch! :wink: