Author
Topic: Land-dedication and city-planning (Read 972 times)

I'd like to propose land dedication with custom rules. This is about the building types (res, ind, com - perhaps more)

Land Dedication

Currently, Simutrans decides which building type it needs (based on homeless and unemployed), then checks the cityrules for places where it could be buildt, weights them according to existing buildings next to that place, and then comes to a decision and builds the house.

I think Simutrans should do this not for actually building a house, but for dedicating the land to a building type. When a building needs to be buildt, it would then choose a spot among those dedicated spots.

# Symbols in rules:# S = must not be road# s = must be road# n = must be bare land# H = must not be house# h = must be house# T = must not be a stop# t = must be a stop# . = anything matches# SPACE = next rowwould be extended with

# Symbols in rules:# R = must not be RES# r = must be RES# C = must not be COM# c = must be COM# I = must not be IND# i = must be IND# D = must not be dedicated# d = must be dedicatedInstead of just a "house" we would define "res", "com" or "ind". For backwards compatibility, "house" would still be available. If land would get dedicated to "house", the existing affinity rules apply to find out what it's actually dedicated to, obviously other dedicated tiles are taken into consideration as if they were buildings.

Planned roadsAn additional step would be to allow the city to dedicate land to roads. Obviously, if you already know where buildings are going to be, you could plan ahead where further roads would go as well. To make sure a city does not go maniac and plan it's growth over the whole map, I think it would make sense to redefine city boundarys. At least on the minimap, they are always shown as rectangles - perhaps they could be in a more defined form, and the city only ever plans within it's own boarders?

Planning ToolsThe Map Editor could give access to land dedication tools, for the player to plan instead of the game. This would obviously be very nice for city planning. While this game is not a city builder, it should please the model-railway kind of players.

More building typesWhat if, besides RES, IND and COM, there would be more types of buildings, maybe subtypes? For example, you could have the type GARDEN. Using land-dedication, you could make it so GARDEN can only appear next to RES. Balanced living spaces. Or what about a type SKYSCRAPER? With land dedication, you could make sure no two SKYSCRAPER are ever next to each other, and instead surrounded by (not quite as tall) normal COM buildings.PATIO could be an inner courtyard that would be used for the center of a 3x3 building block, and only appear there. PLAZA could be something only buildt on a tile surrounded by road or COM. PORT could be only buildt near water tiles,...(For the record - I am not talking about hardcoding those names. I'd simply go with RES#, COM# and IND#, where # is an index. The old type would tell the game how the distribution of pax and post works in that building type)

City IndivitualityPretty much every city (in the same climate) looks the same. This is because each city follows the same rules. What if a city had some random values to help give it personality? For example, minimum_building_desity and renovation_percentage could be different for each city. You could also affect the likelyhood something get's buildt, so one city has a lot more RES, while another has more IND buildings. (that's affected by employment and shelter, but still)

Hmm, I think SimuCity would be a nice enough game, but for me I like to play SimuTrans, e.g. focus on the transport side. To be honest, I am never too worried about which building the game puts where, I am just interested in connecting them.

As for giving them an individual feel: I currently use at lot of city attractions (90) with each having a chance of 33 out of 100 to be built. In combination with 25 levels with each 8 buildings for COM and RES and 20 levels with each 5 buildings for IND, this gives a lot of variation, enough for my taste. (And then I don't use climate at all...).

You can focus on the transport side. Nothing of my suggestion affects the transport side of the game in any way, it only affects how cities are generated on their own.

As for the name thing... my favorite game is called "Crusader Kings" - but most people don't go on crusades these days, since they are too busy reforming some pagan faiths, unifying India, or fending off Mongols or an Aztec Invasion. And still, whenever someone suggests they should add China (which happens very, VERY often) somebody tells them that it's a bad idea, because it is called Crusader Kings.

Someone has to tell them that they should have not added the Aztecs then.

Oh, the wonders of feature creep.

As to the original idea: This goes and comes back from time to time. I agree with two points:

1) Simutrans is focused on transportation. SimCity is more suitable for city-planning simulation.2) If one doesn't find a feature interesting, they can just not use it (so long as it does not hurt the rest of the game).

In my opinion, any city-planning tool of any sort would be more sensible -- makes more sense -- if it were public player only. I could question why a private-owned transportation company would want to plan ahead a city, but not a public player. It's like saying if you want to focus on transportation aspect, you can play as a company and leave any OP/admin tools alone, it won't hurt your game; but if you want some planning, switch to public player for a bit, the tools are there.

Planning tools would come in handy if you are server admin on a multiplayer game, but you'll need to make any planning visible on the map/terrain to the private players (some kind of my toggle-able planning highlighter?).

In my opinion, any city-planning tool of any sort would be more sensible -- makes more sense -- if it were public player only.

Hence I would place the tools that allow the player to do so in the map editor. Though ultimately, the placement is up to whoever writes the menu configuration for a pakset. But that's not really what this is about, it's more like a side effect. The main goal is to be able to define the building spaces of RES, IND and CUR (and potentially more) in the cityrules, rather then just probabilities to place them more likely next to each other.This would most certainly come at a cost and make it harder for the game to actually find a proper building space once a building needs to be buildt, since there would be a lot more checks. This is why these complicated rules for citybuilding should be split up from actually building, since it could be done whenever there are resources available to do it, perhaps even in pause mode (since nothing actively changes). Flag the tiles surrounding the city based on the rules, and put all available spots for each type of building in a list - perhaps with a chance level. Therefore, when the building actually gets buildt, the game just needs to pick a spot from the list instead of doing all kinds of checks.

If land dedication as an automated mechanism existed, it would only be a very small step to involve the (public) player in it, too.

One approach would be to have cities allocate areas of land. Instead of a city being a single rectangle of land that is dynamically resized, a city is a collection of unique immutable rectangles. When a city needs a new area to expand, it allocates a new rectangle of land. All city land areas cover a unique area, even with regard to other cities.

Since city areas cannot overlap, there are no problems with cities growing into each other. Since the sum of all areas that make up a city is not limited to a rectangle, cities can grow in more natural shapes such as around coasts or avoiding hills. Since cities expand by allocating an entire area at a time, road layout can be pre-constructed and rough terrain terraformed to be more suitable. Since only a small area is being allocated for construction it can be assigned a specific layout style or theme that is visually more natural.

If a significant portion of an allocated area is taken up by non-road objects, eg a massive passenger terminal or rail yard, such that it is no longer practical to build in then that area might be assigned to only filler structures such as parks or empty lots to give an aesthetically pleasing use of land. Like wise if an area of land is allocates that is too small to be meaningful such filler structures might be used. If two cities grow into each other then areas and their inhabitants might change ownership if doing so would help city area cohesion.

This would have benefits to players. City expansion is a lot more predictable and players might set up transportation for freshly expanded areas knowing that they will get well developed relatively quickly. Currently cities expand in such a sprawled out way that often they grow away from where transport is placed, or where transport was never intended to be placed. Players will not need to manually place roads or terraform rough areas for efficient growth, reducing the amount of city management they have to do. Tools might be added to suggest to cities where to expand next as well, allowing transport to be setup in preparation for expansion.

It also opens up the potential of major game mechanic changes. For example passenger and mail stops might service an entire city area rather than just the pickup radius which can solve the annoyances with bus networks in cities.

The city creation is now already extremely time consuming during the creation of new maps. Adding three different zones wil further increase this a lot. Also there are already zones in Simutrans, which are obeyed, providing that the final level of com, ind and res are similar (which they are not for many pak sets).

Also given that TTD has no zoning whasoever (and built its huge success with just 17 buildings in total), I am somewhat inclined to find this feature as non-essential for a transport simulator. The overwhelming majority seems to not care for it.

Nevertheless, a simcity simutrans fork for those buildings heavy paksets like the comic paks might be a good idea.

One approach would be to have cities allocate areas of land. Instead of a city being a single rectangle of land that is dynamically resized, a city is a collection of unique immutable rectangles. When a city needs a new area to expand, it allocates a new rectangle of land. All city land areas cover a unique area, even with regard to other cities. [...]

Let's see if I got this all right:To have a name for it, let's call the rectangular areas districts. So a city would claim land for a new district. These districts could be themed - as an example, we could have commercial districts, industrial districts,... and each district can have different internal rules. I suppose there are also rules about where districts could spawn, eg. the current rules for ind, com and res could apply for districts of these typese.Since a district is planned at once, more terrain transformation could be done to make the district more suitable. As an example, an industrial district would need to be as flat as possible; a residential district can keep some hills.You say road layout could be pre-planned. I guess you would have roads between the districts, thus making the roads inside just a matter of style, rather then being needed to connect parts of the city?If the city tries to create a district, but things are in the way, you want to use filler structures. Now, districts need to have a specific size in order to allow for a pre-defined road layout. Therefore, it could happen that tiles cannot be assigned to a grid, simply because there is no pre-defined district small enough for them. There should probably be an option to have district without pre-defined roads that can be any size, using similar rules to the current ones to fill them.

If larger areas of land are allocated at once, wouldn't that mean that 2*1 and 2*2 areas could be reserved for multi-tile city buildings rather easily?

given that TTD has no zoning whasoever (and built its huge success with just 17 buildings in total), I am somewhat inclined to find this feature as non-essential for a transport simulator. The overwhelming majority seems to not care for it.

Not quite a fair comparison.OTTD has, according to their wiki (https://wiki.openttd.org/Trains), at most 31 trains in a 'climate' (pretty much a pakset), which already includes monorail, MagLev and carriages, way, WAY less then an average pakset for Simutrans.Anno 1602 belongs to the citybuilding-genre, and AFAIR there were 3 different buildings for each citizen level with no zoning, making 15 'citybuildings' in total. There were other buildings of course, but those would be best compared to factories and industry. I'm not sure how many the original SimCity had, but probably not too many either.

So it has nothing to do with being a transporting game or a city building game, Simutrans is just generally excessive in how many graphics it uses.

I'd like to add another argument here: Simutrans has inner-city traffic - I don't think that even exists in (O)TTD. This is an aspect that's often unloved, but there are games specifically around that kind of thing - eg. Cities in Motion. If you look at scenarios, the only I can think of top of my head is the NY scenario - A giant city map. A primary gameplay aspect of Simutrans is pax transport, and pax come from cities - but cities are not just 'pax factories', and the houses are not just it's 'fields'. I don't want to go too deep into a discussion about how to improve inner-city networks, but as a matter of fact, it's an element of Simutrans. Which makes cities and how they get created kinda important.

Nevertheless, a simcity simutrans fork for those buildings heavy paksets like the comic paks might be a good idea.

I'm not too much into forks, but I can understand that the creation of new maps would be even more time consuming with my ideas, since any advantage that land dedication has during pause mode or under lower load do not apply.Since Yona-TYT already mentioned scripted rules, would that be a solution? If there was a fork that added such advanced citybuilding rules, map creation would still take a lot more time in it. Wouldn't it be easier to toggle which to use, so there is no 'community split', and rather players can decide whether their PC and patience can handle it?

Just a few cents to the discussion. Zoning in real cities is not permanent. Think of old industrial zones (Brownfields) being converted to commercial or residential zones. Also zoning is not strict. Smaller shopping areas are often in the middle of residential zones, or even some smaller workshops. And there are buildings which are partly commercial and partly residential. I think that rules preferring similar buildings and the cluster feature are able to generate nice cities. I won't stop anyone from adding zones, but I'm happy without. What I would like more is support for multi tile cityhouses or combined res+com.

With a proper balanced pak set, simutrans obeys such zones nicely. Here anexample of pak64.japan, where great car has been taken to hav all level available until the end. See here a city with two industrial (red) and one commercial district (blue).

With a proper balanced pak set, simutrans obeys such zones nicely. Here anexample of pak64.japan, where great car has been taken to hav all level available until the end. See here a city with two industrial (red) and one commercial district (blue).

Nobody claimed otherwise. Buildings of one type flock together, and so they cumulate without need to define actual zones or districts in the code. It's actually a really elegant solution for basic zoning, and nice to see at lower levels in p192c as well.But there are issues with it: For these zones to work, there need to be buildings for each level for each type.

As you can see in your screen, the buildings in the commercial zone and in the left industrial zone are nearly the same size, multistore buildings. It makes sense, they produce the same amount of mail. You can visually see that the right industrial zone would require less vehicles to be covered.

Maybe that's how it actually is in Japan, I was never there. But when I look at maps of citys around here, industrial zones are full of low buildings. The highest you see in industrial zones are usually tanks and chimneys, while the buildings are about two floors high (more likely one floor with a high ceiling), but there is also a lot of space for various goods with no height at all. Of course, there are much higher buildings in industrial zones as well, but they are really massive in area as well, and only get that high in the center, a bit like a pyramid. So they can't be represented with current one-tile-citybuildings - plus, those would be factories.Residential zones can be much higher, say about 5 floors on average, up to ten floors. It just makes sense for those bigger buildings (per Tile-area) to have a higher level than Industry.Commercial is an odd one, since it means both stores and offices. Or does it? Either way, pretty much any skyscraper, even if it has living space in it, would probably be defined as a "commercial building". And obviously, a massive world-trade-center would have a much higher level than a ten-floor-residental building. Furthermore, these skyscrapers would be placed next to each other, unless there are much smaller buildings with the same high level.

Currently, there is not much strategy in how to operate busses in different areas. Sure, industry only offers half the mail, but that's hardly worth changing schedules for. But if your industrial area would only go up to level 10, the residential area to 20, and the commercial area to 30, it would definitelly have an impact on how to build bus routes through cities, giving the different kind of zones meaning besides looks.[But this could be solved much easier: Res only has 50% of the post, Ind only has 50% of the pax. Allow these things to be defined in simuconfig - then, small industrial buildings could have much higher levels, but at a very low percentage of pax, so a oil tank can have the same level as a skyscraper in the 'backend', but only a fragment of people to transport to the player. Totally different request, though]