Ideas, volume 2

[Mek]

If you use a real 3D engine, implement a "ride" option so you can take a seat in a passenger car or in the locomotive's driving cab. I think it won't be much of a deal - simply put the camera to another place and let it move with the train/car.

i think the most important problem with this would be that you need much more detailed models to make this look nice...

[Hellfire]

But still... Implementing it would be fairly easy.

[Kyaputen Harokku]

Yes, even with less detailed models it would be a nice feature to have.

[Zuu]

An interestin thing could be to have on the vhicle window tabs or buttons to change view.

Vews to chose from:

1. TTD-style view. Isometric
2. Front view. Real perspective. (camera outside the vehicle, drivers view without the interiour of the vehicle)
3. On head view. (camera in vehicle drive direction. Located abit above, and behind the loco.

#3 can be either isometric or real perspective.

[Zuu]

With a high amount of diffrent cargo types it can be good to have some sort of tree structure. For example furniture and books are childs of goods.

Then we can have wagons that accept all cargo types that inerheit from goods. These wagons should either have lower capacity or be more expensive than wagons built for only one type of cargo.

[Greyfur]

1) More realistic bus stations... It should be possible to make more platforms for the station, there should be two types of busstations - a bus stop where the bus stops on the street and a bus station - where more buses can get and where the platforms are.

2) Bus depots should be opened (like a big area with buildings, where the buses will be standing and it will have a maximum capacity) or a closed one, again with a limited capacity.

3) Then of course articulated buses should be available and functional.

4) One more thing - the time maybe should be more realistic as in TT, or a slow down/ faster time should be available...

5) Other idea is slow building.... you place the buildings and they will slowly build them up and they will be functional after they are finished.... Each building would have a different build time...

[Jpl]

I'd like if you wouldn't need to buy expensive locomotives for each train you want to drive. You could instead build a depot and some locomotives to there.

Trains would have timetable or they would request locomotive(s) when they are fully loaded.

Another good feature would be that multiple unit trains/railcars could have more units on rush hours. That would "free" units to be used on other lines in between rush hours.

Locomotives/units can also be transferred from one depot to another depot.

Broken trains would require a locomotive to move to depot.

[Greyfur]

City transport should have the possibility of trolleybuses and trams

[Hellfire]

City transport should have the possibility of trolleybuses and trams

This is already in our requirements document, in the Gameplay chapter.

And you have already suggested this!

So please don't worry, we are going to implement trams and probably also trolley busses. Read the FRD to get an idea of what we already have. If you have any additions, feel free to mention them here.

[Hellfire]

I was playing Locomotion the other night. I tried to build a two-level station, with one level above ground and one level below. I noticed that it is almost imposible to do such a thing without destroying some roads/tracks above the ground to be able to see what you're doing underground.

Since the FRD does not yet specify a lot about the user interface, I suggest a feature like this:

• The User can select a chop-off value for the maximum height he can see. This way, all objects and tracks above the selected level will be hidden, revealing the objects below that level.
• Alternative: The user can select a piece of track and a chosen length of connected track to be visible. All other track segments and attached structures like stations and signals will be hidden (or transparent)

[Hellfire]

Building signals on tracks should be easier than the way it's implemented in TTD/Loco.

How about this setting:

The user selects a starting point and an endpoint on a piece of continuous track. Then, using something intuïtive, like a sliding bar, the user sets the density of signals, selects the direction, clicks on "ok" and Voila! One piece of track completely signalled. No measuring, no scrolling. Just plain and simple.

[jfs]

Another idea for signal-placing interface: You select a run of track, select what kind of trains will be running there (eg. by "building" that train, or maybe just how long it will be), and it places signals at fitting intervals.

Another idea: In later years, where trains can be controlled by computer technology, signals don't really have to be explicit. A section of track can be "implicitly signalled", but only if all trains running on it are modern enough. Then the trains will automatically adjust their speed and distance to each other in order to avoid crashes.
I know it's done like that in the Copenhagen Metro system. (Though it sometimes isn't very comfortable to ride in, when there are irregularities and the trains keep speeding up and slowing down all the time...)

[Zuu]

Summary
An idea for how to allow trains to attach/deattach wagons at stations.

Idea

• Trains have at least one engine, and can have wagons.
• Stations have a magic bag where it can store vehicles and engines.
• The bag's capacity can be limited.
• When a train stops on a station it can:
  • attach any vehicle that is in the stations bag, as long as the vehicle is compatible with the rest of the train.
  • deattach any wagon from the train as long as:
    • there is space left in the bag.
  • deattach any loco from the train as long as:
    • there is space left in the bag.
    • there is at least one loco left in the train.
  • resort wagons.

If you want more realism you make the above apply for depots instead of stations.

Additional train orders:

• Deattach wagon('wagon type' or 'wagon sort' or 'place in train', 'n wagons')
• Deattach loco('loco id' or 'loco type' or 'loco sort' or 'place in train', 'n locos')
• Attach wagon('wagon type' or 'wagon sort', 'n wagons')
• Attach loco('loco id' or 'loco type' or 'loco sort', 'n locos')

Where:

• 'id' is the unic id that every loco have, but wagons don't.
• 'sort' is each model you can buy in the shop.
• 'type' is a class of simular models. (example: passenger wagons)
• 'place in the train' is a number where the first car has number 1, and next 2, and so on.
• 'n wagons' is the nuber of wagons that shall be attached/deattached.
• 'n locos' is the nuber of locos that shall be attached/deattached.

[PJayTycy]

It would be most usefull if this is implemented in the train's schedule.

For example, in the station before a hill, an extra loco is added to the train.


Now, you would have a problem with all loco's piling up at the top of the hill, so you would need some kind of "synchronisation" or "multipart" schedules, that exactly tell for each split-off loco/wagon what it should.

ie in this case it would be something like :
1) start somewhere
2) arrive at hill, add loco
3) arrive at top, decouple loco
4a) loco returns to base of hill
4b) train moves on to destination


The same is true for all wagons, you need something to assure it's a nil-operation in the end. Do you have any idea how to make this transparant and easy for the end user?


PJay

[Zuu]

Cant you just take a cheep loco and make it move all locos from the hill and down to the station below.

1. move to station at hill
2. attach X locos with label Q
3. move to station below hill
4. deattach all locos

Well, labels wasn't in the idea, but I realised now that it would be pretty usefull to be able to label a group of locos and/or wagons. If there are more than one sources of locos.

Edit: I know that there is a risk that locos and wagons "disapears" to the wrong place if the player try to make a too complicated system. I also know that this can be too advanced for newbies.

Also I want to point out (in case you havn't noticed) that with this idea locos will not have a static conection to a train ID (as in TTD). In other words the train id, which is an item in a data structure might move from place A to place C, but none of the wagons and locos that where on the train when it deparured might be on the train when it arrives to C.

[Zuu]

To make the idea less abstract, and esier to use for end users you can decide that the front loco can't be deattached. The result of this would be that the front loco is always connected to the same train ID.


Another thing is that if you have a buch of locos at a station a player can't just order them to go to station X, becuse they are not attached to any train. However this is not verry easy to explain for an end user that his 236 locos on station Q cant go to station P becuse they are not attached to any train.

So, maybe from the station window that veiws which locos that are stored in that staion you should be able to transparently order any loco to go to any station. Under the surface we can then create a train that have these orders:
* Go to station P.
* Unatach all, and dispand Train.


But maybe I am diving to deep now.


EDIT: The whole idea with attach/deattach wagons is quite abstract and complicated to a newbie, and should not be necessary to create an avagere network. But can add to the more experienced players.

[PJayTycy]

When you said in your previous post

"a train can start/stop with all engines & wagons changed under way", I was thinking what do you define as "the train" then

I guess, if we want to do this right, we have to disband the whole idea of "a train".

A suggestion to make it transparent:

Define schedules and give them names. Use the normal orders + orders to switch loco's and wagons from 1 schedule to another. In the user-interface, for each stop players should see the station name + how the new train-consist looks like.

I'll use the same example as before (stations are bold): A - a long flat section - B - a steep hill - C - a long flat section - D.

You would define 2 schedules :

• A: wait for full load
• B: attach loco
• C: detach loco
• D: unload

and

• C: wait for 8 loco's
• D: disband

Maybe we should give names to those "magic bags". If the station on top of the hill can be reached from 2 sides, we don't want all extra loco's to end up at one side and none at the other side. So the orders at station C would become "detach loco, put it in east-side pullers" and "wait for 8 loco's from east-side pullers"

[Zuu]

When you said in your previous post

"a train can start/stop with all engines & wagons changed under way", I was thinking what do you define as "the train" then

How I define a train:
* A train have at least one loco and any amount of wagons, that are connected(linked) togeather.
* A train can't exist in a 'magic bag'.
* A train have a shedule.

I guess, if we want to do this right, we have to disband the whole idea of "a train".

Or at least the definition of a train would be a lot more abstract.

Therefor I later suggested that a loco will be staticly linked togeather with the "train" . So when you create a new train, and place the front loco, that loco will be linked with "the train". So in the schedule you cant deattach the front loco as "the train" will follow with that loco.

A suggestion to make it transparent:

Define schedules and give them names. Use the normal orders + orders to switch loco's and wagons from 1 schedule to another. In the user-interface, for each stop players should see the station name + how the new train-consist looks like.

I'll use the same example as before (stations are bold): A - a long flat section - B - a steep hill - C - a long flat section - D.

You would define 2 schedules :

• A: wait for full load
• B: attach loco
• C: detach loco
• D: unload

and

• C: wait for 8 loco's
• D: disband

Maybe we should give names to those "magic bags". If the station on top of the hill can be reached from 2 sides, we don't want all extra loco's to end up at one side and none at the other side. So the orders at station C would become "detach loco, put it in east-side pullers" and "wait for 8 loco's from east-side pullers"

Well, the main diffrence I can see between my idea and yours is that in mine the schedule will follow the train. So I would say that the schedule (or the conductor to make it less abstract) will travel between the stations on the schedual and that the wagons and locos may varry, but there will always be at least one loco.

In your idea the schedule isn't following any spefic train. So they are global, and when the condition at the firs stop is true (enoght locos, wagons, and cargo) a train will be asembled and departure. The train will follow the rules of the sheduale, and when it reaches the end it is dispanded.


In my idea I see no conflicts for playing it as in TTD. Ie build a train, give it some orders (no attach/deattach orders) and start it. Which is what most beginers will do (I guess).

In your idea there is a risk that wagons and locos get lost if you have a compulsory dispand and asemble orders in the end and begining of the schedule. But by remove to dispand order you can probably create something simular, at least if you make your schedules assembel on diffrent stations.

[PJayTycy]

In your idea the schedule isn't following any spefic train. So they are global, and when the condition at the firs stop is true (enoght locos, wagons, and cargo) a train will be asembled and departure. The train will follow the rules of the sheduale, and when it reaches the end it is dispanded.

Well not really, if you don't put "disband" in the schedule (like the first one), the train would just go back to the first station like it has always been in TTD. So, I guess we basicly say the same

But by removing the disband order you can probably create something simular, at least if you make your schedules assembel on diffrent stations.

What do you mean with that last sentence?

And what's your opinion on "naming" magic bags? Do you think that would be usefull or do you have another solution for the problem?

[Zuu]

In your idea the schedule isn't following any spefic train. So they are global, and when the condition at the firs stop is true (enoght locos, wagons, and cargo) a train will be asembled and departure. The train will follow the rules of the sheduale, and when it reaches the end it is dispanded.

Well not really, if you don't put "disband" in the schedule (like the first one), the train would just go back to the first station like it has always been in TTD. So, I guess we basicly say the same

no comment, see my next comment.

But by removing the disband order you can probably create something simular, at least if you make your schedules assembel on diffrent stations.

What do you mean with that last sentence?

I thought that your schedules did consist of:

• A: Assembel train
• B: Goto Q
• C: Attach J
• D: Goto P
• E: Deattach P
• F: Goto Q
• G: Disband train

And that the schedule was something abstract that was sharred among diffrent trains. The when a given condition is true the schedule creates a new train that will begin at A and assemble it self, do stuff, and when it comes to G it will dissasemble it self.

If not a new train (from the same schedule) is created directly after one have been desbanded there is a risk that another schedule creates a train from that station, and uses the some wagons and/or locos that the first schdule needs.

And what's your opinion on "naming" magic bags? Do you think that would be usefull or do you have another solution for the problem?

Name: hmm, maybe we can use the english word for a train parking space. But then this should work for trucks too.

Other soulutinons: maybe if we make it possible for whole Trains to link together as a Optional suggestion suggests in the FRD.