Game architecture
Moderator: Transport Empire Moderators
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Game architecture
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
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Ok - a quickie showing my idea of the game structure
Asterisk shows what is required NOW to do.
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)
Asterisk shows what is required NOW to do.
Code: Select all
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: Select all
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
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.uzurpator wrote:Comments? Anyone?
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: Select all
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
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.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Well. One thing that comes to mind here...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.
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Transport Empire Developer
- Posts: 699
- Joined: 03 Feb 2003 09:30
- Location: Back at the office
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:DominionSpy wrote:Code: Select all
Game |-> Server (only part able to change data) | |-> AI | \-> Model ...
- 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)
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Code: Select all
+------------Oo.------+
| Transport Empire -> |
+---------------------+
Under construction...
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
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.Hellfire wrote: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:DominionSpy wrote:Code: Select all
Game |-> Server (only part able to change data) | |-> AI | \-> Model ...
- 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.
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.
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.
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.)
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
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.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.
William.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
No no no no.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.
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.
Hm - yes - but should we develop: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.
1 application with both client and server embedded?
2 apps communicating via loopback on local machine?
DominionSpy:
Then the
Code: Select all
AI
Code: Select all
Train
Code: Select all
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
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...uzurpator wrote:No no no no.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.
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.
Collision detection is client!!?? What collision detection do you mean?... 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.
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.... 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.
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.
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:Hm - yes - but should we develop: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.
1 application with both client and server embedded?
2 apps communicating via loopback on local machine?
Well, I think that the AI should probably be integrated within the vehicles.... wrote: DominionSpy:
Then theclass is not needed. You will be able to keep the - say train movement routines withinCode: Select all
AI
class - which makes Model class unnecessary.Code: Select all
Train
Code: Select all
Game |-> Server (only part able to change data) | |-> Map | | |-> Tiles | | |-> Vehicles | | | |-> Train | | | \-> ? | | \-> ? | \-> Data | |-> Track | |-> Vehicles | \-> ? . . .
William.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
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.fujitsu wrote:Collision detection is client!!?? What collision detection do you mean?
Collisions between game objects are obviously server side occurances.
Sorry for being ambigous.
Kilobytes. 80 kbps. Maybe 120 kbps or so.Are you talking kilobytes, or kilobits?
say we send 20x20 patch (about one screen)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.
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.
Obviously - but as you see - the client at least needs data on geometry - to preserve bandwidth.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.
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)
Hmm - yes - I see we are on the same pageI 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.
Indeed. But we can keep the last minimap the client requested and just send an update to it. A diff would suffice.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.
Yes - I also lean toward that solution. The problems however persist with local client and data redundancy.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.
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
I would like to quote most of this, but it would get incredibly long! So...
---------------------
So I ended up quoting most of it, but meh.
William.
Ahh, good. I don't really count that as collision detection, but I guess it could be called that. Thanks for clearing that up.uzurpator wrote: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.fujitsu wrote:Collision detection is client!!?? What collision detection do you mean?
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:Kilobytes. 80 kbps. Maybe 120 kbps or so.Are you talking kilobytes, or kilobits?
say we send 20x20 patch (about one screen)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.
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.
I must say I don't get what you mean...... wrote:Hmm - yes - I see we are on the same pageI 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.
Well, not quite a diff, not particularly good for things like that ... But yes, that idea would be good.... wrote: Indeed. But we can keep the last minimap the client requested and just send an update to it. A diff would suffice.
Yeah, the two program idea is good, but it will have to be thought about a lot!... wrote: Yes - I also lean toward that solution. The problems however persist with local client and data redundancy.
---------------------
So I ended up quoting most of it, but meh.
William.
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:No no no no.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.
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.
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.uzurpator wrote: Hm - yes - but should we develop:
1 application with both client and server embedded?
2 apps communicating via loopback on local machine?
Grunt
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
(aka Stephan Grunt, CEO of Grunt Transport Inc. since 1994.)
-
- Engineer
- Posts: 32
- Joined: 12 Jul 2005 08:14
- Location: Melbourne suburbs, Victoria, Australia (GMT+10)
The thread-spawning thing was exactly what I had in mind for single player.Grunt wrote: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.uzurpator wrote: Hm - yes - but should we develop:
1 application with both client and server embedded?
2 apps communicating via loopback on local machine?
William.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: 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?
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
No, I was doing it in Paint Shop Pro and it crashed half-way through .uzurpator wrote:DominionSpy: have you finished your proposition?
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: Select all
IAccessor
^
|
|
IMutator
^
|
|
CObject
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.
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.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: 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:
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.
For now it would constitute something like this:
Code: Select all
God Satan
| |
|-Server |-Client
\-Network \-Network
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
- DominionSpy
- Tycoon
- Posts: 1429
- Joined: 03 Oct 2003 23:59
- Location: Lancashire, UK
- Contact:
I don't see what's wrong with this: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: Select all
God Satan | | |-Server |-Client \-Network \-Network
Code: Select all
Server Client
| |
|-Data |-Renderer
\-Network \-Nework
I'd rather call you insane . Why do we need to name the classes by thier level any way?uzurpator wrote:Call me creative.
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.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
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)DominionSpy wrote:Code: Select all
Server Client | | |-Data |-Renderer \-Network \-Nework
god.cpp
Code: Select all
#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;
}
Code: Select all
BootProg BootProg
\-Server \-Client
| |
|-Data |-Renderer
\-Network \-Nework
Code: Select all
#include "server.h"
int main(void)
{
server *server;
server = new server(params);
server->StartThread(params);
return 0;
}
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 themI'd rather call you insane . Why do we need to name the classes by thier level any way?uzurpator wrote:Call me creative.
And yes - I am insane
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.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Who is online
Users browsing this forum: No registered users and 4 guests