This thread is inspired from the JME Client Thread.
I am planning to create a game where two computers are battleing each other in an RTS fashion. They both have a base, they are building armies and attacking each other with them.
Players in the game only control 1 unit and try to turn the tides in the battles. (If you have played Aeon of Strife, or Dota you know exactly what i am talking about). You have a third person view of your charector. You issue commands like move, attack and cast spell.
While the game can be fast paced, it isn't a twitch type game.
My orginal plan concerning multiplayer was to tackle it like an RTS.
Creating a P2P network, Where everyone runs their own copy of the game.
When ever a player gives a command to his unit, the command is delayed and all of the computers execute it at the same time
Now i see that this has plenty of faults, and all of the solutions seem to sort of peck at Dead Reckoning as being part of it.
But i don't really see how dead Reckoning ties into the picture.
Help on this would be awesome. Thanks.
jeeeez are you everywhere that i am? 
I know the idea of the dead reckoning, the question that i have is how does it apply in an RTS if at all?
I have always had the plan of every client (no servers in P2P) running their own copy of the game.
Also i am thinking of adding physics to the game, what issues can come about from that? Are certain aspects of the engine random?
Ps: I've already read that article. But it leaves some details out. in that article are PDU's certified? Wouldn't they have to be?
Also the current method of sending only sending commands and only sending an updated PDU when the command changes as being the same idea that i had going
I am now pretty sure that dead reckoning really doesn't have a place here.
I agree with you in with respect to physics, but that is why I wrote my PhysicsNetworking API. It offers many of the advantages of dead-reckoning with the additional advantages of realism. With dead-reckoning you would say "Player is moving forward" and would continue to move forward until another update occurs, but the problem with that is sometimes moving forward would not be physically what would occur if it were up-to-date. Now with the PhysicsNetworking I instead send physics updates that says, "Player is in this position, but these forces are at work on him" so the player then has the benefits to continue moving like in dead-reckoning, but is moving in the physics world based on forces. So I can shoot that player and I would see him bounce backwards from an explosion even though he is out of sync (or even if I'm out of sync) and everything goes back to reality when I receive another update from the server. In the case of the PhysicsNetworking API it is client/server based so there is the benefit of a master instance of the game that keeps everyone in sync. That is the reality of the game and everyone just tries to stay in sync with it. The clients send down synchronization messages for the objects they are responsible for (eg. their player, weapon fire, etc.) and the server then validates those messages (keep out the renegade clients) and applies them to the server's instance of the game and then sends those messages off to the other clients to keep them in sync. The server can also be responsible for any items that are not directly controlled by anyone (such as movable objects in the world). This keeps these objects always sync'd to the clients and the server just sends messages updating the clients periodically.
This could be done in a P2P environment as well, but there are major security vulnerabilities from doing it that way as well as synchronization issues that can come up. You have to have a master and relying on a client for that I think is always a bad idea.
darkfrog
Ok i see how having a "server" will greatly help synchronization issues, but in the case of a P2P game having him be anything more than the computer with the "official" game playing would be inneffienct. This game is probably going to have around 200 units on the field at a time. Giving a position, health, engergy and everything else required for each unit alone will require alot of bandwidth, to say the least. The solution I had thought of was maybe being a checksum of certain values and comparing them. If clients didn't match then the game would pause and a synchronization would take place. (Hopefully a very quick one). If a certain computer was causing too faulty checsums then he would be booted since he is either lagging too much or has a modified version of the game. I was also thinking of having clients send in checksums to a game host who would decide what a valid checksum of the files that the game required would be. Of course this could be easily spoofed, but its something, and if everyone on the P2P has the same modified version of the game, then who am i to stop them?
For dealing with synchronization, the only solution i could come up with was to use a fixedLogicalRate. lets say 30 logical updates per second (ups) it then should take 34ms per update on average. Clients would keep track of what number they are on. When an event is fired, it isn't executed immeadiatly, but instead assigned to execute in the future based on the slowest palayer. so if the slowest player has 250ms of ping and every it takes 34ms for every logical update, i'll set the delay to be atleast 8 frames ahead ( 250/34 ). But because that is risking it, (if all goes as planned it'll arrive barely on time) i'll round it to about 10 or 12 updates ahead. That is probably going to be something that i have to play with alot. So if the event took place during update #50, that event will be set to go off during update #60. All clients will then execute that event during update #60.
Now this has huge flaws, because lagspikes become very much noticed as the game is almost forced to halt. But this is nothing in the RTS genre. Also the issue that if a packet doesn't make it on time, the computer will just simply beleive that it never happened. for instance if an event deemed to be executed during update 60 arrived at my computer when it was at update 70, well all hell would break loose. (phew that toook me a looong time 
)
I was thinking of using the physics engine for simple explosion effects and to throw units around. I am wondering if this would cause serious de-syncs now.
I am still unsure if udp can be used in this situation
Thanks for reading my novel on rtses and multiplayer. 
- making the game logic update as slow as the slowest connection is bad in my opinion. better with communications methods that punish only the slow ones…
- bandwidth is not as big of a problem as people think, the problems is just plain good old lag…and lagspikes…
punishing the laggers would be best, but how?
as for bandwidth not being issue, i was thinking of using the available bandwidth to make sure everything is in sync.
my post in this thread says a bit about it
http://www.jmonkeyengine.com/jmeforum/index.php?topic=2163.0
My solution to punishing the laggers in the PhysicsNetworking API is to have implementing games have to write an implementing isValidPhysicsMessage(…) that passes the physics object, position information it wants to apply, and force information it wants to apply. The implementing game simply returns a boolean true if it's considered valid and false if it's not. If it's not valid then the server disregards the message and sends a message back to that client telling it to sync that object with the server.
In effect the lagging client would get choppy and the other clients would just see the last forces acted out on the lagging player (and then most likely depending on friction) the player would stop and just sit since it's not receiving any commands. The other clients can do to this lagger what they want. The implementing game could deal with this situation less harshly by maybe on vaidation of false sending a message to the clients telling them that the player is lagging and pop something up saying they're lagging and maybe make them unable to be touched until they are back. They wouldn't be able to partake in the game but no harm could come to them.
Essentially I create the framework and leave it to the game developer to decide how they want to handle implementation within their framework.
Finally, this isValidPhysicsMessage(…) leaves the handling of renegade clients to the implementing game's server (which I believe is where it should be) and the game can implement as complex logic as they want for validating whether a physics message is valid to the scene or not (eg. too much force applied, too much of a position jump, violating the rules of the game in some way, going someplace that the game has deemed impossible to reach, etc.).
darkfrog
Oh simple enough solution, but that could cause some nasty effects for the lagging client…
I still plan on using JGN, but i am guessing that i would be limited to using Certified Messages… No?
Why? If you are passing positional information then the "send and forget" method works great because there's always one on its way behind it if it gets missed and you don't want it if it's too old. In fact, PhysicsMessage extends PerishableMessage which is on the other side of spectrum from CertifiedMessage. Not only does it not try to resend if it fails the first time, but if for whatever reason it gets lagged over the expiration time of that message then it automatically just gets deleted and is never sent to any listeners.
I am going to try to find some time after Roll-A-Rama is in a more stable place to work on combining a lot of the features that PhysicsNetworking has into the base of JGN, but that's a ways off as I'm still battling with this game. :o
darkfrog
ok, now here i go getting lost again. 
From what i have i read, i got the idea that dead reckoning sends data along the lines of, "unit is going to move north for 100ft at a rate of 2ft/s", the next update is only sent when something news comes up that is a considerable amount different from the last message.
I planned on using somewhat the same system. When an event occurs, it will probably be an order being issued to a unit. Let's say a move command. In my game units aren't just told "move forward!", they are told "move over there if possible, if not, get as close as possible, using the A* pathfinding algorithm. When that order is issued, all that would be sent would be an indiction of what unit was ordered (if that, since players are only allowed to order 1 unit around) and where it was ordered to go. Every client computer will use the A* algorithm to figure out how to get there and therefore figure out the same path and have him go at the same speed as every other computer would.
Now are your saying to avoid this and stick to giving absolute positions? or what if i did a combination of both. Lets say: i give a message of where the unit is at the current time and where he plans to go. This might cause for large packets, but could kill alot of other issues.
Well, my focus in the development of my networking APIs has been towards first-person shooters where at any given time the player can change direction or action so it's not cut-and-dry. The physics networking simply lets you register objects in the client and/or the server and that just sends updates to the server (for the client) or clients (for the server) with current location and the forces on it. Essentially all it is is serialization of the DPO for the game to keep them in sync across the network. This is a much less obtrusive way of dealing with networking so you can develop your entire game with very little consideration of networking.
In your case you probably don't care quite as much with split second changes that can occur, but it was my thought that if I can write an API that can handle the speed of an FPS then it can handle anything.
…and I think it can handle an FPS and hopefully I'll get to show that off soon. 
darkfrog
ha i can't wait for your game darkfrog, also check out the thread i made in your forum, i modified my last post as promised
well the issue isn't speed, it's syncronization and reliability. Just because the network is designed with FPS twitching in mind doesn't mean that it is suited for every situation i guess. Maybe i could help out JGN in that aspect while you further speed.
I'm thinking about going with the hybrid idea now, its just a matter of weather packets begin to become too large.
I would suggest you take a look at the engine and decide based on that. I really believe that it offers everything you want if you are going to be using the physics engine. If it doesn't, just let me know and I'll add it. :-p
darkfrog
Look at the PhysicsNetworking API. The PhysicsNetworking API can be downloaded from the same place you got JGN.
darkfrog
maybe JGN isn't meant for the rts gaming world…
Why do you say that?
darkfrog
well the way it is designed seems to work for an enviroment where speed is key and the dropping of 1 or 2 packets doesn't cause disruption in the network. I've read many article on RTS multiplayer and they all seems to have the common idea of hoping that packets arrive and then attempting a sync incase the don't arrive.
I am still going to use JGN since it already has done alot more networking that i have, it is still very useful though.
The feature of JGN that it is extremely fast is not a disadvantage to it no matter what you intend to use it for. :-p
If you want to send and forget then you can use Message, if you want to go a little slower but more reliable way you can use CertifiedMessage which guarantees delivery. I'm also going to be creating a OrderedMessage that extends CertifiedMessage very soon that guarantees delivery in the order it was sent. JGN is still incredibly abstract and if there's something you'd like added please let me know. It's still in its infancy, but I'm hoping to get good feedback to make it much more.
darkfrog