hehe, well, since you've already stated you're using Darkstar I won't pitch JGN at you.
A really good and easy way to decrease bandwidth needs and add "predictability" is to do dead-reckoning. Simply put, it's Newton's First Law:
"An object at rest tends to stay at rest and an object in motion tends to stay in motion with the same speed and in the same direction unless acted upon by an unbalanced force."
For basic dead-reckoning you simply need to send across information about forces and such and the client will keep the object moving at that speed and in that direction until told otherwise by the server. In jME-Physics-Networking I go to a bit further extent and use what I like to call "physics-reckoning" 
and send the forces currently acting on them and they continue to move in the physics world on the client in the same way they do on the other clients until it receives a change, but friction and collisions still apply.
You can see some disadvantages of dead-reckoning in games like Battlefield 2 if you lag for any period of time vehicles will slide by you, go through walls, go through the ground, etc. whereas if they were bound to a physics world on the client they would still look normal.
teaster said:
I have read about JGN lot, but it doesn't suite my needs of persistent, fault tolerant massive scalablity - sorry not today Darkfrog :)
I'll leave that one alone. ;)
teaster said:
Hmm sounds like it will sort almost all of my troubles, now it is just a question of should I go with tcp or udp...
TCP would eliminated that I had to make sure that clients knew that the other client is stop.
UDP would be much faster, but I have to make sure that people don't get one message saying " I am here, and walking this way." And then never gets the second message saying "I STOP here" and then when the get another message "I am here, and walking another way" he flies back to that position because of he never received that second message saying "I STOP here".
For me it falls obvious on UDP, more work on the client side but at all less cpu usage on the server and less bandwidth.
However would you like TCP, and if so what reasons do you have in your mind?
Also all secure data is going through tcp.
In general it is best to utilize both UDP and TCP in games as they each have their strong points. I prefer to use UDP for synchronization of objects as it has several advantages over TCP when lag comes into play. I've gone into much greater depths in other posts on here and other forums, so if you're interested just search for more details. However, like you said, you then cannot work in a transactional system, but rather single point synchronization system. This means that every message must contain synchronization information for "now"...not just "move this direction" but this is where the object should be, these are the forces working on it, etc.
The idea here is that it doesn't really matter if you lose a message as the next one will bring the object back up to date positionally and otherwise synchronized. Obviously for things relating to an MMO such as trading and such you would want to use TCP for reliability and guaranteed delivery though.
I know that scripting languages are often used in AI, plugins, etc for fast development and faster customize-able.
I have decided to use Lua for this approach, however I found no information about hacking
WARNING, I'm very tired so the grammar is even worse than usual, if you really don't get what I am saying please wait about 7 hours and I will have my morning coffee and eggs with a rewrite of the most of it sorry for the rubbish writing.
darkfrog said:That is exactly what I wanted to say, just don't have my mind up for it today(15 hours of cheap coffee and school really makes you head spin)
teaster said:
I have read about JGN lot, but it doesn't suite my needs of persistent, fault tolerant massive scalablity - sorry not today Darkfrog :)
I'll leave that one alone. ;)
teaster said:
Hmm sounds like it will sort almost all of my troubles, now it is just a question of should I go with tcp or udp...
TCP would eliminated that I had to make sure that clients knew that the other client is stop.
UDP would be much faster, but I have to make sure that people don't get one message saying " I am here, and walking this way." And then never gets the second message saying "I STOP here" and then when the get another message "I am here, and walking another way" he flies back to that position because of he never received that second message saying "I STOP here".
For me it falls obvious on UDP, more work on the client side but at all less cpu usage on the server and less bandwidth.
However would you like TCP, and if so what reasons do you have in your mind?
Also all secure data is going through tcp.
In general it is best to utilize both UDP and TCP in games as they each have their strong points. I prefer to use UDP for synchronization of objects as it has several advantages over TCP when lag comes into play. I've gone into much greater depths in other posts on here and other forums, so if you're interested just search for more details. However, like you said, you then cannot work in a transactional system, but rather single point synchronization system. This means that every message must contain synchronization information for "now"...not just "move this direction" but this is where the object should be, these are the forces working on it, etc.
The idea here is that it doesn't really matter if you lose a message as the next one will bring the object back up to date positionally and otherwise synchronized. Obviously for things relating to an MMO such as trading and such you would want to use TCP for reliability and guaranteed delivery though.
With Darkstar you got a safe connection directly to the server, which I use for almost anything except data synchronization.
For player locations I have unreliable+unordered channels(They are tcp now, but Jeff said it is on a todo list to make them udp)
The synchronization using 4 variables of float for define its place in space(x, y, z) and angle. The head can't look up or down so doesn't really matter with the last two rotation. Then I have a another variable I can use for tell if it is not moving, moving forward, or moving backwards.
I would really want some insight how you are doing with the controller, when it is necessary to update etc, you really seems to have a great hold on this subject.
very bad example where PC(Player controller) and the Output messages are going out - hope you understand.
PC = Player controller
OUT = Sending message out.
// = comment
PC> Walk forward.
OUT> I am walking forward from x, y, z, w.
PC> Stop walking.
OUT> I am stopped at x,y,z,w // what if this never reaches the other client? You wouldn't possibly know.
Momoko_Fan said:I haven't got much time to look it over but it seems very nice from what I've seen.
I know that scripting languages are often used in AI, plugins, etc for fast development and faster customize-able.
I have decided to use Lua for this approach, however I found no information about hacking Lua as a plugin system nor in java at all, can this be done or I am just wasting my time?
I Saw that something was called LuaJava, which implemented lua intro Java would this be a approach I should try look in?
I also wanted to make my plugin system based on Lua, for faster development and more customize able for other folks - but that that belongs in another topic.
Why do you want to use Lua? IMO there are much better languages suited for game scripting, especially since you're making your game for java, you would want a language that is consistent with it. Also you might want to make the scripting platform indendent of language (there are many scripting languages available)
I have really no reason choosing LUA, I just thought it would be the easiest approach.
I will look into Rhiono? scripting tomorrow - I really need to get some sleep.
Good night folks and thanks for the positive responses.
Lua is commonly used for AI scripting but I don't have any experience with it.
PC> Walk forward.
OUT> I am walking forward from x, y, z, w.
PC> Stop walking.
OUT> I am stopped at x,y,z,w // what if this never reaches the other client? You wouldn't possibly know.
That's why you avoid doing that. Instead of sending out "event" messages you send "synchronization" messages instead. So every N milliseconds you send a message saying "Object 123 is at position x, y, z, w", and who cares if one or even several are lost, as soon as you receive another message Object 123 will be updated to the correct position.
For things like "Fire Weapon" you would send that via TCP because you absolutely must know that reached the server.
...but Jeff said it is on a todo list to make them udp
Good luck with that. :roll:
I'll leave you one thing to consider though. You've stated that we seem to have a very similar grasp on the networking aspects of game development. Those are the core concepts introduced into JGN me being the creator and sustainer of it. Also, JGN already supports TCP and UDP and MANY aspects of MMO game networking as I'm currently developing a MMO myself. ;)
...okay, that's it, no more advertising...at least for tonight. :P
Oh, one last thing to consider. Pnuts is by far the fastest and potentially the most powerful scripting language in Java…give it a look. 
That's why you avoid doing that. Instead of sending out "event" messages you send "synchronization" messages instead. So every N milliseconds you send a message saying "Object 123 is at position x, y, z, w", and who cares if one or even several are lost, as soon as you receive another message Object 123 will be updated to the correct position.
That was sort of my point, that each client sends a event which contains the current location, and what the client is doing(walking/standing doing nothing/backwards) It will be events, there will have to be one thread which insurances that every N ms a message is sent, so nobody keep walking and then when they finally make a event( example walk a bit again) they fly back to their right location.
Good luck with that.My biggest concern is not how soon UDP will replace TCP in the network platform, it is that it has to be very scalable, persistent, and fault tolerant. Darkstar might consume a bit more CPU power pr user than JGN ( Don't know the performances fact so can't tell ) But I really hope that I can get out to the masses with my game ( more than 100k of users on one server )
I'll leave you one thing to consider though. You've stated that we seem to have a very similar grasp on the networking aspects of game development. Those are the core concepts introduced into JGN me being the creator and sustainer of it. Also, JGN already supports TCP and UDP and MANY aspects of MMO game networking as I'm currently developing a MMO myself. Wink
...okay, that's it, no more advertising...at least for tonight. tongue
My limit resources makes this possibly when developing even future.
Oh, one last thing to consider. Pnuts is by far the fastest and potentially the most powerful scripting language in Java...give it a look. Wink
Who's nuts? hehe I will also look into that, however I see one very big advanges when choosing LUA - Instead of save options, you can just add information to the script because it is so easy.
But I definably look into Pnuts if it is free :)
Anyway amazing you could read my text, I had a very bad day yesterday, one of those days where everything just goes wrong.
Day before I was lowering my radiator, but it was so dark when so I turned the wrong way, so woke up 2 hours later in 35degress and all sweety.
When I woke up in the morning I went to my fridge, and drank like 0.5l of milk, only to find out that the rest I couldn't drink because it was clumpy and nearly throw up.
Then I found out that I forgot to change from summer time, and I woke up 5 o-clock instead.....
Thanks again :)
Teaster
In JGN everything is non-blocking (since the networking is non-blocking I figured the API on top of it should be as well) so you can actually do synchronization and all other communication in your game thread in JGN if you so desire or you can split it out into five-thousand different threads.
darkfrog said:
In JGN everything is non-blocking (since the networking is non-blocking I figured the API on top of it should be as well) so you can actually do synchronization and all other communication in your game thread in JGN if you so desire or you can split it out into five-thousand different threads.
The issue is when the server is not enough to handle all the request, not because of bandwidth but because of CPU power.
When that time comes for Darkstar it will be theoretical possibly to install Darkstar on a new machine and connect it as a node, and make it clustering.
This could be done with JGN too, but it is all automatic in Darkstar.
sorry Darkfrog :)
I don't care…one less user I have to support. 
…I mean 
teaster said:
darkfrog said:
In JGN everything is non-blocking (since the networking is non-blocking I figured the API on top of it should be as well) so you can actually do synchronization and all other communication in your game thread in JGN if you so desire or you can split it out into five-thousand different threads.
The issue is when the server is not enough to handle all the request, not because of bandwidth but because of CPU power.
When that time comes for Darkstar it will be theoretical possibly to install Darkstar on a new machine and connect it as a node, and make it clustering.
This could be done with JGN too, but it is all automatic in Darkstar.
sorry Darkfrog
Darklord said:After you learn how the platform works, it is easy, and when your MMORPG needs to scale out, you just install linux(my choice) on a new computer, and install java, c/p the classes of the game. And start Darkstar, then it will automatic find other nodes in that cluster and attach them together. That is how Darkstar is meant to be, but the multi node software haven't been released yet.
teaster said:
darkfrog said:
In JGN everything is non-blocking (since the networking is non-blocking I figured the API on top of it should be as well) so you can actually do synchronization and all other communication in your game thread in JGN if you so desire or you can split it out into five-thousand different threads.
The issue is when the server is not enough to handle all the request, not because of bandwidth but because of CPU power.
When that time comes for Darkstar it will be theoretical possibly to install Darkstar on a new machine and connect it as a node, and make it clustering.
This could be done with JGN too, but it is all automatic in Darkstar.
sorry Darkfrog :)
Actually, and I speak unbiased even if my name resembles to some other member on this forum , I think JGN could be a very handy and lightweight tool when it comes to clustering. Im not sure -how- automated clustering is in Darkstar but it's not that hard as you're thinking. The only reason I would switch to Darkstar is if you have large-scale game such as a MMORPG where you need a safe transactional system.
Still, i'm curious what your experiences with Darkstar are.
All of Databases, Synchronization, etc is Darkstars problem and not yours.
The way you program on is that you get callback when Receving a message, Loggin in, loggin out.
Users obvious has to have information, and you get them through a data manager that makes them persistent, and synchronized.
Darkstar is still immature if you ask me, but as with Java from sun there are very few bugs(actually never heard of anyone critical)
I bet JGN is 10 times better to a FPS game with 30-100 players, but after that you have really bad scale problems.
Darkstar is more for major servers, example a poker game where thousands of players should play in separate games, or in a MMOG.
I can only guess of JGN, since I got no experience.
Teaster
darkfrog said:
For things like "Fire Weapon" you would send that via TCP because you absolutely must know that reached the server.
Just a thought, why not send the current animation index of the player every synch packet via UDP? Its just another single value, and from that the other side can figure out if the player "Fires weapon", "Crouches", "Runs", or whatever.
teaster said:
I can only guess of JGN, since I got no experience.
Then you really shouldn't make statements like:
teaster said:
I bet JGN is 10 times better to a FPS game with 30-100 players, but after that you have really bad scale problems.
Especially when they are outright incorrect. In fact, scalability JGN will scale BETTER than Darkstar. I know what you're thinking, "How can he say that?". What a good question (going into sales-pitch mode since you keep talking down JGN when you have no clue what you're talking about)...yes, there are many aspects that Darkstar can handle for you without you having to worry about it, but performance "per player" is significantly better because of how light-weight JGN is in comparison to the bloatedness of Darkstar. Darkstar you can scale over dozens of servers, but JGN you can do the same and get more bang for your buck per server.
I know, you're thinking, "Wow that's GREAT!", but I'm not done yet. JGN doesn't bind you to any pre-conceived and ill-carried out notion of how clustering should be done or make bold promises of things like UDP support that is planned (and has been planned since day one of Darkstar....years and counting), it actually provides that functionality. JGN DOES provide support for clustering for you, but you could always re-write or re-configure if you don't like the way it handles it. JGN is significantly faster per-message than Darkstar even on TCP to TCP comparison. Further, JGN supports compression, encryption, synchronization (built-in so you type maybe three lines of code), synchronized objects, shared objects, multiple Input/Output streams via a single connection or even using InputStream/OutputStreams on a UDP server. You can even do guaranteed delivery, guaranteed ordered messages in the UDP aspect of JGN. You could run everything through UDP an never have to worry about a single lost message. You can run realtime messages (messages that get dropped if they are duplicated so you never have to worry about wasting bandwidth on messages you no longer care about), time sync'd messages (messages that contain the local time they were sent from the remote server on your machine's local time), and there's dozens of other features that I haven't even broached.
I was willing to let you poke the little jabs you've made at JGN up until you said "really bad scale problems". I just won't have that being said about JGN. :P
If that's not good enough I'd be happy to put my money where my mouth is and say that given a simple example (I don't have time for anything more complex at the moment) in Darkstar I can guarantee I could develop an implementation in JGN that will exceed the performance, reliability, and use less code to write than is POSSIBLE to do in Darkstar.
Okay, finished with my rant. :)
teaster said:
All of Databases, Synchronization, etc is Darkstars problem and not yours.
The way you program on is that you get callback when Receving a message, Loggin in, loggin out.
Users obvious has to have information, and you get them through a data manager that makes them persistent, and synchronized.
[/quote]
if thats the case then all of the banks will be dropping ejb's and their current systems in favour of darkstar
darkfrog said:
Ranty mcRant'em
I love your charming little rants as much as the next person (I find them adorable ;) ) but is there actually any empirical evidence of the performance/reliability/scalability of either API?
I'll admit I've never checked for such evidence because frankly I don't really care :P
There are stress tests in JGN that show the ability to send over 1 million messages per second (on a local network) but that's the only official performance testing I've done. The rest has been internal testing for my own purposes. Such is why I was offering to match against anyone willing to take the challenge and develop something in Darkstar and benchmark both examples and show how much faster JGN is.
Quote from: teaster on November 07, 2007, 05:29:03 PMSorry not entire true I actually used it a little but got worried by scaling issue(some time ago)
I can only guess of JGN, since I got no experience.
Then you really shouldn't make statements like:
Especially when they are outright incorrect. In fact, scalability JGN will scale BETTER than Darkstar. I know what you're thinking, "How can he say that?". What a good question (going into sales-pitch mode since you keep talking down JGN when you have no clue what you're talking about)...yes, there are many aspects that Darkstar can handle for you without you having to worry about it, but performance "per player" is significantly better because of how light-weight JGN is in comparison to the bloatedness of Darkstar. Darkstar you can scale over dozens of servers, but JGN you can do the same and get more bang for your buck per server.
If you ask me darkstar is far by bloated. It is heavy weight because there is lot of code but it is not bloated.
Also how could you scale out on more servers with JGN? remember all this is done automatic by the Darkstar platform.
I know, you're thinking, "Wow that's GREAT!", but I'm not done yet. JGN doesn't bind you to any pre-conceived and ill-carried out notion of how clustering should be done or make bold promises of things like UDP support that is planned (and has been planned since day one of Darkstar....years and counting), it actually provides that functionality. JGN DOES provide support for clustering for you, but you could always re-write or re-configure if you don't like the way it handles it. JGN is significantly faster per-message than Darkstar even on TCP to TCP comparison. Further, JGN supports compression, encryption, synchronization (built-in so you type maybe three lines of code), synchronized objects, shared objects, multiple Input/Output streams via a single connection or even using InputStream/OutputStreams on a UDP server. You can even do guaranteed delivery, guaranteed ordered messages in the UDP aspect of JGN. You could run everything through UDP an never have to worry about a single lost message. You can run realtime messages (messages that get dropped if they are duplicated so you never have to worry about wasting bandwidth on messages you no longer care about), time sync'd messages (messages that contain the local time they were sent from the remote server on your machine's local time), and there's dozens of other features that I haven't even broached.
I have never disagreed that JGN is faster on one node, I said that Darkstar will scale better because it is automatic done.
You can split your game in zones, which are using channels, Darkstar finds out how to best optimize them on each node, and if a node fails another will take over.
I was willing to let you poke the little jabs you've made at JGN up until you said "really bad scale problems". I just won't have that being said about JGN. tongueSorry I should have said something like "JGN scales out well on one node, but if you need it to scale over a cluster you might have to reprogram lot of code."
If that's not good enough I'd be happy to put my money where my mouth is and say that given a simple example (I don't have time for anything more complex at the moment) in Darkstar I can guarantee I could develop an implementation in JGN that will exceed the performance, reliability, and use less code to write than is POSSIBLE to do in Darkstar.
A application with Darkstar you could do as low as 10 lines.
if thats the case then all of the banks will be dropping ejb's and their current systems in favour of darkstar
Theoretical they could when the multinode release is released, however I doubt they will for some time since it is too expensive.
There are stress tests in JGN that show the ability to send over 1 million messages per second (on a local network) but that's the only official performance testing I've done. The rest has been internal testing for my own purposes. Such is why I was offering to match against anyone willing to take the challenge and develop something in Darkstar and benchmark both examples and show how much faster JGN is.As I said before I never doubt it will be faster on one node, Darkstar is primary created for Massive games which needs to be Scaleable over multiply nodes, persistent, and fault tolerant.
You can kill the Darkstar task and then start it again, and then all is back to the same.
if we are talking about a persistent, fault tolerant server I take that challenge.
I got no absolutely no doubt that Darkstar is the right choice for a MMOG!
And I got absolutely no doubt that JGN is the right choice for a non massive.
I didn't mean to talk down about JGN, but you use the tools needed for that specific sort of problem you got, I don't think JGN would be good to a major MMOG. - Remember not native English, got some troubles explaining my self.
Teaster.
teaster said:
-->if thats the case then all of the banks will be dropping ejb's and their current systems in favour of darkstar
Theoretical they could when the multinode release is released, however I doubt they will for some time since it is too expensive.
Hmm - how much do you think they pay IBM for WAS
If you're paying Sun LOTS of money it might be moderately "invisible" to you the way they cluster, but there are still servers that have to be configured and set up. I am not debating the performance of JGN for non-MMO games, I'm debating explicitly in MMO games. I say JGN will scale better, run more efficiently, and require less code to write an MMO game than will Darkstar.
How much work have you done with Darkstar? I stand by my statement that it's bloated.
If you need to scale over several servers with JGN it's actually not much code at all to do so. In fact, there is a clustering system I've been developing for some time and plan to release in the near future that makes it even easier and "automatic" for clustering and fail-over.
I don't want to turn this into a flame war. I'll just end by saying I think you might reconsider some of your statements once you've had more time to work with Darkstar.