This is exactly what I hoped for.Brianetta wrote:Dalestan (and OpenTTD devs),
I had an idea for combining orders, groups (as seen in OpenTTD) and liveries. It would involve a change in game play, but it would (I believe, having spoken to my wife about her experience trying to understand the game) make the game much easier to understand.
Borrowing heavily from Simutrans' idea of lines, we define groups first. Groups can contain other groups, giving a hierarchy, and can contain vehicles. A group has an orders list, and a colour scheme or livery too. A group's orders and livery are applied to the vehicles contained within that group. A group inherits orders and liveries from its parent (the group in which it is contained), and its children inherit orders and liveries from it in turn. Any group with an order list or livery of its own completely overrides that of its parent, and passes its own on to its children. Vehicles within a group use the group's orders list, not their own.
Commands sent to a group are sent to all children, grandchildren, etc of that group (for example, go to depot, auto-replace, etc).
The top level group has an empty orders list and uses the main company colour scheme.
Groups could be enhanced to also define service intervals, timetables and other user-definable vehicular attributes that may become available. Groups could, but probably shouldn't, contain more than one type of vehicle. The user should be able to copy the orders of one group into another, to allow that order list to be used as the basis for a new one. "Cloning" such orders should be regarded as meaningless and confusing, and not implemented. All cloning should be handled by inheritance and group membership.
The big advantage here, for the user, is that they are defining services ("Lines," as Simutrans puts it) first, and then deciding which of their vehicles should be running in which service. It's never ambiguous, whether orders are shared or not. Since groups can be placed in a larger group, and divided into smaller groups, without affecting orders and colours, it's still possible to use them in the OpenTTD fashion for group control (sending all the members of a group off to be upgraded, etc).
The user interface itself could be almost exactly the same as the current OpenTTD interface, but with child groups appearing below (and idented beyond) their parent, and additonal buttons for orders, liveries and anything else. Changing the orders of a vehicle would change the order list that it's currently using, and that group's name should be clearly presented on the orders page of the vehicle, so that the user knows exactly what is being changed.
In order to preserve the gameplay expected by, and provided for, Transport Tycoon Deluxe players, vehicles should be default be created in the "ungrouped" group, and members of the "ungrouped" group should have their own orders list. I suggest the current mechanism of sharing orders (control-clicking another vehicle) be abandoned in favour of group based orders.
So, the following objectives would be met by this suggestion:I'm sure there are other benefits, and (aside from the development work) few drawbacks. Opinions?
- The game interface is unchanged for players used to Transport Tycoon Deluxe, and can be used in that way
- Once a player starts to use shared orders, it's very clear which vehicles use those orders
- Vehicles can be easily and unambiguously transferred from one orders list to another
- An orders list does not vanish if there are no vehicles using it, but is still visible and can be re-used
- Vehicles on given routes can be given distinctive colours
- Vehicle groups can be arbitrarily sub-divided for management (an example: same orders, but bought more recently)
- Vehicle groups can be placed within groups for management (an example: all trains on the north network, can be stopped and started together for signal work)
All edits are for markup only; no text changes
From a serious gameplayer standpoint, it adds a lot of control and playability. If you don't like it, don't use it! After all, OpenTTD has already undergone a lot of changes from the original TTD... purists and others simply use what features they want.
From a developer standpoint, it could be major work, but worth doing.
