TSW needs a World SDK, not just a Route Editor I would like to propose a technical idea about the future of Train Sim World and third-party content creation. Before explaining the idea, a little background may be useful. I have been developing content and tools for flight simulators for many years, including FSX and Fly!. With FSX, I developed scenery and tools for processing and generating large geographic datasets, including DEM terrain, land-use data, terrain LOD and scenery. I also developed the Dolomiti X scenery series for FSX, where the goal was not simply to create an isolated airport or route, but to build a geographically coherent environment that could coexist with other scenery and be expanded over time. More recently, I have been developing FlySafe, a flight-safety application which works with geographically referenced data and spatial indexing to manage large numbers of objects and geographic information efficiently. So when I look at the current TSW creation workflow, the first thing that strikes me is not simply that the PC Editor is complicated. The deeper problem is the way the world itself is structured. The fundamental limitation of the current approach As I understand the current TSW architecture, a route is essentially a self-contained world. That works very well for delivering individual routes as complete experiences. But from the point of view of long-term third-party development, it creates a fundamental limitation: routes cannot naturally become parts of a larger geographic railway network. Consider a real-world example from Italy. Imagine that one developer creates: Belluno – Treviso and another developer creates: Ponte nelle Alpi – Calalzo In reality, these are not two separate worlds. They are parts of the same geographic railway system. With a persistent geographic world, both developers could create their content using the same coordinate system. The two routes could occupy their real-world positions and potentially connect. With the current route-as-a-world approach, they remain separate experiences. This is, in my opinion, one of the biggest architectural limitations for third-party content. I don't think TSW needs a complete virtual Earth This is important. I am not suggesting that Dovetail should turn TSW into Google Earth or a planetary simulator. It doesn't even need to contain the entire planet. What I am suggesting is a persistent World Layer. Conceptually: TSW WORLD │ ├── Terrain ├── Roads ├── Buildings ├── Rivers ├── Vegetation ├── Railway Network └── Objects A route would no longer be a complete world. It would be a geographically referenced module inside the world. The coordinate system The foundation could simply be a standard geographic coordinate system such as WGS84: Latitude Longitude Altitude The engine could then convert geographic coordinates into its internal 3D coordinate system. For example: Belluno 46.xxxxxx N 12.xxxxxx E would always refer to the same physical location. This is extremely important. A Dovetail route and a third-party route could reference the same geographic space without having to know anything about each other's internal implementation. Terrain could be generated from DEM data This is another area where I think the creation workflow could be dramatically simplified. A developer could start with a DEM / GeoTIFF: GeoTIFF DEM ↓ Terrain Builder ↓ Heightmap ↓ Terrain Mesh ↓ LOD ↓ TSW World A DEM already contains elevation information. The tool can read the elevation values, convert them into vertices, triangulate the surface and generate the required LOD levels. This is not a new concept. I have worked with exactly this type of terrain data in FSX scenery development. The important point is that the developer should not have to manually construct the terrain inside a complex game engine editor. The SDK should do that work. Quadtree and geographic streaming Again, this is not a new technology. Hierarchical spatial structures such as quadtrees have been used for years in flight simulators and geographic systems. FSX already used hierarchical terrain/scenery concepts and LOD to manage very large geographic environments. I also use spatial indexing concepts in my current FlySafe project. The basic idea is simple: WORLD │ ├── Tile │ ├── Tile │ ├── Tile │ └── Tile │ └── ... The world is divided hierarchically. The simulator does not need to load everything. It loads the data required around the player's current position. For example: Far away → Low LOD Medium → Medium LOD Nearby → High LOD Very close → Maximum detail This allows the world to be much larger than the amount of data that is actually loaded into memory at any given moment. The railway should be a network, not just scenery This is perhaps even more important than the terrain. A railway is not simply a collection of 3D meshes. It is a network. I would therefore separate the geographic world from the railway topology: WORLD │ ├── Spatial Tree │ └── Railway Graph │ ├── Nodes ├── Tracks ├── Switches ├── Signals └── Stations The spatial tree answers: "Where is this object?" The railway graph answers: "How are these locations connected?" That distinction is fundamental. A track should therefore exist as a logical connection between nodes, while the visible rail geometry is generated from that underlying data. Imagine Belluno – Treviso and Ponte nelle Alpi – Calalzo Developer A creates: Belluno – Treviso Developer B creates: Ponte nelle Alpi – Calalzo Both use the same geographic coordinate system. The railway network could then conceptually become: Treviso │ │ Belluno │ │ Ponte nelle Alpi │ │ Calalzo The two developers do not need to create two copies of the same world. They simply contribute different geographic and railway data to the same world. This could eventually allow third-party developers to build large sections of real railway networks incrementally. What the development workflow could look like This is where I think TSW could become much more accessible. Imagine a dedicated TSW World/Route Builder. 1. Import DEM Import DEM / GeoTIFF The tool automatically creates: terrain; terrain tiles; LODs; geographic coordinates. 2. Import aerial/satellite imagery Import Orthophoto The image is automatically georeferenced to the terrain. 3. Draw the railway The developer works directly on a map. Instead of manually building everything inside Unreal, they trace the real railway: ───────────────╮ │ ╰────────────── The tool generates the underlying railway geometry and topology. 4. Add infrastructure The developer places: stations; platforms; signals; depots; level crossings; bridges; tunnels; railway buildings. 5. Create the timetable For example: Belluno 06:32 Ponte nelle Alpi 06:45 Calalzo 07:32 The developer defines the services. The TSW engine handles the simulation. What the developer should NOT have to recreate This is another key point. The content creator should not have to implement: train physics; AI; passengers; weather; lighting; dispatching; signalling behaviour; timetable simulation; train systems; gameplay logic. Those are precisely the things that the TSW engine already does. The creator should primarily define: what exists, where it exists and how the railway is connected. The engine should define: how everything behaves. A useful comparison: Outerra There is an interesting example outside railway simulation: Outerra. Outerra is developing a planetary/world engine where the geographic world itself is the foundation, and different types of content and simulation can exist on top of it. I am not suggesting that TSW should become Outerra. The interesting idea is the architecture: WORLD ↓ CONTENT ↓ SIMULATION rather than: ROUTE ↓ WORLD ↓ SIMULATION That difference has enormous implications for scalability and third-party development. The world doesn't even have to be the entire Earth The system could initially be limited. For example: TSW WORLD 1000 km × 1000 km or any other technically appropriate size. The important thing is not the physical size. The important thing is that the coordinate system is persistent and shared. Once that exists, content can be added to the world without every developer creating another isolated universe. What Dovetail would actually need to expose I don't think Dovetail needs to open-source Unreal Engine integration or expose the entire internal TSW codebase. A stable official SDK/API could be enough. Conceptually, something like: CreateWorld() CreateTerrain() CreateTrack() CreateSwitch() CreateStation() CreateSignal() CreateService() CreateTimetable() ConnectRoutes() BuildPackage() The internal TSW engine could remain completely proprietary. The SDK would simply provide the bridge: CREATOR ↓ TSW WORLD / ROUTE SDK ↓ TSW ENGINE This would also allow Dovetail to maintain control over compatibility between game updates and third-party content. Why I think this matters for TSW's future The current model is essentially: Route A = World A Route B = World B Route C = World C A world-based architecture could instead be: WORLD │ ┌───────────┼───────────┐ │ │ │ Route A Route B Route C │ │ │ └───────────┼───────────┘ │ RAILWAY NETWORK That would fundamentally change what third-party developers could build. A developer could create one section of railway. Another developer could continue it. A third could add a branch line. Someone else could create the station. Another developer could create services and timetables. All of them could contribute to the same geographic world. And this is where I think TSW has a huge opportunity TSW already has a very capable simulation engine. The problem is that the world containing that simulation is too isolated. I don't think the answer is simply to make the current PC Editor more complicated with additional tools. I think the better long-term solution is to create a World SDK that sits above the simulation engine. The workflow would become: GEOGRAPHIC DATA ↓ WORLD SDK ↓ TERRAIN + RAILWAY NETWORK + SCENERY ↓ TSW ENGINE ↓ SIMULATION The technologies involved are not science fiction. DEM processing, geographic coordinates, quadtrees, spatial indexing, terrain LOD, streaming and network graphs have existed for many years. FSX demonstrated many of these concepts long ago. Modern planetary engines such as Outerra demonstrate how far the concept can be taken. And developers like myself have already been working with these technologies outside the TSW ecosystem. The missing piece is the official bridge between this type of development and the TSW simulation engine. My suggestion to Dovetail Don't just give us a better Route Editor. Give us a World SDK. Give developers a persistent geographic world, a shared coordinate system, a proper railway network model and an official way to feed that information into the TSW engine. Then let the TSW engine do what it already does best: simulate the railway. That, in my opinion, would be the foundation for a truly scalable third-party ecosystem for Train Sim World.
Nice proposal for TSW Next (UE5 and starting from scratch) but I think it is not possible to do it with the current model for TSW (UE 4.x). The game already has a shared coordinate system (I think based on gps coordinates projected on a plane), and you can import tiles from other projects (ie: a small part of SEHS was used for Medway Valley) but it has its limitations. Earth is not flat, so if you project a large area (think a few hundreds of Km) on a plane the differences in heights and distances would become noticeable. Another, non-technical, problem are legal rights. If another developer makes an asset that he uses in TSW he keeps the rights. You would need his permission to use it. You can't just add everything that exists to a TSW library and give it away for free.
