OMG!!! I just had a wonderful vision for BOTF2!

Let me explain!!!

Say you start a multiplayer game.Is it possible to in affect- leave the game open for people to join in the middle of the game. For example, allow people to join as a Un-human-claimed empire. Then, when this happens, make the player newly joined player wait till the next turn; after uploading the game info. Then prompt the other players with a message that the government of the "race new player pickedâ€￾ changed. That way you can take full advantage of the many playable races and also fill multi player games with people.

Only thing i can see being a bummer is when the New player joins he starts with an AI built empire and no knowlage of what is going on. But hey, it will be most interesting

i don`t see how this could work, everyone in the game would have to quit so the new guy could get the sav file and then restart, don`t see too many people wanting that in the middle of a campaign

No, i am sure you are wrong on this. There are many games where other players can join the game mid way. I see no reason players would have to quit and re-start. All that is accuring is the game data is being sent to a new player while the others are playing. On the next turn phase the player will be able to join in. I don't even see it being hard to code in.

I would sooner see a problem with playability rather than it being possiable.

This would definitely be possible. In my game, all players download an initial "ClientGameData" object that contains the race database, empire database, tech database, and the empire manager for that player (with object view graph, map visibility data, etc.). Then, each turn, a "TurnUpdateData" object gets sent to each player, with an updated empire manager (and universe view). For Teleon's idea to work, the server would simply have to be capable of accepting a new player in midgame, and letting that player choose an empire that is currently in play by the AI. Then, it would simply have to build and send a new ClientGameData object to just the new player, and swap out the AIPlayer with a HumanPlayer. I already do something similar with the savegame feature--when a client wants to save the game locally, it sends a request to the server, which in turn serializes the gamestate and sends it to the client. None of the other clients/players are affected.

This realy isn't that different then botf 1 where you could quit and start the game with a new player who would take over either an AI or absent player.

You could just IM one of the players and ask them all to quit instead of adding in this feature (which would be trivial to add to a properly designed framework)

As long as you can also be able to turn OFF this feature I'd say: go right ahead. But in most my multiplayer games I play with friends and I don't want to be bothered with the average internetn00b to mess up our game.

I agree its possible, but it could theoretically open the game to hacking.

if the sav file or wahtever it is is so easily given out, it wont be long until someone dedicated figures out a way to bypass the game, and cheat.

Well, cheating may not even be an issue, depending on how you design a game. In Supremacy, all game logic is executed solely on the server, and then each player downloads a game state that is specific to them. In other words, they only download the objects that they can see in the game (items in explored sectors and sectors within sensor range). Everything they send back to the server is sent in the form of "orders" (set fleet destination, add item to build queue, etc.), so nomatter what they manipulate, it won't affect the gamestate on the server. I can change my local copy and give my colony ship unlimited range and a speed of 100 sectors per turn, but those changes won't affect the game at all--they'll just be discarded the next turn.

I went with this approach mostly to save bandwidth--why send data to a player that can't view it?

^^^Isn't one player the server? So that player would still be able to cheat?

No, because the server runs in a separate application domain from the client. The player still connects through a socket. That way the client and server aren't fighting for control of the global game state object.

I'm sure a determined person could patch the server to favor his client but that is true of any game. Do you do client side validation? Like if the server tells you your fleet of ships were destroyed by one enemy colony ship?

What ever ideas we put into a game that involve online play or multi player there's always going to be possible problems with hackers or cheaters. it's whether the idea is feasable and good enough that we should focus on.

TBC

Well, this sort of thing is an issue, because the game is supposed to be very mod-friendly, and people will be able to add and modify items (i.e. ships) in XML. This would obviously pose a problem for multiplayer games. My temporary solution is to load a separate configuration for multiplayer, one which was compiled into the game's executable. However, I may come up with a strong encryption scheme that will allow people to publish "official" mods, which could validated to ensure they have not been tampered with. It's still something I'm thinking about. But, if someone did figure out how to modify a colony ship to have outrageous firepower, the client would know simply by looking at the ship's specs. The clients all download the configuration (race database, tech database, etc) from the server at the beginning of the game, just to make sure the configurations are the same across the board.