For that many players and platforms to ever have a chance of working I have to ditch Springs' peer-to-peer synchronisation model and switch to a traditional client-server model. It's worth noting at this point that peer-synced sims have a historical justification due to bandwidth restrictions.
Just passing X and Y coordinates, status, action, facing and damage would have limited us to 250 moving units in the game at the most. "
That means I can theoretically send data for 12.5K units per update and i've yet to see a Spring game come close to that for total units in-game let alone units visible on screen.
Does one need to have an either/or scenario? Could you have both, and what would be the benefits/flaws of such a design?
What I'm thinking is, if you want to have clients in an asynchronous state towards most parts of the world, you could just synchronize them when needed, which would basically be just implementing a load/save mechanism, that is, a faster rejoin mechanism.
As shown in the below picture, imagine if your client would synchronize with the server (world) using only a part of the screen (green part), depending on what your client sees (blue part). If that green part would be much smaller than the whole world, f.e only a single planet in an MMO galaxy, or something similar in proportion, would it still allow a huge scale MMO while allowing for sync-level latency?
In fact, in an asynchronous system, your clients are more or less synchronizing with the server by receiving updates, and initially they could be as large as the full synchronous update (depending on the map visibility).
Also, how does the fully asynch system scale up when it comes to long battles with a lot of clients involved? While you will usually never have 1000s of players, the EVE-size of battles (1k vs 1k) is something one could expect in an MMO RTS, probably even scaled up a bit. From what I recall reading about the way EVE works is, they don't even send some "basic" information to all the players, f.e the actual dmg and hp of ships you aren't targeting isn't known. You only see the hp and dmg of ships you are targeting, when someone starts/stops attacking or otherwise negatively influencing other ships, and that's that. And with only that much data, they tend to run into bandwidth problems often, which they recently attempted to solve by slowing the game speed locally (time dilation http://community.eveonline.com/devblog. ... og&bid=900
). Still, I expect an MMORTS will also have to send data about hp changes for all visible units, which requires even more bandwidth, so I'm not sure how much an asynch engine can really scale - can we see some math (how often do you intend to send game updates)?
Btw, there is already an open source (engine) that has a server/client model, if you think you can get anything useful from it: https://skatgame.net/mburo/orts/
In short I believe peer-synchronised RTS is a largely obsolete technology due to significant problems with desyncs under different client architectures, languages and compilers (32 vs 64bit, x86 vs ARM, Java vs Obective-C vs C++, VisualStudio vs GCC, etc).
I feel you are tackling a different problem here. I'm not sure the benefits of having less to worry about desynchs will outway the added requirement to create and maintain a new engine for each of the different platforms. Besides, do you really need a Java/Objective-C version of the game, or will a 32bit/64bit difference even have any effect on the speed if your server is doing most of the computation, also not sure if the compiler really matters. The only thing that may be of importance is the x86 and ARM difference, and are you sure Spring (as it is) couldn't be made to compile and run on ARM? Do the libraries that ensure flops are executed properly work on ARM?
Going to try to interpret this as I understand it:
- Complete seperation of codebase for server, clients and AI.
Pros: Cheating prevention, AI crashes don't take down the game. Clients and AI can easily be made in different languages as long as they support the specified protocol.
Cons: Larger bandwidth requirement, slightly slower AI.
- Game simulation to run entirely server-side (x86(64) only).
Pros: Easier to have closed source games. Game is less intensive for client CPUs. No need to use libraries that ensure cross-platform calculation correctness.
Cons: A separate simulation (interpolation) code must be done on the clients, based on the server data.
- Clients send input to server and selectively render game updates based on their capabilities and needs. For example the client could request updates only for the part of the map currently in view. The server only sends updates for units in LOS for efficiency and cheat prevention.
Pros: Scales up to large maps.
Cons: Client requests need to be sanitized and verified for potential cheating.
- AI to be implemented as remote clients, not compiled into server. As far as the server knows they are just another player and have the same restrictions with respect to LOS and updates.
Pros&Cons: Can be seen here: https://skatgame.net/mburo/orts/.
+AddedCon: If your AI is to represent a large faction, it would incur a large extra bandwidth due to a large amount of updates/reads.
- Support for WebGL/Canvas and OpenGL ES2 clients (Mobile)
Pros: A reduced CPU requirement would allow a wider variety of platforms to be targeted.
Cons: Code must be created for each of the new targeted platforms.
- Simplification and unification of lobby and autohost protocols
I don't see this being related to the original (asynchronous) move of this thread. I assume this is a sub-project, care to elaborate?
Couldn't this be done with Spring as it is? Someone may need to create a C API and then just generate interfaces to a bunch of other languages?
- Remote OpenGL proxy. This will extend the work zerver has done on his GML rendering proxy (for spring-mt) to pass server-side OpenGL calls and assets over the wire to a client.
No idea what this means, but I assume you want to have an opengl server with clients connecting to it and just executing the opengl commands locally, as computed on the server?
Well, I guess Pro: Even less CPU/GPU work on the client. Cons: Having to create an OpenGL proxy and protocol. And couldn't it be done on the Spring as it is extending by just the OpenGL proxy, which is a Spring P2P node?
- Remove FPS unit control. This has always been buggy and crap anyway but it becomes even more unusable when combined with my changes
Well it is useless now, yes, but wouldn't asynchronous mode allow for more freedom - you could display FPS mode as you want.