Design mode

[fredp]

Hello everybody

It would be nice to have something like a "Track design mode" with which you could place/remove tracks and roads (and any other action over the scenario) without affecting money and map.
Once you are satisfied with the new layout, you would press a "Build" button which would make the modifications to the map and pay money just for that, without paying for intermediate trials you did.

[Milko]

Hello

Or, at least, it would be interesting to have an undo ...

Giuseppe

[ӔO]

there is an "undo" key. it's binded to "z"

[An_dz]

You can use the public player to change everything.

[skreyola]

AFAIK, z-undo doesn't refund your monies.

[TrainMith]

I personally like this idea.  The name could either be "design mode", "proposal mode", or perhaps "planning mode".

[Erik]

oh, yes
It's often enough that I have to rebuild area's a couple of times before it fits well.

[fredp]

You can use the public player to change everything.

Well, it's not what actually I want. I want to be able to design a new rail track before actually building it, as it happens in real world, spending my money only when the layout fits my needs.

[Spike]

It might be difficult to implement. Simutrans' display system is primarily geared towards displaying what actually exists on the map. Also, calculating the neighboring tiles for tracks and from that the visual appearance of the track requires that the track pieces are part of the map.

Therefore a virtual track laying mode (without actually altering the map) is not so easy to make. I don't say it's impossible, it's just not as straightforward as one might think.

[VS]

Now that we have more players in one game regularly, there's the problem of planning while others modify the map. Planning shouldn't block them, that would be a perfect loophole for malice. So what then...

[Erik]

Well at first, don't make the planning area to big.
For example, designing a yard who is connecting a station to the main track.

[fredp]

Maybe this does not suit Simutrans' programming, but at first I thought about design mode as
1- pause time, so no concurrent events on the map are happening
2- make a copy of the map as is when the design mode button is pressed
3- allow modifications and everything on the map without spending money
4a- if modifications are accepted ("build!" button is pressed), make the edited map become the default one and take the money only for what has actually been built
4b- if no modification is to be done ("cancel" button), just restore the map copy done at 2)
5- unpause time

[Spike]

That would work, just that "copy the map" is not an easy operation either ... if it is a deep copy, it needs a lot of memory, if it is a shallow copy, changes might indirectly influence the objects on the original map ... but maybe Prissi or one of the other developers can come up with a good idea for this proposal.

[jamespetts]

Don't we already have a sort-of design mode in a very limited way with click and drag? The building does not occur until the mouse button is released. This, however, does not work currently in network/online mode, which is not ideal, since click and drag is a far easier way of building things than click start point and click end point. If click and drag (or, indeed, any variant of "design mode") were to be implemented in network play, it would seem sensible to have the preliminary visualisation (during the dragging in click and drag, for example) to be entirely local to the client machine, and the command only sent to the server when the drag is released, which, to the server, would be the equivalent of sending both commands of the two click tool in rapid succession at that point.

[Spike]

Right, I forgot about the track preview mode. Maybe the current code is more suited to a "design mode" than I thought

[prissi]

You could use a sparse map to store any altered tile. But it will be an effort to implement.

[An_dz]

I want to be able to design a new rail track before actually building it, as it happens in real world(...)

As I know in real world there's no design mode, you have to plan it on paper and then implement things.

I know it can be easier, but that's the way Simutrans works (now), You have to plan the network on your mind and sometimes on paper to start building things.

But this feature can be implemented for Online games?

[skreyola]

How about a map overlay for design mode? You would switch into the overlay layer, similar to slice mode, and any building you did there would be at 0c cost until you hit build, and then any ways or wayobjs build on the design layer would be built (with those tiles that don't work on the current real map just not being built (shown in design layer as red, or with a slash through them)), and the player would be charged for the current cost of those modifications...
The programmers could, as a later step, add a balance sheet to the design layer that would show you how much money you have left to play with, but design mode wouldn't prevent you from "building" your proposal just because you don't have enough money for it yet.
When you clicked build, the proposal would start at existing connections (to ways) and build outward from that, stopping when money ran out (and keeping the overspend proposal in the design layer so you could click build again when you had more money).
How does that sound?

[fredp]

Sounds cool, but maybe the "progressive" building mode adds complexity that imho is not needed (well, I'm a "freeplay" lover...)

[skreyola]

I'm not sure it adds that much complexity, but I could be wrong.

[Fabio]

I will revive this proposal with some new thoughts.
Infrastructure (ways, bridges, tunnel etc...) could have a construction time, as buildings do.
During construction, nothing is paid, different sprites are shown , and the infrastructure cannot be used.
At the end of this period (e.g. one month game time), costs are paid and you can use the infrastructure.
Everything is deleted in construction status, is deleted at no cost.
To have a design mode, just pause the game and build/remove just built.

[jamespetts]

Fabio's suggestion is quite an intelligent one.

[skreyola]

I will revive this proposal with some new thoughts.
Infrastructure (ways, bridges, tunnel etc...) could have a construction time, as buildings do.
During construction, nothing is paid, different sprites are shown , and the infrastructure cannot be used.
At the end of this period (e.g. one month game time), costs are paid and you can use the infrastructure.
Everything is deleted in construction status, is deleted at no cost.
To have a design mode, just pause the game and build/remove just built.

This is quite an elegant solution. It took me a minute to realize you were suggesting a construction time for all construction, not just the design layer. However, I think the construction time should be a little shorter than a month.
:support:
However, a design layer, where I could plan things out well in advance of being able to afford them, is still attractive.

[jamespetts]

The construction time could be set in the individual assets' .dat files, so that pakset authors could use the feature to replicate the reality of the time that it takes to build things.

[Banksie_82]

On the topic of time taken to construct stuff (thread possibly ready for a split?), I have often thought, but not enough to make a request, that this should be implemented.

As an extension of this train of thought, I would like to see a specialised vehicle construct/upgrade the ways, much like the one used for rail construction in these pictures.

http://www.nt.gov.au/aarc/news/photolib/tracklayer140302b.jpg
http://www.nt.gov.au/aarc/news/photolib/Fergusson%20River%20Crossing_portrait.jpg
http://www.nt.gov.au/aarc/images/tracklayer%20over%20bridge2_jpg.jpg

This could possibly be a vehicle that the player needs to construct first before any ways can be built. It would travel along existing ways to the construction site (at a speed much like other convoys) then proceed to build/upgrade the way where the player has designed. The rate of construction of each tile/way type will be defined in the pak. This vehicle crawls along until the whole lot is constructed then goes back to the depot.

During construction it will hold up traffic, just like in real life. This will make players think if they really need to upgrade, particularly in experimental. As the passenger numbers in experimental could be affected for a couple of months after construction has finished, just like in real life. People tend to not want to rely on public transport if it is always being interrupted.

Obviously this idea if full of technical difficulties, not least, how do you build this machinery in a depot when the depot needs to be built on the specified way type, which the machinery needs to build. How do you manage two simultaneous construction sites, or multiple construction machinery? Will you need a different construction set to build bridges or tunnels? Is the activation of this machinery automatic once a design of new ways is finished? In that case, a "design mode" might be a necessity.

I don't even want to think about the coding required.

Of course it makes people think and plan the construction side of things more closely. This is something that really appeals to me, as I think I have mentioned on here before, but I understand that it's not everyone's cup of tea. Maybe a switch could be used to disable this feature? However, I'm not sure how wide of an audience it would appeal to, because it certainly isn't worth the effort if only a handful of people use it.

[jamespetts]

On the topic of time taken to construct stuff (thread possibly ready for a split?), I have often thought, but not enough to make a request, that this should be implemented.

The convention for games of this genre to have things constructed instantly is, in essence, an arbitrary accident of history. The very first game of this genre was Sim City, released in 1989, but originally designed in 1985 (and written in C, not C++). That game came about by accident after its designer, Will Wright, was working on another game, Raid on Bungeling Bay, a conventional action game set in an urban landscape. He designed a tool for designing the levels in this game, and found it more fun to design the city backdrops with this tool than actually to play the game, and so Sim City was born. Of course, because it originated, not as a simulation, but as a tool for creating levels, the time that it takes to build things was not simulated, and that carried through to the game itself. Other games followed suit in that aspect of the design (which also appealed to users' desire for the instant gratification of the action genre), the first of which was Sid Meir's 1990 Railroad Tycoon.

Railroad Tycoon was, in turn, based on a board game, in which, likewise, there would have been no time lapse for building the infrastructure, as the complexity of board games is inherently limited by the capacity of the players' memories (it would be difficult for a player to remember that a particular bit of track started its construction a particular number of turns ago, for example). Those two games were the seminal grandfathers of all of the same genre that followed since (including Transport Tycoon, from which Simutans takes its broad inspiration), and the convention established by accident has persisted seemingly without being seriously questioned ever since.

There is much to be said for Simutrans breaking the mould here (as we have, for example, with passengers/goods having destinations, unique in the transport simulation genre, probably because, at the time of Railroad Tycoon/Transport Tycoon, computers weren't up to the task of routing). Having to plan for the time that it takes for infrastructure to be built (such that capacity enhancements need to be planned ahead of time, possibly years ahead of time if bridges or tunnels are involved) is an interesting aspect of reality so far not modelled by Simutrans the modelling of which would substantially enhance it.

I am not sure that we need to go into as much detail as having a dedicated way-building vehicle, as that would be terribly complicated to code and would not add a great deal to the gameplay, but having new units of way take time to be built would be fairly straightforward to implement and could give rise to great benefits. It is also a feature that could easily be switched off for those who prefer the instant gratification style of play.

[sdog]

This [rail construction vehicle] could possibly be a vehicle that the player needs to construct first before any ways can be built. It would travel along existing ways to the construction site (at a speed much like other convoys) then proceed to build/upgrade the way where the player has designed. The rate of construction of each tile/way type will be defined in the pak. This vehicle crawls along until the whole lot is constructed then goes back to the depot.

Perhaps an image for the last phase of a construction could be enough. If the image is shown for the last few moments of a way building and ways are built from one end to the other it would look like the machine is crawling along that way. Showing the current construction site image for a long time for very long stretches of map is indeed not very pleasing. But afterall the whole thing is just eyecandy and not really important, at least i hope so:
Because having to manage those way building vehicles would be another headache. In modern times it also would be delegated to a contractor.

When introducing a construction time it would be also necessary to make a distinction between building new tracks and upgrading old ones. A solution for replacing bridges or building bridges into an already built track must be found. During such a construction traffic is routed around the construction site, on temporary rails or switched to the opposite track. We don't have something in simutrans. So the construction site would have to be passable, if we don't want to stop the players network for months.

A possible workaround could be allowing the new way to be used instantly, but with an extremely low speed, for example the magic 3km/h. This will render long ways useless until finished but just severely hampers a track with a short new section.

[Fabio]

The construction time could be set in the individual assets' .dat files, so that pakset authors could use the feature to replicate the reality of the time that it takes to build things.

A possible workaround could be allowing the new way to be used instantly, but with an extremely low speed, for example the magic 3km/h. This will render long ways useless until finished but just severely hampers a track with a short new section.

These are two great ideas to implement what i proposed.
Pack dependant construction time could e.g. discourage the construction of high speed ways (which could take longer to be built), together with price. Given that price could be irrelevant in later stages of the game, when you start being covered with gold, closing or reducing greatly the speed of a way being upgraded could discourage upgrading unless strictly necessary, specially in a busy and crowded network.
Speed limited to 3 km/h would prevent pathfinding errors, especially when upgrading. I was a bit concerned about vehicles crawling on the way under construction, making it impossible to delete (and so vanifying the design mode idea). After that, I realized that the design mode would be rather used pausing the game, so vehicles wouldn't enter the new tiles anyway.

[Dwachs]

I will revive this proposal with some new thoughts.
Infrastructure (ways, bridges, tunnel etc...) could have a construction time, as buildings do.

What about all the terra-forming tools? More often than not, you have to do that before building.

I also think such a change will be annoying for network games: there the possibility of pause and fast-forward is not given. So a player has to sit in front of his computer some minutes to wait that the actions he take will materialize.

[Fabio]

What about all the terra-forming tools? More often than not, you have to do that before building.

This point makes me think of another request: http://forum.simutrans.com/index.php?topic=6828.msg65718#msg65718

I also think such a change will be annoying for network games: there the possibility of pause and fast-forward is not given. So a player has to sit in front of his computer some minutes to wait that the actions he take will materialize.

Such a feature could be simple disabled gamewise, so all or some network games could have it disabled.

[sdog]

I was a bit concerned about vehicles crawling on the way under construction, making it impossible to delete (and so vanifying the design mode idea). After that, I realized that the design mode would be rather used pausing the game, so vehicles wouldn't enter the new tiles anyway.

As Dwachs mentioned already, this can't be assumed anymore with network games. However, this is already a problem, regardless of the new system.

It could be addressed by introducing a "Stop" button at a convoy's dialogue or a new stop tool, where a way is blocked for a while. In Gui it could have the form of the user placeable labels, in some signal colour,. A normal road sign would not suffice as the vehicles should be stoped, and way search should be suppressed.

Quote from: Dwachs on Today at 08:44:59

I also think such a change will be annoying for network games: there the possibility of pause and fast-forward is not given. So a player has to sit in front of his computer some minutes to wait that the actions he take will materialize.

Such a feature could be simple disabled gamewise, so all or some network games could have it disabled.

I don't think this would be a big issue, as it is now a player doesn't stay in the game the whole time anyway, things happen on a longer time scale.

This would be a good reason not to set the lenght of the construction times in the dat files, as James suggested, but in simuconf.tab, so servers can easily override it.

[Fabio]

This would be a good reason not to set the lenght of the construction times in the dat files, as James suggested, but in simuconf.tab, so servers can easily override it.

In simuconf.tab there could be the "general" construction time, whereas in the .dat file there could be simply a multiplier.
This way, there could be differentiation between objects (es. dirt road 1x, city road 5x, highway 10x) but based on server (or local) time setting (es. construction time=24 hours would bring to dirt road 24 hours, city road 120 hours, highway 240 hours, whereas construction time=6 hours would bring to dirt road 6 hours, city road 30 hours, highway 60 hours)

[skreyola]

I think the construction time should not be too terribly long, or it will make network design mistakes more dangerous than they already are, in terms of overcrowding and maintenance costs. If a "realistic" construction delay is included, I think a short one should be available by conf option. Or better yet, make the duration of construction a conf option, so people who don't like this idea can keep the current behavior, while people who love realism can make line construction take a year or more.

@sdog: Network games point well taken. Perhaps the overlay method for design is better all around.

@fabio: I love your idea of construction time multipliers.

[Fabio]

it will make network design mistakes more dangerous than they already are

but if you realize the mistake while it's under construction, you could delete your mistake at no cost at all

[skreyola]

but if you realize the mistake while it's under construction, you could delete your mistake at no cost at all

That doesn't help when you've built line A that costs a bundle to maintain but (oops) won't work properly until another line, B, has finished being built. That's what I meant by design mistakes, as in, having set this up, the company is no longer profitable, and I need this new line yesterday.