Where is the final DD?

Archived discussions related to Transport Empire. Read-only access only.

Moderator: Transport Empire Moderators

Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

iLess wrote:BTW. Hellfire: I'm still waiting for an answer to my mail...
True, true. Wow, a lot of discussion going on here. :D

I'll try to use bbcode to show who wrote what.

Code: Select all

Start e-mail
iLess wrote:Hello again

Thanks for the fast reply. About http://www.tt-forums.net/viewtopic.php?t=24083. The Unicode Problem u had can be solved quite easily:

std::wstring s = L"....";
std::wcout << s;

this should work.
Thanks a lot. I tried that approach and it worked perfectly.
iLess wrote:
Hellfire wrote:There is a task list, http://www.tt-forums.net/viewtopic.php?t=24083. It's pretty recent, about a month old. As I am the only programmer working on Transport Empire, progress is really slow. ;)
The task list is quite short and a lot of things can be added to it. If you'd like to contribute, but in a different area than mentioned there, please let me know.

Yeah the list is kinda small ;-). With core being the biggest and most interesting part though. About Configuration... How do you mean that by tab-limited text files for configuration? why not something more structuraly like

enginetype <Typename> {
attribute1 value1;
attribute2 value2;
....
}

instead of

enginetype <typename> value1 value2 ...
Tab-delimited files have the advantage that most spreadsheet programs can read and write them. Also, some other games use this approach succesfully.
iLess wrote:
Hellfire wrote:
iLess wrote:And about the DD. I saw something about the possibility to build underground tracks and stations. But it seems not clearly defined yet what happens, when two different tracks (off different companies) cross.


True. I'm not sure whether those details should be put in there. If you look through the code, you'll notice that some classes or methods have extensive commenting. These comments should be recorded in some document, but I didn't have the time to do that. The details about buidling underground and overgroud (e.g. tunnels and bridges) should be recorded in such a document. Not in the DD.
Hm I see. Well IMO this is something that affects gameplay heavily and not just a implementation detail that should be left to the programmer to decide. But I'm just new so I don't know much about this projects policies.
Hellfire wrote:
iLess wrote:IMO there should be some way of going over or under the existing track. To do this the underground should be divided into 3d tiles (boxes) that are the continuation of the ground tiles into the 3rd dimension. This structure could also be used to organize bridges that pass over other bridges or buildings.

That's funny... During an IRC discussion, this idea also came forward. This is indeed the way to go. There are other problems with building underground, though. Have you played Locomotion? If you have, then you'll probably know what I'm talking about.

No unfortunately i haven't played Locomotion. I don't think there is a Mac Version. So what were the major problems with building underground structures there?
When you try to build underground in populated areas, you inevitably run into problems. You usually can't see what you're building because surface-objects are blocking the view. You can hide buildings and trees, but when you hide the roads, you also hide the tracks you're trying to build underground.

We will need to find a proper way to build underground. Perhaps a simple "hide everything above height=n" will do the trick. Before the GUI for building underground is implemented, it should be discussed. It hasn't really come up yet, except for some "building underground should be better" posts in the ideas topic.
iLess wrote:well atm. I don't really know yet what i want to do. I mean you took core, which includes almost everything besides GUI. I kinda would be interested in core too.
That's great, really! The core is waaaaaaay too big to work on just by myself. I can use every help I can get. :)
iLess wrote:Is the source on sourceforge all you did so far?
Yes, it is. I always commit before shutdown. (Except when the code does not compile). How well (or not) does the code run on a Mac?
iLess wrote:I was just wondering about the Registrar stuff. How do you intend to handle stuff the user just watched at but has scrolled away from? just leave it in the cache and simulate on client. or throw it away completely?
My original idea was to just leave it there and update it when the user looks at it.
iLess wrote:Doesn't scrolling actually get very slow whenever the client wants to see a new part of the map but has to w8 until all information on that part has been transfered to him?
If the region that is registered for updates is exactly the size of the visible area, it would indeed. That's why it should be larger than the visible area. If the user scrolls, the registration is updated, BUT in the ideal case, all the tiles are already on the client side BEFORE the user can see them while scrolling.
iLess wrote:Or maybe at the beginning the state of the whole map is sent to the user, and after that only the part visible is updated.
Imagine a 1024x1024 map. Suppose each tile has 12 bytes of information. Then you're pumping 12Mb over the network and the game hasn't even started yet.
iLess wrote:So whenever the client scrolls or jumps to another place the old cached data is showed until the new info has arrived. This would have the side-effect though that if someone had a high ping, he would see stuff (houses, tracks, trains...) suddenly pop into existence when he jumps to another position.
That's a possible way to handle that. I thought of this one: there is no cached data. Old data is not shown. If the data from the server hasn't arrived yet, then the UI will gradually fade in the new data whenever it arrives.
iLess wrote:Could not scrolling and jumping around excessively overload the available bandwith and the server? To counter that problem the server would have to find out what the last cached information on the client in that particular area is and only send the stuff that changed or so...
You're thinking along the same lines as I have lately. If the server knows what the client has in cache, we can indeed save a lot on bandwidth. However, this will lead to an increased memory and cpu load at the server, which will make the game slower for all players. As most internet connections have enough bandwidth to handle the data traffic without too much lag (e.g. the user does not have to wait five seconds before the map shows up), this is less of an issue at this moment.
iLess wrote:Well i don't know but maybe there has already been lots off discussion about that. But as there is so much in this forum i didn't have the time yet to read everything. BTW. did you decide what additional libraries you are going to use?
No, I have not, although SDL+OpenGL were selected for the UI.

Code: Select all

End e-mail
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

Steve wrote:I also heard about CVS, but perhaps Hellfire has that sorted already.
Yes, I use the CVS at Sourceforge.
Hyronymus wrote:
iLess wrote:About Track laying: I saw this cool java demo written by some guy where you could lay almost freeform tracks. What made you decide against freeform tracks and use a gridbased system?
We decided against Java, our intention is a cross-platform game.
I think there's a small misunderstanding here... iLess was talking about the tracklaying mechanism PJay built. It was less about the fact that he built it in Java. If we use PJay's tracklaying system, we can rebuild it in C++.
iLess wrote:
Hyronymus wrote:We decided against Java,...
Maybe i did formulate it in a wrong way. I didn't say the game should be in java. I mean this track-laying java-proggi was just a prototype for a concept.
Yup... I jumped the gun. :P
iLess wrote:EDIT: I just played a little around with a wiki and forum. Its not much yet. But it seems to work. http://tempire.selfip.org/.
Plz Tell me if it is too slow. I'm still learning though how to edit wiki stuff. Its kinda weird.
Yay! Cool, a site to play with. ;) MediaWiki indeed has its quirks, but if you can get it to work, it's really nice. The old wiki worked nicely...
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
User avatar
orudge
Administrator
Administrator
Posts: 25129
Joined: 26 Jan 2001 20:18
Skype: orudge
Location: Banchory, UK
Contact:

Post by orudge »

CVS, hmm, I'd suggest Subversion would be the better thing to use. SourceForge supports that now too, can convert your existing CVS repository automatically too.
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

If you can point out the advantages of subversion, sure. ;)

I use Eclipse for development, which has great CVS support built-in. I don't know how good the Subversion plugin for Eclipse is. I'd have to check that out, but I don't have the time for that yet.

Until then, CVS will do fine. :)
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
User avatar
iLess
Engineer
Engineer
Posts: 38
Joined: 23 Apr 2006 01:21

Post by iLess »

Hellfire wrote: Tab-delimited files have the advantage that most spreadsheet programs can read and write them. Also, some other games use this approach successfully.


Well although I don't like tab-delimited files, it seems that they are suited for this particular kind of game. So as I don't really have an argument against using them, I think it is the way to go. I just want to point out, that it would be no problem at all for me, to parse something more complex. The Boost library has a very good Parsing library - named Spirit- that lets you define the Parser directly inside the C++-Code by overloading the Operators and thus defining some pseudo EBNF-Language inside C++. Pretty cool stuff. (the library that contains Spirit and lots of other usefull libs: http://www.boost.org and Spirit itself: http://www.boost.org/libs/spirit/)
Hellfire wrote: Yes, it is. I always commit before shutdown. (Except when the code does not compile). How well (or not) does the code run on a Mac?


I ran it and it seems to work. Here's the output of the client.

Code: Select all

Connecting...
Connected!
Requesting (0, 0) - (7, 7)
requesting...
PacketFactory: I can't handle a packet of type 24 (yet)!
PacketFactory: I can't handle a packet of type 30 (yet)!
Packet received!
Got MapChunkPacket. Processing...
Requesting (8, 8) - (15, 15)
requesting...
Requesting (0, 0) - (7, 7)
We already have this piece of the map!
Our map now looks like this:
01 01 00 01 00 01 01 00 xx xx xx xx xx xx xx xx 
00 01 01 01 01 00 00 00 xx xx xx xx xx xx xx xx 
01 01 00 01 00 00 00 01 xx xx xx xx xx xx xx xx 
01 01 00 01 01 01 01 01 xx xx xx xx xx xx xx xx 
00 01 01 01 00 01 00 01 xx xx xx xx xx xx xx xx 
00 01 01 00 00 00 00 00 xx xx xx xx xx xx xx xx 
01 00 01 01 00 01 01 01 xx xx xx xx xx xx xx xx 
00 00 00 00 01 01 00 01 xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 
PacketFactory: I can't handle a packet of type 28 (yet)!
Hellfire wrote: Imagine a 1024x1024 map. Suppose each tile has 12 bytes of information. Then you're pumping 12Mb over the network and the game hasn't even started yet.
Well I see now thats not what we really want ;-). Having the player only see smaller views of the whole should make it also possible to let the game continue while new players join in.

Suppose the game has already started, and all of the map has changed since the Beginning. Now another player joins in... What info does he get?
He registers the position he is looking at and gets all the information about that area + a little more, for scrolling. This Information includes Tiles, Buildings, Stations, Tracks, and Vehicles.

Now there is some general information which is kind-of detached from the map. This includes all the players on the server, and their companies and other stuff like financial statistics etc. As this is not too much, we could send that too at the beginning of the game.
But now for vehicles, it gets more complicated. I would like to see a list of all the vehicles of type X which are owned by company Y, or a list of all industries of type X. If i get all informations about them this would be an overkill (especially for vehicles and towns). Suddenly the player would have all vehicles on the map and the client would continue to simulate their position... Or all the towns with their buildings would just float around in the empty space ;-). Not to mention the huge amount of data that would have to be sent. How can this problem be solved?
1. Have different classes to describe all the properties of a gameobject, that are handled like different separate entities.
2. Take an ObjectView Approach. This is basically what you have done already for the map.

As I really like your Registrar-Approach I would like to expand this view-Idea to every aspect of the game. I think this will make it also possible to support later-on games where the world is simulated on more than one single server. For this we need to classify the data that describes an object. Whenever the client wants info about a gameobject, he would implicitly or explicitly define what layer of information he wants.
This could be the following 3 layers:
1. Basic Information (Name+identifier+object Type. This would just mean "Hey look! I exist")
2. Visual and State Information (model, position, orientation, speed etc...)
3. Non-Visual and Meta Information (cost, income, age, reliability, etc.)

For browsing through the list of all vehicles of type X of company Y the client would only need to get Basic Information about their existence. If the user would select one and open a dialog that contains more information, 3.) and possibly 2.) would have to be supplied too. Today I found a good article that discusses exactly what I have in mind (http://www.gamasutra.com/resource_guide ... ght_01.htm).

Now refering to the article i think an ObjectView for every Tile would surely be an overkill as with N players having visited all tiles, the data for the map would be N times bigger in the worst case, which is not acceptable. A View for each group of mxm Tiles would be an option but, this would induce restrictions on the map dimensions.

As most of the data we have is more or less static - tiles and tracks won't change that often - the ObjectViews for those won't be too complex. But for vehicles it becomes tricky. As they will move each frame, they will pretty much define what the user perceives as "the game is running smooth or not". So i think their movement should be handled mostly by the client. Thus giving him the possibility to put in more or less frames of movement (if he has the available spare time).
For vehicles I would suggest one View per vehicle. The View would get updates of position and speed on keyframes, whenever the vehicle needs to change its direction, stop or reverse (or something completely different). Then the View would interpolate the state between the old and the new states. But with this approach another problem arises. The Physics on the Server (which is running at N FPS) will have another timestep than the one on the client (running at M FPS), thus introducing gradual divergence of the gameobject state between server and client, if we use floatingpoint numbers.
Hellfire wrote: If the user scrolls, the registration is updated, BUT in the ideal case, all the tiles are already on the client side BEFORE the user can see them while scrolling.
This should work fine, as long as the user doesn't jump to a completely different area of the map, or tries to look at the mini map ;-). For handling the mini map there should be a special mode of view registration where the client receives only a small subset of information about the area he is looking at. In terms of ObjectViews we would need either another class of Views which follow only a subset of the MapState information, or the MapObjectView has to be configurable to select only a subset of information.
A third approach would be to have an ObjectView for each different component of the MapState (tracks, tiletype, trees, buildings on it etc.,) and combine them as needed.

BTW. Have you ever had a look at OpenTTD. How did they solve those problems?
Hellfire wrote: That's a possible way to handle that. I thought of this one: there is no cached data. Old data is not shown. If the data from the server hasn't arrived yet, then the UI will gradually fade in the new data whenever it arrives.
With vehicles i think this is the way to go, but when the user jumps to a new part of the map, he jumps into nothing and suddenly a landscape fades in from the dark?
Or we show a flat landscape (on base level) and lots of small people running around and gradually building up the stuff that should be there ;-)

I hope my thoughts are not too chaotic. But I just can't help it I am a little a chaotic person ;-).
Last edited by iLess on 01 May 2006 22:24, edited 3 times in total.
User avatar
orudge
Administrator
Administrator
Posts: 25129
Joined: 26 Jan 2001 20:18
Skype: orudge
Location: Banchory, UK
Contact:

Post by orudge »

Hellfire wrote:If you can point out the advantages of subversion, sure. ;)
Amongst other things:

* File and directory versioning
* Easy directory renaming and deletion
* Cheap file and directory copies
* Atomic commits
* Efficient handling of binary files
* Metadata support
* Faster than CVS
* WebDAV/DeltaV support

;)
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

iLess wrote:Very long post
I'll answer your post tomorrow night... I should be in bed right now, instead of browsing the forums... :roll:

(At a first glance, it looks very promising, though)
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
User avatar
iLess
Engineer
Engineer
Posts: 38
Joined: 23 Apr 2006 01:21

Post by iLess »

It was "tomorrow" Hellfire. where's your answer? ;-)
Hellfire
Transport Empire Developer
Transport Empire Developer
Posts: 699
Joined: 03 Feb 2003 09:30
Location: Back at the office

Post by Hellfire »

iLess wrote:Well although I don't like tab-delimited files, it seems that they are suited for this particular kind of game. So as I don't really have an argument against using them, I think it is the way to go. I just want to point out, that it would be no problem at all for me, to parse something more complex. The Boost library has a very good Parsing library - named Spirit- that lets you define the Parser directly inside the C++-Code by overloading the Operators and thus defining some pseudo EBNF-Language inside C++. Pretty cool stuff. (the library that contains Spirit and lots of other usefull libs: http://www.boost.org and Spirit itself: http://www.boost.org/libs/spirit/)

I ran it and it seems to work. Here's the output of the client.

Code: Select all

...
Requesting (0, 0) - (7, 7)
...
Requesting (8, 8) - (15, 15)
...
Requesting (0, 0) - (7, 7)
Hmmm... That looks a bit like old code. The HEAD revision of the CVS gives different output. Which revision of client.cpp do you have?
iLess wrote:Well I see now thats not what we really want ;-). Having the player only see smaller views of the whole should make it also possible to let the game continue while new players join in.

Suppose the game has already started, and all of the map has changed since the Beginning. Now another player joins in... What info does he get?
He registers the position he is looking at and gets all the information about that area + a little more, for scrolling. This Information includes Tiles, Buildings, Stations, Tracks, and Vehicles.

Now there is some general information which is kind-of detached from the map. This includes all the players on the server, and their companies and other stuff like financial statistics etc. As this is not too much, we could send that too at the beginning of the game.
But now for vehicles, it gets more complicated. I would like to see a list of all the vehicles of type X which are owned by company Y, or a list of all industries of type X. If i get all informations about them this would be an overkill (especially for vehicles and towns). Suddenly the player would have all vehicles on the map and the client would continue to simulate their position... Or all the towns with their buildings would just float around in the empty space ;-). Not to mention the huge amount of data that would have to be sent. How can this problem be solved?
1. Have different classes to describe all the properties of a gameobject, that are handled like different separate entities.
2. Take an ObjectView Approach. This is basically what you have done already for the map.
Just a note here: the Registration object has a Type member. The constants for this member variable are enumerated in Registration.h. The map is just one kind of registration. Others would indeed be "vehicle list" or "station list" or "player info".
iLess wrote:As I really like your Registrar-Approach I would like to expand this view-Idea to every aspect of the game. I think this will make it also possible to support later-on games where the world is simulated on more than one single server.
It was my intention to apply the Registrar approach to every aspect of the game. The client application will be as "dumb" as possible. The only logic it contains is to display things to the user. Internally, the server runs at a constant "framerate". (Frame is not the right word here. Just remember that each loop of the server takes a minimum amount of time). Clients run one frame behind the server. The client has two states in memory, say at t=0 and t=1. Between t=0 and t=1, all the data is interpolated, to give the player an experience that is as smooth as possible, even though the actual calculations are done at a fixed rate.

I like your "multiple server" idea. This would indeed be one of the possibilities, if the registrar approach is done consistently.
iLess wrote:For this we need to classify the data that describes an object. Whenever the client wants info about a gameobject, he would implicitly or explicitly define what layer of information he wants.
This could be the following 3 layers:
1. Basic Information (Name+identifier+object Type. This would just mean "Hey look! I exist")
2. Visual and State Information (model, position, orientation, speed etc...)
3. Non-Visual and Meta Information (cost, income, age, reliability, etc.)
There are probably more, but that won't be a problem. We can add more whenever we encounter them.
iLess wrote:For browsing through the list of all vehicles of type X of company Y the client would only need to get Basic Information about their existence.
True.
iLess wrote: If the user would select one and open a dialog that contains more information, 3.) and possibly 2.) would have to be supplied too. Today I found a good article that discusses exactly what I have in mind (http://www.gamasutra.com/resource_guide ... ght_01.htm).
WTF? I had to register at that site...
iLess wrote:Now refering to the article i think an ObjectView for every Tile would surely be an overkill as with N players having visited all tiles, the data for the map would be N times bigger in the worst case, which is not acceptable. A View for each group of mxm Tiles would be an option but, this would induce restrictions on the map dimensions.
Those object views are similar to the Registrar system I've built. The registrar has an obvious advantage though: a Registration object that captures the entire map will use the same amount of memory as a Registration object that captures just one tile.
iLess wrote:As most of the data we have is more or less static - tiles and tracks won't change that often - the ObjectViews for those won't be too complex. But for vehicles it becomes tricky. As they will move each frame, they will pretty much define what the user perceives as "the game is running smooth or not". So i think their movement should be handled mostly by the client. Thus giving him the possibility to put in more or less frames of movement (if he has the available spare time).
That's one of the reasons why the client will be behind the server: the server will only send positions. The client will interpolate those positions, creating the illusion of smooth gameplay.
iLess wrote:For vehicles I would suggest one View per vehicle. The View would get updates of position and speed on keyframes, whenever the vehicle needs to change its direction, stop or reverse (or something completely different). Then the View would interpolate the state between the old and the new states. But with this approach another problem arises. The Physics on the Server (which is running at N FPS) will have another timestep than the one on the client (running at M FPS), thus introducing gradual divergence of the gameobject state between server and client, if we use floatingpoint numbers.
Woops... Basically, we both say the same. :oops:

As for the divergence: at this moment, the server runs at 20 updates per second (20ups), unless the load is too high, then it will be slower. The client runs at max speed. Hopefully, this is quite a lot faster than 20 frames per second. Because of this difference, we must keep this fact in mind at all times. At the beginning of each loop, the server transmits the frame number to all the clients. The clients can use this to keep the game in sync with the server.
iLess wrote:
Hellfire wrote:If the user scrolls, the registration is updated, BUT in the ideal case, all the tiles are already on the client side BEFORE the user can see them while scrolling.
This should work fine, as long as the user doesn't jump to a completely different area of the map, or tries to look at the mini map ;-). For handling the mini map there should be a special mode of view registration where the client receives only a small subset of information about the area he is looking at. In terms of ObjectViews we would need either another class of Views which follow only a subset of the MapState information, or the MapObjectView has to be configurable to select only a subset of information.
A third approach would be to have an ObjectView for each different component of the MapState (tracks, tiletype, trees, buildings on it etc.,) and combine them as needed.
The word minimap says it all, really. :)

We could just send a (compressed) bitmap or a diff whenever a user regged it and it changes.
iLess wrote:BTW. Have you ever had a look at OpenTTD. How did they solve those problems?
Nope. Haven't, sorry.
iLess wrote:
Hellfire wrote: That's a possible way to handle that. I thought of this one: there is no cached data. Old data is not shown. If the data from the server hasn't arrived yet, then the UI will gradually fade in the new data whenever it arrives.
With vehicles i think this is the way to go, but when the user jumps to a new part of the map, he jumps into nothing and suddenly a landscape fades in from the dark?
Or we show a flat landscape (on base level) and lots of small people running around and gradually building up the stuff that should be there ;-)
Heh... That would be the humorous approach for the same problem. ;)
Feel free to contact me over Email! My current timezone: Europe/Amsterdam (GMT+1 or GMT+2)

Code: Select all

+------------Oo.------+
| Transport Empire -> |
+---------------------+
[ General TE Discussion ] [ TE Development ] [ TE Coding ]
Under construction...
User avatar
Hyronymus
Tycoon
Tycoon
Posts: 13233
Joined: 03 Dec 2002 10:36
Location: The Netherlands
Contact:

Post by Hyronymus »

Hellfire wrote:Heh... That would be the humorous approach for the same problem. ;)
Doesn't SimCity 4 render the map slowly on slow PC's and for the time being display a framework of all buildings etc?
User avatar
Purno
Tycoon
Tycoon
Posts: 16659
Joined: 30 Mar 2004 12:30
Location: Almere, The Netherlands

Post by Purno »

Hyronymus wrote:
Hellfire wrote:Heh... That would be the humorous approach for the same problem. ;)
Doesn't SimCity 4 render the map slowly on slow PC's and for the time being display a framework of all buildings etc?
3000 does. Dunno about 4.
Contributor to the The 2cc Set and Dutch Trainset. Inventor of the Metro concept. Retired Graphics Artist.
Image Image
Download TT | Latest TTDPatch | OpenTTD | OpenTTDCoop | BaNaNaS: OpenTTD content system | 2048² OTTD scenario of the Netherlands
GRF Codec | GRF Crawler | GRF Maker | Usefull graphics & tools sites | NML Documentation Wiki | NFO Documentation Wiki
All my graphics are licensed under GPL. "Always remember you're unique, just like everyone else."
Costas
Engineer
Engineer
Posts: 105
Joined: 31 Mar 2006 17:03

Post by Costas »

hi guys nice to see the project is moving!

i am no programer or anything but there is something u may be interested:

there is a game called aces high. Its a plane simulator online and the amazing thing about it is that their servers can have max 500 players or more at the same time all flying planes!!! i dont know how they do it though :roll: but i never had major lag problems

mb u give the units/vehicles freedom so that they communicate with the server like virtual players, like bots in day of defeat or counterstrike. then even if there is lag, the train will jump to its proper position (cant remember the term)

if all that sounds dumb well at least i gave it a try! :D

on second thought it does sound dumb ahahsh oh well too late

Topic locked, new Design Document is being written by Hyronymus. Please read the progress here.
Locked

Return to “Transport Empire Development Archive”

Who is online

Users browsing this forum: No registered users and 5 guests