Transport Tycoon Forums

glenjimen wrote:I don't know if this is possible in a 2-D game, but it would be cool if, after zooming out past zoom level "far", the screen automatically became the mini-map.

I like that idea. I will try if it works. (Problem will be that the minimap is pixel based. And sending actively changed pixel data to the graphics card is slow... Sending huge pixel data like the minimap is very slow...)

Oh wow, 10 million km in width and height seems quite large. Is this the value for each map? Or could it be lower? Why not trying to create a map system in which you have maps of, say, 40.000km in width and same in height and if you get to an edge there isn't actually an edge but the same map again much like the real earth. Obviously, the area would be larger than the real earth's surface due to not having a sphere but it seems like a compromise. Anyways, one would be able to have kind of a sphere - interesting in terms of long air routes. It might be much work though.

The map has a lot water, I'm guessing this can be changed using the seed?

I also love the scroll out mini map idea.

One last thing: why not going for real runway lengths when maps are this huge?

I think you won't be happy to get a map larger than 10k x 10k. Raw integer in Java is 4bytes. So if for example you store grid coordinate in two integer (x,y) you will have to support 100 000 000 * 2 integers what gives about 750 MB. And that's only a tip of the iceberg, because, I guess you store some height data also so in this example taking one float per grid would be additional 340 MB. So this gives 1GB of data. But still this is only the top more has to be there like objects. And all this has to be stored in some kind of collections. My guess is so big map would easily eat about 4GB of data. And still there's memory overhead Java adds for objects which is 8 bytes per object. Also there are CPU performance related reasons - the more objects you have the more updates per frame have to be done. I think a 2048 x 2048 will be the way to go in this case. Of course - if you have an i7 CPU with 6 cores and the game will be heavily parraller in execution , and 16 GB of RAM - things may look better.

There is also a thing I've figured out that the off-screen elements must not be updated every frame, because player can't see them, so there could be a little cheat that vehicles outside the screen are updated every 1/4 of a second. This is the only way to optimize such a extreme environment.

I'm pretty sure smallfly has done the math to be sure it works. As he's using seeds to generate the maps, storage needed is definitely smaller than what you calculated.
Still, over two billion tiles seems a bit unrealistic in any terms.

Edit: And this is certainly the first time I ever think that a map is too large

LocoMH wrote:Oh wow, 10 million km in width and height seems quite large.

Just think of an unlimited map. The exact size does not matter.

LocoMH wrote:The map has a lot water, I'm guessing this can be changed using the seed?

Currently the seed does not influence the total amount of water. But it could be the case for future versions. Currently the seed only influences terrain shapes, so that no map looks like the other.

LocoMH wrote:I also love the scroll out mini map idea.

The terrain view and the mini map have different purposes. The terrain view shows your objects, vehicles etc. The mini map shows statistical information. Sometimes you want to see terrain view and mini map at the same time. I will stick to the current seperation of terrain view and mini map. Videos say more than thousand words, so here we go:
http://www.youtube.com/watch?v=QQ9Ac-c0XDE&noredirect=1

LocoMH wrote:One last thing: why not going for real runway lengths when maps are this huge?

You already explained why (see above). The maximum zoom must be able to show most of the runway. And there are several other issues. For example the terrain generator must generate very long flat stripes, so that you can find a place for your extreme long runway.

lukasz1985 wrote:I think you won't be happy to get a map larger than 10k x 10k. Raw integer in Java is 4bytes. So if for example you store grid coordinate in two integer (x,y) you will have to support 100 000 000 * 2 integers what gives about 750 MB. And that's only a tip of the iceberg, because, I guess you store some height data also so in this example taking one float per grid would be additional 340 MB. So this gives 1GB of data. But still this is only the top more has to be there like objects. And all this has to be stored in some kind of collections. My guess is so big map would easily eat about 4GB of data. And still there's memory overhead Java adds for objects which is 8 bytes per object. Also there are CPU performance related reasons - the more objects you have the more updates per frame have to be done. I think a 2048 x 2048 will be the way to go in this case. Of course - if you have an i7 CPU with 6 cores and the game will be heavily parraller in execution , and 16 GB of RAM - things may look better.

The terrain is calculated based on a random generator seed. The terrain heights are not stored. As soon as you scroll around the map, the currently visible terrain heights are calculated using the
current seed and displayed. (The only heights being stored are the ones edited by the player) Have a look at the bottom right corner of the video ("memory usage" in the monitor window) You see that there are less than 100 MB used.)

lukasz1985 wrote:There is also a thing I've figured out that the off-screen elements must not be updated every frame, because player can't see them, so there could be a little cheat that vehicles outside the screen are updated every 1/4 of a second. This is the only way to optimize such a extreme environment.

Yeah. This is quite the way P1SIM is calculating currently invisible mobile objects.

So what for terraforming? If you terraform the terrain you have to store height somewhere. Do you want do this using lazy initialization, i.e.: by storing only height data for pieces where land was changed? Or no terraforming here?

lukasz1985 wrote:If you terraform the terrain you have to store height somewhere. Do you want do this (...) by storing only height data for pieces where land was changed?

Yes.

the video looks great so mini map resizes - that's amazing i like it

smallfly wrote:The terrain is calculated based on a random generator seed. The terrain heights are not stored. As soon as you scroll around the map, the currently visible terrain heights are calculated using the
current seed and displayed. (The only heights being stored are the ones edited by the player)

So, are you saying, if you build a small town, every time you move the screen to the right to look at some undeveloped land, that land is randomly generated.

You move to the right and see a mountain, move back to your town, move to the right and see a lake, move back to town...

I know many people want large maps, but I somehow personally prefer smaller, limited maps after playing locomotion for some years .
An option to limit the size of a map and a simple map editor would be nice (at least for a singleplayer game). Apart from the idea of endless maps which may be not so endless because there are spritelimits or other problems there exist some other interesting ideas for maps, for example in the civilization series: a "planet" with limited snow borders in the south/north and if you scroll to the right or left side you return to your starting point or another idea is a round map like in settler6.

glenjimen wrote:You move to the right and see a mountain, move back to your town, move to the right and see a lake, move back to town...

No, because the random seed does not change. You see a mountain every time, but that mountain isn't stored when you're not looking at it.

But how about playing from heightmaps? In this case you will have to store the height data.

And another thing is that how about performance when scrolling maps? I guess CPU needs more time as the algorithm generating heights gets more complicated. I guess you use some caching. So there is actually a trade-of between the map fancyness and performance. I wonder how you deal with OpenGL, do you stream buffers or vertex arrays. But this you may not know if you use Slick2d.

lukasz1985 wrote:But how about playing from heightmaps? In this case you will have to store the height data.

If you're playing from a heightmap you already have a copy of the height data. (And unless the heightmap is also disproportionately colossal, it fits into memory easily.)

And another thing is that how about performance when scrolling maps? I guess CPU needs more time as the algorithm generating heights gets more complicated. I guess you use some caching. So there is actually a trade-of between the map fancyness and performance.

Not a significant one. Elite - on the 2MHz BBC Micro in 1984 - generates 125-planet galaxies from a random seed with practically no perceptible lag. I cannot believe, on any modern (and by modern, I'm including the 450MHz K6-3 I retired last year) hardware, any sensible algorithm without some gratuitous antioptimisation bug can't generate a screenful of map faster than you can blink - think about the way that Minecraft chunks just turn up without perceptible delay (absent network lag), and Minecraft is not the best optimised program ever.

But remember how much abstaraction is built over there. Elite was a pure Assembly while P1SiM is Java and that is 2 abstraction levels higher (+ OS and Library overhead). Nevertheless I agree with that design decision especially because Java is very memory hungry.

The current terrain related algorithms work fine and highly performant. Thus I would like to go on with the logistics paths development now.

But I respect your wishes. And if there is a greater group of people that prefer a limited map and no randomly generated but completely self designed terrain (or a height map based one), I'm sure I'll find a way to implement that. But that would be an additional feature. The original idea of P1SIM is having an unlimited map.

"Unlimited" maps make some sense for a multiplayer game, because many games which have both singleplayer and multiplayer are too small for multiplayer and too large for singleplayer, but I believe minecraft which has a similar concept (I never played it because I hate it to be limited to blocky graphics) has a limited mapsize on Xbox360, too.

robo wrote:"Unlimited" maps make some sense for a multiplayer game, because many games which have both singleplayer and multiplayer are too small for multiplayer and too large for singleplayer, but I believe minecraft which has a similar concept (I never played it because I hate it to be limited to blocky graphics) has a limited mapsize on Xbox360, too.

AFAIK that's down to a technical limitation, not a design decision, and it's something they'd like to overcome.

I like the video - more videos, please, they show how things actually look!

Robo wrote:

if you scroll to the right or left side you return to your starting point

That's what I meant, too. Graphically, it would look kinda like this example with a single island and water around it - you'd have to do some math to have steady transitions on the edges, obviously. So, whenever you reach the edge (which is only defined internally), you just get to the beginning of the map again.

LocoMH wrote:So, whenever you reach the edge (which is only defined internally), you just get to the beginning of the map again.

I will keep the concept in mind for future updates.

Should the world be a sphere ?