The International Simutrans Forum

 

Author Topic: The Condition of the Working Class in Simutrans  (Read 405 times)

0 Members and 1 Guest are viewing this topic.

Offline Matthew

  • *
  • Posts: 160
  • Languages: EN, some ZH, DE & SQ
The Condition of the Working Class in Simutrans
« on: June 08, 2019, 09:52:18 PM »
In the recent discussion on factories, I mentioned that the pak's mix of working-class housing is interestingly different to actual 19th century towns. I long ago noticed the same thing as Jando: that early working-class (Low/Very Low) housing is largely Hovels, which are low density (16/64 pop) tiles usually found on the periphery of towns, and Townhouses (which are roughly one-third Low, representing domestic servants).

Peripheries and Potteries

While I don't claim to have much understanding of the town generation algorithm, I would speculate that the game places most working-class homes at the edges of urban areas because Hovels are Level 1 and 2 buildings. Putting the poor in low-density buildings on the edge of town would be accurate if we were modelling 21st century Africa and, given Simutrans' history, perhaps it reflects some period of Germany's development. However, it does not reflect Great Britain in the Industrial Revolution. There certainly were shanty towns, but they were not particularly likely to be on the outskirts. One of 19th-century London's most notorious shanty towns was 'the Potteries', in north Kensington. It started off with poor Irish people essentially living in pigsties, so it would have looked pretty much like pak.128-Britain's Hovels. The unfortunate inhabitants of Grenfell Tower were part of a long line of poor immigrants who'd lived on that piece of land in shoddy housing, but all of them lived close to the centre of town.

Rather than shanty towns, most manual labourers and their families lived in slums: areas of cheap housing which were close to the places where they worked and so they walked to work (as Jando and James also noted, this is why the pak shouldn't need transport for Very Low passengers until the 1860s). Since land closer to the centre was more expensive, this had to be high-density housing. In Scotland, this took the form of tenements, which are helpfully represented in the pak from 1870 onwards. But in England, the typical slum building was the court: narrow alleys with two or three storeys of brick-built rooms on two or three sides, entered through a passageway from the public street (or another court). You can see an example in the attached photo. People today sometimes confuse them with the terraced houses we can see today on Coronation Street or in mining areas, but those were often the result of slum clearance schemes; court houses were built back-to-back and not only houses but individual rooms were often shared by several families. Their importance in the economy of Liverpool was summarized by I.C. Taylor:

Quote
"[Courts and cellars] were, in fact, the home of almost half of the town's working-class population for much of the nineteenth century. Cellar dwelling reached a peak after the Famine migration of Irish in 1847 when conservative estimates put this 'underground' population at 30,000. Courts were finally banned in 1864 but by then the borough contained 3,073 courts consisting of 17,825 court houses with an estimated 110,000 population. A thousand courts survived in 1903 and the last fell only in the slum clearance programme of the 1960s." *

Now it must be admitted that our games have less need for dense housing than real-life towns because industry is often added at the peripheries as well. But the industry tends to be much denser than the hovels, and the industries that are found in town centres (such as Fishing Ports and game-creation Markets) often suffer from staff shortages which it is difficult to remedy until Very Low class urban transport becomes available from the 1860s.

Court trial

One obvious way to remedy this omission is to create new citybuildings and so I've modded one of Kieron's lovely terraces (available at https://app.box.com/s/t7d6nl7vf0dolib47tnw1byjpsad6sa5). Here are the key parameters:
Code: [Select]
Name=court_housing_test
copyright=Kieron/MRForrester
type=res
chance=100
population_and_visitor_demand_capacity=168
Level=6
# Terraces
class_proportion[0]=90
class_proportion[1]=10
class_proportion[2]=0
class_proportion[3]=0
class_proportion[4]=0
intro_year=1780
retire_year=1900

I've used it a couple of games and so far, it works as intended - you get dense working-class housing around the centre of towns. I think it is helping to solve the commuter problem, but I'm not certain as there are so many variables at play. The graphics are a work in progress (partly because Blender and I seem to be having a feud).

Like everyone else on this forum, my level of interest in Simutrans waxes and wanes, and there's no point making promises about the future. But I might be able to develop this further if other players could kindly explain a few things to me.

a) What is the relation between population_and_visitor_demand_capacity and the in-game population of the tile/citybuilding? There is a comment in existing datfiles stating that the in-game pop is doubled, but also implying that this depends on metres_per_tile. One of my test games was at 235 mpt, but the in-game population was still exactly double.

b) Following on from that: is the population_and_visitor_demand_capacity supposed to represent the population on the 40m/tile scale or the mpt scale?

c) Courts were a popular choice because they enabled landlords to turn a profit from the space between their street-facing houses. That means that they would be an ideal way to use the new multi-tile citybuilding feature of Simutrans-Extended to expand into empty tiles with a road frontage. James, last year you said that TileCutter was unusable for this pak because it didn't support transparencies, but we now have TileCutter v1.x, which does (in theory). Has anyone tried using the new TileCutter with Extended? I am already struggling with Blender (did I mention how awful Blender's UI is?), Git, Java, and Perl, so I would prefer not to tackle Python if TileCutter is useless.  ;D

One last thing

A comment in the .dat file for Hovels says that they are "Agricultural labourers' dwellings or similar". I think this reflects another misunderstanding of 19th century working-class housing, which lies behind some of the problems with freight networks, and I have written another long post suggesting a solution. But that solution requires C++ coding, far beyond my abilities (I haven't even managed to compile the game yet!  :-[ ). James, if you would like to have that discussion now, on the understanding that the town generation rework isn't likely to start for many months or years, then I'll open another thread. But if it would just be an annoying distraction from your progress with vehicle consists, then I'll keep my thoughts saved in the cloud for a rainy day in the future....

* I.C. Taylor (1970), 'The court and cellar dwelling: The eighteenth century origin of the Liverpool slum', Transactions of the Historic Society of Lancashire and Cheshire, 122, p.69. The PDF also includes some of the best available photos of court housing.
« Last Edit: June 08, 2019, 10:10:35 PM by Matthew »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: The Condition of the Working Class in Simutrans
« Reply #1 on: June 09, 2019, 09:16:50 PM »
Thank you for your work on this, both the research and the pakset creation work. The article about the Liverpool slums was most interesting. The court houses look splendid. Two minor things with those houses: first of all, they would probably benefit from using the clusters feature to create plausible slums; and secondly, unless I am missing something, the fronthouses seem to lack the tunnel entrances necessary to access the couts...? You mention that you are having trouble with Blender - can you elaborate in case I can assist (perhaps in a different thread so that we can focus on the economic isues in this thread)?

I am very interested to note that the latest version of TileCutter has transparency support; I had not realised that until you pointed this out. This is a very happy thing for the future of the pakset, as it will allow much easier creation of multi-tile buildings, and conversion of existing buildings (especially buildings such as the gasworks which have lots of spindly parts that could benefit from transparency) to the new transparent workflow.

The economic issues discussed do raise some complex matters. Starting with the simplest, you correctly surmise that the levels dictate the town growth. What has happened is that the pakset authors created the buildings in the days before classes, and then, when I added the classes feature in 2017, I just added classes to the existing buildings, which may then have left some gaps, such as high density, lower class buildings. I suspect that these additional buildings will assist even without the modifiction to the town growth system planned.

The more complex issue is the town growth system. The current method is quite crude: it simply grows towns from the geographic centre, starting with level 1 buildings and then either renovating existing buildings up to a higher level or radiating outwards with new level 1 buildings whenver it is the town's time to grow, either repeatedly in succession up to a target population on initial map generation, or incrementally in a running game. Town growth is done per town (without reference to overall population) and is based on a fixed level plus the proportion of passengers, mail and goods transported and demanded electricity supplied.

The proposal (see here the outline, and here for a more technical discussion) is for town growth to be much more closely linked to local transport. Thus, instead of being either semi-random or forced by hard-coded constraints in the executable or pakset, the idea is that the density, wealth and mix of commercial, residential and industrial buildings, as well as a tile by tile land value, would be driven by an algorithm closely influenced by local transport. Thus, slums (along with wealthy neighbourhoods, middle-income suburbias and all other manners of locales) should develop organically when local economic conditions (largely dictated by local transport, or, more precisely, local mobility and accessibility to specific sorts of destinations) are correct for them.

In any event, to answer some of your questions: you wrote that the relationship between meters per tile and the relationship between the .dat file parameters for and the in-game figures for the visitor demand and population capacity appeared not to exist; may I ask whether you attempted to change the meters_per_tile setting on an existing game? The meters_per_tile setting cannot be changed for an existing saved game.

In relation to the scale, the economics is always based on the meters per tile setting: the graphical scale of ~40m/tile is not used for any economic calibration. Therefore, assume the 125m/tile scale for the purposes of calibrating population.

I do not believe that anyone has tried using the new TileCutter with Extended, but, since the graphical code is essentially unaltered from Standard, it seems very unlikely that this would not work on Extended as well as on Standard.

As to the other long post about agricultural housing, I suggest that you read the thread containing the techincal discussion of city growth and see how your idea fits into that.

Thank you again for your work on this: it is much appreciated. [/url]

Offline wlindley us

  • Devotee
  • *
  • Posts: 962
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Re: The Condition of the Working Class in Simutrans
« Reply #2 on: June 10, 2019, 12:54:46 PM »
I also encourage you to consider the approach I used in drawing the stone monuments — create a group of 1x1 buildings, pluggable together like Lego blocks in your .dat file.  This means you can have a dozen variations of your buildings with different combinations of single tiles. No need for cutting tiles if each of them can work stand-alone; let the game engine recombine them for you.  (I do wish Blender could better be integrated into our workflow!)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: The Condition of the Working Class in Simutrans
« Reply #3 on: June 12, 2019, 09:09:01 AM »
I also encourage you to consider the approach I used in drawing the stone monuments — create a group of 1x1 buildings, pluggable together like Lego blocks in your .dat file.  This means you can have a dozen variations of your buildings with different combinations of single tiles. No need for cutting tiles if each of them can work stand-alone; let the game engine recombine them for you.  (I do wish Blender could better be integrated into our workflow!)

I think that that can only work with multi-tile buildings, can it not? These buildings are single tile buildings. This may be relevant for larger buildings later, however.

Incidentally, I expect that the availability of a transparent compatible TileCutter will improve the workflow efficiency and final quality of buildings produced using your method.

Offline Matthew

  • *
  • Posts: 160
  • Languages: EN, some ZH, DE & SQ
Re: The Condition of the Working Class in Simutrans
« Reply #4 on: June 20, 2019, 07:22:00 PM »
Two minor things with those houses: first of all, they would probably benefit from using the clusters feature to create plausible slums;

Sorry, I didn't paste that in the .dat snippet. They're in cluster 9.

Quote
and secondly, unless I am missing something, the fronthouses seem to lack the tunnel entrances necessary to access the courts...?

You can always tell these cheap courts have been put up by shoddy builders.  :P
This has been fixed as part of the ongoing process of taking Kieron's beautiful terraces and turning them into something uglier & more crowded. This screenshot shows two 1x1 courts placed by the game, as a city centre cluster, on the left. On the right is a single 1x2 building placed manually.

Quote
You mention that you are having trouble with Blender - can you elaborate in case I can assist (perhaps in a different thread so that we can focus on the economic isues in this thread)?

Thank you for the offer. So far, I've been plaguing blender.stackoverflow.com with my generic Blender questions, since I'm already harrassing people here enough with Simutrans-specific ones!

Quote
I am very interested to note that the latest version of TileCutter has transparency support; I had not realised that until you pointed this out. This is a very happy thing for the future of the pakset, as it will allow much easier creation of multi-tile buildings, and conversion of existing buildings (especially buildings such as the gasworks which have lots of spindly parts that could benefit from transparency) to the new transparent workflow.
...
I do not believe that anyone has tried using the new TileCutter with Extended, but, since the graphical code is essentially unaltered from Standard, it seems very unlikely that this would not work on Extended as well as on Standard.

I haven't experimented with TileCutter yet, as wlindley's suggestion of modular buildings might make it unnecessary for this project. But it's helpful to clarify that there are no known obstacles.

Quote
The economic issues discussed do raise some complex matters. Starting with the simplest, you correctly surmise that the levels dictate the town growth. What has happened is that the pakset authors created the buildings in the days before classes, and then, when I added the classes feature in 2017, I just added classes to the existing buildings, which may then have left some gaps, such as high density, lower class buildings. I suspect that these additional buildings will assist even without the modifiction to the town growth system planned.

The more complex issue is the town growth system. The current method is quite crude: it simply grows towns from the geographic centre, starting with level 1 buildings and then either renovating existing buildings up to a higher level or radiating outwards with new level 1 buildings whenver it is the town's time to grow, either repeatedly in succession up to a target population on initial map generation, or incrementally in a running game. Town growth is done per town (without reference to overall population) and is based on a fixed level plus the proportion of passengers, mail and goods transported and demanded electricity supplied.

Thank you for outlining the current system so clearly. Although it isn't perfect, it's certainly more than adequate for a transport sim, and I'm grateful to you and all the others who have made it work so well. I'm still trying to work out whether this pak has the desired economic effect in a test game.

Quote
In any event, to answer some of your questions: you wrote that the relationship between meters per tile and the relationship between the .dat file parameters for and the in-game figures for the visitor demand and population capacity appeared not to exist; may I ask whether you attempted to change the meters_per_tile setting on an existing game? The meters_per_tile setting cannot be changed for an existing saved game.

That's the kind of point that I could have easily overlooked, but in this case I'm certain that the test game has had 235 mpt since the start, because I wrote a batch file to switch between the default settings (for online games) and 235 mpt. And it shows up in-game in all the calculations.

Quote
In relation to the scale, the economics is always based on the meters per tile setting: the graphical scale of ~40m/tile is not used for any economic calibration. Therefore, assume the 125m/tile scale for the purposes of calibrating population.

Thank you; it's helpful to know that we should assume 125m/tile in buildings' economic statistics. There are numerous comments in existing .dat files about the doubling the number in .dat for 125mpt, which made me think that population_and_visitor_demand_capacity was scaled by mpt, but I obviously got that wrong. Now I know, I will try to work out accurate figures.

Quote
The proposal (see here the outline, and here for a more technical discussion) is for town growth to be much more closely linked to local transport. Thus, instead of being either semi-random or forced by hard-coded constraints in the executable or pakset, the idea is that the density, wealth and mix of commercial, residential and industrial buildings, as well as a tile by tile land value, would be driven by an algorithm closely influenced by local transport. Thus, slums (along with wealthy neighbourhoods, middle-income suburbias and all other manners of locales) should develop organically when local economic conditions (largely dictated by local transport, or, more precisely, local mobility and accessibility to specific sorts of destinations) are correct for them.
...
As to the other long post about agricultural housing, I suggest that you read the thread containing the techincal discussion of city growth and see how your idea fits into that.
 

I enjoyed reading those threads last year, so it will be no trouble to look them again before I post!

Quote
Thank you again for your work on this: it is much appreciated. [/url]

Thank you for your helpful comments. I know this is a slow reply, but I wanted to wait until I'd made some progress.

I also encourage you to consider the approach I used in drawing the stone monuments — create a group of 1x1 buildings, pluggable together like Lego blocks in your .dat file.  This means you can have a dozen variations of your buildings with different combinations of single tiles. No need for cutting tiles if each of them can work stand-alone; let the game engine recombine them for you.  (I do wish Blender could better be integrated into our workflow!)

This has been a productive suggestion; thank you! As a result, I spent an evening last week cutting up your tiles (with actual scissors) and trying to fit them back together again using the .dat file.  ;D

After some trial-and-error, I think I've got my head around it and I now seem to have a functioning multi-tile citybuilding. It will be interesting to see how the game engine handles it before I consider making more.

Offline ACarlotti

  • *
  • Posts: 444
Re: The Condition of the Working Class in Simutrans
« Reply #5 on: June 20, 2019, 10:06:14 PM »
I wrote a batch file to switch between the default settings (for online games) and 235 mpt.
If you're not running the server, then this is unnecessary, because all the settings that need to match are set by the savegame or the server. Even if you are running the server, it would only be necessary to change the mpt setting when you create a new server game.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18593
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: The Condition of the Working Class in Simutrans
« Reply #6 on: June 22, 2019, 12:52:24 PM »
In relation to meters per tile settings: it should be noted that, whether playing a local or an online game, it is not possible to change these after game creation. This is because these settings embed data of a very wide variety of sorts into a wide variety of objects that, once created, are not explicitly linked back to the meters per tile setting, and it would take a very large amount of coding work to write code to unpick each of these data and reset them to what would be correct for a different meters per tile setting. Given that the utility of being able to change the meters per tile setting in a game already created is low, the very large amount of work necessary to achieve this I did not consider worthwhile.

In any event, thank you for your ongoing work on this: this is most worthwhile. I think that there might be an error in one of your links, as the pictures for the multi-tile city building seem to be the same as for the 1x1 court houses; I suspect that it is the link for the multi-tile building that is incorrect. I should be grateful if you could post the correct link for this, as I should be very interested to see it.

The 1x1 courts do look good with their archways, although I notice that the brick texture seems to be much lighter than on the original terraces - is this intentional? They do seem to be somewhat too light for the style of the pakset (whose lighting setup is intended to emulate a cloudy day, hence the lack of any strong shadows in the pakset (apart from aircraft, whose shadows are hard-coded into the game engine and serve a function)). Do note that some Blender issues may be specific to the specific Simutrans/Pak128.Britain Blender setup (especially those relating to rendering), so it might be that some of your questions may be better dealt with here.

Thank you again for your work on this so far: it is much appreciated.