Is there a reason why we even need a server for offline?

Please excuse my ignorance on this matter if this has been explained else where and this isn't a thread for complaints, I'm just curious as to why with pretty much every RTS game that has come before that when you play offline for campaigns or skirmish modes that the game starts directly from the client, but PA doesn't?

Lot of people have written some amazingly detailed threads on about the offline server, server optimizations and what could be done to improve performance like proper multi-threaded server, but I'm wondering if we are going about this all the wrong way and doing a long-winded way around of playing offline when the client could actually probably do it and do it better as its already multi-threaded? Offline servers are great if you have 2 computers, or want to run a server via Linux or something, or even perhaps a LAN, but solo play it makes very little sense.

Anyways, just wanted to throw this out there and maybe can explain whats going on, or why it has to be this way or something...

Basically every game you play runs a server for you to play offline, you just don't know it as it's integrated into the game.

Playing offline in every game is the same as connecting to your own seserver and playing essentially, only it's hidden away to make things simple for people.

It has been explained in great detail that the game was designed in 2 parts. The closest the game can come is running a server quietly in the background without the player even knowing.

Honestly, it likely runs better in 2 parts anyway. That way, the server does everything it needs, and the individuals only receive information from the server they need. Each part just does it's own part. That way, nothing else strains anything else.

Hiding it behind the client, makes it as little bother as possible. In that regard, your question may be why is it so necesary for a solo game, but my question is why is it so different and such a problem in a solo game if it is so hidden you don't notice it?

It isn't very different. You click local game button, you play. If you care about the "how?", then it is a superior system for flexibility amongst any form of running the game with or without mods or other players or AIs. If you don't care about the "how?", then the game runs, end of story.

PA was originally built to run as a server-client architecture. This is putting it fairly simply, however - the actual way they designed it is very, very specific. Trying to change the way that works would be like trying to port it to consoles.

First of all there is more client-server games around where most of players don't even know they're client-server. Basically client-server only mean how different parts of game "talk with each other" and it's might be absolutely invisible for the player. As most of games around are closed-source you can't just check it without spending a lot of time on it.

For example mostly every RTS for multiplayer have role of "host" which in some case might be also treated as "server" because in some games all other players connect to him. Usually only role of such "host" might be control of game state sync and connection status of other players. Of course this "host" isn't actually different than any other player and only some additional piece of logic that control correctness of game state, but it's possible that exactly same logic used for one player when you play this game offline.

Secondly game might be client-server, but still work different way that not like PA's. For example some RTS games that use client-server for networking, but their simulation is still synchronous or even async.

So Uber might easily built both client and server into one executable and with some effort they can replace network connection over TCP with some internal messaging system, but developers time is limited and there is no reason to do that. At moment code that working for multiplayer is well tested, isn't crash prone and optimized while new code will potentially have more bugs and possible bottlenecks.

Answer is: it's has to be this way because everything in game split in client / server and to make it actually work different way game have to be rewritten. Still developers might easily hide it's all from players like many other do before, but it's won't benefit game at all.

oops wrong thread

Essentially the term 'server' is confusing the issue. What your describing is actually the 'simulation' (which every RTS game has to have).

When playing offline, the simulation runs on your machine + the client side stuff (user input / output, graphics, sound etc). When playing online, the simulation is run on the 'server' and sent to everyone playing that game (so playing single player *online* actually reduces the load on your system for PA).

When people are commenting about threading for the server- what we actually mean is we'd like the simulation to support threading. Currently *that part* of the game code runs on 1 thread. Now PA is well threaded- it uses different threads for graphics (up to about 3), UI (as many as you like), network (again lots here) + simulation (currently 1). When people are experiencing slow downs in large games it is the simulation that is struggling to keep up- hence the suggestions of making this multi threaded (however be aware this isn't an easy thing to do).

Anyway hope that makes things a bit clearer....?

For design decisions and technical goals such as eliminate lowest common denominator, support up to 40 players, up to million units in a game, chrono cam, join in progress, etc. Classical RTS network model is typically synchronous lockstep architecture where all simulation had to be in sync in order for the game to progress. As a consequence the slowest computer in the game dictates speed of it. Everybody must have the same game state otherwise it will not proceed. With PA being separated like this; the slowest machine does not affect everybody in the game. A client/server architecture eliminates or mitigates in entire classes of problems for examples: cheats/hacks, desync errors, etc.

By separating the concerns like this you make it easier for development and maintenance of the game. When we talk about the server; what were really talking about is its concerns. It contains the simulation (authoritative over current state of the game), HistoryServer (has all previous information required for chrono cam and features like it), and viewpoint servers (what the history server is sending to each client and is the view of the game for each client). The client is only concerned with user interaction, graphics, etc. Only has access to what the server sends it.

There were some design decisions and technical goals that were used for promotional material during the Kickstarter campaign:

- https://www.kickstarter.com/projects/659943965/planetary-annihilation-a-next-generation-rts

More tech stuff:
A high-level overview of the server by chargrove
Synchronous RTS Engines and a Tale of Desyncs by forrestthewoods
The Tech of Planetary Annihilation: ChronoCam by forrestthewoods
Q&A - Planetary Annihilation ChronoCam by forrestthewoods

It gets even messier than that because "server" actually means a collection of things that together are required for hosting a game. The simulation is one part of this, but there is also a history server that works the magic behind the chronocam. My understanding that playing the game just involves viewing the chronocam at the latest possible point. The server also has a bunch of back end logic for lobbies.

thanks all for the reply guys...