The amount of units slowing down the game.

In a lot of real time strategy games like supreme commander, supreme commander forged alliance and others. The games are really epic but their comes a time in the game where the game speed starts to slow down as more units are on the screen. are you guys going to implement a way where that won't happen or are you going to decrease the chances of that not happening as more units come on the screen. I'm wondering because you guys said that their is no unit cap in the game. It's great that you guys aren't adding one but won't the game slow down as more units are on the screen like some of the games I mentioned. Were you guys going to try something like the planet has a lot of units and when you enter another planet will that turn into another map where the game isn't focusing on the units on the other planets. When you have a answer, tell me?

This is a completely different engine compared to the Moho Engine, it's problems will not necessarily be the the same for PA. Even then, a fair number of the guys that worked up the Moho Engine are also hard at work on PA, so I'm sure they're well aware of the issues the old engine faced.

in regards to the 'No Unit Cap', that's not technically correct, there will be a Cap, what it will be we won't know until we can get in some serious stress testing once the Engine is or mostly is Feature Complete. But the idea for the engine is that it's perfectly scalable, so 5 years down the line it will try to take advantage of you average gamer's 32GBs of RAM or what ever, allowing for bigger games.

Don't forget that PA uses a Client-Server setup, so as long as you're connected to UberNet the idea is that your using a Server to handle the entirety of the Sim and it only sends each client exactly what it needs, no more no less.

Mike

There's no explicit unit cap like many games have and one of our big goals is having extremely high unit counts as part of normal gameplay.

However slow down isn't something we can just wish away. Computers are not infinitely powerful. However one benefit of the client / server model is that often times the slow down you see in old games is caused by the peer to peer network model requiring all clients to do all of the work, and that won't be an issue for us. As long as the one server is powerful enough the game time won't slow down. Some client frame rates might still slow down, but the game time won't.

I am really curious to see what's possible when someone throws an Intel S2600CP2 and couple of Xeon E5-2687W's with half a terabyte of RAM acting as a server at the PA engine.

Amen, your unit cap should be the opponent.

And just to clarify a misconception that I hear a lot:

The Client-Server architecture is not referring to Uber's servers, necessarily. It has nothing to do with the way SimCity 5 requires you to always be online.

Most RTS games run their simulations in lockstep with every other computer in the game. The conversation looks something like this:

Computer 1: I'm 15 seconds into the game.
Computer 2: I'm also 15 seconds into the game!
Computer 1: I'm 16 seconds in.
Computer 2: Oh, I'm at 17 - I'll slow down and let you catch up.
Computer 1: I'm at 17 now and my player just gave a move order.
Computer 2: OK, I'm going to give that player's units a move order too. 18 seconds.

And so on. This reduces network chatter a lot because you don't have to send the position of every single unit, but it also has some weaknesses in that every computer has to wait for the slowest computer, and if at any point one computer comes up with a different simulation result than another one, the whole game either gets desynced or crashes.

The Client-Server architecture acts more like a game of Call of Duty. The Server is the computer that's doing all of the processing work - it's not UberNet. If you're hosting a game, the Server is your computer. It looks more like this (assuming that the Server is also a player's computer):

Server: Ok, here's where your player's units are, here's where my player's units are.
Client: My player just gave a move order.
Server: Your player's units started moving. My player's units are starting to move too.
Client: My player just gave an attack order.
Server: Your player's units are shooting at my player's units. One of my player's units exploded.

And so on. The advantage here is that it's extremely resilient to lost connections and slow computers. This disadvantage is that it's very chatty and you'll have to have a fairly good connection for optimal play - more bandwidth is more important than less latency is this case.

Lag will also look different between the two models. In a traditional RTS, lag looks like the entire game slowing down. Units move slower and shoot slower and it just looks like your computer is struggling to simulate everything (which it might be, but it could also be any other computer in your game).

In a Client-Server model, lag is going to look like units teleporting and making strange, erratic movements as your computer tries to predict what the game is going to look like in the next few seconds based on wholly incomplete information. It will look almost the same as a laggy game of Call of Duty, but probably not as bad due to the overall slower pace of an RTS. It will also slow down from time to time, but only if the Server itself is struggling with the simulation.

Wow, that's a novel. I hope that helps people understand the network architecture, though.

Excellent post, thank you for the explanation!