A very long list of ideas for improving Train Fever

Home Forums Support A very long list of ideas for improving Train Fever

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #17625
    electricmonk2k
    Participant

    After having played the game for some 320 hours, I thought I’d write down the ideas that came into my head and share them here. Several of these are small fixes that could make a big difference.

    Main User Interface

    The user-interface is how the user interacts with the game. Any awkwardness involving the user-interface translates into awkwardness involving the gameplay experience. It feels particularly awkward for new players, but with a bit of perseverance, they can get used to it’s quirks, but it would be better if the quirks did not exist in the first place, as they may even put some players off altogether.

    • When attempting to open a window that is already open, the window should flash and be brought to the front. Currently, if a player tries to open a window that is already open, they may wonder why it is not opening if they do not realise it is already open. Also, they may not immediately find it if several windows are open (especially if the window is partially obscured). This could be done by flashing the border, Inverting the titlebar or the text and text-background, or even temporarily making the viewport brighter.
    • The mouse-cursor should change according to what mode it is in. This would come in handy if bulldozer-mode is selected – it will reduce the chance of someone accidentally demolishing something when they were intending to select something. Likewise, the cursor should also change when in ‘add station’ mode (it will reduce the chance on someone adding an unwanted station to a route when they wanted to select the station to see it’s info), and also when in construction mode and road-upgrade mode. If it is not possible to change the cursor, at least have a little sprite that follows the cursor that changes according to what mode the cursor is in. Being able to tell at a glance which mode the cursor is in would all of a sudden make the interface feel a whole lot less awkward.
    • Build-menu: If clicking on the build-menu header (where the text “Tracks” “Roads” “Landscaping” etc. appears), the menu should be collapsed and the mouse-cursor should revert to select-mode. Clicking on one of the build-icons to revert to select-mode is counter-intuitive. As an alternative to clicking anywhere on the titlebar, there should be a cross (or some other icon) on the titlebar that can be clicked on to collapse it.
    • The construction menus (roads/bus-stops) should make it more obvious that they can be scrolled. Choosing to use the style of the scrollbar that only shows up when the cursor is near means the player might play the game for a long time without realising that it is possible to build country-roads and large bus-stops (I ended up building long-distance country roads using the narrowest city-street before I realised you could build proper country roads). One way of doing this (without reverting to a more traditional scrollbar-design) is to have the menu big enough to show part of the next icon (it may help if icon-backgrounds have a different background colour to the menu backgrounds as more of the next icon can be seen this way) so that it is more obvious that it can be scrolled. At least make sure that a partial item is visible so the player will know that scrolling is possible.
    • The ‘lines’ button should be in the bottom-left with things like vehicles, finances etc. (if it really must be in the build-menu, it could be in both places – the finances window is also opened by clicking the amount of money so the UI has already set the precedent of having two places to access the same thing).
    • Can we please have a file-selector for the same-game? Having just a text-box gives the game a very ‘unfinished’ feel. Even if it looks like the load-game file-selector with an additional text-entry box, that would be fine. Also if saving, it should warn the player if they are about to overwrite an existing save (quicksave should not display this warning). Having a file-selector can come in handy for those of us who like to have an elaborate naming-convention for our saves, as well as being handy if making a series of saves to report a particular bug and want to remember how we named the saves of the previous steps.
    • The roads in the upgrade roads menu (the one with a road and a plus-sign) should have a plus-sign drawn on the icon for each road-type (like there’s a plus sign drawn on the menu-icon) so the player can more easily see they are in upgrade-road-mode rather than build-road-mode.
    • The tooltip for the roads in the roads-menu should show the cost per metre (without additional terraforming costs). Ditto for rails.
    • When building bridges and tunnels, the bridge-choice and tunnel-choice menus should be movable (they have titlebar that can be dragged) so it doesn’t get in the way.
    • All newly opened windows should have priority over the build menu. I have actually observed an entire new window being hidden behind the build menu.

     

    Windows/information/notifications

    Information is important for conveniently being able to assess the state of any part of a game. Presently, there are many opportunities to improve both the amount of information available and the presentation of existing information. In particular, many of the things that are currently displayed in the “Manage lines” window for individual routes need to be displayed in the “Line” window as well as the “Manage lines” window (the user should not have to open the ‘Manage lines’ window just to see something that is particular to one line).
    General

    • There should be an option to only display all frequencies in seconds. You can more easily compare frequencies at a glance. Perhaps also have an option to only display in minutes (with one or two decimal places).

    Windows and viewports

    • The windows should be resizeable. This is especially handy for windows like the “Mange lines” or individual line windows. However, for windows with a viewport, preventing resizing might prevent some players from complaining about a slowdown with multiple viewports open, but please give the people with high-end graphics cards the option to have their viewports as big as they want. Likewise, it should be possible to shrink viewports if the player wants to see their vehicle but doesn’t want to take up too much rendering-time.
    • With viewports, while it is possible to rotate and zoom the view, it is not possible to tilt. I suspect this was done deliberately to prevent the horizon coming into view which would cause the amount of geometry to render to shoot up, but perhaps have limited tilting (e.g. so you have a direct overhead view). Perhaps the culling-distance should be reduced for viewports if the player really wants to tilt the horizon into view.
    • There should be an option to rotate all viewports to the same orientation as the main view. That way, all the trains will appear to be running in “the right direction” relative to the main view. Also, if multiple viewports have exactly the same camera-orientation, would there be any opportunities to reduce the number of rendering-calculations that need to be done if multiple cameras have exactly the same orientation (the only thing I can think of off the top of my head is that the rotation-component for the world-to-view matrix only needs to be calculated once)?
    • Extra viewport – this is just a window that can be navigated around just like the main viewport.
    • There should be an option to turn the main viewport off. This can come in handy if the player wants to follow several trains simultaneously and does not care about having a main view that is mostly covered by windows. As well as completely turning it off, there could be an option to have it only take up half or quarter of the screen, or use 2×2 or 4×4 screen-pixels per rendered pixel (for example, if the user has a 4k (2160p) monitor, they could switch the main view to 1080p or 540p mode and everything else (windows, UI, etc.) will be at 2160p).
    • Ability to collapse windows so the viewport is not rendered (saves GPU time), but all the other information is still shown. For some reason, stations, depots, etc. start without viewport but try to manipulate the window and a viewport appears. Currently you can click on the word ‘overview’ on the overview tab to collapse the window, but this rolls up most of the window and not just the viewport. It would be nice if we could just turn off the viewport and keep all the other information on the overview tab. Perhaps the window should contain an icon to switch off the viewport, or there could be an icon on the tab-heading itself, but just clicking on the word ‘overview’ isn’t intuitive.
    • If changing tabs on the windows causes the window to expand and the unexpanded window is at the right edge of the screen, perhaps it could be moved a bit to the left so that the rightmost part is not off the edge of the screen. But on the other hand, some users may not want their windows to be moved automatically, so this should just be an option.
    • Whenever the “Error not enough money” dialog pops up, it should say how much is required. This could come in handy if you press the “clone train” button and don’t have enough money and want to know the cost (you cannot work out the cost of the train by selling it if not new).

    Station window

    • Stations and waypoints should list which lines they are served by (both picking up and dropping off goods). These lines should be clickable so clicking on them opens the ‘line’ window for the selected line (this is what happens by clicking the line-link in the vehicle window). Currently, stations have a “waiting at station” list that only lists the lines for which there is some goods/passengers waiting (and it does not have a clickable link). It should also list lines that drop off goods/passengers.
    • The “waiting at station” list should also include lines with zero goods waiting. That way, the player can see if a connection exists (a connection exists if the industry served by the station has “Yes” for it’s “Line Usage” in the industry window and the line is set up properly (one reason an industry might have a “Line Usage” of “No” would be if the player sent the goods to a passenger-station by mistake)).
    • In the list of lines serving the station, an icon could be placed next to the line-name to show if it is a road-vehicle or train that is serving the line (question: Is it possible for a single line to contain both road and rail vehicles?).
    • Also, an icon could be placed next to the line-name to indicate the load-type (e.g.. “load if available”, “full-load (any)”, “full-load (all)”). This might mean that if the same line visits the station multiple times, it might have to be mentioned multiple times in the list of lines (especially if the load-type is different each time).
    • Another idea for the list of lines serving a station is to show the name of the next non-waypoint destination.
    • For bus-stops, if the name of the town is not included in the bus-stop name, the station’s info-window should mention somewhere the name of the town it is in.

    Industry window

    • For “Line usage”, as well as just “No” and “Yes”, if “Yes”, it should also mention which lines it is used by. These lines should be clickable and open up the line-window for that line.
    • For each line that carries produced goods away from the industry, it should mention how much of the production is for each line, and how much production is sent out directly to the destination without using any lines.
    • Industries that receive goods should list which primary-industries and lines the input-products were supplied by.

    Vehicle window

    • Each vehicle window should have a progress-bar – a bar that grows according to how near to the destination (next non-waypoint station) the vehicle is (there could also be additional markings representing waypoints or even signals). The progress is the distance covered and not the expected time (distance is easier to calculate). Of course this will need to be re-calculated if the route is changed midway. Also in the ‘Vehicles’ window (the window that lists all the vehicles), there should be a column that shows the progress-bar for each vehicle. When stopped at a station, the progress bar will be empty. If heading to a depot, the progress bar should be a different colour and be sized according to how close it is to the depot. Likewise if joining a route (the vehicle has just been released from a depot or has been assigned to a different line but has not yet reached the first stop of that line).
    • When a vehicle is re-joining a line (e.g.. it has just been released from a depot or has been reassigned from another line), the vehicle’s line-colour is currently white. However, white is also used as a route-colour. To distinguish this from the white-line, the border of the line-colour box should be grey (or some other colour) instead of black until the vehicle rejoins the line.
    • Vehicle windows should also say the name of the previous stop visited as well as current destination. The previous stop could be in a smaller font than the next stop, drawn in grey and either on top or below the name of the next station, and should be clickable (it brings up the station window). If the train is stopped at a station, either the previous stop is not displayed, or both the previous and next stops are displayed (one on top of the current stop-name and one below). This way, we can also see if a train is stopping at a station to pick up passengers/goods, or if it waiting for a clear path (perhaps the heading-to station name could change colour if the train is stopped at a station to pick up passengers/goods). If heading to (or from) a depot, the depot-name should be shown and clickable (it brings up the depot window).
    • In the Vehicle window’s ‘line’-tab, the current line it’s assigned to should have some sort of indication (be it a highlight or radio-button (and yes, it is mentioned in the overview-tab, but would be nice to have an indication in line-tab as well)).
    • The vehicle window’s ‘details’ tab, the vehicle’s name is shown. As well as the age, it should show the lifespan (in brackets afterwards). Also, the age should be drawn in red if it is older than it’s lifespan.
    • The acceleration when both full and empty should be shown (possibly in the details tab). Perhaps also have some information about uphill and downhill acceleration.
    • The total length of the train should be shown (in both metres and number of wagons/locomotives) (also for road vehicles).
    • Train-windows should have a “Train composition” tab (or “Train details”) that shows what the train is composed of (locomotives and wagons) in a series of rows. As well as a column for rolling-stock, also have a column that lists the age of each item, as well as it’s maximum speed. Clicking on the rolling-stock item (or vehicle) should bring up the vehicle information window (this is the window that’s currently embedded in the “buy vehicle” dialog). For road vehicles (unless articulated), there will only be one row, but it will still be handy to be able to click the vehicle to bring up the vehicle information window.
    • Vehicle windows should mention the amount of time the vehicle has spent waiting for a full load the last time it waited for a full load. Additionally, if it is currently waiting for a full load, it should display the time it has been waiting.

    Vehicle information window (currently embedded in the ‘buy vehicles’ window)

    • There should be a tab that shows the acceleration of the vehicle on one axis and the mass on another. This can be handy to find out howmany full wagons a locomotive can cope with. Maybe also somehow show how acceleration will be affected by gradient.
    • The length of the vehicle/locomotive/wagon (in metres) should be shown.

    Depot window

    • The current total length of the trains being assembled should be shown. This can come in handy if trying to figure out if the train is too big for the station or if you need to consider building larger stations. I think that currently, the only things with defined lengths are station-platforms. (Question: If train is too long for platform, is it OK if the locomotive sticks off end? Or the rear-most door of the rear-most carriage, or the front-most door of the front-most carriage?) Perhaps for carriages, the loading time could be multiplied by the number of doors divided by the number of doors on the platform (if !=0 ), but with the “compartment car”, there is no corridor (doors are on on both sides of compartments) so passengers will not be able to exit even if the coach is partially off the end of a platform.
    • A count of the number of wagons should be shown (like it is in the ‘manage lines’ window). For very large trains, counting the number of wagons can become tedious – especially if the window needs to be scrolled to see all wagons. This count could also be shown somewhere in the vehicle’s window.
    • The total weight of the vehicle should be shown. Both the weight when all wagons are full and when all wagons are empty.
    • Perhaps there could be a wagons-tab that shows things like the capacity/load/weight of individual wagons and age (although this might be better off as a tab of the vehicle-window).
    • Clone Train: Right clicking should show the cost to clone.
    • It should be possible to clone a train not in the depot (as long as the rolling-stock is still available). Press a ‘clone external train’ button and then click on the train to clone.
    • Depots should show incoming vehicles as well as vehicles currently in the depot, like the list of depots in the ‘manage lines’ dialog does.

    Manage Lines window

    • The columns should be sortable. That way you can easily find out which lines are making the biggest losses.
    • A column for the date the line was created should be added. If you can sort columns, you can easily see which are your oldest lines.
    • The vehicle-type filters should act like check-boxes rather than radio-buttons (e.g. you want to see both bus and tram lines but not trains).
    • Additionally, there should be filters for passenger-trains and goods-trains (trains that carry both will show up if either filter is applied). If you’re planning the urban bus and tram lines and trying to identify gaps in the network, you probably don’t want to see the path taken by goods-vehicles. Perhaps even have filters for the different cargo-types carried by the vehicles (but this may generate too many filters if the player is using many plug-in industries).

    Line window

    • The line-window should list all vehicles servicing that line. This is already shown for the line’s row in the “Manage Lines” window – it just needs to be shown in the line-window as well.
    • In fact, all the information from the line’s row in the “Manage Lines” window should be present in the line-window (such as frequency, profit, etc.).
    • Likewise, the buttons for the tasks that are in the “Manage lines” window (such as “send to depot and sell”) should also be present in the line-window.
    • Additionally, a button should be present (in both the line window and the line’s row in the ‘manage lines’ window) to assign all vehicles on this route to a different route. This is useful if you want to buy some shiny new vehicles for your flagship route and want to re-assign the current route’s vehicles to another route.
    • The total line-capacity should be displayed (that is, the sum of all capacities of all vehicles servicing the line).
    • It should be possible to move stations up and down the list of stations. The interface could be similar to that for moving wagons and locomotives up and down a train. Currently, the only way to add a new station at the start is to add it after the start, delete the start-station and re-add it after the new start-station.
    • A check-box should be present to enable/disable showing the line’s overlay on the map. Sometimes, the player may want to keep the line-window open and be able to view the map without the line. Perhaps there could be an additional option to not show the line even when the line-manager window is open.
    • The line window should mention if a connection is not possible (this is the same thing as the line’s colour-overlay on the map not being shown due to a gap or whatever). At the moment, you can only see this by looking at the map to see if the line-overlay is absent. It would be nice to see this in the line-window too. This can also be shown in the line’s row in the “Manage lines” window. Additionally, it should mention the reason for the non-connection (roads/rails not connected, rails connected but electrification not connected, roads connected but tram-track not connected, etc.).
    • When mentioning whether a connection is possible or not, the route-rows on the line-window should be coloured according to whether or not the current station can be connected to the previous station. For example the text could be black if everything is OK, red if there is a gap in the road/rail, yellow if there is a gap in the electrification, and blue if there is a gap in the tram-connectivity but not the bus-connectivity, or pink if a train has been sent to a road-vehicle destination, or a goods-train has been sent to a passenger-station or vice versa (not sure how this would work for mixed goods/passenger trains), and grey if the same station is shown immediately after itself. The first station will mostly be coloured in black, but it could be yellow if there is no electrified platform at the first station. Alternatively (or additionally), the line’s station-list should have a column that shows an icon for the current non-connection problem with the previous station (e.g.. a circle with a line through it if no physical connection, a thunderbolt with a line through it if no electrified connection, etc.)
    • Additionally, as well as errors, the route-rows could show warnings for things like whether an electrified connection does exist but is longer than the non-electrified connection (and similarly for tram-connections longer than bus-connections).
    • The line-window would have an icon (or text) that mentions what sort of vehicles the line is for (road/tram/rail/electric-rail). An empty line should have no icon, and a line with problems should have an icon indicating that there is a problem (e.g. it contains both road and rail stations).
    • The list of stations should have a column to show the distance from either the first station, the previous non-waypoint station, or previous station or waypoint.
    • The list of stations should mention if a station is currently a ghost-station (it has just been demolished but has not yet disappeared).
    • The line-window could have a ‘vehicle progress’ tab that shows a bar that represents the total length of the route with dots representing the vehicles’ current positions on the route and lines representing stations. This can come in handy to see if your vehicles are evenly spaced. This bar could also be displayed in the “Manage lines” window on the line’s row.

    Town list

    • “people line usage” and “cargo items supply” should be columns in this list.

    Town info

    • List which industries and lines the goods were supplied by.

    Notifications

    • There should be a notifications-window that lists all recent (or possibly even all) pop-up notifications that have occured. This can be accessed from a button in the bottom-left of the screen (next to things like vehicle-lists, town-lists, etc.).
    • As well as showing notifications, the notification window should have options to turn off popping up certain types of notifications if there are too many pop-ups. These turned-off notifications will still appear on the list of notifications, and clicking the notification will pop it up.
    • The following events are worthy of a notification:
      • A train has been waiting for a free path or a road-vehicle has been blocked for more than a certain amount of time (this is a good way for automatically spotting a gridlock or a sign a line has too many vehicles servicing it).
      • If there is no path to the destination and a certain amount of time has passed.
      • The first a new station has a vehicle stop in it (this is best tuned off by default).
      • If a vehicle is loading in “full load” mode and no new goods have been received for a while (or if the rate of decay is faster than the rate of arrival).
      • The train has made a certain number of consecutive empty runs (“Load if available” mode).
      • A vehicle has been waiting in a depot for more than a year and has not been assigned a line.
      • If a line has had a negative profit for a period of five years.
      • If a line has had zero income for a period of two years.
      • If a train does not have enough power to get it up the current slope it’s on (the speed drops to 1kph).
      • If a fast train is stuck behind a slower train on the same route (this might be hard to work out – especially if the slower train in front has greater acceleration than the fast train or the signals are sufficiently far enough apart).
      • An industry is scheduled to be upgraded/downgraded
      • … and additionally when the change happens.
      • Every time a new item is available to build (eg. high speed track, catenary, new bridge type), a notification should be popped up.
      • When the road-style changes (ca. 1925)
    • For “New vehicle available” notifications, clicking on the notification should bring up the vehicle information window (this is what you see embedded in the “Buy Vehicles” dialog).

    Routes (lines)

    Station lists

    • Clone line: Copies the stations from one line onto another. This is handy if you are building a line that is mostly similar to another line but the two lines have different end-stations (both lines together look like a ‘Y’ with a long stem)
    • Reverse line: Reverses the order of the stations. When used in conjunction with ‘clone line’, you can very quickly make a route that runs in the opposite direction to an existing circular route.
    • Move end-station to start or start-station to end. For example, if you made a route starting at the train-station and then the town grows and you want to extend it’s start to beyond the train-station, then instead of adding the additional stops on the end, you can add them to the start of the route..
    • Circular routes: Option to run vehicles in the opposite direction of a circle using the same route-slot. However, it may not be so straightforward if trains use waypoints or one-way single track, or if towns have one-way streets. Also, the player would need to assign vehicles to both directions of the route. Perhaps it is better to just use ‘clone line’ and ‘reverse line’ instead.
    • Express routes: Use the same route-slot to create an express-version of the route. These could just exclude a few stops and use faster vehicles (and would also be more expensive for the passengers). May also have to include/exclude some waypoints in the express route. Perhaps it is better to just use ‘clone line’ instead and modify the list of stations and waypoints.

    Line-colours and line-textures

    • Ability to define a custom colour for the route. This is handy if there is a colour-clash of two nearby routes. To do so, in the ‘Line’ dialog (‘overview’ tab), click the colour-bar and you get a colour-picker dialog. This is also handy if attempting to re-create a real-world route-system and want to specify exact colours. Also some people may want to make goods lines darker or less saturated than passenger-lines or have other means of assigning colour-variations to line-type-categories.
    • The following colours (and their 50% darker counterparts) should also be used in the standardised list of route-colours used by Train-Fever
      • orange
      • bubble gum pink (#FFC1CC)
      • chartreuse (green-yellow) (#AFFF00)
      • violet (blue-ish purple)
      • aquamarine (#7FFFD4)
      • light grey and dark grey
      • brown (would have to make sure dark brown is distinguishable from dark red / dark orange).
    • For the route-colours, an alternative to (or complementary to) having a colour-picker is to be able to customise the palette of available route-colours. This is handy if you want to re-create the colour-scheme of a real-world network-diagram (branches could be different routes given the same colour) (an example: here are the colours for the lines on the London Underground). Palettes could be made into add-ons that can be shared amongst players.
    • It should be possible to select different shaped arrow-textures for the route-overlay: Road/Rail routes could have different route-overlay textures. So could tram/electric. Perhaps the player could choose a texture with sharper arrows for express-routes and textures with half-arrows for circular routes. Also, as well as giving each route it’s own colour, each route could have it’s own texture. This would be handy for colour-blind players. Likewise, textures could be made into add-ons.

    Warnings

    • Pop up a warning if attempting to send goods to passenger station or vice versa.
    • Warn if a line contains a mixture of goods and passenger stations (but if there are at least four stations on the line (at least two goods and two passenger stations), a mixed goods and passenger train may be viable).
    • Warn if a route is serviced by a combination of electric/nonelectric trains or a combination of tram/bus.
    • Warn if the same station is listed twice in a row in a route.

    Other

    • When using a station, a train could be given the option of using either of two tracks on an island-platform. This can ease congestion by making more optimal use of station-platforms.
    • If a route is serviced by both slow trains and fast trains, the slow and fast trains could use different platforms and if the fast train is catching up with the slow train, the slow train can wait until the faster train has left the station.
    • Line statistics: Number of items shipped this past year, and a graph showing usage over time.
    • Passenger line statistics: As well as drawing a graph showing usage over time, the graph could be divided into categories of journey (work, shopping, leisure, visiting friends, other)

    Views

    View modes

    • In the view menu (cargo, contours, land usage etc), the following additional views should be available.
      • Speed-limits of track-segments. These are shown when constructing. It would be nice to see them when in place. As an alternative to a number in a circle, it will be possible to colour the line according to it’s speed limit (the track will be coloured in shades of red – dark red is slowest, bright red is fastest, and for high-speed track shades of orange will be used instead), but it is still important to show the absolute speed as a number. When showing the speed, if the track is high-speed, the edge of the circle should be in orange instead of red.
      • Show the boundaries between all the track-segments. This can make things like building level-crossings easier as you can see where the road-segments join (which means a level crossing cannot be built at that point). To do this, either all track-segments could be highlighted or a marker could be placed where two segments join (and another type of marker could be shown for open segments-nodes (segment-nodes not connected to another segment)).
      • Grid view: A 2D grid of squares of a fixed length (or length that can be controlled with a slider) is drawn on top of the map. Useful for measuring. Optionally, this grid could also be rotated and moved.
      • Altitude view: Colour the land according to it’s altitude (e.g.. black could be the lowest point and white the highest). In order to see smaller changes, the colour-gradient could be made to repeat a certain number of times so you would see a number of black-to-white gradients along the height of the mountains (the number of times the gradient repeats can be set by the user).
      • Gradient view. This could colour all track segments according to the gradient (black is flat, white is maximum steepness of road (railways will use the same scale so the maximum steepness of a rail is medium-grey)). However, this will only show the gradient and not the surface-orientation. Optionally, the player can select whether to just colour roads, rails or both.
      • Surface-normal view (an alternative to gradient view): Colour each pixel according to the surface-normal colouring-scheme (the angle of the surface-normal to the horizontal plane) (anyone who knows how to interpret normal-maps when presented as an RGB triplet will find this handy). As well as just the gradient, this also shows the orientation. Also, as well as just track, you can colour the ground this way as well, or even both the track and ground.
      • Another idea is to exaggerate the height-differences. That is, the Z co-ordinates (height) are multiplied by a constant to exaggerate any bumpiness. Small hills can more clearly be seen this way. This is purely visual and affects the renderer only – construction-costs and physics are unaffected. As an alternative, the albedo can be exaggerated to better visualise the topology, or even increasing the specular component of the terrain might help. Alternatively, exaggerating the Z co-ordinate is something that could only be done when visualising the normal-map as an RGB triplet so the differences can more clearly be seen without affecting the physical topology.
      • Colour tracks according to whether or not electrified. This is an excellent means of finding where those tiny gaps in the catenary are located. If a pixel both electric and non-electric, the non-electric colour gets priority. This is also a lot easier than searching for missing segments in the catenary by either visually inspecting the catenary or hovering the electrification-cursor over minuscule sections of track to see if they are green.
      • Colour tracks according to whether or not they are high-speed. This is easier than checking for the subtle colour-difference between the two track types and is also useful to find minuscule gaps between two high-speed portions of track.
      • View ‘main connection’ roads in a green overlay.
      • X-ray mode so you can see tunnels and their contents (they will be drawn translucently – like they are when building a tunnel). Perhaps also draw infrastructure that is blocked by hills (the easiest way to do this is to not render the ground at all).
      • Clearance-volume view. The maximum volume that vehicles using the road can occupy is shown. This makes it possible to visualise how high you need a bridge to be to clear the clearance-volume.
    • Options to make certain objects see-through or completely invisible. Examples are trees, buildings, stations, infrastructure, vehicles, smoke from steam locomotives, the land itself, etc.
    • Draw overlay. This could be implemented as another view where the player can use the mouse to draw black lines on the screen as a reminder for themselves of possible future plans. The overlay can be enabled and disabled in the views-menu like the other view. There are three possible ways this could be implemented.
      • Draw as a texture. The player draws their plans (or whatever else they want to draw) as texels on a texture that is drawn on all objects. You’d need either a very large texture that covers the whole map, or only have textures in areas where drawing is present.
      • Draw as geometry. This is like having a 3D pen that can be used to draw things anywhere in the map.
      • Draw as 2D overlay: This is the easiest means of implementing “Draw Overlay”, but also the most restrictive. The player draws their plans onto a 2D bitmap. However, once the camera’s position and orientation change, all the drawings will be in the wrong place. To solve this, each 2D bitmap could remember the camera’s position and orientation and there will be a dialog that lets the user show one of their drawings and when doing so,, the camera’s position and orientation are restored to where it was when the drawing was made.

    Height contours

    • How high is the distance between two height-contours? There should be a window that tells you the height of a height-contour when the height-contours are on (similar to the window that pops up explaining the land-use colours) (this will be called the “height contour information” window).
    • Option to change the density of height-contours (the height between two height-contours). A control for this could be in the “height contour information” window. Perhaps if having too many height-contours makes the scene cluttered when viewing distant mountains, the height-contours could only be shown within a certain distance from the camera.
    • If rendering too many contours is expensive for the GPU/CPU, an alternative would be to change the reference-point (altitude) of the first height-contour.
    • If the height of contours can be changed, as well as displaying it in metres, it should be displayed in bridge-clearance-height units (or a fraction thereof). This means that if you see a contour, then the next contour is where you have to build a bridge for sufficient clearance. BTW is the height-clearance for road the same as the height-clearance for rail?

    Measurement tools

    • Measurement tool: Given two points on the map, show both the purely horizontal distance and the 3d distance between the points (3d distance is the length of the line and the purely horizontal distance is the length of the line projected onto the horizontal plane).
    • Track measurement tool: Given a start-point and endpoint, finds the length of the shortest distance along the road/rail network between the two points.
    • Display the altitude at the point under the cursor (could be the average height of the pixel-frustum projected from the pixel of the mouse-cursor). Optionally, also show a height-contour at that height as well (with additional height-contours in different colours for bridge and tunnel clearance heights)
    • Display the gradient and slope-orientation at the point under the cursor.
    • Draw a circle of a given radius from a given point.

    Other

    • Mini-map. This would come in handy if you want to see the whole world at a glance and don’t want to slow the GPU down to a crawl. The basic mini-map would be completely static and just show where the town-centres and industries and water are (this does not change). Optionally, town buildings (changes with growth/demolition), height (colour each pixel according to height) (changes with terraforming and construction), infrastructure (changes with construction) can be shown. As long as the rotation is limited to 90 degree angles and the zoom is fixed, the mini-map should not take up much CPU/GPU time.
    • For industries, the outline of the goods-icon could be a different colour depending on whether the product is produced or consumed.

    Construction

    Construction in Train Fever can sometimes be a very frustrating experience – especially for new players. The more experienced you get, the more “rules of thumb” you end up learning. Here are some ideas that may make construction a lot easier, more automatic and less reliant on “rules of thumb”. This is a collection of ideas I have had, and there isn’t really a unifying vision. But it’s nice to have lots of ideas thrown around…
    General Track laying

    • A very minimalistic but useful improvement would be that when a track-segment is destroyed, a ghost marker is placed at the centres of the start-node and end-node of the destroyed segment that remains in place until the next segment is built or construction-mode is exited (the ghost markers disappear). Seeing the location of the last thing that was built can make things easier with little effort from the developers, although if some of the ideas below are implemented, the ghost-marker may not be of much use. Perhaps it might even be possible to press a key or button to move the start node or end note to where the old start or end node was.
    • When you want to build a road/rail segment, as well as moving the end-point, it should be possible to move the start-point. This makes building bridges and tunnels easier (aligning pillars, making sure the road/rail-segment is just the right length etc.). Like the end-segment, the start-segment can connect to other nodes if it moved nearby. Either the start-node and end-node can be selected (using the left mouse-button), or another mouse-button (or left mouse-button +shift/ctrl/alt/etc.) can be used to drag the start-node. Also, there should be the ability to lock the two nodes (movements applied to one node are applied to the other) so that the entire segment can be moved, or even rotated around a central point. If locking nodes, perhaps things like curvature and gradient can be locked too.
    • When building rail, it should be possible to instead of building a line from the start-node to the end-node, to just lay a tiny segment of rail just beyond the end of the end-node (as long as nothing is blocking it) (this can be done for roads too). This tiny segment can be called an ‘Anchor’ – it has the same orientation and altitude as the track that would have been laid in normal-mode. This can come in handy if you’re planning to build a direct line through some rough terrain but due to a cash-shortage, you want to first build a longer and windier line with steeper gradients which you plan on upgrading later and you want to use the tiny rail-segment as an anchor so you remember your original plan (also if you build several of these anchors, you can upgrade the line in stages). This also has other uses (in situations where you want to have something to connect your track to) and can come in handy if the developers chose not to implement the ability to move the start-point.
    • Another idea involving anchors is when the player is laying a long segment of track over rough terrain, a small segment of track (anchor) could be placed at the ‘zero crossings’ – that is, the places where the altitude of the ghost-track is equal to the altitude of the pre-existing terrain. Again, this is handy if the player wants to build a cheap track (where the segments follow the land (this minimises terraforming costs)) but plan for when a more expensive track is to be laid by remembering the ‘zero-crossings’ (once the player wants to upgrade the line, the bits in between could be replaced by terraformed land, bridges, tunnels, etc.).
    • The ability to build only part of the segment you are about to build would come in handy – especially if the two nodes of the segment are joined to already existing segments. Once the positions of the start node and end node have been worked out (this is the bit where you have the green tick and red circle), there would be a third node that can be dragged along the length of the segment you are about to build. Only the track from the start-node to this third node (or end node to third node will be built). One situation where this could come in handy is if building a railway in a place where there is a main-connection road, you can build the partial track-segment from the end of the segment (or start of the segment) to just before the main connection road. With the new track in place, you can then build a bridge with pillars aligned perfectly to your new track, and once you’ve connected the ends of the bridge to the main connection road, you can then demolish the road that is blocking the railway, and then build the remainder of the railway to connect the two ends of the gap.

    Curvature and gradient

    • An option to rotate the end end (and possibly also the start) nodes (‘node orientation’) so the track approaches the node from different direction. This can come in handy when building flyovers and diveunders. There will of course be the option to restore the node-orientation to the default position (forwards).
    • As well as the start and end-nodes, a third node could also be used to control the track-curvature.
    • Instead of just a curve from A to B, have an option to increase the length of the straight track at the start and end and reduce the radius of the curve in the middle. Likewise, the player may want to have curved ends of smaller radius with straight track in the middle.
    • To build in a perfectly straight line (non-curved), as well as the snapping (which is only practical if the segment is long enough), there should be a button (or key) you can press to force the track to be straight. This is better than the current snapping-to-straight ability we currently have which is useless for short segments and can get in the way when attempting to build long segments with a really high radius.
    • Lock Curvature. When dragging, press a button (or key) that locks the curvature so when the curvature is locked, you can only build track of the current radius (moving the mouse makes the node as close to the mouse as the constraint will allow) until the curvature is unlocked.
    • Lock Gradient: Like Lock Curvature, but with gradient instead of curvature.

    Track modification of existing dead-end segments

    • It should be possible to modify existing dead-end track segments (segments that have an end or start that does not connect to anything (at least one open node)). This can make it easier to fine-tune the track when building it (it saves you from having to destroy a segment and re-build it). Perhaps when in construction-mode, you can right click a track-segment and you get a context-menu (the segment is also highlighted) with a few options.
      • The easiest thing to do would be to prune a short section of track (about 1 sleeper in length as long as the remaining track is at least 1 sleeper in length) from the end of the segment (or beginning as well if both nodes of the segment are unconnected). The cost would be the cost of demolishing a 1-sleeper length track-segment.
      • Change curvature of dead-end segment. This changes the radius of a curve without having to manually demolish and rebuild it. The cost could be somewhat less than the cost of demolishing the old curved track and building the new curved track. This could also be done for the track coming out of a switch, but then, you’d only be able to decrease the curve-radius unless it somehow becomes possible to merge the other path of the switch’s segment with the following segment.
      • Change gradient of dead-end segment. The altitude of the connected node remains the same. If both nodes are unconnected, the altitude of either the start, centre or end can be locked.
      • Change altitude of unconnected node of segment. If both nodes are unconnected, you can change the altitude of either the start or end nodes or both at the same time.
      • Change node orientation (rotate the node).

    Segment information and manipulation

    • For each segment, it should be possible to query the segment and obtain data such as the length, radius, gradient and any other parameter that segments may have. It should be possible to copy the numeric values to the clipboard.
    • When building a new segment, it should be possible to open a dialog that lets you manually type in parameters of the segment that is about to be built. Hopefully, the construction tools should be adequate to build segments without having to resort to manually typing things in – this is for those of us who want to have ultra-fine control of our segments. It should be possible to visualise how the segment will look and make further changes before construction is finalised.
    • Ability to split existing track segments into smaller segments. You can currently ‘hack’ this ability by building a switch near the point you want to create the split. However, it would be nice to be able to split a really long segment while there is a train on it.
      • I have noticed that sometimes, a segment can have both a curved part and straight part (or two curved parts). Perhaps make it possible to automatically split the segment at such points.
      • Make it possible to split a curved segment at the point the track is oriented in exactly the same direction as a reference-track (a straight track selected by the player). That is, for a given curved track, find the spot that’s parallel to a reference straight-track and split the curved segment at that point.
    • Merge road/rail-segments: Most of the time, this is probably not possible, unless the two segments have exactly the same radius and gradient. However, if we allow minor changes to the existing segments to be made (curvature, gradient, etc.), it might be possible when there isn’t a perfect match of gradient and curvature as long as nothing is blocking the path of the ‘averaged out’ segment. This is mostly useful for when you want to build a switch on a part of the track where two segments join, and for getting rid of all those tiny segments that get left over after switch-construction.

    Alignment and snapping

    • Option to turn off the automatic snapping (e.g. when joining a station to a road). While sometimes this can be handy, it can also sometimes get in the way (the player should not have to demolish a road that does not block the station to be built just to be able to build the station). You can occasionally work around this by zooming in real close from straight above, but snapping will still happen if close enough. Perhaps holding down shift or ctrl or alt will disable snapping.
    • Alignment tool: Select a object (be it building, station, bridge-pillar or even track), and all infrastructure will be built perfectly aligned to the object until turned off.
    • “Move as close as possible” tool: When building a segment with two open nodes (or a station), using this tool will move the segment (without changing it’s orientation) so it just touches the obstacle (e.g. bridge pillar). This is handy for making the most use of an existing situation. The player would have the option to either keep the altitude locked and only build as close as terraforming will allow, or change the altitude to enable the object to be moved as close as possible.
    • Clone altitude: Clones selected altitude on either the start or the end node. If a fixed gradient is set, both nodes change height. Can also work for stations as well as track.
    • Clone curvature: Select a segment and your segment will be built with the same radius (the curvature is locked).
    • Make segment concentric. Select a segment and your segment will be built with a radius (the curvature is locked) making it perfectly concentric with the other segment. This can make some aesthetically pleasing layouts.
    • Station alignment. This is a mode for building large stations that combines the alignment tool, the “Move as close as possible” tool and the “Clone altitude” tool. By building two train-stations perfectly aligned next to each other at the same altitude, you can pretend it’s a very large station or a mixed passenger-goods station. Optionally, this mode could build some additional passing-tracks (tracks without a platform) between the two stations.

    Multi-track building mode

    • Multi-track building mode. Having the ability to build two or more parallel tracks can not only save time, but it also makes it a lot less frustrating to build multi-track tunnels or multi-track bridges (especially if they cross the river or existing infrastructure at an angle). The existing method of building double-track tunnels is not only unintuitive but can be frustrating if there is something blocking the second track but not the first. And I’m sure building double-track tunnels is also cheaper than building single-track tunnels and then expanding to make it double-track.
    • When building a double-track segment, perhaps have an option to automatically place a connecting track going from one track to the other (a crossover) using two switches. If more than two tracks, it should be possible for any two adjacent tracks, or perhaps even make it automatically possible to build two sets of crossovers if there are more than 3 tracks.

    Level crossings

    Bridge-building is not a task that the new player would want to tackle immediately, so they might choose to just use level crossings for the time being (there’s not much traffic around in 1850 anyway). However, there are plenty of pitfalls the player may encounter – many which are not immediately obvious. To counter this, more helpful error-messages could be displayed.

    • AFAIK, it is not possible to build a road over an existing railway. If the user attempts to do this, they should be warned to build the road first and then the railway.
    • If attempting to build track that crosses the road at the boundary of two (or more) road-segments, the player should be given a warning suggesting that they rebuild the road as a single segment to prevent the track crossing at a segment-boundary.
    • AFAIK, you can only build multiple tracks across the same segment if they are parallel (there is no gap in the track-ballast). If the player is building a second non-adjacent track across the same road-segment, they should be told that this is not possible (either that or an attempt should be made to split the road-segment so that both tracks end up on different segments.

    Switches (points) and crossings

    Increasing the variety of junction-types available not only allows the player to build more compact junctions, but complicated junctions can be aesthetically pleasing as well.

    • It should be possible to build a crossing (diamond crossing (X-shaped)) where two tracks cross. I can see two reasons the developers decided not to include these, it may make the path-based-signalling algorithm harder to implement and there may be all sorts of problems aligning the track. Having observed what happens when building level-crossings (a lot of the road is re-aligned), it might be harder to do with rails because they have a lower gradient-limit and therefore more space would be needed to align the track. Also, I think the players might be confused if the rail to cross consists of two or more segments at the point of crossing, but if the player can get the hang of the quirks involved in building level-crossings, they can also learn how to build a crossing of two railways. However, I have thought of two situations where building a crossing might be easier to implement, so we could make a few exceptions to the ‘no crossings’ rule.
      • If a double track line branches off from another double track line (this is known as a ‘level junction’ or ‘flat crossing’), the outer curved track will cross the straight track connected to the inner curve. When using double-track building-mode, a level junction could be built could be built (two switches and a crossing) in the same way that a single switch is built in single-track mode. Because the entire level-junction will probably be a single segment, the crossing can automatically be aligned with the rest of the tracks..
      • A double-crossover on two adjacent parallel tracks. This is four switches and a diamond crossing connecting the left track with the right track of a double-track segment. Again, the whole unit can be built as a single segment. This can be built in two stages like a single crossover is built (you just have to build the second crossover yourself), or alternatively when in multi-track building mode, it should be possible to build one of these things in one go (select two joined parallel tracks, place a start node and an end node and a double-track crossing is drawn between the nodes (as long as the switch curve radius isn’t too low).
      • A single crossover on three adjacent parallel tracks that goes from the track on one side (A) to the track on the far side (C), crossing the centre track (B) with a diamond crossing. Optionally, the crossing on track B could become a double-slip switch (or even a single slip switch). This principle could be extended to more than 3 parallel tracks, or even double-crossover (would require a triple crossing on track B).
    • There are other ideas for new switch-types that do not involve crossings. Even these would improve the compactness of junctions.
      • Parallel crossovers: If there are 3 parallel adjacent tracks, a parallel crossing from track B to track C can be built at the same position along the 3 tracks as the crossing from track A to track B. This would lead to segment with two switches at either end of the centre-track and one switch on each of the outermost tracks. This can be extended to N tracks and N-1 crossovers. I suspect this would be easier if both crossovers’ switches started at the same point along the track.
      • 3 way switches: I’ve been thinking of these and have come to the conclusion that unless automatic merging of track-segments is implemented, they will have to be built with the restriction that if the middle-track (first track) is perfectly straight, the third track’s maximum radius should be no greater than the absolute radius of the second track (otherwise, it would have to merge with connecting segments or grow if the other paths lead to open nodes) (this assumes 3 way switches are built by adding a second branch to an existing switch (the start-node would snap to the point of the start of the switch)) (I’m not sure what the restriction would be if the middle track is not perfectly straight). Also, I’m not sure if it would be possible to build the centre-branch last.
      • 3 way switch crossovers: If there are 3 parallel adjacent tracks, a 3-way switch on track B could create two crossovers (with tracks A and C). This might be easier to implement if the switches on A and C start at the same position along the track.
      • Combination of non-crossover 3-way switch and crossover 3-way switch: One branch could be part of a crossover to an adjacent track and the other branch could lead off somewhere else.

    Terraforming

    • A tool that raises an area of land exactly the height required to build a bridge with sufficient clearance over track that would be on the land at it’s current altitude. Of course if the nearby land containing the track to be crossed is at a slightly higher altitude, the raised land will still need to be raised further. Perhaps this tool could use a ‘picker’ to select a nearby area of land with track and the selected area is used as a reference for the “Raise height for bridge clearance” tool. Likewise, a similar tool could be made for lowering land enough to build a tunnel.
    • Similar to the tool above, another tool could lower the land by half the height of a bridge-clearance. This enables you to build both the track going under and the bridge using the least amount of slope and the least amount of terraforming (assuming the land is mostly flat).

    Bridges and Tunnels

    • When building either a bridge or tunnel, the height-difference between the end-node and the ground-level should be shown.
    • A new bridge-building mode: Drag a bridge from a start-point to an end-point and a bridge is created over the obstacles below with minimalistic height-clearance and earth is terraformed up to meet both ends of bridge (or a single bridge-segment is built). Bridges at a gradient can be built this way too (just change the gradient and the start and end heights are changed automatically for minimum clearance (the gradient will remain the same because both heights are changed by the same amount)), and perhaps you can even adjust how much ‘padding’ you want to add to the minimum-clearance if you want taller bridges. This can be used for tunnels as well. Of course, the old method (building a road and using the M and N keys) will be kept as bridges built this way (especially the stone-bridge) look more organic than a perfectly-flat bridge. Perhaps both modes could be combined and the altitude-clearance calculations could take the humpiness into account.
    • When dragging the end-node to build a bridge, there should be a mode to automatically select a bridge-type according to which bridge-type has pillars that fit (it cycles through all the available bridge-types until it finds one with pillars that fit). This is handy if you have a choice between long and thin pillars or thick round pillars.
    • When using the M and N keys to control the humpiness of a bridge, it should be possible to press a third key to reset the humpiness to the neutral position.
    • When building a bridge (or tunnel) using a long segment, have a third node that controls the point at which the gradient becomes flat. This is useful for when building a bridge and the track starts at the same height as the track you want to build a bridge over, but you want to stop increasing the height once the bridge has reached clearance-altitude. Alternatively, the gradient can automatically be adjusted so that when it reaches the obstacle to cross over (or under if it’s a tunnel), the gradient automatically changes so the clearance-altitude (or depth) is reached when the obstacle is reached, and the remainder of the bridge (or tunnel) is built with zero gradient. Perhaps both modes could be combined, the gradient is locked and the third node positioned automatically.
    • If the segment to build includes the start of a bridge or tunnel, only build the track as far as where the tunnel portal will be, or where the start of a bridge would be built. This is useful for when building a tunnel and you want to change the gradient the moment you reach sufficient depth to start tunnelling.
    • When building a track that includes the start of a tunnel, the placing of the tunnel entrance depends on the existing state of the terrain, and currently, the portal cannot be moved if the end-node remains in place. It should be possible to drag the tunnel-portal so that it can be placed anywhere along the length of the track that is to be built. If placed further down, the part before the tunnel portal will just be made deeper. If dragged closer to the start, land will be terraformed upwards to allow an earlier start to the tunnel (a ghost-mesh will show the land that needs to be terraformed upwards). The player can still see if the tunnel is deep enough if there is no terraforming at the end of the segment. If the segment to build has multiple tunnel portals, these could be manipulated as well. Also, it should be possible to add extra tunnel portals and subtract existing portals. There could even be a height-contour drawn at the height of the roof of the selected tunnel-portal. A similar means can be employed for building bridges – part of the track would be on a bridge and part of the track could be on land terraformed upwards. This is handy if you want to get round the “No signals on bridges” rule without having to continuously guess where to raise the land upwards.
    • A new tunnel-building mode: Draw a tunnel-segment under some obstacles. The tunnel is extended to the minimal length needed to reach ground-level (the gradient can be lessened by making the extensions not so minimal, and perhaps even control the curvature in some way or decide where the portals are (the ground by the portals is either terraformed upwards or downwards)).
    • If there is a “Bridge Pillar Collision” error, instead of making all pillars invisible, the pillars should be shown and the offending pillar should be coloured red (like the bridge is if it collides with something).
    • The user should be given some control over exactly where bridge-pillars are placed (for example, they might want to build a road underneath it in the future).
    • Given two bridge-pillars, there should be a construction-mode that enables the player to draw a segment that goes underneath the bridge between these two pillars at the narrowest possible angle that can be built without causing a collision. The segment should be the minimum length required to be able to build from without worrying about causing a collision with the bridge-pillars. Optionally, the segment could be composed of two curved segments to enable even greater use of available space.
    • Sometimes when the player wants to build a bridge over a road but the height-clearance is not sufficient, the land is terraformed up so the road crosses at a level-crossing. Offer the user an alternative to push the road down so a bridge can be built over it instead.
    • Make it possible to build a bridge over stations (would need a long distance between pillars) and possibly even certain types of town-buildings.

    Electrification

    One of the problems with the current electrification building mode is that it is easy to miss out on minuscule segments when adding catenary. Here are some solutions. These solutions can also be used to transform track into high-speed track.

    • A flood-fill tool that electrifies everything up to the next dead-end, switch or station.
    • Select a start-point and an end-point and everything in between is electrified. However, if there are multiple routes, only the shortest route may be electrified, and it may become too easy to miss things like crossover-tracks.
    • Given an area (it could be a rectangular area in screen-space), all track within the area will be electrified. But if the view is tilted at a low angle, it may become easy to accidentally electrify large swathes of distant track.
    • In the ‘line’ window, there should be a button to electrify the entire line. But this may take the fun out of electrifying track, and it may miss out on crossovers between the two tracks of a double-track line not used by the line. Right-clicking will show the cost.

    Signal placement

    • There should be a tool that given a length of track without any switches, platforms, etc, places a signal every X metres (the number of signals that will be placed is also shown), or places X signals (the distance between signals is also shown).

    Blueprint mode

    • Blueprint-mode is a mode in which no actual land/infrastructure is changed, but allows you to design a new track-layout for free before you build it. The way this works is that the game keeps two versions of the map (or just the map-region where blueprint-based construction is being used). Construction affects only the copy, and the regular map remains unchanged until the plan is turned into reality (synchronisation is done (the changed copy is copied to the original) or the player cancels the changes). This would be especially handy for anyone who wants to play the game in ‘Iron-Man’ mode and does not want to waste money with layout-experiments.
    • In Blueprint-mode, terraforming meshes that are blueprints could be rendered using blue polygons with white outlines (the ghost meshes for terraforming when building in normal mode are currently rendered with white polygons and black outlines).
    • One interesting consequence of having Blueprint-mode is that it would then be possible to implement a gameplay mode where instead of instantaneously building the track, you can commission the construction of the track – that is, it takes a certain amount of time to build. This is how things work in the real world and anyone who wanted ultra-realism could play like this, but personally, I think building track instantly is much more fun so this should only be an option. Also, it might make doing things like building a ‘quick hack’ to escape a gridlock-situation a lot harder.
    • If ‘commission construction’ mode is implemented, it might be possible to specify which parts to build first and which parts to build later (e.g. first build the railway and then build the road-bridge over it).
    • Perhaps during construction of a non-blueprint segment, it could be possible to join the nodes of non-blueprint segments to blueprint segments. However, this would violate the “blueprint-map does not affect the main map” rule.

    Land reservation and building decommissioning

    • It should be possible to reserve land to prevent towns growing onto where you want to expand your network later on (but if multi-player mode is ever implemented, this has great potential for abuse). Perhaps if some land is occupied by a ‘blueprint’ (see “Blueprint mode”), the town will see the land as reserved, but this breaks the “blueprint-map does not affect the main map” rule which would make the game slower. Currently, this can be ‘hacked’ by building rail-track on land to constrain town-expansion.
    • Instead of telling towns to demolish buildings, you can mark a building for decommissioning and reserve it’s footprint when the decommissioning is done. This will be a lot cheaper than demolition, but it could take many years. Perhaps if the building is demolished in ‘blueprint-mode’, it could become decommissioned.

    Construction visuals and feedback

    • A height-contour could be shown for the altitudes of the start and end nodes. These could be in different colours. This can come in handy if trying to decide whether to build a downwards track after a bridge crosses what it was meant to cross, or extend the bridge to a nearby hill.
    • If a certain point on an existing road/railway (or any other obstacle which you can build a bridge over) is selected (or group of points), a height-contour can be drawn at the altitude required to build a bridge over the existing road/railway. Also when building a new segment, height-contours can be shown for the altitude required to build a bridge over the lowest and highest points in the segment. Likewise, a height contour can be drawn to show how deep a tunnel has to be to be able to go under certain obstacles. This can come in handy if you want to build a road/railway up a hill and only start tunnelling at the last moment when there is sufficient height-clearance.
    • When showing the white (or red) mesh of terrain to be terraformed, it should be in a different colour/shade depending on whether terrain is being added (terraformed up) or subtracted (terraformed down).
    • When the mesh of terrain to terraform turns pink, the problematic parts of the mesh (the parts whose terraformation is not possible (e.g.. it causes a collision with an existing object)) should be a deeper shade of red than the rest of the mesh.
    • Construction icon: The tick should have orange or yellow background (or some other colour/shade that is different from the not-possible-grey) if construction is possible but if there is not enough money or a vehicle is in the way.
    • When showing the construction-price, additionally, the ratio of the actual cost to the cost of building on terrain that is perfectly aligned (the “no terraform cost”) is shown (or instead of showing the ratio, the “no terraform cost” is shown). That way, the player can see how much money they will save if building closer to the existing terrain.
    • When dragging a node, there should be some sort of indicator to show if the road-segment is sufficiently long to host an inline bus-stop on both sides of the road.

    Demolition

    • Small and big bulldozers: Currently, it is too easy to accidentally demolish the wrong things (e.g., you were demolishing the track leading up to a station an accidentally demolished the station). In the bulldozer menu, you could select between “small bulldozer” (only demolish track and signals) and “big bulldozer” (also demolishes buildings and stations and waypoints etc. as well as track). Perhaps once the big-bulldozer is used, it immediately reverts back to small-bulldozer, but then, if you want to delete a large number of inline stops, you might want to select an additional option to not revert back to the small bulldozer once the big bulldozer has been used. If blueprint-mode is implemented, there could be a bulldozer that only demolishes blueprint-objects.
    • Warn if the player is about to demolish a station currently served by at least one line (this may be over the top for inline bus-stops).
    • When the “Buildings must be removed first” message is displayed, the relevant buildings should be highlighted.

    Stations

    • Removed waypoints should also become ghost-stations in the same way that regular stations become ghost-stations. But this might be a problem if demolishing multiple waypoints and the newly positioned waypoint takes on the identity of a different waypoint which was not the intention.
    • Make it possible for a bus-stop to be on multiple segments.
    • Multiple bus-stops on the same segment. This can be ‘hacked’ by building a road joining the segment between the two stops. Alternatively, if “split segment” is implemented, this would make an easier ‘hack’ possible.
    • Ability to upgrade a bus-station to a tram-station without having to demolish and rebuild. Perhaps this can be done by building tram-tracks in a bus-station.

    Other editing

    • When moving an end-point around, there should be the ability to undo the last drag (that is, restore the node to it’s previous location before the node was dragged). This can be useful if we got a bridge in just the right spot and we tried to see if we could move it, but ‘just the right spot’ was so small it’s impossible to find again (this happens a lot if the view was rotated since the last drag). As well as undoing the drag, the camera could optionally be oriented to where it was when the last drag ended.
    • As well as being able to undo the last drag, it should be possible to move the end-node back to the last place it was where building was possible (ignoring warnings about cash and vehicles in the way).
    • Terrain-hugging mode. Divide the track to build multiple segments so the track follows the terrain instead of spending money on lots of bridges tunnels and terraforming. This will build a bumpier track, but can save a lot of money. Of course, there will still be small amounts of terraforming involved – especially if the gradient of the land is too steep. Perhaps the player can also control the maximum number of segments the track will be divided into.

    Misc construction

    • Tree planting mode. And perhaps other eye-candy objects too.
    • Signs: Can be used as reminders, to point something out to other people who want to look at your savegames, or to point out a bug when submitting a save-game to the developers.

    Infrastructure

    Stations

    • Stations with more than 5 platforms would be nice.
    • Mixed passenger/goods stations (This can currently be ‘hacked’ by building one next to another, but unless the various alignment-tools are implemented, it is hard to perfectly align the two stations)).
    • If two short trains terminate at the same platform and arrive in opposite directions to each other, it should be possible for both of them to use the platform at the same time as long as it’s long enough for both trains. If bay platforms are implemented, this would always be the case. However, it should also be possible to do this without bay-platforms. Not only would it allow for greater flexibility with the train lengths (as long as the platform is long enough for the total length of both trains), but it would also allow for through-trains to use that platform as well.
    • Advanced station building mode: It becomes possible to have greater control of the different components of the station. For example some platforms could become bay-platforms. Some platforms could be for passengers and some for goods. Some tracks would have a platform on each side to double the loading-speed, and some tracks would not be connected to a platform at all (passing-tracks) (these would be for trains that do not stop in the station at all). Perhaps the passing-tracks could even have crossovers to the track at the platform to enable multiple through-trains to use the same platform at the same time. Maybe even allow for the building of multi-layered stations with tracks crossing at right-angles (such as Berlin HBf, Amsterdam Sloterdijk, Tamworth), or even curved stations (e.g. York).
    • If a train is passing a station platform, a speed-limit is imposed. However, if it is using a passing-track, there should be no such speed-limit.
    • The large bus/tram stops should have an entrance-lane as wide as the widest city-road. That way, two vehicles can enter and two can exit at the same time.

    Signals and Waypoints

    • A waypoint that lets faster trains through but not slower trains (or vice versa). This is handy if your route has trains of mixed speed and you need overtaking places. However, the same effect can be achieved by splitting the route into two and using regular waypoints.
    • Priority-signals that give way to faster trains at a junction (I’m not sure if that is how signal-blocks currently work – are the signals currently priority signals or FIFO signals?).

    Roads

    • One-way streets. As well as being able to control traffic and have narrower roads with greater speed-limits, it can also come in handy for building dual carriageways and proper motorways.
      • Perhaps there could be an exception for public transport (all private transport can only go one way, and player-owned vehicles (or only trams) can go both ways.
      • There will only be a single tram-track on a one-way street.
      • If two one-way streets join, the corners of the road at paths that are not allowed will look pointy and and the corners of the road where paths are allowed will look smooth (like they currently do). This will make it easy to build realistic-looking slip-roads (highway ramps) when building a motorway.
    • Pedestrian-only streets. These could be extremely narrow and would allow for no road vehicles (with the possible exception of trams (two-way tramlines would have to use gauntlet track )). This would also enable towns to have Medieval-looking town-centres. However, there would have to be a mechanism in place to prevent the player from turning too many streets into pedestrian-only zones to force people away from their cars. Additionally, pedestrians and trams could also appear on sections of grass between streets.
    • Road-waypoints. Might come in handy for micromanaging your buslines (e.g. making them use the inner path on a wide street) or preventing goods-vehicles from passing through a congested city centre.

    Railways

    • I think that the high-speed track is introduced too early (it should be introduced in the 1960s or 1970s), and that the low-speed track needs it’s speed limit increasing to 160kph. Either that or keep things the way they are and have a 2nd type of high-speed track introduced in 1980 limited to 400kph (or 300kph if increasing the ‘speed of light’ breaks the game) and limiting the 1st type of high-speed track to 200kph.
    • Allow signals on bridges (and possibly also in tunnels).

    Bridges

    • Do all bridge-types cost the same? Do they all have the same speed-limit? Is it just purely aesthetic? There should be an indication of the features and limits (cost, max speed, min radius, max length, max pillar height, max distance between pillars).
    • If there is a maximum bridge-pillar height, it will prevent the player from cheating to get the “Glacier express” award. I once saw a screenshot of someone getting the “Glacier express” award purely by building bridges with really high pillars.
    • Maximum bridge weight: Vehicles will only be allowed to enter the bridge if they are below a certain weight. In the event of trains, there are several options for working out the maximum weight – either the heaviest locomotive/wagon, the weight of the entire train, or the weight of just the portion of the train currently on the bridge (if a long train is above the bridge maximum weight, it might still be allowed on if the bridge is shorter than the train and the heaviest train-segment that can fit on the full length of the bridge is below the maximum weight).
    • Different bridge-clearance heights for different types of vehicles. Some vehicles (such as double-decker buses) would require a taller bridge to be able to fit under. However, it would be too fiddly to have large numbers of bridge-clearances, but to make things easier, only things that obviously require higher bridges (double-stacked containers, double-decker trains, double-decker buses) would require extra clearance. Also to make things easier, the introduction of the first double-decker vehicles could co-inside with the introduction of bridge-types with better pillars (less footprint, greater maximum distance, etc.), or possibly even a relaxing of the maximum-gradient restriction. I’m not sure if the catenary would need to be made higher if the line is to be made suitable for double-height wagons, and for that matter whether a bridge would need higher clearance to enable catenary. Also, there would have to be a view-mode that shows track under bridges that is only suitable for single-decker traffic. Having to rebuild your infrastructure to allow for taller bridges might be frustrating for some (not just having to build taller bridges and raising the height of the roads/rails leading up to them, but also demolishing old aesthetically-pleasing bridge-types that are no longer available) (so this should just be an option (making it optional also means that old savegames will still work when a double-decker vehicle is currently under a not high enough bridge)), but OTOH enabling this may make the game more dynamic.
    • Double-decker bridges (two layers stacked on top of each other). Although I think this would already be possible if there was a bridge-type that had small pillars on the left and right sides but not the centre).
    • Suspension bridges. These could have a really long distance between pillars (this length could be known as a ‘span’), but may require a large height-clearance if you want to build directly over the towers (but not over the centre of the span).

    Pedestrian infrastructure

    • Pedestrian underpass/overpass so that they don’t have to cross the road and block traffic (e.g. when getting from a train-station to it’s grouped bus-stop). Perhaps if a bus-station is next to a train-station, there could even be an underpass linking the train-station and bus-station directly.
    • Pedestrian staircase from non-connected elevated road to road below. If there is a bus-stop on the elevated road, passengers could walk down the stairs to get to the road below.

    Other

    • Abandoned track. Any railway that is not used will become slightly overgrow with grass, and the rails will rust. This can also happen to unused country roads that are not ‘main connection’ roads and are not used by any traffic. It could also happen to non-active town-roads too.

    Industries

    • The vanilla set of industries should provide for a cargo-vector whose end-product isn’t ‘goods’.
    • There should be an agricultural vector in the standard industry chain. The simplest is taking wheat from a farm to a food-processing-plant to turn into food that is to be delivered to the towns. Towns require food to grow (but to make things easier, the amount of food required to max-out a town’s growth-potential would be lower than the town’s maximum food-acceptance). The Train Fever goods model comes in handy because if a farm is close enough to a food-processing-plant which is close enough to a town, a food-chain can start up by itself and the town will have sufficient food for growth (just turn on cargo-view to see which towns are being fed). Farms can only be present below a certain altitude (but food-processing-plants can be anywhere), which means that towns on a distant plateau will not have access to food until a food-service is set up. Alternatively, the map-generator could only place farms in certain areas of the map.
    • Likewise, towns in the desert should also require water.
    • I’ve not looked into the industry mod-capabilities, but would it be possible to make a cyclic chain? An example of a cyclic chain is Iron-mine -(iron)-> Steel-mill -(steel)-> Vehicle-factory -(Vehicles)-> Iron-mine. What will happen is that if the iron-mine is supplied with vehicles, the iron-production will increase.
    • Also, is it possible to make industries that produce multiple cargo-types? Or ones that produce cargo items if either of the inputs is present (OR), or both inputs present (AND), or to have optional requirements (some of which may increase the rate of production).
    • Would industry plugins be able to detect the presence of other industry plugins? That way, you could separate different production-vectors into different plugins, and if a plugin that produces a certain cargo-type is absent, the industry can ignore the requirement for that type of cargo.
    • The industry-window should show a graph of production over time. Also, it should show how much was delivered to each line that serves the industry, and how much was sent without a line (where the cargo items travel by themselves) within the past year.
    • In the current industry-model, would having a vector with unlimited acceptance break gameplay (make it too easy to make money)?

    Vehicles

    • In the vanilla version of the game (the game without mods), it would be nice to have a greater selection of trains. While I can understand that it takes time to model the trains and that the modding community provide a huge selection, I have identified a few notable gaps in the vanilla trains-list (I’ve only played up to 1957 so far). Bear in mind that many people will form their opinion of the game in vanilla-mode without trying the numerous mods.
      • The player has to wait until 1888 (38 years) until they have a choice between a fast but not powerful locomotive and a slower heavy goods vehicle. All new locomotives introduced before 1888 improve all the paramaters from the previous locomotives so until 1888, the player will always choose the best locomotive they can afford without having to make any real decisions. Perhaps an earlier heavy goods locomotive (max speed 35kph, power 170kW, tractive effort 40kN) should be introduced in the early 1860’s.
      • From 1944 (when the Class 75.4 Baden VI c steam locomotive expires) to 1958 (when the the Class V 100 diesel is introduced), there is no heavy goods locomotive available that isn’t electric. Sometime between ca.1925 and 1944, a new locomotive (either steam or diesel) should be introduced with a top speed of 90kph and a kW of between 580 and 809 and a tractive effort between 90 and 177. Either that or the expiry date of the Class 75.4 Baden VI c and introduction date of the Class V 100 could be tweaked so one becomes available when the other expires. Or was this done deliberately to encourage the player to electrify most of the network?
      • When the Class A4 is introduced in 1935 with a maximum speed of 145kph, the maximum passenger-wagon speed is 120kph and remains so for another 25 years (during which two more >120kph locomotives are introduced) until the introduction of a 140kph passenger-wagon in 1960.
      • In 1907, there is an abrupt jump in the maximum speed from 50 to 100kph. Was this done deliberately to force the player to have to deal with locomotives of vastly different speeds sharing the same track?
      • Sometime after 1907, a locomotive with a low kW and maximum speed of ca. 70kph and low running-costs could be introduced. This could be used to serve passenger-lines in out of the way branch-lines in rural parts of the map with not much traffic, or short and light goods-trains in those same areas. Then in the 1940s or early 1950s, a diesel locomotive with similar specs (but a bit better overall) could be made available.
    • Specialised road-vehicles for the different cargo-types. Road vehicles should have different graphics according to the different cargo-types. It would be nice to be able to identify the type of cargo being carried by a road-vehicle just by looking at it like you can do with train-wagons. To make things easier for the developers, perhaps the same container could be used by several different road-vehicles, and instead of a different vehicle-type, the player just needs to outfit the vehicle to carry a particular cargo-type.
    • Tilting trains: These could have a reduced curvature speed-penalty (would this only apply to high-speed track?).
    • In the train-window, as well as controls for stopping and reversing trains, if the train is waiting at a signal that leads to a signal-block with at least one interchange, there should be a control to give the train priority at the current signal. This can sometimes be handy to reduce temporary gridlock if you want to move a particular train out of the way ASAP.
    • Also, there should be a control to force the train to ignore the current signal completely or even go the wrong way. But then, it should be the player’s responsibility to avoid collisions. This can come in handy if the player needs to unblock a gridlock.
    • Trains should show their current altitude somewhere.
    • Boats: Giving the player an aquatic transport-vector gives the game more variety, and also enables the players to take advantage of maps with a large area of water. In the early stages of the game, boats can be handy because you don’t need to build much infrastructure – only harbours, boat-depots and the occasional waypoint. Later on, boats will have very fast loading-speeds so they remain competitive with high-speed land-vehicles, and in the year 2016 (or earlier if you don’t care about realism), a scientific breakthrough will enable high-speed boats. Although the player can still build a really long bridge and run TGVs on it if they really want, the game should be balanced in such a way as to discourage that sort of thing. There are several possibilities for implementing an aquatic transport-vector.
      • The simplest thing is to just use the existing zero-altitude rivers and lakes. All the developers would need to do is add harbours, boats and a path-finding algorithm that uses water and avoids bridge-pillars (or avoids low bridges altogether), and uses buoys as waypoints.
      • A more advanced game could have canals, canal-locks and aqueducts. These would be expensive to build.
      • An even more advanced game could also include rivers that can change altitude (go downwards in the flow-direction) and require more power to travel against the flow-direction, river-rapids (where navigation is not possible (the river may have a steeper gradient here)), and high-altitude lakes (beware of letting the player flood large areas of the map).
      • Some boats may require higher bridge-clearances than others. For example, barges may not require much clearance, but shipping-container carriers require lots. Also, the lowest bridges that can cross water may still be too low even for the barges. In this case, there will be moveable bridges (e.g., drawbridges, swing bridges, etc. (see https://en.wikipedia.org/wiki/Moveable_bridge )) to enable river-traffic with low-altitude bridges at the expense of only one mode of transport being able to cross at once. Perhaps in the 1850s, this may be the only means of crossing a navigable waterway (bridges with tall enough pillars won’t yet be available).

    Gameplay and game mechanics

    • Subsidies: Every so often, an announcement could be made that if the player builds a line connecting two industries or two towns within a year, they will be paid double the price for the next year. As well as giving the player a bit of extra cash, it will also encourage them to play in such a way where instead of building a single network which keeps expanding, they will build multiple networks and sometime in the future, they will all join up. Without subsidies, there is little incentive for the player to have multiple network-hubs early on in the game, and with just one hub, if the town-growth mechanics are not changed, the player will end up with a single cluster of big cities and a scattering of unconnected small towns.
    • Allow the player to set how much they charge the passengers for tickets. Charge them too much and they’ll travel by car or won’t travel at all, but if the line is overcrowded, the player might be able to get away with changing the ticket-price. However, I suspect that this would lead to too much micromanagement.
    • Passenger satisfaction: This will affect whether or not the passengers would choose to travel using this line again. This could depend on the ticket-price, the time taken (which includes the amount of delays they encountered en-route), and also on the quality of the scenery (this would be hard to measure, but I suppose being near mountains and water and trees might help).
    • In addition to the ‘full-load’ options, there could be the following options.
      • Wait until either full or the next train is waiting to enter the station (if there is still some cargo waiting to be loaded, the train will wait until the remaining cargo has been loaded).
      • Wait until x% full (if there is still some cargo waiting to be loaded, the train will wait until the remaining cargo has been loaded).
      • Wait for at least one cargo item to arrive (if there is still some cargo waiting to be loaded, the train will wait until the remaining cargo has been loaded). This is handy to start an industry chain from a ‘dead’ industry and you want to deliver the first cargo-item ASAP.
      • Wait for either x seconds or the train is full (if the loading-speed is so slow that the train cannot be fully load in x seconds, it will wait until the remaining cargo has been loaded).
      • If there are two trains and one is waiting for a full load, it should leave when the other train arrives at it’s destination. If there are more than 2 trains, the train should leave when the trains are spread out evenly on the route.
    • Settable game-speed to real-time ratio (how fast game-time passes in real-time). Events in the game will still happen at same rate as with real time (locomotive speeds will be the same, as will the ’20 minute rule’). However, it will take longer (in game time) for new locomotives to become available. This is for players who want to extend the challenge of “the early years” and build a large network before newer and more convenient locomotives become available). Town growth and maximum town goods acceptance will also be affected.
    • Option to turn off maximum goods-acceptance. However, I suspect the game would then need major rebalancing, but even so, the town would still require some goods to enhance growth. Maybe instead of turning off the maximum goods-acceptance, this value could just be doubled in easy games.
    • Beginners may want to reduce the industry density so they don’t accidentally saturate towns with goods preventing more industries from being productive and wondering why their industries are not working.
    • Variable cost ratios. As well as being able to set the difficulty to “Easy, Medium, Hard”, there should also be a “Custom” option where you can set the costs for different categories of expenditure. Some players may want low vehicle-costs and low vehicle-running-costs, but very high construction and terraforming costs.
    • Events like festivals crop up. You are given a warning a year in advance and a large area of land is set aside to be turned into a festival-venue (a building of the ‘leisure’ category). You can spend the year making sure the station has adequate connections to other parts of the map and there’s an adequate bus/tram connection from the station to the venue. After that, for a period of one year, the venue will attract large numbers of passengers before it is dismantled. In the year beforehand, the land will look like an under-construction building which becomes built when the festival starts and vanishes when it’s over. Likewise, an existing commercial-building could become the host of a trade-show.

    Map generator

    • Xtra-large maps. To reduce the number of people complaining about the game slowing down, Xtra-large maps will not be available on 32-bit builds, and possibly machines that don’t meet certain other criteria (e.g. they use the GPU on board the Intel CPU for rendering instead of a dedicated graphics-card, although I’m not sure just how restrictive the Intel GPU is compared to an AMD or NVIDIA card).
    • Rectangular maps – for when you want the benefits of large maps without the slowing-down caused by large maps. This will enable you to build really long lines in one dimension if you don’t care about the size of the second dimension.
    • Perfectly flat maps. As well as being able to start a Netherlands-themed game, this option will also be easier for beginners as they don’t have to worry about track-alignment so much.
    • Settable water-percentage. Also set whether the land is a huge continent or cluster of islands.
    • When staring a game in 1850, it is hard to predict how your machine will handle the map in the year 2050. To counter this, the game should come with sample save-games (or they can be downloaded) played from 1850 until 2050 (without any mods) that can be used to measure the game-speed. The player can tweak the graphics settings and once they have found an acceptable compromise between map-size and graphics settings, they can start a new game with the largest map-size they think their machine can handle. Also, different machines may have different bottlenecks depending on both the CPU and GPU. Of course, these saves will come with an option set that prevents the player using the saves to unlock achievements (or the maps could be in sandbox-mode if that is implemented).
    • Settable town-density and industry-density. In order not to break the ‘seed’-value, the existing seeds will still produce the same maps if the densities are set to a certain value (I think that the current densities should be at the higher end when it comes to large maps).
    • As well as changing town-density, it should be possible to control whether or not groups of towns cluster together. That way there can be places with a high density of towns (giving the area the character of the German Ruhr-area) (in such areas, inter-city tramlines will be viable) and places with a lower density of towns (a more rural character).
    • Also, instead of giving each town the same growth-potential, some ‘towns’ will be destined to remain small, while others will be destined to blossom into cities or even metropolises (there should be an icon next to the town-name on the map (and in the town-list dialog) that indicates the type of ‘town’ it is). Villages will be just a few houses and shops and be so small it’s not worth building a train-station by them (they will usually be served by a bus with a single bus-stop) unless it’s the early (pre inter-city buses) stages of the game (although if it’s an isolated village near the route of the train-line, it might be worth building a nearby train station). Towns will be worth connecting and have a single train-station – even if all express-trains avoid it. Cities could have a central station and a small suburban station on each of the lines exiting the main station, and metropolises would have many stations (a whole network of regional trains and even a ‘S-Bahn’ network).
    • It should be possible to create worlds with the following distributions of towns:
      • One big city and lots of small towns (a bit like Ireland where the rail network will be dominated by lines radiating out from the big city). Maybe a second or even a third city.
      • One or two big cities and several small cities and several towns (a bit like UK or France where the rail-network is still centred on the capital city but there are several other important rail-nodes).
      • A group of cities without having a centralised ‘capital city’, with the usual towns filling in the space in between (a bit like West-Germany without West-Berlin where the rail-network is like a web without a centralised node).

    Visuals

    • I’ve noticed that the “Geometry” setting changes both the mesh-detail and the culling-distance. It would be nice to have separate controls for mesh-detail and cull-distance.
    • As vehicles get older, their specular component decreases – that is, they become less shiny. If you replace an old vehicle with one of the same type, it would be nice to see it look shinier. That way you can get a feel of their age by just seeing how shiny they are. Additionally, they can acquire extra textures such as rust, graffiti, etc. if they become too old and urgently need replacing.

    Awards

    • The “Trans World Express” award: Make a train complete a train-route that connects the two most distant towns on a large map.
    • The “Path-Based Awesomeness” award: Have a large number of trains present in the same signal block at once.
    • All 5 (or more) platforms of a 5 platform train-station are simultaneously occupied (the vehicles must stop there and the player cannot cheat by forcing them to stop).
    • Create a 5 (or more?) platform station with eight tracks (or four pairs of double-tracks or any combination thereof) leading out of each junction on each side of the station, and each entrance and exit track should be reachable from all platforms. It should be possible to do this with combined passenger and goods stations (where a goods-station has been built next to a passenger-station) as well. As a bonus, there should be at least one route assigned to each track (`total_routes = MAX(num_entrances_on_left, num_entrances_on_right)`). An additional bonus would be to have one route that takes every possible combination of entrance and exit tracks (`total_routes = num_entrances_on_left * num_entrances_on_right`) but I suspect a 5-platform station won’t be able to handle the traffic such a large number of routes will generate. Perhaps an additional requirement could involve having a flyover or underpass, or even a tunnel under the station that connects to both signal-blocks.
    • The “Uh-Oh Spaghetti-Oh” award: Create a junction (in a single signal-block?) with at least 14(?) switches. If the developers are planning to add crossings and more complicated switches, this award could include those as part of the criteria as well.
    • The “Spaghetti Hyperghetti” award: Six double-track railways converge onto a single area. In this area, there should be a junction where for each railway, it should be possible to reach all the 5 other railways. To maximise the total number of pathways in the junction, all diverging switches would have to appear before all converging switches (and if crossings are implemented, no crossings will be allowed, only bridges and tunnels). A bonus award will be unlocked if a route is assigned to all 6 incoming railways (`total_routes = ceiling(num_railways/2)`), and an additional bonus if there is a route that uses every possible entrance-exit combination (`total_routes = triangular_number(num_railways)`). However, in practice, if there are more than four railways converging at a singe spot and the angles between them are spaced evenly, the angle the path will make with it’s adjacent paths (immediately to the left and right) will be less than 90 degrees, which means it would be much more efficient to build a distant bypass directly from the start to the end bypassing the junction completely. In that case, the award could let us get away with not building tracks to join adjacent railways (`total_routes = triangular_number(num_railways) – num_railways`) (although in situations where the junction is at a junction of 3 valleys, it might make sense to have routes that turn more than 90 degrees when you want to climb a mountain). Unless the entire junction is contained in a single signal-block, I suspect that the algorithm to calculate whether a junction meets these criteria would be tricky. Maybe there could be a rule where all switches of junction have to be in area of X square metres.
    • The “Stairway to Heaven” award. Four roads or railways on bridges should cross over each other at the same spot and there’s an additional road/railway at ground-level at that spot too. This may only be achievable later in the game when the pillars can be high enough and far enough apart to make such a construction possible. Also, it would be nice if there were at least four bridge-types available (although if two tracks are road and two tracks rail, for bridge-types is currently possible).
    • The “Highway to Hell” award. Four roads or railways in tunnels should cross under each other at the same spot and there’s an additional road/railway at ground-level at that spot too.
    • A single cargo-item uses more than one vehicle to be transported to it’s destination (e.g. a unit of goods is transported from the factory to the station by train, and then a truck transports it to a distant suburb, or a train takes an item to the bottom of a hill with a slope that’s too steep for a train to handle, and a road-vehicle takes it the rest of the way). Additionally, there should be a similar award whenever a passenger changes from one vehicle to another.
    • As well as global achievements, we could have per-map achievements. These will be mostly the same as the global achievements although some may be contradictory (e.g. Train Fever and Truck Fever). This encourages players to build complicated junctions and ‘stairways to heaven’ in all their maps.

    Other

    • An option to prevent the camera following the height of the terrain. This is especially handy if the camera is zoomed out really far.
    • An option to automatically pause the game the instant before the first day of a new month is reached. This will enable us to maximise our expenditure before the maintenance-costs are paid.
    • The jukebox selection could depend on the time-period.
    • The first time a certain model of vehicle arrives at a station, it could play a particular tune. The vanilla vehicles would only pick the pre-existing Train-Fever tunes, but modded vehicles could be modified to pick any tune on your machine. Similarly, other events could trigger certain tunes to be played (e.g. when 1925 is reached and the road-style changes).
    • It should be possible to rename towns.
    • More irregular shaped buildings. Triangular buildings such as the Flatiron Building would enable the towns to use those corners on the map that rectangular buildings won’t fit in. Also, I notice that many of the small leisure-‘buildings’ are just small parks. These could be made to fit into irregular shapes if they are procedurally generated. One of the nice things about the Train-Fever towns is that the street-layouts look very organic. It would be nice if we had buildings that made the most of streets at tight angles. Otherwise, the player may be tempted to turn their cities into grid-based cities to optimise town-density.
    • Save-games should also save the workspace-data (which windows are open and their placements, and perhaps even whether things like catenary are selected in the build menu etc.). However, this may be a bad idea if loading the save on a display with a different resolution or aspect-ratio.
    • Tip of the day: When loading a saved game or staring a new game, a tip could be displayed. For example: “When building a road, press M and N to change the humpiness of the road. If the road is long enough, it will become a bridge or tunnel”.
    • An idea for optimisation: Instead of automatically checking to see if the routes need updating every time a new segment is built, allow the player to build without checking and require them to manually press an “update routes” button. Though I’m not sure how much CPU-time this will save and some players may get into the habit of forgetting to press this button, so if it is implemented, this would be best left as an option. Also, the routes may still have to be recalculated if some track containing an existing route is deleted.
    • There should be a savegame/screenshot/video competition every few months or so (e.g. most scenic railway, most complicated junction), and the winner gets a free trip to Minatur Wunderland in Hamburg.

    The Bugs

    Things I’m not sure if they’re a bug or a feature

    • It is currently possible to send a goods train to a passenger station and vice-versa. Maybe there is a reason for this (e.g. mixed goods and passenger trains involving 4 or more stops), or the player might want to use a passenger-station as a waypoint for a goods station. But for new players, they might be wondering why they can’t deliver goods to that station they built right in the centre of town (at least pop up a warning if sending goods to a passenger station).
    • Grouping a train-station with a bus-station can cause picked-up passengers in a train to vanish.
    • Sending a train to a depot (even if just to add an extra wagon) discards the content. Perhaps this is a feature because all the passengers want to go to their original destinations, but for cargo such as coal, coal is coal no matter where it is sent. Maybe instead of just sending trains to the depot, there should be an option to unload at the next station first and then go to the depot.
    • If train set to stop at grouped bus-train-stop, the bus or train station is then demolished and rebuilt (e.g. changing from old-style station to new-style station), this causes the two to be ungrouped (not a bug?), but the train-route (and bus route?) only re-appears if the new train-station is grouped with the bus-stop (or vice versa).
    • Trains have sometimes been observed to use their old paths if the paths have recently been updated (this may be the case if a train has not reached one of it’s stations yet (or for that matter, the route-start) after the line has been updated).
    • When the game is both paused and minimised, it still uses some CPU and GPU power (on a laptop, this drains the battery).

    Things that are definitely a bug

    • When using the vehicle-type filter in the “Manage lines” dialog, occasionally a railway line will show if using the “road” filter. However if I change the filter to “railroad”, the lines that showed when the “road” filter were active are still present. I’ve also noticed the opposite too, and even trams are guilty of this behaviour too. Perhaps this bug has something to do with grouped stations.
    • Sometimes when deleting the track that connects to a crossover, it sometimes becomes impossible to join a new track to one of the ends of the crossover. This is a very common occurrence.
    • I have observed non-contiguous track-lengths joined as a single track-segment (for track-lengths A->B->C, A and C can sometimes be the same segment even if B is deleted). This affects things like the bulldozer (A and C turn yellow) and being warned about a train in the way when attempting to demolish A or C when the train is on C or A. This most commonly happens when building a segment over a valley with an ‘island’ (terrain high enough to not require a bridge) in the middle which becomes two bridges, and then on the island, building a switch on the non-bridged track, deleting the switch and joining the two bridges back together. This will lead to the two bridges becoming a single non-connected segment. I have also observed this behaviour with one bridge and one non-contiguous non-bridged length joined as a single segment.
    • Sometimes bus-routes take very ‘loopy’ routes – even when there is an inline stop on both sides of the road. I have observed this happen when I am editing one bus-route and different nearby bus-route suddenly decided to loop round a block fro no apparent reason.
    • Sometimes when raising terrain, a huge spike can be created and the terraforming cost overflows the datatype the money is stored in (I once ended up with a positive bank-balance of ca. 2.1 billion when I had hardly any money to start with (btw. this did not cause any achievements such as “Transport Shark” etc. to be unlocked (I had not yet unlocked that achievement at the time))). If the bug cannot be found, at least have a sanity-check in place to see if the construction cost (when converting from floating point to integer) is greater than the maximum value of the integer-datatype used for money. If so, a bug-report should be sent back with things like camera-orientation, the mesh in the pixel-projection volume (pixel-frustum) pre-terraform, and any other relevant info.
    • I have sometimes observed that when I have recently been rebuilding the tracks a train-route uses, or change the route mid-way (e.g. add or subtract a waypoint), when the train drops off it’s cargo at it’s destination, the payment is not paid. This might also happen if the source-station or destination station has been demolished and then rebuilt – even while the game is paused the whole time.
    • If attempting to electrify track in station and there is a train at another platform, it still says there is a train in way.
    • I once (build 5080) somehow managed to get an electric locomotive to head to an unelectrified track at a station with mixed electrified/unelectrified tracks (the electric track was not fully connected to the rest of the electric network, and the route-overlay graphic showed the route on a platform with unelectrified track). Unfortunately, I forgot to make a savegame of the incident. Please tell me this is a know bug as I tried to reproduce this but cannot. I do know that a depot was involved in this somewhere.
    • Sometimes, it is somehow possible to create an extremely short section of track that can only be found if you zoom in really close and keep moving the mouse around with the bulldozer selected until you see a small yellow highlight.
    • When building a bridge, if after successfully finding a place where you can build a bridge, you drag the end-node towards the start node to the point where it shows a terraformed hill instead of a bridge, and then drag back away from the start node, the first bridge-type will be selected instead of the last-selected bridge-type. Ideally, the bridge-type that was originally selected should remain.
    • If deleting and then building a track when a stopped train will use it and the train behind it is still moving and also about to use it, the moving train behind will reserve the path preventing the stopped train in front from moving (“Waiting for free path”). However, if I stop the train behind, all of a sudden, the train in front can start moving again. BTW the stopped train may have been partially inside a station, or at least near (heading away from) a station.
    #17638
    simonmd
    Participant

    Bloody hell, you don’t do things by half do you?!!!

    If Urban Games put this kind of thought into the game, we wouldn’t have half the issues we do now, that’s for sure.

    You mentioned there is no tilt function and you cant see the horizon? Well, I can on mine, clicking and holding the mouse scroll wheel allows you to tilt as does two of the keyboard keys, R and F I think.

    I totally agree about being able to collapse minor windows but still be able to see the info. Many times I’ve wanted to keep an eye on a route or a vehicle so have left it open in a corner but of course, the PC is then having to render all of it’s movements as well. Being able to close the viewpoint but keep info like speed, passengers/cargo, etc. would be useful and save screen space to boot.

    Haven’t had time to read the rest yet but I hope someone at Urban Games does, some very good points that they would be foolish to miss.

    #17667
    electricmonk2k
    Participant

    Re tilt function: Actually, it is possible to tilt the contents of the viewport-windows but the game won’t let me tilt far enough to bring the horizon into view. But I suspect there’s a reason for that – the closer we get to the horizon, the more geometry appears in the viewport.I can of course tilt the main view enough to see the horizon.

    I too would like to collapse my windows and just see the info. This would be even better if there was a progress-bar so we’d also be able to see just how close the train is to it’s destination.

    Anyway, I had a look at the latest build and saw that you could now have a choice in the format of the units and even whether or not they were in Metric or Imperial. This would be a good place to put the frequency format setting (“seconds if < 3 minutes, otherwise minutes” (current), “minutes” (with up to 2 decimal places), “seconds”, “mmm:ss”) as long as it can also be changed in-game.

    #17671
    Anonymous
    Inactive

    Hi! Nice list, but it lacks Avenues and working bus lanes (if I didn’t catch it because of the length).. Trams should also become light-rail lines and railbusses should have the option to go underground.

     

    #17705
    electricmonk2k
    Participant

    We all have our pet ideas which we hope that someday the developers will implement.

    Anyway, I’m thinking about fleshing out my ideas for construction into the ultimate construction-tool with an explanation of how it could implement much of the functionality in a single tool, and even making some mockup screenshots showing the proposed tool-UI.

Viewing 5 posts - 1 through 5 (of 5 total)
  • The forum ‘Support’ is closed to new topics and replies.