Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Fri Nov 24, 2017 12:11 am

All times are UTC




Post new topic  Reply to topic  [ 30 posts ]  Go to page 1 2 Next
Author Message
 Post subject: Game architecture
PostPosted: Fri Sep 23, 2005 5:21 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
OK - this is probably the most important part of all topics - as it will destine the whole game.

Now - what game architecture will we use? Client - Server? Peer-2-Peer?

Should the engine be multi threaded? And if so - how?

As for me - I think that we should develop two things. Client and server in a multi threaded fashion. This will require to develop a protocol to send data to and from the server, but will ensure that if something goes askew - it can only do so in one place (server).

As for multi threading - since multi-core cpus are starting to be avalible to everyone - I think it is mandatory for the game to support multi-threading. The size of data we are going to manipulate will require every bit of processing power we can get.

As for the detailed diagrams - I'll have to give it some thought :)

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Sat Sep 24, 2005 1:36 am 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
Ok - a quickie showing my idea of the game structure

Asterisk shows what is required NOW to do.

Code:
Server
|-> Network
|-> * Map
|     |-'
|     | '
|     |-'
|     \- * Tiles
|-> * Data
|     |-'
|     | '
|     |-'
|     \-> * Parser
|-> * Time
\-> * Client
    |-> * Interface
    |     |-> * GUI
    |     |     \-> * Renderer
    |     |           |- * GL
    |     |           \- D3D
    |     \-> * SDL
    |         |-> * Keyboard
    |         \-> * Mouse
    |-> * Timer
    \-> Sfx



Server - main class, the watchdog responsible for keeping the game run at steady pace (25 fps?), it also starts all methods from lower classes.

Network - class responsible for communication with other servers via TCP/IP network (note - only one server actually runs the game, the rest just feeds data to the clients).

Map - a class containing (and modifying) all data about towns, tiles, vertices and alike. Also contains map generator. The dots indicate various classes that will hold town data, track data etc.

Tiles - a class holding information on tiles (what kind of terrain are they). It contains map generator. It also holds geometry data - that is normals, vertex colors and various other properties that are associated with Tiles.

Data - class that holds all definitions of all game objects (tiles, buildings, trees, vehicles, shaders - everything). It holds important Parser class which will mow through all configuration files providing all data needed to make the game.

Time - class being the watchdog looking at the passing time (real time and game time alike)

Client - second most important class, it is responsible for all the things that are actually seen. It is responsible for drawing and input handling. Client is responsible for sending the server all the commands from the user.


Interface - A class handling user input.

GUI - a class responsible for drawing and handling Graphical User Interface

Renderer - a class that will draw all the stuff. It holds preprocessed models (in a form of display lists) and shaders.

GL/D3D - respectively - openGL and Direct 3D classes responsible for the drawing :)

SDL - a class responsible for testing controls - eg mouse and keyboard input.

Timer - client level time measure - only for real time.

Now typical use case would look like this (in the game loop)

Code:
server -> start server frame // start measuring miliseconds in this frame
server -> time -> update Calendar
server -> read and process client commands
server -> map -> update Vehicles
server -> map -> update Towns
server -> map -> update Other
server -> Prepare Client Data
server -> client -> start client frame
server -> client -> Interface -> SDL -> test Keyboard
server -> client -> Interface -> SDL -> test mouse
if (mouse click) server -> client -> Interface -> GUI -> test for window collisions
if (window collision) server -> client -> inteface -> GUI -> determine commands
if (keyboard) server -> client -> interface -> SDL -> keyboard -> determine commands
server -> client -> Inteface -> GUI -> Renderer -> draw windows
server -> end client frame
server -> end server frame

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Sun Sep 25, 2005 9:29 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
Comments? Anyone?

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Sun Sep 25, 2005 10:10 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Oct 03, 2003 11:59 pm
Posts: 1429
Location: Lancashire, UK
uzurpator wrote:
Comments? Anyone?

I was going to wait until I had drawn up an alternative structure for the program but I'll post what I've been working on.

I don't think this structure gives us enough decoupling between the different parts. I think we should work towards a completely separate client and server and also between the data (model), view and control.

This is a rough diagram showing the structure I'm thinking of:
Code:
Game
|-> Server (only part able to change data)
|   |-> AI
|   \-> Model
|       |-> Map
|       |   |-> Tiles
|       |   |-> ?
|       |   \-> ?
|       \-> Data
|           |-> Track
|           |-> Vehicles
|           \-> ?
|-> Client
|   |-> Control
|   |   |-> FrameRateController
|   |   |-> SoundController
|   |   |-> GamePainterController (controls the paint cycle)
|   |   |-> TimeController
|   |   \-> InputController
|   \-> View
|       |-> GamePainter
|       |-> VehiclePainter
|       |-> TrackPainter
|       \-? etc.
\-> Network

This doesn't show where interfaces are used because that would make it very complex. I'm working on a UML class diagram to show the full structure and interaction between the parts and post that when it's ready.

_________________
Image
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.


Top
   
 Post subject:
PostPosted: Sun Sep 25, 2005 10:46 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
DominionSpy wrote:
I don't think this structure gives us enough decoupling between the different parts. I think we should work towards a completely separate client and server and also between the data (model), view and control.


Well. One thing that comes to mind here...

Maybe we should develop two applications altogather - TEserver and TEclient - split them into two executables and communicate using solely TCP/IP loopback on a local machine. This way we could skip the network class - and get quasi multithreading. And for "free" we get network problems resolved.

What needs to be resolved here is synchronisation and data protocol between client and server. I'll have to give it a thought.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Mon Sep 26, 2005 10:57 am 
Offline
Transport Empire Developer
Transport Empire Developer
User avatar

Joined: Mon Feb 03, 2003 9:30 am
Posts: 699
Location: Back at the office
DominionSpy wrote:
Code:
Game
|-> Server (only part able to change data)
|   |-> AI
|   \-> Model
...

A long time ago, we thought that it might be worthwile to consider the AI to be a client playing the game too. This will have some advantages:
  • To the game, all players are the same
  • AI is completely transparent to the game core.
  • In multiplayer games, the AI can take over if a player disconnects.
  • In multiplayer games, a player can connect to a game and take the place of one of the AI players.

_________________
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)
Code:
+------------Oo.------+
| Transport Empire -> |
+---------------------+

[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...


Top
   
 Post subject:
PostPosted: Mon Sep 26, 2005 1:54 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Oct 03, 2003 11:59 pm
Posts: 1429
Location: Lancashire, UK
Hellfire wrote:
DominionSpy wrote:
Code:
Game
|-> Server (only part able to change data)
|   |-> AI
|   \-> Model
...

A long time ago, we thought that it might be worthwile to consider the AI to be a client playing the game too. This will have some advantages:
  • To the game, all players are the same
  • AI is completely transparent to the game core.
  • In multiplayer games, the AI can take over if a player disconnects.
  • In multiplayer games, a player can connect to a game and take the place of one of the AI players.

I was actually meaning vehicle AI (such as routing), rather than opponent AI, but you're right, it should have been put with the client rather than the server.

_________________
Image
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.


Top
   
 Post subject:
PostPosted: Mon Sep 26, 2005 8:45 pm 
Offline
Route Supervisor
Route Supervisor
User avatar

Joined: Fri Oct 03, 2003 8:22 pm
Posts: 449
Location: Edmonton, Alberta
Anything under "Model" should be available to both the client and the server; although only the server can actually modify that information, the client will still need to have it in order to be able to render the player's view and be able to accurately represent what the client can do.

I am leaning towards writing a completely separate client and server whereupon a singleplayer game is one where the only human player on the server is the client; this solves the issues of having to deal with a separate single player component.

_________________
Grunt
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)


Top
   
 Post subject:
PostPosted: Mon Sep 26, 2005 11:58 pm 
Offline
Engineer
Engineer

Joined: Tue Jul 12, 2005 8:14 am
Posts: 32
Location: Melbourne suburbs, Victoria, Australia (GMT+10)
Grunt wrote:
Anything under "Model" should be available to both the client and the server; although only the server can actually modify that information, the client will still need to have it in order to be able to render the player's view and be able to accurately represent what the client can do.

I am leaning towards writing a completely separate client and server whereupon a singleplayer game is one where the only human player on the server is the client; this solves the issues of having to deal with a separate single player component.


Yeah, there should be no distinction between a single-player game and a multiplayer one. It will make things easier for all of the coders, and it will mean that the AI can be used identically in multiplayer and single-player without having to write slightly different interfaces. It will be much easier, in the long run, to have a single-player game being a multiplayer game without the multiple players.

William.


Top
   
 Post subject:
PostPosted: Tue Sep 27, 2005 6:02 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
Grunt wrote:
Anything under "Model" should be available to both the client and the server; although only the server can actually modify that information, the client will still need to have it in order to be able to render the player's view and be able to accurately represent what the client can do.


No no no no.

The (local or not) client cannot access server only data. We are talking about hundreads of megabytes of information. This stunt might work for local client, but via internet it is compleatly unacceptable. For this sole reason we need to start at the stiff bandwidith constraints from scratch.

The client only recieves snapshots (small packages) of data from the server - and sends requests to the server for data. Nothing more.

GUI, drawing and collision detection however are client only occurances.

In the simplest model client asks:

"Give me a leaf of data: 20x20 tiles starting at 482x345"
or
"Give me info on train 282"

and server responds accordingly. What we need to make sure that the data stream will not exceed ~10 kb/s and that client/server will not go async.

Quote:
I am leaning towards writing a completely separate client and server whereupon a singleplayer game is one where the only human player on the server is the client; this solves the issues of having to deal with a separate single player component.


Hm - yes - but should we develop:

1 application with both client and server embedded?
2 apps communicating via loopback on local machine?

DominionSpy:

Then the
Code:
AI
class is not needed. You will be able to keep the - say train movement routines within
Code:
Train
class - which makes Model class unnecessary.

Code:
Game
|-> Server (only part able to change data)
|      |-> Map
|      |   |-> Tiles
|      |   |-> Vehicles
|      |   |    |-> Train
|      |   |    \-> ?
|      |   \-> ?
|      \-> Data
|          |-> Track
|          |-> Vehicles
|          \-> ?
.
.
.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Tue Sep 27, 2005 9:32 pm 
Offline
Engineer
Engineer

Joined: Tue Jul 12, 2005 8:14 am
Posts: 32
Location: Melbourne suburbs, Victoria, Australia (GMT+10)
uzurpator wrote:
Grunt wrote:
Anything under "Model" should be available to both the client and the server; although only the server can actually modify that information, the client will still need to have it in order to be able to render the player's view and be able to accurately represent what the client can do.


No no no no.

The (local or not) client cannot access server only data. We are talking about hundreads of megabytes of information. This stunt might work for local client, but via internet it is compleatly unacceptable. For this sole reason we need to start at the stiff bandwidith constraints from scratch.


I was hoping he wasn't saying that the client shouldn't have access to the entire map data... I agree with you uzurpator, it would be massive...

... wrote:
The client only recieves snapshots (small packages) of data from the server - and sends requests to the server for data. Nothing more.

GUI, drawing and collision detection however are client only occurances.


Collision detection is client!!?? What collision detection do you mean?

... wrote:
In the simplest model client asks:

"Give me a leaf of data: 20x20 tiles starting at 482x345"
or
"Give me info on train 282"

and server responds accordingly. What we need to make sure that the data stream will not exceed ~10 kb/s and that client/server will not go async.


Are you talking kilobytes, or kilobits? Whatever you were talking about, we shouldn't need to transfer much data to the client. We simply need to give it details about the vertices, terrain, etc of the tile, and anything that is on the tile, along with an ID for reference with the server. The client doesn't need all of the data about a tile that a server does, as the client doesn't do pathfinding or anything like that. It doesn't need all of the data about a station, because it will request it if and when it needs it, which it may not need to do very often at all.

I also think that the bandwidth could be limited by just transfering what is needed, say by giving no data for a tile that hasn't changed since the last request. This would take the bandwidth down massively, and the client would only need the data for the current viewport.

The only problem with this approach (that I can see), comes up when we notice that we really have to have a minimap. This means that the data for all of the tiles is going to have to be transferred to the client. We could always have the server do some of the minimap generation, or we could have a tiny amount of data for each tile retrieved, just enough to display the minimap. Otherwise, opening the minimap would create...............................lag.

... wrote:
Quote:
I am leaning towards writing a completely separate client and server whereupon a singleplayer game is one where the only human player on the server is the client; this solves the issues of having to deal with a separate single player component.


Hm - yes - but should we develop:

1 application with both client and server embedded?
2 apps communicating via loopback on local machine?


I think two apps, or we are going to have problems with having to keep the multi- and single-player code working, and if we have seperate methods for each, we will have to test both multi- and single-player, whereas if we go with the method that has been accepted for most of this topic, we really only have to thoroughly test one method, for the other is effectively the same.

... wrote:
DominionSpy:

Then the
Code:
AI
class is not needed. You will be able to keep the - say train movement routines within
Code:
Train
class - which makes Model class unnecessary.

Code:
Game
|-> Server (only part able to change data)
|      |-> Map
|      |   |-> Tiles
|      |   |-> Vehicles
|      |   |    |-> Train
|      |   |    \-> ?
|      |   \-> ?
|      \-> Data
|          |-> Track
|          |-> Vehicles
|          \-> ?
.
.
.


Well, I think that the AI should probably be integrated within the vehicles.

William.


Top
   
 Post subject:
PostPosted: Tue Sep 27, 2005 10:09 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
fujitsu wrote:
Collision detection is client!!?? What collision detection do you mean?


GUI vs Game World. Obviously the server does not know where the windows are (and why should it know?) - so the client must scan what was clicked and when.

Collisions between game objects are obviously server side occurances.

Sorry for being ambigous.

Quote:
Are you talking kilobytes, or kilobits?


Kilobytes. 80 kbps. Maybe 120 kbps or so.

Quote:
Whatever you were talking about, we shouldn't need to transfer much data to the client. We simply need to give it details about the vertices, terrain, etc of the tile, and anything that is on the tile, along with an ID for reference with the server.


say we send 20x20 patch (about one screen)

21x21 vertex height * short int = 882 bytes
21x21 vertex data (indexed) * byte = 441 bytes

so you just sent 1 kB of data. Say we compress = with 50% ratio = 600 bytes = 662 bytes. And you didn't even started to send tile info. With 20 snapshots/second you already ate whole bandwidth avalible to you...

This actually gives a reason to give the client access to server data on a local host. To avoid sending millions of vertices we need to give the server and client access to geometry data - and doing that without client access on local machine would double memory requirements.

Toughie.

Quote:
The client doesn't need all of the data about a tile that a server does, as the client doesn't do pathfinding or anything like that. It doesn't need all of the data about a station, because it will request it if and when it needs it, which it may not need to do very often at all.


Obviously - but as you see - the client at least needs data on geometry - to preserve bandwidth.

Also - the protocol needs to be asynchronous - ie - we send the client only the data that is neede for the viewport to display correctly. But - we need to make sure that we don't send much raw data, but mostly indices (like: train 32 broke, or train 36 moved 1 unit forward)

Quote:
I also think that the bandwidth could be limited by just transfering what is needed, say by giving no data for a tile that hasn't changed since the last request. This would take the bandwidth down massively, and the client would only need the data for the current viewport.


Hmm - yes - I see we are on the same page :)

Quote:
The only problem with this approach (that I can see), comes up when we notice that we really have to have a minimap. This means that the data for all of the tiles is going to have to be transferred to the client. We could always have the server do some of the minimap generation, or we could have a tiny amount of data for each tile retrieved, just enough to display the minimap. Otherwise, opening the minimap would create...............................lag.


Indeed. But we can keep the last minimap the client requested and just send an update to it. A diff would suffice.

Quote:
I think two apps, or we are going to have problems with having to keep the multi- and single-player code working, and if we have seperate methods for each, we will have to test both multi- and single-player, whereas if we go with the method that has been accepted for most of this topic, we really only have to thoroughly test one method, for the other is effectively the same.


Yes - I also lean toward that solution. The problems however persist with local client and data redundancy.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Wed Sep 28, 2005 9:43 am 
Offline
Engineer
Engineer

Joined: Tue Jul 12, 2005 8:14 am
Posts: 32
Location: Melbourne suburbs, Victoria, Australia (GMT+10)
I would like to quote most of this, but it would get incredibly long! So...
uzurpator wrote:
fujitsu wrote:
Collision detection is client!!?? What collision detection do you mean?


GUI vs Game World. Obviously the server does not know where the windows are (and why should it know?) - so the client must scan what was clicked and when.


Ahh, good. I don't really count that as collision detection, but I guess it could be called that. Thanks for clearing that up.

... wrote:
Quote:
Are you talking kilobytes, or kilobits?


Kilobytes. 80 kbps. Maybe 120 kbps or so.

Quote:
Whatever you were talking about, we shouldn't need to transfer much data to the client. We simply need to give it details about the vertices, terrain, etc of the tile, and anything that is on the tile, along with an ID for reference with the server.


say we send 20x20 patch (about one screen)

21x21 vertex height * short int = 882 bytes
21x21 vertex data (indexed) * byte = 441 bytes

so you just sent 1 kB of data. Say we compress = with 50% ratio = 600 bytes = 662 bytes. And you didn't even started to send tile info. With 20 snapshots/second you already ate whole bandwidth avalible to you...

This actually gives a reason to give the client access to server data on a local host. To avoid sending millions of vertices we need to give the server and client access to geometry data - and doing that without client access on local machine would double memory requirements.

Toughie.


Very true, we need to work this out somehow... But why 20 whole snapshots per second? Couldn't we do what you specify below for the minimap? And wouldn't many of the tiles be completely empty? These are some questions that need to be answered before we work out what on earth we are going to do about the data transfer...

... wrote:
Quote:
I also think that the bandwidth could be limited by just transfering what is needed, say by giving no data for a tile that hasn't changed since the last request. This would take the bandwidth down massively, and the client would only need the data for the current viewport.


Hmm - yes - I see we are on the same page :)


I must say I don't get what you mean...

... wrote:
Indeed. But we can keep the last minimap the client requested and just send an update to it. A diff would suffice.


Well, not quite a diff, not particularly good for things like that :P... But yes, that idea would be good.

... wrote:
Yes - I also lean toward that solution. The problems however persist with local client and data redundancy.


Yeah, the two program idea is good, but it will have to be thought about a lot!

---------------------

So I ended up quoting most of it, but meh.

William.


Top
   
 Post subject:
PostPosted: Wed Sep 28, 2005 1:47 pm 
Offline
Route Supervisor
Route Supervisor
User avatar

Joined: Fri Oct 03, 2003 8:22 pm
Posts: 449
Location: Edmonton, Alberta
uzurpator wrote:
Grunt wrote:
Anything under "Model" should be available to both the client and the server; although only the server can actually modify that information, the client will still need to have it in order to be able to render the player's view and be able to accurately represent what the client can do.


No no no no.

The (local or not) client cannot access server only data. We are talking about hundreads of megabytes of information. This stunt might work for local client, but via internet it is compleatly unacceptable. For this sole reason we need to start at the stiff bandwidith constraints from scratch.

The client only recieves snapshots (small packages) of data from the server - and sends requests to the server for data. Nothing more.

GUI, drawing and collision detection however are client only occurances.

In the simplest model client asks:

"Give me a leaf of data: 20x20 tiles starting at 482x345"
or
"Give me info on train 282"

and server responds accordingly. What we need to make sure that the data stream will not exceed ~10 kb/s and that client/server will not go async.

You misunderstand my point - I'm trying to get across that the client will still need access to the data structures in order to make sense of the data the server sends to the client. Of course the client doesn't need to know everything about everything in the game world - probably just what it can see at this given point in time or otherwise can get information about (e.g. if you have a list of trains open).


uzurpator wrote:
Hm - yes - but should we develop:

1 application with both client and server embedded?
2 apps communicating via loopback on local machine?


It's possible to have the all-in-one application spawn two threads which would then communicate via loopback - this seems to me as though it would be a good solution.

_________________
Grunt

(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)


Top
   
 Post subject:
PostPosted: Wed Sep 28, 2005 10:08 pm 
Offline
Engineer
Engineer

Joined: Tue Jul 12, 2005 8:14 am
Posts: 32
Location: Melbourne suburbs, Victoria, Australia (GMT+10)
Grunt wrote:
uzurpator wrote:
Hm - yes - but should we develop:

1 application with both client and server embedded?
2 apps communicating via loopback on local machine?


It's possible to have the all-in-one application spawn two threads which would then communicate via loopback - this seems to me as though it would be a good solution.


The thread-spawning thing was exactly what I had in mind for single player.

William.


Top
   
 Post subject:
PostPosted: Thu Sep 29, 2005 7:17 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
Well - if it is made as two seperate apps then we don't need to worry about the thread spawning stuff -> less work. Also it would make it easier to distribute two files - eg upated client or updated server.

Good - however this topic is about game structure - namely - class tree. We should concentrate on the classes essential for the engine to work (ie - generate terrain, make working interface etc).

DominionSpy: have you finished your proposition?

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Thu Sep 29, 2005 11:36 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Oct 03, 2003 11:59 pm
Posts: 1429
Location: Lancashire, UK
uzurpator wrote:
DominionSpy: have you finished your proposition?

No, I was doing it in Paint Shop Pro and it crashed half-way through :(.
I'm going away for the weekend, so I won't be able to work on it till then.

The basic idea is that there is a hierarchy of interfaces in the model, like this:
Code:
IAccessor
    ^
    |
    |
IMutator
    ^
    |
    |
 CObject

The IAccessor interface only has methods to retrieve information. This is the interface for the View.
The IMutator interface has methods to change the data. This is the interface for the Control.
The CObject class then implements the IMutator interface (which extends the IAccessor interface).

The hierarchy in the model is then extended by having a superclass CModel for all the models and extra interfaces for common behaviours such as say IMovable for all objects that are not stationary.

_________________
Image
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.


Top
   
 Post subject:
PostPosted: Sun Oct 16, 2005 9:26 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
Ok - I think we should really disregard this thread and build the tree on the fly.

For now it would constitute something like this:

Code:
God             Satan
 |               |
 |-Server        |-Client
 \-Network       \-Network


God - main program that will boot server and network threads and kill them when necessary
Satan - main program that will boot client and network threadsa and kill them when necessary

Server - for now this class has a main loop that does all the magic, in times to come it will also control all the data the game processes
Network - classes that will talk to each other to remain in touch :)
Client - class doing the displaying of client data

For now we should concentrate on making both Server and Client exchange data

BTW - I name classes by their level in the tree:

God
Seraph
Cherub
Angel
Saint
Blessed

Satan
Daemon
Devil
Imp
Sinner
Damned

Call me creative.

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
 Post subject:
PostPosted: Mon Oct 24, 2005 10:25 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Fri Oct 03, 2003 11:59 pm
Posts: 1429
Location: Lancashire, UK
uzurpator wrote:
Ok - I think we should really disregard this thread and build the tree on the fly.

For now it would constitute something like this:

Code:
God             Satan
 |               |
 |-Server        |-Client
 \-Network       \-Network

I don't see what's wrong with this:
Code:
Server       Client
 |             |
 |-Data        |-Renderer
 \-Network     \-Nework


uzurpator wrote:
Call me creative.

I'd rather call you insane :P. Why do we need to name the classes by thier level any way?

_________________
Image
You're saying I'm a Dominion spy, and don't even know it! - Dr. Bashir
That's the Joker in my avatar, not me. No wait it is me.


Top
   
 Post subject:
PostPosted: Mon Oct 24, 2005 12:20 pm 
Offline
Transport Empire Moderator
Transport Empire Moderator
User avatar

Joined: Fri Jan 10, 2003 12:21 pm
Posts: 2125
Location: Wroclaw, Poland / Katowice, Poland
DominionSpy wrote:
Code:
Server       Client
 |             |
 |-Data        |-Renderer
 \-Network     \-Nework


Nothing wrong with them. Altho in this naming client and server are not classes. They are basicly (note - I omitted network<->server communication data structures - altho we can embed them in the classes)

god.cpp
Code:
#include "server.h"

int main(void)
{
server *server;
server = new server(params);
network *network;
network = new network(params);
server->StartThread(params);
network->StartThread(params);
return 0;
}


So I think that naming them as they were classes is kind of a stretch. Altho come to think of it - this structure would probably be better :)

Code:
BootProg       BootProg
 \-Server       \-Client
   |               |
   |-Data          |-Renderer
   \-Network       \-Nework


bootprog.cpp
Code:
#include "server.h"

int main(void)
{
server *server;
server = new server(params);
server->StartThread(params);
return 0;
}


Quote:
uzurpator wrote:
Call me creative.

I'd rather call you insane :P. Why do we need to name the classes by thier level any way?


I didn't say _we_ I said I use those. They are just to explain to the others the weird terminology I might use :) Disregard them :D

And yes - I am insane :D

_________________
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 30 posts ]  Go to page 1 2 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000-2017 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2017.
Hosted by Zernebok Hosting.