I have been thinking lately about which shortcuts one could take when it comes to multiplayer games.
I have seen several homemades serveres and they are ussualy lots of trouble making, this is ofcourse including homemade protocols.
Isent there a market full of Java servers usuable for gojo(good old java objects ) programming. What about tomcat, Suns J2ee server?
What kind of shortcuts could be made in terms of a non-buggy reliable server framework?
The problem with J2EE is it’s almost entirely built around HTTP which is a stateless TCP protocol and freakishly slow in comparison to TCP stateful and UDP.
As far as using simple Java objects for communication that’s exactly what JGN is there for. 
I really don’t think it can get much easier than what JGN provides…granted I’m biased, but I’m also open to making changes if you think of ways to make it better.
http://forum.captiveimagination.com/index.php/board,4.0.html
Wel correct me if I am wrong. But is JGN not "just " library? I mean you have todo much of the game-server administration- code yourself, and ensure locks and consistency?
Been looking at the darkstar projects they claim to be able to-do everything, anyone have experienece with this?.
But perhaps it depends on the game type. A simple two player tetris would not need a darkstar server.
Yeah, I've actually spent quite a bit of time with Darkstar. 
JGN is just a library in its core functionality, but there are extensions to help do most of what Darkstar claims to offer and quite a bit more. In addition, it's FAR faster than Darkstar. I really need to post some benchmarks to help show just how big the difference is. 
JGN is completely thread-safe, so you don't have to worry about locks and consistency in JGN specifically, though you might in your game. However, there are things like SharedObjects in JGN that allow you to create an object on one machine and share it to everyone else connected to you. Further, if anyone makes an update to that object it gets synchronized across the entire network. There is also RemoteObjects that work very similar to something like Hessian, but with the J2EE junk and extremely fast.
There are many layers to JGN and it is being extended even further for clustering currently and should have just about anything you might want (in addition to jME-Networking and jME-Physics-Networking extension projects). However, if there's something you find missing or lacking just drop a message in the forum and we'll try to get it in.
yeah, reading up on darkstartand will try to run a few of the toutorials. Then i'll try out JGN
Darkstar really have some cool things, but communication is based upon byte-streams iin order to make every kind og clients connect). Thats could be an annoyance and JGN seems to be more easy that way.
My game does not have much need for FST (frequent State transfers) as many FPSs does but it will contain lots of entities and logic that needs to be syncronised and i am looking for a framework that will save me much of that hazzle. So my main concern is not speed but consistency and managebility. Managebility means how easy to debug, how easy to maintain. How easy to change. There is a hell of alot of difference between just extending an object to make it synkronised than having to create a new kind of packet-type with some kind of payload etc etc etc.
I would say one of the easiest things in JGN (with the help of jME-Networking) is object synchronization. All you have to do is register the object on each machine in the network where one designates itself as "authoritative" (meaning it sends updates for the objects position as it sees it) and the others are "listeners" for that object so they simply receive updates for positioning of the object as it updates. Essentially one line of code per object per client and you've got basic object synchronization in networking…can't get much easier than that.
Good luck with Darkstar…it does have some cool features that JGN does not yet have, but I still hold to the belief that it is not the right decision for any project but the EXTREMELY large MMORPG games that hold to the typical MMO mentality of "We only care that we receive updates, who cares if they happen very quickly". ;) However, what I'm working on now will hopefully even change that from being the case…but I'm extremely opinionated and quite biased in this case though, so I could be blinded.
Hi
Just to wade in on this one too
Darkstar has effectivl 2 parts. The heavy weight bit, that has support for transactions, persisteance, fault tolerance etc, and the light weight bit that is there for when you need very high throughput, with fault tolerance. For example. I use both bits. My clients send updates 10 times a second to each other through the lightweight channels, this means that I get good update times, then, I also send once a second, an update to heavy weight piece, this does some basic cheat detection and persists the locaiton, this means that if a client loses connection, when they reconnect, I know to within 1 second, where they were.
I've not spent much time looking at JGN, so I can't really compare, all I can do is say that SGS fits my needs, and you will probably need to make the decision for yourself. You won't get an unbias view from me or Darkfrog :).
Darkstar currently does not have any easy plumbing type code, it's all very much byte[] based. You could probably rejig some of the JGN extensions to get your synchronised objects, but the thing with SGS is that you need to think very carefully about when you want to get at an object, and what else you need to get at at the same time, and what you don't. It's very easy to screw yourself over with SGS and end up with everything being pulled back from the back end store every update, and then your performance will suck. On the other hand, get it right, and you have a fantastic MMO backend with lots of bells and whistles
If you have any specific SGS questions, head on over to the forums on JavaGaming.org, I think this is probably a conversation for those and the JGN forums, rather than jME's
Endolf
Someone can correct me if I'm wrong, but I don't see Darkstar as an alternative except for big companies.
Hi
You are right in that the SDK is just that, it's a developer kit, not a proper stack. And you are right that the full stack likes proper server rooms. You are also right that 1 and 2 man shows are not going to be able to run large server rooms themselves.
On the flip side, it has been stated a number of times that Sun will offer hosting (not just the playground), I have no idea of the details of this though. How many of us 1 and 2 man bands have multiple servers anyway though?. Ok, no doubt some will. If you have just a single server, then you should be able to run the full stack when it's released (the whole thing will be open source).
If you were planing on running your game server in your computer room hanging off your home net connection, then no, SGS is probably not suited, it's over kill for that environment. If you were thinking about renting multiple servers for your back end, then it's worth looking at.
HTH
Endolf.
Endolf said:
If you were planing on running your game server in your computer room hanging off your home net connection, then no, SGS is probably not suited, it's over kill for that environment. If you were thinking about renting multiple servers for your back end, then it's worth looking at.
I'll believe that it's possible a 1 man show could get it going on a box or two hosted at whatchamacalit ISP, but until they release more info, it all just us and our opin-e-ons. :)
culli said:
Someone can correct me if I'm wrong,
Okay, your very wrong.
but I don't see Darkstar as an alternative except for big companies. Why? Because the SDK only runs on one box, and in their FAQ they say that it is difficult to put together an actual SGS server farm because it requires "sophisticated interconnect".
This is correct. To do what we do and reach massive scale requires a seriuosu machien room investment.
However you have totally missed the point.
One of the primary purposes of Darkstar is to enable small developers to produce massive sale games. By offering
a standard execution environment that load balances across all a provider's hosted games,w e make that economical
to run and administer.
Sun has quite a few *big* hosting providers already chomping at the bit to provide hosting for infependant developers. Some of the biggest names in the business, in fact.
The Darkstar development cycle for a small developer is as follows:
(1) Get to code correctness and multi-user tests up to about 50 or so players on a box in your office.
(2) Go to a provider for your beta. We are encouraging a model where this period is provided free by the hosting provider
and are leading the way ourselves with the Playground.
(3) "Throw switch" and start charging, at which point you revenue split with your provider.
This allows the small developer to get into the game without building their own machine room, or their own operations crew. Both of which are out of the question for the little guy. Sure, you can throw up a single server or two in your garage... and if you are successful you run smack into the "success disaster" of overloading your infrastructure, and your game gets a reputation as "garbage" you'll never recover from.
See "Anarchy Online" as a real world lesson.
Until such time as somebody out there offers cheap SGS hosting, I don't think it's an option for us 1 or 2 man shows.
Until there is content, what will they host? 8)
This is the classic catch 22 of any new platform launch. Thats why we're putting our money where our mouth is, not only in funding on going Darkstar development, but in the playground. Does jumping in now take a bit of faith in the future? Sure, but thats true of getting in on the ground floor on any new platform. And thats what Darkstar is-- the first standardized platform for game servers.
Considering you options though, which as a small guy are virtually non-existent, IMHO its na easier choice them many,
Its takes $20 million dollars to launch the server side of an MMO the way its been done up til now (cf Jessica Mulligan: http://www.gamasutra.com/e32006/news.php?story=9248 ). Tell me thats an option for the garage and small shop?
My guess is that Sun's goal is to sell hardware.
Your guess is wrong.
Ouur goal is nothing short of a revolution in the online space. We wish to make MMO development more then a "big boys only" club. The result will be a much larger and more vibrant industry with space for everyone from small developers working with providers to some of the biggest companies lowiering their risk and thus being able to afford to take more chances. This will open up the market with much more varied product attracting more consumers.
The end result will be many more games running on much more hardware and requiring much more support. All of which is good for us.
On another note I found your performance comment intriguing. As not just the chief architect on Project Darkstar but also the co-author of one of the leading books on Java performance tuning (http://java.sun.com/docs/books/performance) there is a phrase I use at every speach ive ever given. To paraphrase Mark Twain.:
"There are three kinds of lies. Lies, Damn lies and Benchmarks."
It is very easy to do a "benchmark" that proves anything unless you are rigorous in your methodology and know *exactly* what it is you are measuring. Its this latter Im curious about. Darkstar does so much thats never been done before in thsi space that I'm curious how you managed an "apples to apples" comparison. I'd love some more details.
In any event, thanks for the interest in our project. In general the most direct and correct information on itcan be obtained unedited at the Project Darkstar website and our discussion forums.
Regards
Jeff Kesselman
Chief Darkstar Architect
P.S. Since the question was short-cuts. Here's a data-point for you.
I'm doing a synchronized SNES level game (think Bomberman) called "Bunny Hunter Online" for my
JavaOne talk.
It's based on Slick on the client and Darkstar for the server. It is entirely server-side logic
Im about to reach feature complete in a total of 2 man weeks. This includes code, background
art (my sprites were provided to me by a friend) , and some light music and sound production.
jeffpk said:
Okay, your very wrong.
standard flippant reply:
jeffpk said:
P.S.
culli said:
standard flippant reply: My what? (referring to the incorrect use of "your", a pet peeve of mine, my grammar ain't perfect either, but I know how to use "your" and "you're" }:-@). Pet peeves aside, I'm glad to see your summary of what Darkstar is and intends to be!
Thanks. You and my mom ( a full time professional author) hate when I do that 8)
Ok, so why isn't this kind of summary on the FAQ page? (If it is, I deserve to be called blind :))
Its a good question. Honestly, the answer is because it hasn't been asked fequently. Most of our ocre community hanging out at JGO know all this from past peaches I';ve given.
But its a fair observation and I'll add it to the FAQ.
Chickens and eggs. I really like what I'm seeing with Darkstar as far as developer implementation goes. It's what I want my framework to be.
Cool. Thats really good to hear. Im sure we have palces we can improve things, add features, etc, but its nice to hear we're on the right track 8)
Sounds like my guess is partially right. Sun does want to sell more hardware, but the part I missed is that you want to do it by promoting MMO game development for "the masses".
heh true enough. I just wanted to make sure the entire picture was clear 8)
As far as performance goes, I won't respond to that because I didn't make those comments, Endolf did.
Actually I thought Dark Frog did. *shrug*
I thought my point was in responce to dark frog, who commented
games that hold to the typical MMO mentality of "We only care that we receive updates, who cares if they happen very quickly"
Yes, there are parts of dark star that do not handle huge amounts of transient data every second, but thats distributed transactions for you. You have to design around other issues like 200-500ms lag times on the internet, likewise, there are design considerations when looking at persistance and transactional issues.
If you want your clients to chatter to each other with realtime, transient data, then use the channels in darkstar, thats what they are there for. The heavy weight stuff is slower, but it has to be, it does lots of things for you.
It's just pointing out that whilst there are slower bits, there are reasons for it, and when you want speed, use the right tool (channels)
HTH
Endolf
Endolf said:
If you want your clients to chatter to each other with realtime, transient data, then use the channels in darkstar, thats what they are there for. The heavy weight stuff is slower, but it has to be, it does lots of things for you.
It's just pointing out that whilst there are slower bits, there are reasons for it, and when you want speed, use the right tool (channels)
Precisely. Darkstar is a bit of a tool-box. Don't try to drive in screws with the hammer ;)
JK
A little late in the discussion, but I'll chime back in here.
I'll acknowledge that Darkstar has some really amazing features that have not been done before but at the end of the day no matter how you look at it, it was designed as a beast. It is a heavy-weight system and that can be good and that can be bad, but for the types of projects that most of the smaller development groups do I personally think you are taking a major performance hit by using a system like Darkstar. For specific MMOs I think Darkstar can be valuable and offer things that no other networking engine/API (including JGN) offers. However, I will acknowledge that it has been quite a while since I did my time on Darkstar and there may have been vast changes since then.
Jeff is undoubtedly biased for the same reasons I'm undoubtedly biased and I think the designs for our respective networking systems are focused towards vastly different goals and I think that is where a decision should be made to use one or another. One definitely has more development time and marketing than the other though but I'd put my money where my mouth is any day to stack up performance between the two.
Fair enough. Time is not something I have a lot of at the moment, but hopefully very soon I'll find some time to get back and re-write my tests for proper benchmarking with the most recent version of Darkstar. Also, I should apologize for what I'm sure seems very much like "Darkstar bashing". Much of that is due to what I saw as major shortcomings in the engine, but I also come at this from a very different perspective than most developers so a lot of it is probably unwarranted from a real-world development point of view. I know I wouldn't be all too thrilled if you came in and started just talking down JGN without backing it up with tangible proof.
I will make this a high priority to get this information back to you regarding performance tests between JGN and Darkstar.
Oky doke. Ill be interested to see what you come up with.
Please make sure to use the latest version (9.1) because there was a bug in 9.0, that appears neither before nor after, and that was slowing down client to client communication.
JK