Home › Forums › General Discussion › [PROPOSAL][MAPS] Regions in Train-Fever maps.
- This topic has 1 reply, 1 voice, and was last updated 8 years, 10 months ago by electricmonk2k.
-
AuthorPosts
-
January 10, 2016 at 18:16 #20996electricmonk2kParticipant
Hi, It has been announced that the next patch is going to improve the map-generation options. There have been some threads (here and here) that discuss this, as well as a few points made in my very long list of suggestions for improving Train Fever. However, what nobody has mentioned so far is adding regions to the map. The idea behind having regions in Train Fever maps is not an atomic idea, and therefore, it can be implemented in several layers/stages (eg. only the ideas that influence the map-generator could be implemented, but the ideas for the in-game effect of regions could be implemented later).
- Using height-maps as a base for additional processing: The simplest is that when you enable importing heightmaps, you should allow the map-generator to apply some additional processing to the imported map (the base-map). For example, if the hilliness (amount of hills/mountains) in the TF map-generator is set to low, then the imported heightmap (the base-map) could contain the base-altitude of the region (which could be mostly flat but with a few large areas of high altitude). This way, you can generate maps containing large plateaux with not many hills. By using the same base-map, you can use TF’s built in generator to apply additional processing to the base-map and make many variations on the same map. In Transport Tycoon Deluxe when playing the Arctic map, half the map (a triangular area) would be a high plateau and half the map close to sea-level. This could be implemented in TF if the imported map was divided into two triangular regions of different height. Of course, more complicated layouts would be possible using a more complicated base-map.
- Using region-maps to tell the map-generator what to do in each region: A slightly more elaborate way of adding regions is to have the ability to import a bitmap whose colours give different sets of parameters to the map-generator for the part of the map represented by the bitmap (a physical-geography region-map). For example, one colour in the bitmap could mean “perfectly flat”, one “slightly flat” (Train-Fever’s ‘flat’ option), “hilly” (Train-Fever’s ‘medium’ option), “mountainous” (Train-Fever’s ‘hilly’ option), and “extreme” (more mountainous than even TF’s existing most mountainous option (‘hilly’) – if the whole map was ‘extreme’, TF would be unplayable (without a really huge tunnelling/terraforming budget), but if only parts of the map were ‘extreme’, it could pose some interesting challenges and enable us to generate some Switzerland-like maps). This could be combined with the first idea by using a both a separate base-map bitmap for the base height-map along with the physical-geography region-map that controls the applied hilliness (and maybe a few other parameters such as roughness) to apply additional processing to the base map on a per-region basis. Without a base-map, each region of the region-map could have a base altitude (so that things like plateaux can be created), but maybe it is possible to combine regional base-altitudes with a base-map. One consequence of this idea is that if you use a base-map and a physical-geography region-map based on the real world, it would be possible to create maps that resemble the real world when zoomed out, yet when you zoom in, the map is different each time the map-seed is changed. This will enable you to play on real-world maps yet have an element of randomness in the terrain in each game. Additionally, the water-percentage could be individually set for each region. I’m not quite sure how transitioning between different regions would be handled, but perhaps, each region could be expanded by a certain number of height-map pixels, and the game will interpolate the height according to how far away it is from the edge of the region (but even this might make regional-transitions a bit too obvious).
- Using additional region-maps to control town-density, etc.: As well as having a bitmap for controlling the hilliness of a region, you could also have an additional bitmap (region-map) to control things the density of towns according to region. Each region could have additional parameters so that as well as the density of towns, you could have things such as the ratio of small-towns to cities per region, and the maximum number of towns per region (this could even be 0). This could make for some really interesting maps. This way, you could create regions where towns are clustered close together (and for example, give it the characteristic of the German Ruhr area), whereas regions with a lower town-density will have a more rural feel to them. This town-density region-map would be a different region-map than the physical geography region-map, although you could instruct the map-generator to use the same bitmap for both, and in that case, not only will you save time if you want your town-density to correspond to the physical-geography type, but the map-generator will require less data in memory. You could also use this map to control industry density as well, or even have a separate industry-density map … which brings me on to my next point.
- Industrial / Resource region-maps: Sometimes, it may be nice to have certain industries absent from parts of the map to encourage longer-distance goods-lines. But sometimes, you might just want to create realistic coal-seams for example. You could create binary resource-maps where a particular resource (or industry) is either present or absent. Up to 8 of these binary resource-maps could be combined into a single 8-bit bitmap. For the vanilla TF industries, 8 bits is enough, but if there was a mod that increased the total number of industries, you’d have to divide the resource-map into several bitmaps (in fact, this should be possible even with fewer than 8 industries/resources so that creating resource-maps in graphics-editors becomes less cluttered). As well as binary-resource-maps, you could create resource-maps where a certain number of bits determines the density of a particular resource. So if two bits were applied to iron, ’00’ would mean iron is absent, ’01’ would mean a low iron density, ’10’ medium and ’11’ high. You could of course combine multi-bit resource-maps in the same bitmap (in the graphics editor, the bitmap’s palette could be constructed in such a way that for example, Iron could be represented by 3 shades of red (bits 0 and 1), and coal by 3 shades of green (bits 2 and 3), and the overlap would be shown using various shades of yellow), but in this case, having more than one resource might get messy so it may be best to have a different bitmap for each resource. Of course, multiple resources could share a layer so a certain bit could be both coal and iron, for example (all coal-seams and iron-seams would be in the same place).
The above suggestions affect the map-generator only (although if new industries opened randomly during the game, they would still have to refer to the industry/resource maps, and if a cliff is rendered in a region rich in iron, it could use a redder texture). Below are some suggestions for how regions could be used in-game.
- Culture-maps: These could dictate things like what language/etymology is used for the town-names and bus-stop names in each map, giving each region of the map a distinct ‘nationality’. Also, certain buildings would only appear in some of the regions defined in the culture-maps. That way, each regions’ towns could have their own architectural style. For example, the area representing Northern Europe could have buildings inspired by Hanseatic architectural styles, Alpine towns could have Alpine architecture, and Mediterranean town could have Mediterranean architecture. The area representing Eastern Europe could produce a lot of monotonous concrete architecture in the period of 1945-1989. As well as different town-buildings, perhaps this could also affect the appearance of industries, road-styles, or even station styles. Another idea could even involve the towns having a different road-layout style according to region – ‘American’ towns could have all the roads laid out in a grid, whereas ‘European’ towns could have a more organic road-layout (what it’s like now) (perhaps the roads could try and follow the height-contours), or even towns where the roads radiate from a central point. There are two ways culture-maps could be implemented in-game.
- Using the town to store culture-data. This has the advantage that the game would not require the extra memory for the data-structure used for the culture-map. What happens here is that during the map-generation phase, the map-generator assigns each town a particular culture. That way, when deciding what to name the bus-stops and what types of buildings to allow, instead of referencing a large bitmap, it just needs to reference the town for such things. The dis-advantage to this method is that towns can grow outside of their regions on the culture-maps, and town-ownerships of distant industries etc. will not respect the culture-maps.
- Using the cultural region-map in-game. While this would increase the memory-requirements (unless a scaled culture-map is used), towns would not be allowed to expand into different regions (the map generator may require a minimum distance between a town-centre and a region-boundary) (also, I’m not sure how exclaves would be handled). As well as preventing towns from expanding into different regions, the town-ownership of an industry or station would use a similar algorithm to the existing algorithm, but would only consider towns in the same region. Another feature that could be implemented is that when goods automatically ‘walk’ if a destination is close enough, this will only happen if the source and destination are in the same region (self-moving goods cannot cross a region-boundary). However, this could also mean that in order to serve an industry, the station and the industry (along with the road connecting them) would have to be in the same region. Likewise, a station would not be able to serve a town-building if they were in different regions (and stations would not be allowed to straddle region-boundaries).
- Vegetation maps: Used to determine which species of trees are present/absent in a particular region. It would be nice to see each region given it’s own set of trees (also, increasing the altitude could also affect the distribution of trees – the higher you go, the more Conifer trees and fewer Broadleaf trees (the ‘tree-line’ could also change according to the region)). Perhaps the vegetation-map would just determine which species of trees inhabit a region, and to determine the tree-density, a resource-map could be used (although you might want to determine tree-density in a vegetation-map instead if you did not want forest-industries popping up wherever there is a sizeable forest). Like with culture-maps, to save from having to reference an extra-bitmap during the game, each town could store it’s own set of vegetation-parameters, and the type of vegetation will depend on which town ‘owns’ a particular piece of land. As well as trees, we can determine the density etc. of farms if farms are nothing more than eye-candy – however, farms would probably best be determined by the resource-maps (this would be handy if there was an agricultural cargo-vector). One additional idea which I’m not sure how practical it would be to implement would be to mix Temperate and Wild-West textures, but I suspect that that would not only require some work, but would increase the amount of textures stored in memory which could cause the game to slow down (unless the graphics card has a huge amount of texture-memory) – and this doesn’t even address the problem of how to handle the boundary between the two types of textures).
Given the above ideas, each region on the map will truly be given a unique character! But there’s more…
- Construction-cost maps: The price for construction/terraforming could be different in each region. This also has the advantage that once the player has established a profitable network in a cheap-region, they can’t terraform the new more-expensive regions as much as they can terraform their old cheap region. For this to have an effect on gameplay, the construction costs would have to be orders of magnitude greater in some regions than in others (I think this is somewhat unrealistic in the real-world, but this will give the player a challenge and prevent the game from becoming too tedious once they can afford to ignore all construction-costs in the cheap regions).
Anyway, because the large maps would require an extremely large bitmap to maintain a 1:1 correspondence between bitmap-pixels and heightmap-pixels, region-maps could map to the game’s map at a ratio of 1:4, 1:16, 1:256 etc. With a high ratio, some of the geographical region-maps might appear too blocky (eg. the base-map), but with some sort of smoothing, that could be sorted out. Also, high-ratios in the culture-maps won’t be so noticeable.
As well as using imported bitmaps for regions, it would be possible to divide the map into regions using a pre-defined combinations of primitive shapes (triangles, squares, circles, etc.). For example, in Transport Tycoon Deluxe when I play the Arctic level, the world is divided into two triangles, one contains low-lying farmlands, and the other contains snowy plateaux that are far from a farm and require a transportation network to feed. This could be one of many pre-defined region-maps in TF consisting only of primitives.
If the player does not want to spend ages tweaking the settings for each individual region, there could be a button for each region to randomise the parameters for each region. Likewise, there could be a button to randomise the parameters for a particular region-map for all regions, or all region-maps for all regions. Also, each ‘colour’ of the region-maps could come with it’s own set of pre-defined settings depending on what type of region-map it is (eg. for physical geography maps, colour #1 could be flat, colour #2 could be hilly, colour #3 mountainous (and perhaps colour #0 could always be water)). Maybe one of the .lua files could be used to pre-define default values for a particular colour (this would come in handy if you want to add mods and you want one of the colours’ default values to be a modded entity (eg. a new type of industry)).
If all of this seems too much, could you at least add the ability to export the generated heightmap so we can manually tweak the maps until our heart’s content.
January 23, 2016 at 18:32 #21078electricmonk2kParticipantAnother idea I had for the different cultural regions would be to make slight changes to the pedestrian/driving behaviour. Depending on the region, drivers would be less or more likely to do things such as give way to pedestrians waiting to cross the road and other vehicles. Things like how reckless the driver is or how likely a passenger is to make an unsafe crossing of the road could also change from region to region. This would be more interesting if disasters were added (such as a bus colliding with a pedestrian), but even if there were no disasters, it would still have an influence on traffic-flow.
Also, the different types of roads could have different speed-limits depending on the region.
-
AuthorPosts
- The forum ‘General Discussion’ is closed to new topics and replies.