The Condition of the Working Class in Simutrans

[Matthew]

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:

"[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 Expand

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. 

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.

[jamespetts]

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]

[wlindley]

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!)

[jamespetts]

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.

[Matthew]

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.

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. 
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.

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!

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.

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.

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.

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.

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!

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. 

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.

[ACarlotti]

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.

[jamespetts]

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.

[jamespetts]

Can I ask whether you have managed to make any progress with sorting out the lightness of the textures in this? I have seen these in your bug report game, and these do look good aside from the texture brightness, which should be fairly easy to fix.

[Matthew]

Can I ask whether you have managed to make any progress with sorting out the lightness of the textures in this? I have seen these in your bug report game, and these do look good aside from the texture brightness, which should be fairly easy to fix.

James, I apologize for the very slow reply to this. Thank you very much for the feedback, as I am learning this as I go along. The shade of those brick walls had already been changed to be the same as other pakset buildings (old on the L, current on the R):



The current shade is actually the same as an existing building in pak128.Britain-Ex: the 1970s bungalow. For future reference, here are the relevant material settings:

Code Select Expand

Brick walls of bungalows -> Brick walls of court
Diffuse: RGB 0.922/0.922/0.922; Lambert; intensity 0.800
Specular: RGB 1.000/1.000/1.000; CookTorr; intensity 0.500, hardness 50
Texture RGB 0.900/0.550/0.410; brightness 0.900; contrast 1.000; saturation 1.000

However, I don't doubt that it appears brighter to you. We can compare them in this image:

*

On the left is the court in my save, in the centre is the bungalow, on the right is the court with all the other material & texture settings copied from the bungalow, including these:

Code Select Expand

Felt roof of garage -> Slate roof of court
Diffuse: RGB 0.000/0.000/0.000; Lambert; intensity 0.800
Specular: RGB 0.376/0.370/0.370; CookTorr; intensity 0.500, hardness 50
Texture RGB 1.000/1.00/ 1.000; brightness 0.727; contrast 0.886; saturation 1.000

If anything, the right-hand walls look brighter to me, and we've lost the look of cheap bricks that I was going for. The image also includes a reference photo of old bricks on a cloudy day. (The tunnel bricks, not the ones used to close the tunnel mouth.) The photo is of the Wapping tunnel entrance built in 1830 for the L&MR, which happily is about 50 metres away from Crosbie Street, my model for court housing. To me it looks as though I ought to make the court walls a little darker, but it's roughly right.

But then why does the bungalow 'feel' darker to you? I'm no artist, but I wonder whether it's because its brick wall is smaller and is broken up with darker objects (doors and windows). So the way to improve the courts might be to break up the expanses with other elements (stains, posters, furniture, litter), something that I want to do anyway to give them a 'lived-in' look. But to do that, I need to know how different tiles will fit together, which is stalled by what follows.

Last summer, I play-tested the court housing as multi-tile citybuildings and the results were mixed. They load, but they don't work as expected.

Firstly, they caused a population explosion. Initially I thought this was ideal for the Industrial Revolution era, but it got out of hand: bus stops had thousands of passengers waiting and railway stations had tens of thousands queuing. There was no room for anything other than Very Low passengers. My figures were based on historical data from Crosbie Street, so I spent a lot of time reading up on 18th-19th century Liverpool to find the error. I eventually realized that the street plan I had used for my calculations had a misprinted scale. Juggling the multiple Simutrans/pakset scales is complicated enough already without academics claiming that 100ft = 328m!

Secondly, the rotation of multi-tile citybuildings is random: their entrances only face on to roads by luck. So IMHO introducing them would remove one of the magical aspects of Simutrans graphics. I wonder whether THLeaderH was less worried about roadfronts because East Asian cities were historically laid out in compounds (such as Pak.256's only multi-tile citybuilding, the public apartment compound). In contrast, multiple tiles with roadfronts would be ideal for court housing, since (in the game as in real life) they would fill up the empty spaces in the middle of blocks from the road.

Prissi wrote a different implementation of multi-tile citybuildings for Standard, which does handle rotation to roadfronts. I know you (James) have recently asked Phystam to prioritize transferring this over, but I suspect that will also mean disentangling THLeaderH's code and possible also Catasteroid's changes to renovation.

So for these two reasons, this project is stalled while I (a) rescale the paks and (b) try to learn some C++ in the hope that I might be able to help with sorting out rotation. That's why I've been learning to compile, etc. But maybe the court housing will be ready to submit again by the time the next Bridgewater-Brunel game reaches 1780, which must still be several (real-life) months away. How long does a BB month take in real life?

* This image is CC-BY-SA 4.0, photo credit to Wikimedia Commons user Rodhullandemu, artwork credit here and here.

[jamespetts]

I had typed a reply which was destroyed when the attachment with a screenshot turned out to be too large, so I will respond briefly.

First of all, thank you for your detailed response: that is helpful. I think that the perception of the buildings being too bright was a result of:

(1) them being brighter than most other buildings of the era (especially the townhouses, which are in a much darker brown; the bungalow is not a contemporary of these buildings);
(2) the fact that buildings of this era would inevitably be darkened by soot and grime; and
(3) the rough look given by the high contrast between neighbouring pixels in the texture.

You write that you were after a cheap brick look, but I do not believe that this is achieved: it looks more like an error with the rendering than any actual bricks. The contrast between each pixel and its neighbour is much greater than one would expect if one were looking at a real object from a distance. The lower right image, where you have copied the settings from the bungalow, looks much more natural. To achieve a cheap brick look, I suggest that you edit the base texture to add more staining, or simply alter the underlying colours/brightness/intensity to imitate soot/grime staining.

One final thing: the inside of the arches seem to be too bright. This is probably due to a limitation in the lighting algorithm of the Blender internal renderer, so you will need manually to darken the textures inside the arches, and preferably also replace the ground texture with something other than brick, as one would not expect red brick on the ground.

Thank you very much for your work on these: they are most useful, and, with the minor modifications suggested, will be a splendid addition to the pakset.