Loading

NotRoadTypes

Wrap Raw Revise
  1. Spec
  2.  
  3. Essential
  4. • ‘road' and ‘tram' are independent, like ‘road’ and ‘rail’
  5. • they can coexist on the same tile in some cases, but do not influence each other
  6. • the term ‘roadtypes’ is confusing for historical reasons and due to pre-existing use in code, and is not used here: this is NotRoadTypes
  7. • ‘tram’ and ‘road’ are built as subtypes
  8. • per tile, one subtype of ‘road’ and one subtype of ’tram’ may be present
  9. • construction tools for ‘road’ and ’tram' are independent
  10. • adding/removing/converting ‘road’ on a tile does not affect ‘tram’ for tile and vice-versa
  11. • vehicles are either ‘road’ or ‘tram’, they cannot be both
  12. • vehicle routing and movement per ‘road’ and ‘tram’ are independent
  13. • any ‘road’ subtype may be freely combined with any ’tram’ subtype, there are no ways to make ‘road’ and ’tram’ incompatible with each other by subtype or any other means 
  14. • subtypes
  15.     ◦ proposed up to 15 ‘road' subtypes and 15 ‘tram’ subtypes (implementation detail: uses 4 bits each, uses 8 bits free in m8)
  16.     ◦ 15 is more than enough for any game
  17.     ◦ spec shouldn’t have an opinion on how many type a game needs, but 3 or 4 of each is plenty imho
  18.     ◦ each subtype has a label
  19.     ◦ vehicle compatibility with a subtype is determined by label
  20.     ◦ vehicle may determine some properties by subtype (power, possibly others)
  21. • drawing
  22.     ◦ ‘tram’ is always drawn above ‘road’; authors need to be aware of this when drawing sprites, no mechanism will be provided to vary this
  23.     ◦ drawing of city roads, bridges, tunnels, and similar will follow existing behaviour
  24.     ◦ drawing of rail crossings may or may not be fixed (road tile is enforced for tram crossings currently, this looked non-trivial to fix when I tried)
  25.     ◦ methods _may_ be provided to enable more control over appearance, e.g. snow above snowline etc
  26. • catenary
  27.     ◦ subtypes can provide catenary, or not (implementation detail: flag or cb returning sprites)
  28.     ◦ both ‘road’ and ‘tram’ can provide catenary on a tile
  29.     ◦ authors will need to draw catenary carefully to avoid it looking bad when ‘road’ and ‘tram’ catenary are combined on a tile
  30.     ◦ vehicle power on a tile is determined by vehicle against subtype label, unrelated to drawing of catenary sprites
  31.     ◦ there is sophisticated handling of rail catenary to preserve continuity where railtypes cross, something similar needs to be provided for NotRoadTypes
  32. • converting between subtypes
  33.     ◦ a convert tool is needed, similar to rail conversion
  34.     ◦ this will need to consider ownership carefully
  35.         ▪ too restrictive = can’t overbuild subtypes in towns
  36.         ▪ too permissive = deliberate or accidental breaking of existing routes by overbuilding incompatible subtype
  37. • drive-in stops:
  38.     ◦ behaviour of articulated vehicles and trams unchanged, can’t use drive-in stops
  39.     ◦ catenary needs to be provided for ‘road' drive-in stops
  40. • overtaking: out of scope
  41.  
  42. Optional (proposed by frosch)
  43. • split global toolbar to ‘road’ and ‘light rail’
  44. • this makes the distinction between the transport types obvious
  45. • in this way it’s clear that a tile can have
  46.     ◦ 1 type of rail
  47.     ◦ 1 type of road
  48.     ◦ 1 type of light rail
  49. • unknown: would the various vehicle menus, station menus etc also be split for ‘road’ and ‘light rail’? 
Posted by Anonymous at 10 Apr 2016, 09:46:16 UTC
Language: text • Views: 348

Version history

Revision # Author Created at
peakc5v6g Anonymous 10 Apr 2016, 09:45:39 UTC Diff
putsmzfzb Anonymous 10 Apr 2016, 09:44:09 UTC Diff

Comments