Hi monkeys,
Like the title says what i’m going to asking there is just a proposal i wish will be well accepted 
I made this post because there aren’t many resources over the Internet and in the forum about how to make an acceptable real-time syncronization networking architecture, and MonkeyZone does not do a job in this way, because is really complex as a start point to understand this kind of architecture just seeing the code. So, IMHO, will be vary EXTRAORDINARY if the core team (or other contrinutors) develop a little kind of multiplayer FPS very simple that needs a week or 2 to be developed. Maybe also well documented and explained with comments at every row of code XD.
Some days ago there where a tread about a collaborative game developed by the JME members and the core team explained that this role was destinated to MonkeyZone. Maybe this kind of game will attract more users and for what i’ve seen, when a newby programmer like me looks for a game engine, a well explained tutorial-style game like a multiplayer FPS could be a good showcase to valuate the features of the engine because this kind of games are the most difficult to develop for many reasons that you well know 
But first of all, this game could be a good entry point to learn networking architectures and every aspects of real-time syncronized games, wich is IMHO the hardest part of the development to a inexperienced programmer.
So, what do you thik about this idea?
PS Like always, sorry me for my terrifying english XD
There actually is a lot of documentation out there but I don’t mind your well-planned attempt to get some FPS code fee free 
Ok, so you know how to get the theory behind a real-time mirroing engine right?
Please give me the links or the title of a book published not before 2008 (in my professional experience, after 3 -4 years a technology is considered old and books that talks about how to nuild a technology too) and don’t post the usual valve software page.
However my intent is to learn, and because i think this kind of games is really difficult to be developed whitout a good knowing of sync algorithms and theory, i am not able to develop this right now. But with you help, i hope, this topic could be more and more easy to understand
In terms of software what you say isn’t exactly true. Some concepts can only be implemented years later, most established concepts hold for years. Also, why play the blowfish? You were talking about a “little FPS example” and not cutting edge 256-player FPS network code. The knowledge in the “usual valve papers” is base knowledge for that as well and if you know it I don’t know where the conceptual problem lies?
Have you looked at the work being done on MirrorMonkey?
Yes, i looked it, but it is still a work in progress and waht i'm looking for is the implemetation of MirrorMonkey, and anyway i what something that explain how to implement this kind of system and a book of 800 pages ( XD ) that covers the theory behind the strategies of the implementation
Also, why play the blowfish? You were talking about a “little FPS example” and not cutting edge 256-player FPS network code
Sorry me but i don't understand idioms so can you tell me what " why play the blowfish?" means please?
The knowledge in the “usual valve papers” is base knowledge for that as well and if you know it I don’t know where the conceptual problem lies?
Sure, it is true, but this topics can't be covered in 2 html pages that explain something like the 2% of the topics. And i'm not an experienced user of JME so it is really difficult to me to develop the concepts explained.. What I am asking for is a good tutorial made by good programmers that well know the engine and how to design and implement complex mechanics...
A blowfish is suddenly bigger than before when it feels threatened. The concepts are outside the scope of the engine really, you could synchronize anything based on how your game looks. I also agree that MirrorMonkey gives a very good example and is basically exactly what you’re asking for.
I don’t play the blowfish, ahahahah You didn’t post some resource that match what i’m looking for. However, I hope that MM will be released soon so i could learn what i’m looking for. Just the last question:
The little sync framework i’ve developed for my porpose simply does the following:
A InputHandler object process the input and sends it to the server that applies data and broadcasts the new object state to all clients. What has blocked me was the development of an action handler server-side. For example if i press left mouse button, a “shoot” action is sent to the server that again broadcasts the action to clients, but this action start a process for what a “cannonBall” is shot and if it collide with an enemy it will damage those.
The question is:
Where have i to simulate the cannonball?
Have i to compute the cannonBall impact on the client that lunched it and send the result to clients?
Have i to replace the scenegraph on the server and sync every object in it?
These questions made me think:
“Well, this is really hard stuff, maybe some JME guru could help me or maybe makes some tutorial-game code that will be helpful for every other programmer that stumble with this topic”
I am thinking about this issue too. But since i am not yet at the point of implementing network code i have time to look at the result of this thread.
My idea is to syncronize only player inputs. As long as no random game events happend each client can calculate all independelnty. This would keep the network load low. But i am not yet sure if it’s possible to fully synchronize all player inputs.
@kazeshiro
If it’s actually theory you’re interested in, then you can check out the links on this page: Reddit - FPS Game Networking Models
NOTE: The Q3 Networking Model linked in the page is down at the time of this post. Here’s an archive of the site from (web.archive.org). http://web.archive.org/web/20110718080312/http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
I know you said you didn’t want anything pre-2008 but there’s a reason you can’t find much of anything newer than what i’ve posted… It’s because these are tried and true methods that are still in use today by the industry leaders in FPS development. The interesting thing is that if you actually read the articles that are linked, you’ll notice that most of these different studios were developing their netcode in parallel timeframe’s (especially id and valve) and they essentially came up with the same theoretical model just implemented in a different way. So that has to tell you something…
Not to offend you but based on your posts it seems to me that you’re one of the following:
a) Impatient and lazy
b) A copy-paste coder with no real understanding of the systems you interface with
c) A newbie that just wants quick results to stay motivated
Although the ‘c’ type isn’t necessarily bad, with the approach you’re taking to this whole thing it will lead to you being a ‘b’ type.
CHALLENGE
I think the best way to learn is to teach (especially when dealing with theory), so I challenge you to read the articles at the link that I supplied and come back to this thread (or start another if you like) and teach US the theory behind the common FPS networking model. It doesn’t have to be ultra sophisticated at first, just a basic summary of the model that is clear to everybody.
-Feen
AHAHAHA to tell the true i am all of three!!! XD
a) Surely i’m impatient because i’ve not so much time to spend learning game programming, university and job releted studies take me most of my spare time 
And lazy forever!!! XD
b) This is true for some aspects in the sense that it is not in my interest udestand for example the system behind nifty gui… some topic doesn’t motivate me enough to spend little time i have. The same is for shaders and 3d souds… But things like AI, networking and physics are really iteresting to me and i want to be able to write this systems myself (it’s an italian idioms to say that i really want to have a good knowledge )
c) this is true for the same reasons explained below, time is my enemy!!!
However, I start this topic just for the reason that IMHO, a tutorial-game that everyone wanna do could be a good idea… And sometimes I felt a little hurted by the answares posted… But what i’m looking for is only a good and rapid way to learn a difficult topic and not well documented by books or others resources. A 800 pages book could be the best solution to really understand the theory behind real time sync and if it is accompanied with a good source code, the mission is reached!!
I will take a look at the links but there are many other topic about this problems and if instead of said the same things 43243252 times, all of you gods of the code wrote a “Tips and tricks” about the implementation with SpiderMonkey, everyone would be happier XD
Thanks a lot for the links
I’m really bogged down with clients at the moment, but after I get some free time I may try to put something like this together. Don’t hold your breath though, because atm there is no end in sight for my current work.
-Feen
I really hate having to manually quote so this will be it, I think.
Where have i to simulate the cannonball?
Depends on the type of game you are writing.
Have i to compute the cannonBall impact on the client that lunched it and send the result to clients?
Depends on the type of game you are writing and the answer to the first question. Though the client-side approach means that you will allow cheating. The server must run the simulation and be authoritative if you do not trust the clients.
Have i to replace the scenegraph on the server and sync every object in it?
No. Even if the server is handling the simulation you only need to sync the moving stuff. Scene graph != game objects even though JME tries to encourage that. Scene graph = things you render. Game objects = things you simulate.
These questions made me think:
“Well, this is really hard stuff, maybe some JME guru could help me or maybe makes some tutorial-game code that will be helpful for every other programmer that stumble with this topic”
As you say, this stuff is really hard. To create a tutorial game would probably take such a guru about two weeks of pretty solid coding... then you'd end up with MonkeyZone basically, with respect to how documented it is. Then there's another month or more of writing the documentation at a level that someone who couldn't just write their own would understand. Because it's very hard. And just as hard to explain.
I may put something together after Mythruna is done (read: a very long time from now)... other than that, I can discuss my freelance contracting rates. I'm not trying to be mean, but I'm essentially working two jobs right now and can't afford to work a third for a month and a half for free.
If you look for books, lower your expectations on publish dates and just make sure to look for something that talks about using UDP. Bonus points go to books that specifically mention the Valve docs or id implementations. As Feen mentions, these architectures are pretty solid and well known by now. The valve docs read like a three-layer dip of "exactly how you want to write a real-time networking game". Mythruna only uses the first two "layers" of that dip.
And if you can't figure out how to apply those kinds of game books to JME then you may need to revisit this idea when you know Java better. It can be frustrating but really 3D networked games are one of the most difficult forms of software to write. That kind of expertise is tough to explain in a few tutorials. I've been coding for more than 20 years now and I still had to read the valve docs three times (and take notes) before I really got all of the little nuggets of wisdom in there.
And for anyone else stumbling upon this thread, here are the links referenced:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization
Ok, i have read some documentations from id, valve and quake.
I’ve tried to extract some common factors of this implementations and what i’ve found is that the best approach for this architecture, considering somethings like avoid cheating, sync the game time and meny other things, is an authoritative server where all game logic is computed making the other clients mere renderes. What i have in mind is:
A client that deals only with rendering and handling input that is sent to the server;
A unique server that runs a physics simulation that every physics tick sends an update of the whole game state (players position, players hp, etc…) through UDP messages (for velocity) something like 30 times per seconds,
the server has also to run the game logic and process clients input.
Pratically all players trigger the button to move around the arena, the clients handle those input and send reliable ActionMessage(s) to the server,
the server processes the input and compute the next simulation,
after the physics simulation has been completed the game logic is applied (if a cannon ball collided with a player the server subtrackts the player’s hp),
the server broadcasts the new game state to all clients,
the clients update the local game state and render it.
Do you think this kind of architecture may be a good implementation?
Obviously some clients prediction is nedded, though i don’t know right now how can be made…
Surely there are many conceptual improvements that must be done in a real multiplayer action game but IMHO this can be a good start point (before the optimization process ) because there are many issues that are avoided in this way: cheating, all updates are sent at the same time, in a futuristic vision the GPU-Server can computes all updates in a GPU loaving the CPU free of process all game logics and handle networking XD, and maybe many others…
What do you think about it???
And the key is time based buffers. Your client rendering will need to be rendering the past just slightly… so you need to keep a buffer of the specific events you’ve received and then interpolate rendering frames. That way your rendering speed can be at a different rate than the network data that you are receiving.
…though, I’d do like valve and buffer state. Say, run physics at 60 or 50 FPS but only send a buffer of state 20 times a second… using UDP. The client then uses this to add to the end of its buffer and the render loop interpolates between known values based on its current time.
I don’t think I’m explaining it very well but it works out pretty smoothly.
Yes!!! This was exactly what i was traing to say!! Damn my english!! XD
However this is the way i thought it. But the only thing that i don’t know how to implement is the client interpolation
I’ve seen the interpolateTransform() methond in javadoc and tried to use it but it seemd like no moving stuff was going on… And maybe, it is insufficient to do only an interpolation on the trasform of a player. Another things really difficult to do smoothly the correction af a position, because maybe in the time the smooth process is done (moving to position x to position y) the player could be moved in a totally opposite point, which result in a continuos approximation instead of a real-time movement…
It is the reason why i don’t know how to implement the client side prediction…