Hi Guys,
I see there has been a lot of interest in Darkstar, and a lot of guess work and half-understandings.
Although our primary forum home is over on JGO, I'll try toi monitor this thread as well so I can get real and correct information out to you.
One early thing to clear up "Project Darkstar" is technically the name of the project. The SGS is technically the name of the server that is being developed by the Project Darkstar team.
In practice however most pelple just call the SGS "Darkstar" as kind of a nick-name. Hope that makes that relationship a bit clearer.
Jeff Kesselman
Chief Darkstar Architect
Jeff,
Thanks for dropping by. Please keep the updates and info coming. I'm sure there are quite a bit of things getting lost in translation and there are many people here with an interest in the project.
Would be nice to get a JME example up and running in the framework perhaps
yes it would.
The EA stack was shipped with a J2ME API done and there have been some interesting things done in the field.
(eg http://www.youtube.com/watch?v=yI54azrcuOM )
We did not have time to get the J2ME API out for the 0.9 stack at GDC, but its coming.
Bunny Hunters would probably port nicely to a MIDP2 phone 8)
jeffpk said:
We did not have time to get the J2ME API out for the 0.9 stack at GDC, but its coming.
Bunny Hunters would probably port nicely to a MIDP2 phone 8)
Think he meant jME as in JMonkeyEngine... nice to know J2ME is coming though :)
Oh!
Well, Bunny Hunters is Slick, which is on top of JME. I know about some proprietary work thats been done on 3D games but I'm not at liberty to share that 
Biggest issue really is the art requirements for a 3D game. I have in mind to port my NWN loader for Java3D to JMonkey when I have a chance and that will open some options I think…
Edit: Endolf correctly points out the Slick is directly on top of lwjgl, not JME. So although they share a common underpinning, Slick is not JME based.
No promises, but I will make the attempt to port my ugly-as-sin, work on it in my spare time, code that uses Apache Mina, with a JMonkeyEngine client, over to Darkstar before JavaOne. I'll let you know how it goes… if it goes.
I did notice that the Darkstar SDK had Mina jars in there…
Yes, we're currently using mina for our low level transport code. Be aware that this is an implementation detail that could change.
jeffpk said:
Yes, we're currently using mina for our low level transport code.
I've just read the license for Darkstar:
a. License grant. Provided you are in compliance with this Agreement, Sun grants You a limited non-exclusive license to use Software for internal non-commercial purposes for a period of one hundred eighty (180) days after the date You first acquire, access, download, use, install, or open the packaging of, Software.
So if we spent X number of years developing a game (which we can't even according to this) then in the end we can't publish it without paying X
number of $s for a license ?
Depending on the value of that X we could have wasted our time. What if it's millions or just thousands ? I don't mind paying for a product at all but some amounts
are not payable.
I know that you have a vaguely specified philosophy about hosting our games and then we split the profit or something. But what can we REALLY be sure of ?
EDIT: ps the download link https://games-darkstar.dev.java.net/L2.html is broken
EDIT2: Just read on your forum that it's now Open Source ? So I guess that makes everything I said false ?
Baune said:
EDIT: ps the download link https://games-darkstar.dev.java.net/L2.html is broken
In general this is caused by a temporary problem at java.net. If it fails try hitting reload.
EDIT2: Just read on your forum that it's now Open Source ? So I guess that makes everything I said false ?
Yes and no. I *think* this is in the FAQ but if not it probably should be.
Open Sourcing something takes some time at Sun, its a fairly involved process. We wanted to get the binary otu ASAP so we released that with the license you see. That license is temporary and as soon as we can get the Open Source version out the door will be replaced by an Open Source license.
Hi all!
I just wanted to mention that I have been hacking on Darkstar and jME over the past week or so and I have a prototype of them working "sorta". By "sorta" I mean that the way I am currently driving the jME simulation on the server side would probably be considered a hideous hack. I would love to hear some opinions straight from the frog's mouth regarding the best way to handle something like this.
I just recently noticed the JGN stuff, and I think it might be interesting/possible to make it run on top of Darkstar which might be prime, at least for people that are interested in the Darkstar back end.
Let me discuss briefly what I am doing currently. Please note that this is just my first attempt at proof of concept, not what I would consider an optimal solution.
The Darkstar server boots, starts up an instance of the jME simulation (This is the hacky part, Ill get to that later) and loads up a terrain and places a few random boxes for fun.
jME client connects, it receives a message to load a terrain, goes out and snags the model from a URL, loads it, and drops the player in where the server says to do so.
On the server side, a state machine tracks the clients current movement request, like Forward, Backward, TurnLeft, TurnRight, and updates the server simulation based on what movement the client is requesting. Right now on the server simulation I am tying these back to a subclass of com.jme.scene.Node which overrides updateWorldData() to handle various position updates. (Ok, that is probably dirty hack number 2). The server objects send translation and rotation events back to the client which it then applies to its simulation. No client side prediction at this point so it makes for a really jerky ride, but like I said before, it is a proof of concept.
Ok, now for the fun part!. There is really no way to start a thread inside Darkstar, and of course this is for good reason. Perhaps this will change once Jeff releases the stack extension manual :D. What Darkstar can do is run a task at a specific interval, So what I did was essentially take the SimpleGame class that runs in headless mode, and convert the run() method to something that can be triggered by a Darkstar repeating task. Right now, I think I have the simulation updating every 100ms. Of course to do this, there is a little bit of thread related voodoo regarding locks and various GL stuff that I had to comment out, but I believe this may not really be a problem, since the server does not display anything.
I will try to get a downloadable client to play with here pretty soon, but time is a bit tight this week.
Well, I've said it before and I'll say it again. Positioning of objects based on actions is VERY VERY BAD! :P If for whatever reason it gets out of sync then it is permanently out of sync.
That said, I'll outline what JGN's "recommended approach" is for scene-graph positioning in networking:
- Use UDP when possible
- Fire RealtimeMessages (these are messages that only one can exist at a time in any queue for an object, so if there is a duplicate only the newest created will be kept)
- Use positional synchronization instead of events - this way you can drop 50 packets and the 51st brings you back up-to-date
- Synchronize based on proximity - You care less about objects further away from you being in sync than you do about objects that are closest to you so JGN provides a mechanism to adjust update frequency based on proximity
- Prioritize based on relevence - Yes a crate in a scene is important if you keep running into it, but another player right in front of you is more important since he's likely to kill you
- Someone is authoritative and everyone else should listen to him - In JGN you can register scene graph objects either authoritative or passive listeners for updates. Authoritative will send out the updates for positional information and the passive listeners will just accept this information (see below for clarification for client/server)
- Server is the absolute authority - JGN provides functionality for validating every synchronization change that occurs in a scene-graph and it's up to the game developer to validate whether this is a "valid" update, a lag glitch, or a "hack" attempt and to respond approprietly - all clients are designed to "submit" when they are corrected by the server for any mistakes they make
This is a very quick overview of the way JGN's scene-graph synchronization system works (granted the core of JGN forces none of these rules so you are never forced to do it one way).
Well, mostly i agree.
I wouldn't put some of it in such absolute terms.
There is always a trade off between verisimitude and snappiness of the simulation and security. the mroe you can decide at the appropriate point on the clients, the better response will seem. A great example is a first person shooter. Only the shooter really has any idea if the target is on or off reticle, so in an ideal cehat-free world yould make that decision on the shooter's machine.
HOWEVER clients are inherently insecure. So making game critical decisions at the client can open you to serious cheating. Some of the best strategies involve decision making at both places. The feedback to the user is based on the local state but anything it claims is checked for correctness on the server. One place you see this sort of approach a lot is in collision-detection.
Limiting communication resolution by distance generally works well in a game that is rendering in3D perspective, but not very well in a top down game. Every game type has some kind of heurestics you can take advantage of to reduce traffic. The trick is to use the appropriate ones to your game form.
If a game is not lock-step, I agree you probably want to communicate not just positiuon, but also vector of motion and any other data that is useful for motion prediction. A lock step game however can get away with lower level communication and save bandwidth in ist communication. Bunny Hunters, which I am just completing, is such a game.
I dont agree with TCP fear. if what you are doing really is losable data then you can use UDP, but its always the case that there is some critical data. You don't want to lose damage information for instance. In order to handle this in UDP, people start implementing re-try strategies and before they know it have re-implemented a bad TCP. And thats a losing strategy.
The net is tuned for and understands real TCP so use it when yo uneed reliable data. And if you have to use it for some of your data, ask yourself what your really getting for the complexity of having two different ways of communicating data in your code.
Finally, while you CAN run your whole game off a tick in Darkstar,and in some instances you might have to, its an inefficient way when compared to event driven strategies. You might want to ask yourself what the server really has to do and how much of it can be free running and event driven.
MMO RPGs, for instance, typically run most of the game free and event driven and only go to a hard tick for combat.
darkfrog said:
Well, I've said it before and I'll say it again. Positioning of objects based on actions is VERY VERY BAD! :P If for whatever reason it gets out of sync then it is permanently out of sync.
That said, I'll outline what JGN's "recommended approach" is for scene-graph positioning in networking:
- Use UDP when possible
- Fire RealtimeMessages (these are messages that only one can exist at a time in any queue for an object, so if there is a duplicate only the newest created will be kept)
- Use positional synchronization instead of events - this way you can drop 50 packets and the 51st brings you back up-to-date
- Synchronize based on proximity - You care less about objects further away from you being in sync than you do about objects that are closest to you so JGN provides a mechanism to adjust update frequency based on proximity
- Prioritize based on relevence - Yes a crate in a scene is important if you keep running into it, but another player right in front of you is more important since he's likely to kill you
- Someone is authoritative and everyone else should listen to him - In JGN you can register scene graph objects either authoritative or passive listeners for updates. Authoritative will send out the updates for positional information and the passive listeners will just accept this information (see below for clarification for client/server)
- Server is the absolute authority - JGN provides functionality for validating every synchronization change that occurs in a scene-graph and it's up to the game developer to validate whether this is a "valid" update, a lag glitch, or a "hack" attempt and to respond approprietly - all clients are designed to "submit" when they are corrected by the server for any mistakes they make
This is a very quick overview of the way JGN's scene-graph synchronization system works (granted the core of JGN forces none of these rules so you are never forced to do it one way).
I think it's misleading to only say scenegraph synch..as you can sync anything you want..no graphics is required.
jeffpk said:
I wouldn't put some of it in such absolute terms.
That's why I was saying "recommended" and that you are by no means bound to that design using JGN.
jeffpk said:
HOWEVER clients are inherently insecure. So making game critical decisions at the client can open you to serious cheating. Some of the best strategies involve decision making at both places. The feedback to the user is based on the local state but anything it claims is checked for correctness on the server. One place you see this sort of approach a lot is in collision-detection.
I agree. In fact, the game I'm currently developing utilizes this through the jME-Physics (ODE) and gains the benefit of getting (essentially) dead-reckoning on the client machine for free, but the server is also running the physics as well and can validate that the client isn't breaking the rules.
jeffpk said:
I dont agree with TCP fear. if what you are doing really is losable data then you can use UDP, but its always the case that there is *some* critical data. You don't want to lose damage information for instance. In order to handle this in UDP, people start implementing re-try strategies and before they know it have re-implemented a bad TCP. And thats a losing strategy.
It was not my intent to convey "TCP fear". I believe in quite the opposite. In JGN specifically the recommended approach (with the JGNClient and JGNServer system) is to use both a "reliable" and a "fast" messaging connection (TCP and UDP). I believe in nearly all games these should be utilized together to gain the most in game performance. We were specifically talking about scene-graph positioning so I was explaining the recommended approach there. In that situation UDP can be far superior not so much because it has less overhead, but rather in the flaws of UDP becomes its advantage. The fact that messages can and will be lost because they are not guaranteed helps in situations of lag spikes or networking issues. With TCP you have a lag spike or connection issue you are stacking up packets that once the connection is stable again streams all of that information through that then has to be processed thus increasing the game lag because of the delay that is created before it is back on track. I do agree with you though that TCP is the best approach for anything necessary to be reliably delivered (however, JGN does also support that "bad TCP" you mention as it provides built-in functionality to guarantee delivery and order of delivery for UDP).
jeffpk said:
MMO RPGs, for instance, typically run most of the game free and event driven and only go to a hard tick for combat.
I'm currently developing a MMO game, but quite different than the normal design of a MMO. In fact, for all practical purposes it's a real-time game and MMO running in one. The server essentially has two systems running for their respective handling and deals appropriately to handle the security aspects of MMO but also manages the real-time nature for fast-paced dogfighting.
Baune said:
I think it's misleading to only say scenegraph synch..as you can sync anything you want..no graphics is required.
Again, this was in the context of the question asked. JGN does support synchronization of objects apart from a scene-graph or even a game. In fact, someone the other day decided not to use the synchronization system at all and decided to use SharedObjects (a portion of JGN that allows you to create an object on one machine and it gets shared to all connected machines and any changes from any connection synchronizes to all machines dynamically) to manage scene-graph elements instead. Personally I had never considered the idea of doing that, but they seem quite happy with it. JGN is designed to be extremely flexible and really isn't even required that it be used for game development, although that's the primary focus it was designed for.
darkfrog said:
It was not my intent to convey "TCP fear". I believe in quite the opposite. In JGN specifically the recommended approach (with the JGNClient and JGNServer system) is to use both a "reliable" and a "fast" messaging connection (TCP and UDP).
my apologies then
I believe in nearly all games these should be utilized together to gain the most in game performance.
So we do differ some here. A lot of it depends, to my mind, on the other constraints of your game.
For instance, if you intend to support analog modems you are stuck with the reality of up to 6 second pauses in communication of *any* kind while modems retrain. You have to design your game to handle those, in which case TCP pauses are in the noise and don't really matter much.
jeffpk said:
darkfrog said:
I believe in nearly all games these should be utilized together to gain the most in game performance.
Ok, let's be honest here - is anyone really designing MMORPGs or even FPS type games for people still using dial-up?
That is true, but I think he still does have a valid point. I think what he was trying to convey (granted not with a very normal circumstance) is that there are circumstances outside the bounds of normal game best-case scenario. This is why I say "nearly all games" instead of "all games" though. :)
I think the valid point that I take from this is that a networking engine (Darkstar, JGN, or anything else) needs to be able to support any circumstances that a game might have and not force something on them that doesn't work for their scenario.
chirstius said:
jeffpk said:
darkfrog said:
I believe in nearly all games these should be utilized together to gain the most in game performance.
So we do differ some here. A lot of it depends, to my mind, on the other constraints of your game.
For instance, if you intend to support analog modems you are stuck with the reality of up to 6 second pauses in communication of *any* kind while modems retrain. You have to design your game to handle those, in which case TCP pauses are in the noise and don't really matter much.
Ok, let's be honest here - is anyone really designing MMORPGs or even FPS type games for people still using dial-up? Seriously?
Yes.
A great many commercial MMOs still support dial-up. There are large parts of the country still where broadaband isn't common.
For instance, I regularly play CoH with someone on dial up.