I would like to introduce my thoughts on how to attemp an MMORTS Infrastructure. I think it is way different to set up an server for a huge RTS then lets say Minecraft. At least in terms of computing power. Sure there is the cloud and you can rent some big servers. but what does that cost? So a solution could be. Home computing. There is a huge amount of computing power sleeping in todays PCs. My attemp to realize a MMORTS/huge scale RTS(HSRTS?) would be the following: 1. there is a Data/Sheduling server, it cuts the Maps/planets in pieces and sends the needed data to the clients that shall compute them 1.1 data should be anonymised, there is no need to send the server internal ID for units or players to the specific client. You can start both by 0 and increment up. Thats for security issues and to help prevent hacking. 1.2 there can be 3 different models to help handle disconnects and cheating 1.2.1 No redundancy's results of computation are controlled spot test wise. If there is no answer from the client anymore u need to redo the computation also. 1.2.2 One redundancy 2 client solve the same computation if they have different outcomes u need to do a serverside or 3rd one to verifiy the right result. If one client has a disconnect there still is the result from the other. 1.2.3 Two redundancy's three client solve the same computation, If there there is a different result and its 2:1 take the one thats 2, if one or 2 connections lost there are still 2 or 1 clients left, Need handling for 3 different results or 1 connection lost and 2 different results. (more then 2 redundancys are quite silly i think) 1.3 There could be several version to help to achieve connection, double flags, permanent pinging , sending farewell flags etc. 1.4 result-data could be hashed for faster compare. 1.5 You can even split the computaion over games: so none of the participants of one game is involed in there computation. 1.6 The computation order of splitting and anonymise Data up by server, send to client, compute, send to server, compare, maybe compute again, reanonymise, send to game client, draw interface, could take up quite some mili seconds, so there should be thinking of how to (not prevent this from happening ) integrate this into the games UI, to not let the flow of the game feel smoth. some solution could be: 1.6.1 make a countdowntimer for actions or orders (storywise uploadtime for new order at unit) could be 1 or 2 seconds per unit. 1.6.2 less micromanagment more AI or generalized orders. 1.6.3 sending not only current positions but also movement/shooting vektors and so showing the player the Future on his screen, may result in units flip floping over the place when actual data arrives 2. traffic handling the more units there are the more stuff happens the more traffic will occur. 2.1 one solution can be to look at Video Streaming, You can send one complete data set every 10/25/50 Frames, and in between only the changes. 2.2 just send the stuff actuall show on player screen, minimaps are computed by the other pc's and streamlined as low res videostream (should be enough for a minimap) 2.2.1 clicking on the minimap therefore would result in no instant reaction by the game, because it has to wait for the server to respond. 2.2.2 maybe ther for use the same input delay/cooldown as for units note: multiple windows are something i didnt think of in this circumstance. 3 hell you can even do compute clients only for the fans of the game when they are not actuall playing, but dont turn of pcs or are just surving the web or stuff. This is by no means the advice how to make PA, i just want to throw this Idea out there and discuss about it a little bit, maybe there are some thinking points for Uber. So to get this into something we all can maybe benefit from. I encourage all the Nerds and Geeks out there to trow in their expertise.
While what you propose may be theoretically possible, I don't think you realize how incredibly technically challenging even hosting a regular MMO game is. Much less developing a highly theoretical distributed computation AND distributed networking system to run it. What you suggest is, given current technology and human knowledge and abilities, very close to totally infeasible for anyone, much less a small studio.
You should go read up on the model that TA used for compute as it has some similarities in some ways. Overall though as described there are a number of difficult issues to solve with your methods. Most strikingly figuring out how the necessary compute is split up and making sure all of the data necessary is on all of the machines doing compute. In addition a ton of added latency. Compute is scaling faster than bandwidth as well. So another hard part here would be doing this with less bandwidth. In fact bandwidth is actually more costly than compute at this point. This method works well for data that needs a lot of compute for only a little bandwidth like protein folding or bitcoin mining. Remember that under our current scheme the only bandwidth we use is to tell each client exactly what they need to know at each moment.
Whats the standard(minimum) upload / download bandwith u expect to work with? Or is it just all scaleable or for worse connetions downslowing?
So the short version is that it was async. Each player calculated their own units and sent them to everyone else peer-to-peer. AI's could be run on just one machine.
Well, there's two major types of setups. On the cloud, compute is cheap but network bandwidth per user is limited. Inside the home, compute resources are very expensive but a 100/1000 network is no problem. The cleanest separation of compute is likely between worlds. For example, the beefy gaming PC handles everything on the big world, while moderate computers get moons as their domain. It's not exactly a shared load, but it lets things scale without too many hazards. A bit more complicated is figuring out how to share loads from a single world. I imagine the data transactions get very large very quickly, and even a <10ms network latency becomes a crippling issue. More hosting PCs also become more points for failure. One PC crashing would effectively kill a world. For a LAN, that is a bit acceptable as the angst is entirely between friends. With some saved data and the replay system, it should be no problem to regenerate the lost world and continue the game.
Yeah sounds quite alike. Though without the server that sits in the middle. p2p seems quite a bit a upload multiplier then. The sheduling task of the server is at least down to 1/8of a planet not that much of a problem. Though i might be naive. First there are the given instances solar system > planets> hemisphere> 1/2hemisphere> 1/4hemisphere after that it gets tricky if you want to stay generic. Please dont understand me wrong i do not want to convince anybody, just have a nice little discussion. For the traffic though. I might cook up some experiment. But nevertheless good input, wouldnt have thougt of the traffic as main bottleneck.
Thats why i would go for redundancys. If you accept the latency you could go for one pc na, one eu, one asia. But such a game must be build with that in mind. So no intensive micro battles for instance. For starcraft this would be the death. But if you focus on more strategic gameplay this gets less important. But then again you need smart units imo.
Just an FYI, there is already a MMORTS, Mankind, which was first released back in 1998. It uses 3D models (not 2D sprites) and has both ground and space combat. The graphics look like they are from about 2001'ish but it has the same gameplay mechanics as TA. I keep checking on it from time to time to see how it runs. It does, I believe, most of the functionality raised by the OP, so perhaps you can ask the developers there for some input.
