Transport Tycoon Forums

Talking with Hellfire after this week's meeting I presented him with an idea I had for our general engine setup. This is a style I believe is relatively new among games (Battlefield 1942 uses it for one). What that is is a separation of the user and the game engine even in a single player game. That is, the game is setup as a server on the computer and the local player joins it. Don't worry about security; for a local game the server isn't really listening. But what this allows us to do is easily treat both people and AI as equals. The AI's won't know the difference between eachother and any real players by design. Other pros to this scheme is near seamless single player to multiplayer conversion, observers, dedicated servers, (and as hellfire pointed out) distributed Ai's (clients can host AI's as well as server).



This is a picture of a locally hosted game with two AI and one remote player. The arrows represent who functions on what class. They all connect to a facade (interface) class which instructs the engine (cGame) when everything is ready to compute. The player is updated on changes in the game state by an observer (modeled after java's Observer class) which tells the userinterface class. This class has all the models/sound/textures through cMedia. It also has inputs (keyboard, mouse) (not shown). The data is sent to cPlayer, a superclass for all the types of players. For the particular local player, it simply passes on information from the userinterface.



The remote player would likely see this. Notice that only one player talks to the facade. Here, the dotted lines represent network communication. The other players do exist, but thtere is no engine in this model to receive the input. There's reason an AI could not exist here and also talk to the server through the facade, however that would increase network traffic. By only having the engine on one computer, desynchronization is nearly a moot point, and players will have a hard time cheating (except the one hosting the game).

Again this is an upper level suggestion. There are many classes involved which aren't shown, and communication is simplified. Hopefully, communication isn't too simplified.

So... What does everyone think?

epistax wrote:Again this is an upper level suggestion. There are many classes involved which aren't shown, and communication is simplified. Hopefully, communication isn't too simplified.

As you all can see, this design could apply to any type of game. To keep the upper level design as simple as possible only two features have been included:

1. Multiplayer gameplay
2. AI players

Details like maps, vehicles or tcp sockets will be modeled in "lower" levels.

Very nicely done !!

But I think it will be difficult to decide what parts of the code shoud go in the GUI and what parts in the core-game. Think about the network traffic. For example, the movement of a train. There some different approaches to that:

• Send a message only when a train is starting/leaving/changed orders/... with it's current position, and full path description. => Lots of chances for desync, and decisions about the train's actual speed should be in the game-core and not in the GUI
• Send a message whenever a train does something "unnatural" : starting, stopping, slowing down, taking a turn, changed orders, ...
• Send a message every 250ms with all info about all the trains in the complete network
• ...

I just fear that having completely no game-core on the client side might generate very much internet traffic.

PJayTycy wrote:Send a message only when a train is starting/leaving/changed orders/... with it's current position, and full path description. => Lots of chances for desync, and decisions about the train's actual speed should be in the game-core and not in the GUI

Two possibilities I see:

The game engine transmits (upon change) the location of a given train, and where it is going. Locally the train can be updated on position, but only position. The remote game engine still transmits when it docks/crashes/etc, so the desync won't happen. Also known locally can be the location the train is heading. The train will stop dead at that location, assuming no further updates from the server. Anyway the worst case desynch would cause a train whos orders were changed to appear in a different location locally for an amount of time before getting a server message that it is different. (perhaps as you say, a complete update could be sent on a periodic signal).

The other method I can think of is strictly locally there exists a complete game core, and every once and a while the remote server scraps the local game and creates a new one up-do-date.

Compared to network communication, processor time is infinite, so we certainly want to reduce traffic as much as possible. So, I'm agreeing with you

There haven't been much objections to this model... Perhaps we should start adding some detail to the diagrams?

Not a bad idea. It'd probably be done in chunks because the full thing could be too big to fit nicely in here. We can chat about this in the IRC channel.

epistax wrote:The game engine transmits (upon change) the location of a given train, and where it is going. Locally the train can be updated on position.

Well, this still requires a lite-weight game-engine between your remoteObserver and the userInterface or in the userInterface.

I think a good guideline for the amount of traffic needed to send over the network would be all the info an AI player would/could use. If the AI player knows what it means, the game-engine in the userInterface should be able to handle it too.

epistax wrote:Not a bad idea. It'd probably be done in chunks because the full thing could be too big to fit nicely in here. We can chat about this in the IRC channel.

Ok. I'll try to be online at 11:00 pm (GMT, so that's 6:00pm for you). If you can't make that, please mail me. Email address is in my profile.

PJayTycy: feel free to join us on IRC

would this mean you could make the AI a seperate file? that would be cool. First off all making a working AI is hard, so it can be done at anytime you want and by anyone, the game doesn't need an AI to run. 2nd you can make differnd AI files, wich you can load on the start of a game. so you can load for player 1 easy.AI and for player 2 defensive.AI.
I have seen these AI files in space empires 4 if i'm not mistaken (a turnbased space game). At start there were only some bad AI players, but slowely the comunity made some better AI players.
Or am I only busting in open doors atm?

broodje wrote:would this mean you could make the AI a seperate file?

No... A separate object. Not really the same thing

But with objects, you can do a nice thing, called subclassing. With subclassing it would be possible to have several different AI subclasses, which can be dynamically linked at runtime, meaning that you wouldn't need to recompile to select a different AI object.

In fact: you could put objects in a separate dll (or unix equivalent) and link new AI players without recompiling the app!

okey I was not using the right words , I meant the last thing so you can asign new AI players withoud recompiling the app

Do UML diagrams require attention at this time?

UML diagrams are what people produce to prove to others (mostly superiors) that they are actually doing something.

I think its good to have around as a basis, but chances are we don't need it.