Has anyone every looked into the possibility of tying Darkstar with jME?
Darkstar is, as far as I know a networking librairy containing very fast networking code and load balancing code. Ideal for multiplayer games via the internet.
I was wondering if anyone has ever tried it or could perhaps give his vision about these two products in combination 
Thank you
Darklord,
Iāve looked at it somewhat preliminarily and it scared me away. I was considering doing a simple game with it to see how complicated it would be. Just looking at the API I realized I donāt have that much spare time. :-p
Darkstar is specifically geared towards massively multiplayer games, although other games can be accomplished with it. I think for extremely large games there could definitely be a reason to use the project as there is nothing currently that supports all of the capabilities that it does. However, I believe it would take less to time to add those features to an existing project than it would take to learn how to use them in Darkstar.
Obviously Iām biased since it can be construed to do many of the things that my JavaGameNetworking API does. It definitely has a lot of features that my API does not as well. However, I would be happy to compare performance and learning curve between the projects as I know where my projects stands. 
If you end up doing anything with Darkstar I would be interested in how you progress. Iāve been talking to a couple people using JGN that are interested in using it for a massively multiplayer game. To that end I will probably be adding specific support for MMO games to JGN in the near future.
If you havenāt already check it out it might be beneficial: http://javagamenetworking.dev.java.net
I hope that wasnāt too slanted in favor of my API.
darkfrog
Chris hasnāt been keeping it as up-to-date as he would like but his third podcast has an interview with Project Darkstarās Lead Architect Jeffrey Kesselman. During the interview Jeffrey states, āWe actually hope that the middleware developers out there once they
start seeing and understanding the system are going to go āyou know I want to write a game engine on top of thatāā¦Darkstar is not limited to any specific type of game.ā Itās primarily about removing the little things that have plagued developers to date (scaling, failover, resource allocation, etc.)
Chrisā Game On podcast
digitalnburn, interested in helping write a plugin for JGN to make them work together?
Once I release JGN 2.0 I will very likely look hard at making it all work with Darkstar, but until then I've got my work cut out for me to make the fastest game networking API around.
darkfrog
Then you must really be laughing.
I would love to help but right now I'm very overcommitted.
No problem, I'm in the same boat. :-p
darkfrog
I started to look into dark star for the load balancing/distributive computer aspects of it, and I have to say, reading the tutorial document had me down right impressed from the get go, the design is very simple in concept, and luckily for me it meshes extremely well with how I've been designing my current projects (I assume anyone who is writing client server code using NIO would be able to say the same). The concepts seem simple enough though the implementation of those can be very confusing. I started a simple multiplayer asteroids type of game as a way to begin learning things, and I believe I have the server side of it nearly completed on day 1 of learning the API, this is day 1 after getting home from work and doing that in my spare time. I expect to have a working client for the game done tonight though the client will be trickier as the actual displaying of the data is independant of the network. Overall I'd say that darkstar seems pretty easy, though there aren't any start to finish tutorials available yet for making a client and a server, there are several examples and there is a tutorial for writing a chat client and a tutorial for writing a server that just basically has a few objects you can look at, it doesn't actually go into details of how you'd interact with two player objects, it shows you how to respond to a message from the client, but not how to tell other clients about what just happened from one client (not that it's hard, but it's not explicitly shown even though the server example includes all the necessary references to do so, maybe the next release will improve that).
I haven't used JGN so I can't compare it, and as I've only got 1 day under my belt and no real working test I can't claim to be an expert on darkstar (which I can't help but think of as dorkstarā¦ no matter how cool the project itself is, I just want to punch myself every time I type darkstar).
Now for the cons, at this point, it's not clear what the licensing is going to be like for this, the cost, or even the general idea of what you would pay for. javagaming.org there is some discussion about this, and it looks like it might lean towards a service based model where you would have to host your work with sun, though they do say they expect to have the option to host your own copy of that software, I also expect they mean if you are a multimillion dollar corporation that they feel they can trust to behave responsibly and not just some small timer who doesn't want to pay a premium for suns hosting package. There is also no clear date set for when the licensing will be settled, though it should probably be less than 3 months away from what I read, nothing concrete there.
So basically while I wouldn't knock the API which I believe will work fine with JME and provide some very nice stability features, the licensing is very scary right now, if the only affordable solution is to host at a possibly expensive sun server, as apposed to being able to manage your own farm, or pay for a license that is intended for very large corporations, then this might not be of much value to a lot of the people who develop smaller games. Until the licensing is resolved, you can't really release anything in a production environment anyway, so that's something to consider. If you are developing anything massively multiplayer/service oriented than I can't help but think the core features of darkstar are hard to ignore, but if your game can be broken down into smallish < 200 people chunks of people that are independant then you can easily seperate your game into independant servers with maybe a master server that directs traffick.
Good points Dan. I've been looking at SGS - I find that better than Darkstar personally - somewhat as well. It definitely has some extremely impressive features, but there are many disconcerting aspects about the API, licensing, and other miscellaneous things. For MM games I think the advantages are hard to ignore, but for just about anything else I've got to believe there's a better solution. Once I get JGN 2.0 released I will be writing a plugin for SGS to JGN to get all the advantages of SGS without sacrificing the performance features that JGN provides above and beyond what SGS has. I'm also planning on doing some further tests between JGN and SGS to show in a real game the distinctions (more for my own personal insights than anything else) between the APIs.
darkfrog
I think I've settled on Dorkster, it has that trendy napster sound, yet properly mocks the name, one of these days when I'm trying to negotiate some cheaper than normal license with the sun people I'm sure it'll come back to haunt me (aren't you the guy that coined dorksterā¦ yeah, we'll give you the special priceā¦ the we spit in your server price).
Anyway, I don't think the value is only in MMO games, or even just games, though that may be the strongest points. I believe that it's worth at least being familiar with the API if you think you may need the stability and other features, so that your own code can easily be ported over easily. I think any NIO client server that isn't doing anything super fancy will port very easily, my own example I think that I just need to get rid of my section of code that exists soley to take a bunch of bytes and convert them into a command (In my server design I take the first 4 bytes and create an int, and that's how long the rest of the command isā¦). If I get rid of that (as well as the code that takes a ready to send command and puts the length in front) then I think I'm good to go. Maybe at the end of this weekend I'll go through and heavily comment my dorkster game code (assuming I get it working) so that there can be a fully working example of a simple but playable game with communication between clients (server centricā¦ peer to peer is great and all, and I might find that it's easy enough to implement chat peer to peer using SGS while leaving the game server centric cause I'm paranoid of cheating). Heck, the game idea is simple enough, maybe I need to take a little time to learn the midlet API and slap it on a cell phones too (one of the features of SGS is it should be easy to use the same code for UDP, TCPIP, HTTP, etc communication, which is not nearly as impressive as the other things it's supposed to do but still nice). As a further note, if you already have a working networking code that is pretty easy to use, I don't think that SGS will make development any faster/easier really, but I'm not far enough along with the client side to say for sureā¦ yet.
[edit]The client API is significantly more complicated to implement than the server API, probaby because the example I'm working off of does peer to peer communication in addition and it's hard to seperate those out since I don't know what I'm doing yet[/edit]
DanK said:
I also expect they mean if you are a multimillion dollar corporation that they feel they can trust to behave responsibly and not just some small timer who doesn't want to pay a premium for suns hosting package.
What do you meen by 'behave responsibly'?
Thanks, I've already read about Quake, Unreal, and various others that have posted information on how they handle networking. I appreciate the links though and will go over that first one when I have a few minutes.
darkfrog
For good MMORPG programming, I don't think what works for a FPS game is necessarily going to work that well for games that aren't as action oriented, and more important, a game like quake has extremely different priorities when it comes to scale of the game server.
The big attraction to me for SGS is the ability to make use of a server farm, when JGN can handle that, without my application having to be aware of how it's being split apart (this data is on server x and this is on server y) then I'm definitely interested. I didn't originally consider the stability advantages of SGS a major priority for me, but that's probably just poor planning on my part, as the more machines you have the more likely failure is for at least one, so I would have to say that the server would need to seamlessly handle failure of a 'slice' (server must go on like it's not that big of a deal, the client can hang for all I care when it comes to something like this, they'll be good when they reconnect). I think I could actually figure out how to do this on my own, especially having had a chance to see how SGS works, I learned a lot in learning what I did, but I also assume sun's engineers will do a much better generic job than I can (possibly to the point their generic framework is superior to my specific function version).
I figure that I can host 500-1000 clients on a single machine and that the database backend will be my first bottleneck and I'm confident that I can easilly deal with that by putting several machines in charge of handling the database (I think most commercial databases can be placed on farms and take advantage of them). I've got a few months before I can even hope to worry about that stuff too much because I need to actually have the game working. There's much I need to get done, and even more I need to learn before I get to worry about how to distribute my game over a server farm.
If I end up developing a MMORPG supporting extension for JGN then I'll have to have some sort of object-store system similar to what SGS supports with their GLOs. At the current point JGN does not inehrently support clustering, but that would be a necessary feature of support for MMORPGs.
darkfrog
By behave responsibly, I mean represent a company large enough to pay $30,000 or so for a site license to host their own local copy of sun's program, and should they do something unresponsible, be worth the cost to sue for it. It has nothing to do with how ethical a lone programmer is, and what's more important, is my impression based on what I've read in other forums, I don't represent sun, I don't have any special inside knowledge, if I did, I would have to sign an NDA before they gave me any more knowledge than what is publicly posted.
Since I'm posting I might as well sayā¦ I think I'm personally going to try to pretend dorkster doesn't exist for a while, at least until their next release. I spent a lot of time on it, and while I like what it will do, and how it does it seems reasonable too, I don't actually need what it does now, and I feel like I'm somewhat wasting my time learning the API when it's still early enough to go through some very large changes, I'll be watching for it to develop more, as I do think eventually I will want to use the API, but I'm going to hold off on it until I have a direct need and hopefully will be able to know what kind of limitations/costs the licensing will involve.
Dan,
If you're interested in utilizing JGN for the project I've been thinking a lot about adding an extension for supporting MMORPG games. If this is something you'd like to pursue I'd be happy to work with you to achieve that.
darkfrog
let me throw in two urls i picked up while i was scanning for some good mmog-network coding. maybe they hold some valuable info for you.
an in depth description of how to do multiplayer over the network. including the aspects of NAT and cheating.
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/IntroductionToMultiplayerGameProgramming
this is how quake 3 does it with udp:
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
the q3 appoach seems to be very good. i don
Wouldnt the hardest part be to fully use clustering? If your network librairy would support that, the scalability would be enourmous. Then again im not sure what gets involved with clustering. I reckon if you slice tasks up and distribute them amongst multiple servers you'd need to have 1 "registry" server that tracks if all slices get processed and return a result. When one fails, it schedules the same slice to an other server. Problem with that would be that if the "registry" server fails, you're doomedā¦ technically
I've actually started doing some work on clustering / ranged servers for Galaxies Beyond. It allows fail-over of one server to another but also defines a range of "space" that each server is designated as "their territory" and so the client will dynamically connect and disconnect from servers depending where they are in space. This will not likely be done for a while, but is extremely powerful and at any time it can't connect to the "designated server" it will connect to the closest one it can find.
darkfrog said:
at any time it can't connect to the "designated server" it will connect to the closest one it can find.
So that would eliminate the problem of one server having to deal with the busiest place in the galaxy? Since multiplayer games (im assumed you're not using all those servers for a single player game :D ) often have spots that are entirely desolated... and extremely crowded.
Their designated space is increased or decreased by the "back end server" that coordinates things between them. Say if you were in an area of space all by yourself that nobody ever visits then you might stay on the same server for a very long time, or five servers may be sharing a single sector of space.
I also resolve a lot of the issues network traffic with the synchronization system in JGN because each registered object has an update "priority" that determines how frequently it should be updated but that is dynamically adjusted based on the distance from the camera they are so for an object really far off in the distance you don't need to receive an update but once every couple seconds.