News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

Making Attractions 'Experimental'

Started by Carl, September 22, 2011, 03:17:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Carl

For a while I've formulating some ideas about how to improve the functionality of "attractions"/"curiosities" within Simutrans-Experimental. In my view, attractions are a relatively untapped resource which---if used properly---can be used to greatly enhance the realism of paksets. Many of the idea that follow have been nurtured through developing new attraction-sets for pak64.experimental.

Here are three ideas to improve the functionality of attractions, some of which should (I hope) be fairly easy to implement.


1. 'Upgrading'
Short version: Attractions should adopt a variant of the upgrading function of factories.

Longer version: Attractions are currently 'immortal'. But in reality, many attractions grow with the city they belong to. A small football field might, over time, grow into an international stadium. A small neighbourhood school might, as the neighbourhood grows, become a large school. By adopting a variant of the current factory upgrade behaviour, Experimental could simulate this behaviour.

This could be implemented as follows. In the .dat file for attractions, two new kinds of value would be specified: "upgrade_time" and "upgrades". For instance:

upgrade_time=5000
upgrade[0]=LargeStadium

This would indicate that when the city to which the attraction belongs reaches 5000 inhabitants, the attraction will be upgraded to a Large Stadium. (There could also be a further "upgrade_chance" parameter to introduce some unpredictability here.) Note that this would only be appropriate for city attractions -- that is, those which also specify a "build_time" parameter.


2. Dependence relations/prerequisites
Short version: allow for attractions whose appearance depends on the prior existence of another (specific) attraction.

Longer version: In the real world, some attractions won't appear unless another attraction are already present. That is, some attractions are pre-requisites for others. You might expect that a large science company would only set up a research lab in a city which had a university, for instance.

This can be simulated by specifying in the research lab's .dat file that it will appear only if the city already has a university. This means that the "chance=x" parameter for the research lab will be a conditional probability--it's the probability of its occurrence given that the city has a university.

Note that this would also allow for "sets" of attractions which, while in themselves unlikely to occur, will always occur together. For instance it might be the case that attraction A1 only occurs in 5% of cities -- but that the occurrence of an A1 will always (eventually) lead to the building of an attraction A2. This is currently not possible to simluate. If the "chance" parameters for A1 and A2 are both set to 5%, it's very improbable that they would ever occur together. But dependence relations will make this easy to simulate. The "chance=X" parameter for A2 will be 100, but its presence will depend on A1's presence. The two will always occur together---and if the chance of A1 occurring is 5%, this makes the probability of A2 occurring also 5%.


3. Multiple instances
Short version: allow attraction dat files to define multiple "build_time" parameters.

Longer version: An attraction's "build_time" parameter specifies how big a city has to be before that attraction can be built. But for the most part, a city will only contain one of each attraction, no matter how big it gets. However, some attractions occur multiple times in larger cities. For example: once a city reaches a certain size, it will need a second school---and then, eventually,  a third and fourth school. In order to simulate this, it would be useful to specify multiple build_time parameters, as follows:

Name=PrimarySchool
build_time[0]=5000
build_time[1]=12000
build_time[2]=20000
build_time[3]=29000

The same goes for all kinds of attractions.

Now this can be done under the current system, of course, by simply making several different attractions which are identical save for their build_times. But this can clutter up the list attractions which can be built, so this solution would be more elegant.

The Hood


ӔO

Do the attractions need to be the same size as the older one? or would they relocate if there's no free space around it?
As far as I'm aware, cities don't auto delete/destroy buildings or roads that have been already built.

It would seem a bit odd if they relocated, but it would be equally odd if the attraction reserves empty space around it.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

jamespetts

Carl,

these are some interesting ideas indeed. One question on the first idea - do you imagine the attraction upgrading even if the newer attraction is a different size to the existing one? If so, that could be tricky to code. All the other things, at a glance, at least, seem possible: the issue is that there are a rather large number of higher priority things to do! Nonetheless, it's always helpful to have suggestions, even if they must remain suggestions for some time before being implemented. Of course, if somebody else were to code them, that would be another matter...

Thank you for your thoughts!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

greenling

Opening hours 20:00 - 23:00
(In Night from friday on saturday and saturday on sunday it possibly that i be keep longer in Forum.)
I am The Assistant from Pakfilearcheologist!
Working on a big Problem!

Carl

Quote from: jamespetts on September 22, 2011, 08:44:56 PM
Carl,

these are some interesting ideas indeed. One question on the first idea - do you imagine the attraction upgrading even if the newer attraction is a different size to the existing one? If so, that could be tricky to code. All the other things, at a glance, at least, seem possible: the issue is that there are a rather large number of higher priority things to do! Nonetheless, it's always helpful to have suggestions, even if they must remain suggestions for some time before being implemented. Of course, if somebody else were to code them, that would be another matter...

Thank you for your thoughts!

On the "different size" question. Am I right in thinking that town halls change size when they upgrade? Could this behaviour be adopted? Town halls do relocate sometimes when they upgrade, and maybe this would seem odd for attractions -- but equally it might in fact reflect real-life practice in many cases. Many kinds of institution outgrow their existing site and move to larger ones.

Alternatively, there could be a "same size" restriction on attraction-upgrading -- which would be restrictive, but better than no upgrading at all. (Just out of curiosity, how does this currently work for city factories?)

Obviously I appreciate that there are lots of higher-priority things to implement. I'd love to be able to help out in coding this, but my abilities simply aren't up-to-scratch. For instance, I can more or less decipher how the factory-upgrade code works by reading it---but I'd have no idea how to go about implement something similar for attractions.

jamespetts

Hmm - I don't think that town halls up-size when they upgrade: I've never seen it happen. Wouldn't they end up on the outskirts of a town if they did that, as there would be no space in the centre?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

Having checked pak64's townhalls, they start at 1x1 squares and upgrade to 2x2 squares. Depending on the pakset's cityrules.tab, there may still be some free space in the centre of town---but I guess that sometimes town halls will have to relocate to the outskirts.

jamespetts

Hmm, interesting. That code could perhaps be re-used, in that case, but I've never really looked at the town hall code.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

Or have them "consume" nearby citybuildings if possible?

Junna

Quote from: carlbaker on September 22, 2011, 09:10:16 PM
Having checked pak64's townhalls, they start at 1x1 squares and upgrade to 2x2 squares. Depending on the pakset's cityrules.tab, there may still be some free space in the centre of town---but I guess that sometimes town halls will have to relocate to the outskirts.

I have a custom town-hall set for 64 that has 3-tile town halls at the end of the spectrum, and they do indeed relocate if the upgrade does not fit.
Quote from: The Hood on September 22, 2011, 09:15:28 PM
Or have them "consume" nearby citybuildings if possible?

I think this would be more desirable (because it tends to look a bit off when the city-hall is on the very outskirts of a rather large city).

prissi

The townhall will destroy houses to grow. But most often there is a road in the way and the townhall will relocate. This happens at 1500 inhabitants, thus towns grow happily even after.

It has also another effect: Since attractions want to be close to townhall, a relocated townhall will spread attraction more over the city.

However, replacing attractions with larger ones will be difficult; just assume there are two stop close to them, or they will destroy an important road in order to upgrade.

wlindley

I greatly support this, especially as I have been considering re-doing the Pak128.Britain church. Since I have to add snow to it anyway, I hope to create a 1x1 chapel, one or two 2x2 town churches, and a 3x3 cathedral. These suggestions would be splendid.