I’m just looking into networking libraries and I was wondering how the uses and features of JGN and Darkstar compared. I’ve heard on these forums that JGN boasts about 1 million messages/sec, but it seems to be a library designed to handle mostly networked game events. Is Darkstar capable of handling and transmitting similarly fast-paced events, or would it be better to use Darkstar as a hosing system and switch over to JGN for the actual game networking?
I think a “versus” comparison is probably not a good idea here since they each aim at different audiences. I don’t want to speak for Darkstar (particularly since I’m the author of JGN) but from what I’ve seen and used it is primarily focused towards MMO style games and provides some really great features to that style of game.
JGN is more focused as a general purpose and lower-level game networking API that provides commonly used functionality to game developers in order to simplify the networking aspect of game development. For example, in just a few lines of code you can synchronize scenegraph objects in your game between a client and server (and the server will validate the synchronization events and broadcast to other connected clients).
A game simply needs to define an implementation of GraphicalController (there are already some simple implementations for jME, jME-Physics, Swing, and GTGE) that actually handles the application and generation of synchronization messages. See below for the jME implementation as an example:
http://captiveimagination.com/svn/public/jme-networking/trunk/src/com/captiveimagination/jmenet/JMEGraphicalController.java
Also, here is an example utilizing the FlagRush tutorial from jME to synchronize the motorcycles across multiple clients:
http://captiveimagination.com/svn/public/jme-networking/trunk/src/com/captiveimagination/jmenet/flagrush/
This is one of many enabling features of JGN. Also, I’m currently writing a massive extension to JGN to support MMO games (since I’m currently writing one) but for classical MMO games Darkstar is probably going to be your most reliable option at the moment. Also, there is some interesting functionality that Darkstar has that JGN has no plans in the near future to support.
I’ll leave it to Jeff or someone else here give more details on the benefits of Darkstar.
I’m needing a mix between mmo and more standard instance-based multiplayer sessions. I envisioned using darkstar for the hosting and connecting and most metagame server-client transactions and JGN for the faster paced game events. I was mostly wondering if either could be used for both metagame and game events. For metagame, I’m referrring to chat messages, locating hosting, viewing statistics and other transactions that aren’t necessarily time dependent.
Yes, JGN has full support for all of that. However, to be fair I believe Darkstar is probably competent at accomplishing all of those tasks as well.
From the sounds of things, JGN was built to be fast and efficient, although I’m don’t know anything about its scalability. I know Darkstar loves to tout its scalability and mmo features. These features are needed for my current work, but I also need the efficiency that JGN would offer. Does anyone know how Darkstar compares to JGN in raw performance ability?
Stability and scalability is definitely something to bear in mind when making a decision. Darkstar has the backing of Sun and JGN has the backing of several developers writing games…doesn’t really compare, but one big benefit of JGN over Darkstar I would say is that if you find a bug you’re likely to get a fix in less than a week (sometimes overnight). We don’t compare to Darkstar in terms of support or probably even stability, but if you want raw performance I’m willing to back JGN’s performance against any networking solution. 
To sum up, please use JGN and help us make it more scalable and stable. 
Hi
Darkstar has 2 communication techniques, in one, a client talks directly to the server, at this point the server stars a transaction, with all the scalability, and performance implications that come with that. The other way is using channels, as long as you have not set the server to listen to the channel, messages are not much more than bounced right back at the other clients on the channel, thats about as fast as is possible :).
I’ve not tried JGN, so I can’t really compare the two either.
Endolf
Are there any benchmarks for Project Darkstar? The basic test is creating an object on a client -> sending it to the server -> server unpacks it and then -> sends it back to the client. There is a byte buffer of size 10bytes inside the object that is being transfered.
JGO claims to do this at 0.001ms. What about Darkstar?
BTW, I saw Darkstar’s booth at AGDC but didn’t stop by (regretting that right now especially b/c they had that nice mini-lecture thing going on … didn’t have enough time on the show room floor).
Perhaps I’m just in the dark (maybe a little pun intended) here, but what games are currently written and available using Darkstar? Are there any production quality games out there using Darkstar for their games or even any big companies relying on it for an up-and-coming game?
We can talk all day about Darkstar being cool because Sun is pushing it, but nothing speaks louder than examples. That might be a good way to show how great Darkstar is.
Taken from the FAQ on their homepage (www.projectdarkstar.com)
[quote]Who uses Project Darkstar?
NCSoft has been prototyping a new game using the SGS
A great many smaller developers are taking advantage of the Darkstar opportunity right now as well. Project Darkstar fundamentally changes the economics of massively multi-player online game development to open it up for small developers as well as large ones.
[/quote]
Thanks for the help, you’ve given me much to think on. I still need to look carefully at the api’s to see which best fits my needs. Plus our multiplayer setup has yet to be finalized (although it’s close), which is definitely going to have an impact on my decision.
Would anyone be interested in working with me to resolve this question once and for all? If someone is willing to work with me to create a basic (unbiased) game and then use both Darkstar and JGN I would be happy to write all the JGN code for it. This question has been raised on various forums and this would help to give concrete evidence to support one or the other.
[quote]For example, in just a few lines of code you can synchronize scenegraph objects in your game between a client and server (and the server will validate the synchronization events and broadcast to other connected clients).
[/quote]
Can someone explain this more in detail?
For instance … say you have 2 players in a room. You also have a room object that contains all the players in the room.
Each player is associated with a client (in the real world). If there are 2 players (A&B). If A’s position changes, how is that change propagated through the system ?
If this were RMI, there would be a server class that has the room object. A Player would connect and be added to the room. Any other Players in the room would be then sent to the Player that just connected (via method calls on the Player Object … also note, that both the Room and Player objects would extend RemoteObject. Any time a player updates their location … this information is propagated throughout the system (basically any time the system is getting the location of a Player).
Also, what is the performance difference between auto synchronization (like above) then writting our own method of doing it (player sends location to server, server then broadcasts that out to appropriate players)?
Thanks for ur help
In the case of JGN this is taken care of for you via the synchronization system. Refer to the FlagRush tutorial link I referenced above for more details about how that is set up, but essentially you tell the SychronizationManager that you want to “register” an object (the object would most likely be your scenegraph object) and then how frequent you want to send updates out. This is primarily beneficial for realtime games where you have so much movement going on all the time that if you were to go the RMI route you would have to be sending messages just as fast as you possibly can to keep up and then it wouldn’t be fast enough unless you’ve got some mediation thread that is actually updating your RMI object based on your scenegraph object.
The idea is to simply “register” your object on the client that is responsible for the positioning of this object and it will send positional information down to the server on the frequency you specify. The server receives those messages and validates them (which is another thing you really don’t have in RMI by default) and if it validates it is broadcast to the other clients to apply to their scenegraph. If it doesn’t validate a message is sent from the server to the client telling it the position where the object should be.
While we’re on the topic of synchronization another HUGE advantage to JGN is that it prefers UDP communication for synchronization messages since it doesn’t matter if some get missed along the way. Further, there is something called a RealtimeMessage (that all SychronizeMessages in JGN extend) that keeps you from managing useless updates. Classically you could queue up updates to be sent from one machine to another (or even updates that are queued up upon receipt to be processed on the recipient) and if you get any system pause or any performance hit or even an unability to send messages because of lag you could potentially stack up multiple positional updates for an object when really you only care about the most recent. Classically you’d have wasted time processing and applying all of the old updates (I’ve seen this happen even on Battlefield 2 when I lag) and you’ll see yourself sliding forward back into “now” but in JGN a RealtimeMessage only one of a specific “id” (or object reference) can exist in the queue and so you can add 5000 every second and it simply replaces the old one with the new one and you never have to worry on either side of having to process old synchronization messages. UDP if you’re not familiar with it is really great for this type of work because using TCP can often exhibit much more lag given that you are using guaranteed delivery, so when you send 500 messages 500 messages are guaranteed to get there no matter what. UDP will happily drop messages along the way which is beneficial in scenarios like this.
It’s important to point out that I’m not suggesting UDP is better than TCP though. JGN is about leveraging both in the places where they are beneficial. For important information that MUST arrive it is always best to use TCP when possible. However, JGN does support a CertifiedMessage that guarantees delivery on both UDP and TCP (sort of necessary in the way JGN abstracts the type of server being used) and even provides a Receipt message letting you know that the message was successfully received on the remote machine.
JGN is an easy to use framework but a LOT of thought has gone into the way it was written and providing support for common game development needs. I think this is starting to become obvious as point-by-point comparisons between RMI and JGN are examined. Yes, RMI can work for what you are doing, but if you have the ability to run an arbitrary server I don’t see any advantage that RMI provides over JGN.
Okay so, here’s how I see it:
JGN: Object level communciation. Lower requirements server side. Great if all you want is communication
Darkstar: Byte packet level communication. More server requirements, a lot more functionality. Great if you need/want that functionality.
The other thing Darkstar brings you is some industry standardization. We have big industry players using it now (NCSoft, Gaia Online, etc), integration with other key game service components like Perpetual’s backend, and are developing a market for hosting providers. That last can be very important to small developers.
Performance is for the most part a non-issue. We haven’t gone through a tuning phase yet because we are finishing multi-node now but there is no reason why performance doing the same kinds of operations (pure channeled message passing) should be markedly different in the long run.
Darkstar does push for near linear scalability by adding new nodes to the system. I honestly don’t know what JGN does there.
RMI: A straw man. It ain’t designed for games. Don’t use it for anything where latency is going to be an issue.
For the latest Darkstar information see the sister Darkstar forums at www.projectdarkstar.com
True JGN focuses explicitly on the “networking” aspect of games and doesn’t attempt to be the juggernaut that Darkstar tries to be, it is quite misleading to say that all it does is communication. Further, JGN DOES support byte packet level communication.
I heard quite a while back on NCSoft’s evaluation of Darkstar. Have they officially decided to move forward using it? :
In shear number of features Darkstar probably blows JGN away, but I can say there are some very powerful features that JGN has that Darkstar can’t touch. JGN is about simplicity to the developer while providing all the power to accomplish their networking goals. Also, there’s no reason you couldn’t use Perpetual with JGN as well. Hosting providing is a great feature and one that JGN will never attempt to compete with Darkstar on, but that’s because I don’t believe it’s a front that a networking engine has any business touching.
There is a major extension being developed for JGN that provides clustering, fail-over, and redundancy functionality in addition to data storage backing for MMO games. This is a massive project I’ve been undertaking in my spare time while developing my own MMORPG that uses it. It will still be a few months until that is publicly available, but even without this extension JGN in the core has features that do not inhibit “nodes” the same way Darkstar does (and even allows you to create your own architecture).
One of the greatest features of JGN over Darkstar is that it does not force you into some pre-defined architecture but rather provides you all the low-level tools you might need and even provides you with some extensions should you choose to use them. This is where I’ll tie back to my preliminary statement that Darkstar and JGN have different market focus. JGN is all about the developer and enabling them to write network games however they see fit while helping to hide some of the complexity. Darkstar does much in this respect too, but in many ways forces you to use their architecture.
Both have their strengths and weaknesses and a decision to use one over the other should be based on how closely your game’s architecture falls in line with the architectural decisions made for the respective framework.
Can you give a little bit of clarification of what you mean by Darkstar bringing industry standardization?
Jeff, I’ve actually done quite a bit with Darkstar and take a little offense at a statement like your opening argument about JGN as I don’t believe you ever took me up on my suggestion to even take a look at it.
I’m sorry you took offense. I tried to hit the high points and focal points.
I didn’t mention that JNAG has been ported to Darkstar, and does the object level over Dakrstar channels, either.
We don’t feel we force much of any architecture on a game, we’re hardly a game engine. We do require you write your server code in an event driven style with fairly short events. Thats about it that I can think of. In return, we take mono-threaded code and make it scale out massively across a large scale back-end automatically. We load balance, and we fail-over. We also make the back end logic automatically persistent and gaurantee referential integrity.
In general, I am afraid that such general characterizations as you have given above can devolve quickly into flame war and opinion and thats not at all where I wish to go. Your proud of what you’ve built. I’m proud of what we’ve built. Thats as it should be.
People should take a good look at the technologies and what they offer both in terms of functionality and in terms of market place. On our end we are more the just a technology, but a technical initiative. We are trying to redefine the market for massively mult-iplayer online games in a way that opens it for small developers. If we are successful, thats another thing to consider.
Once they have done their homework, then they should make an informed decision. partisan voices will be partisan and thats the sum total of it.
fine
I agree, a flame-war is not beneficial to either side and I apologize for my part in working that direction.
Definitely we are both going to be defensive of our own products and if we didn’t agree with the way they were written we obviously wouldn’t have written them that way. 
In many ways that has been my goal as well with JGN. However, somewhat on a more general level my idea was to reduce the complexity of adding network support to games and get all the complex logic out of the game itself and into an abstraction API that handles it for you. I have high ambitions in the MMO realm as well, but definitely have not accomplished as much as Darkstar has at this point. Darkstar’s goals are much broader than mine though and I respect the desire Sun has to go beyond just the software aspects of an engine to helping with the hardware ramifications of the servers necessary. It’s a large step in the right direction toward helping indy projects have a potential of being successful with broader scoped games.
As for as the Indie Developer … ProjectDarkStar I thought wasn’t designed for small systems. In fact, this quote is from DarkStar’s FAQ
A server room is a huge barrier to entry for any small indie shop. Does JGN have such requirements?
Part of the point of SGS, the way it can farm out the work between nodes, means that it’s possible to sell game hosting, like web hosting is sold now. That means that indie developers don’t need any hardware of their own. It has always been said that you can run it on a single node if you wish, but that removes the redundancy and scalability that SGS provides. To scale across multiple nodes, depending on the amount of data that is needed, gigabit network might do the job, but only for a small number of nodes. As your data increases in complexity and size, faster, lower latency node interconnects are needed.
Endolf