Generic game server

Networking & Multiplayer
#1

Hi all,

I have a personal game project I’d like to dev on. It’s a multiplayer game playable in the browser, written in Java. Currently, I’m writing a gameserver. This is going well, but I wonder if there are already gameservers available? I found some projects, such as Red dwarf, Vassal, Arianne and there are more. I’m looking for a generic gameserver, which has most stuff abstracted away. For instance, I’d like to support multiple transport implementations such as binary sockets, websockets, et cetera. The projects I found tie themself to binary sockets, and as such is unusable for my webbased client.

Surely there must be some kind of generic game server project, aimed on handling comomn tasks like accounts, chatrooms, gamerooms, logging, class API?

Thanks in advance!

#2

If you’re set on developing your own site, there’s a framework called “Jogre” on source forge
that might be your best bet.

The other likely path is to shop your game to whatever site seems most compatible. There are a
bunch of indie game sites that use Java as their primary engine, and some no doubt would welcome
volunteer developers. Boardspace.net is in that group.

#3

@ddyer
I believe he wants a server for a game, not a site.

Other than that, sorry I can’t help :confused:
I think you’ll have to go solo on this one; I wrote my own game server with similar functionality and it’s not that hard to do :stuck_out_tongue:

#4

I think Project Darkstar does a lot of this stuff?

You can check out gamegardens.org for a lobby API as well as some magic to automatically send state changes across the network.

And you can get a VPS like http://www.123systems.net/ as a starting point for your multiplayer projects. It’s a good place to get things going, and later you can get a more dedicated server if you have enough people playing your game.

#5

Jogre relies on binary sockets, like Arianne, Darkstar, Red dwarf, Vassal. Gamegardens looks interesting but has some weird dependencies which I want to avoid. Also, it seems to do xml parsing by hand.

Writing a gameserver indeed is not that hard. Writing a full-featured gameserver is very hard though, since it involves a lot of stuff. Think flooding, banning, rough talk detection, player admin, game admin, logging, UI elements, data definitions, et cetera. As a matter of fact, I already have a good working gameserver which can be used locally. The remote gameserver also somewhat works, but as I develop on it, most stuff I want/do just seems the 345670976542345679th wheel invented. I want to avoid that, to keep code quality high and quantity low.

Looking to most gameserver java implementations, it seems accepted to tightly couple the code to binary sockets. Which is logical, since the assumption that only java applets will consume the server was since a few years back normal. It sucks though, because it instantly rules out the possibilty to use it for my project :frowning:

#6

Hmmm you would be better to forget about banning (will you ban every single person that does something ‘‘incorrect’’ yourself?) and rough talk detection (too complicated or too simple…). For player admin and game admin, I guess that most of it should be in your game code and not in the server code right? (I understand admin as in managing the game option). UI elements!? Does it means the user interface in your game? (how is that related to the network code).

Logging and user account could be an interesting feature. As well as lobby for joining games.

What do you mean about binary socket, does it means you need to send your data in binary form? Personally I use a server where you send object over the network, it’s so much easier. The process of serialization is not really a problem for performance either.

#7

Basically I mean a server which is not tied to any of the underlying mechanisms of transporting objects. Whether that be pigeons, strings, binary data, I just want to throw objects to the server and let the server receive them. Gameserver projects which are tightly coupled to TCP sockets therefore are not suitable for my project.

The features I named are just a small amount of examples I can come up with thinking about it for 10 seconds. I can think of hundreds more which can all be useful for any type of gameserver. The UI elements I mean are the abstracted definitions (interfaces) of the various managing UI widgets. Think server status, add servers, manage users, traffic, load, et cetera, complete with reference implementations using some kind of UI toolkit.

#8

Loosely speaking, some server-client architectures have a very tight relationship, where the server is an integral part of the game. Others have a looser relationship where the server expects certain things, but otherwise acts as a neutral facilitator. It sounds like you’re looking for the latter, but even there, there are many things which are pretty nailed down and might not suit you.

#9

just sending objects is the RMI way which is well… silly.

you probably don’t care about mantaining object identity and related consistency across sites.

Given you just want to send dataobjects/struct like stuff just check out protocol buffers et al.
add some plumming (mina reddwarf or any other library that adds connectivity)
add some identity server or write your own for banning
move langague, voting and admin stuff to your game specific bit…
stir and add salt to taste.

after that you can wonder about HA and scaling, though I hope your plumming supplier already though a little bit about that one.

#10

Mr_Light,

I’m looking for some generic implementation of a gameserver. I can think of lots of functionality needed for most java games, flooding, banning, rough talk detection, player admin, game admin, logging, UI elements, data definitions et cetera. I know I can write a server myself, but for me it really seems to be the 345671092387625th +1 attempt at it.

I never mentioned RMI or any other implementation detail. The only need I have is that the gameserver should be compatible with any tranportation method (WebSockets, binary et cetera).

#11

I still suggest you write your own server and not worry about how many times it’s been done before because although each implementation is similar in function, they are all different in architecture and you will waste less time debugging when you know your own code and how it works, rather than use someone else’s library that may or may not do exactly what you want it do in a certain way that you like. And etc…

#12

and with a good idea of how you server have to work and the requiered arrchitecture it may be even shorter to restart one from scratch than reusing one