Roadmap

This is the roadmap to future versions of openBVE, subject to change.

The following summarizes the main goals:

The majority of routes and trains have to be downloaded and installed by users in potentially obscure ways that are all but easy and intuitive. With managed add-ons, an official add-on directory was added which the game can directly query to show what is available to download. Add-ons can then be downloaded and installed automatically with the mere click of a button. When newer versions of add-ons are available, they can be updated easily as well. Was introduced in 1.3.2.

At the moment, the renderer is heavily tied to the concept of "track positions" which is inherited from the CSV/RW route formats. This means that the renderer decides which objects to render at any given time based on what track position the camera is currently located at. As long as openBVE simulates a single rail, this is an acceptable concept, although it means that the camera cannot freely roam the world - it can only be moved relative to the rail. For an interconnected network of rails, this concept does not work at all, and so a new renderer will be designed that manages objects by placing them on a 2D grid. It can then decide which objects to renderer by examining which gide node the camera is currently in, and which other grid nodes are visible from that location.

Additionally, the current renderer uses mostly immediate mode rendering, which means that every object that is to be renderered is sent to the graphics card every single frame. This is very slow and limits the number of objects and the complexity of objects that route developers can utilize. The new renderer will store objects on the graphics card so that less transfer between main memory and the card will be necessary, greatly speeding up the rendering process. Planned for the 1.5/1.6 series.

At the moment, openBVE only simulates a single rail on which trains can drive on. Everything else is purely decorative. This is going to change so that an interconnected network of rails is simulated. The primary goal is to allow opposing traffic, for players to choose trains services that operate in either direction within the same route, and to develop routes that can be driven forth and back continuously (single rail or double rail with switches). The CSV/RW formats will allow some of these features, while others might only be available via new formats or editors. Planned for the 1.7/1.8 series.

The the moment, trains are inseparable units, mainly because the existing train formats do not work on individual cars, but on the train as a whole. This is going to change. All future train formats will be based on individual cars so that they can be freely combined into consists. This also opens up the possibility of coupling, decoupling and associated shunting operations during the game. Planned for the 1.9/1.10 series.

At the moment, openBVE uses a main menu based on Windows Forms that precedes the actual execution of the game. As such, a number of things cannot be done, for example easily configuring keyboard controls, accessing the menu from within the running game, loading a new route from within the game, and so on. Eventually, a new menu system will be developed that is entirely in-game without depending on Windows Forms. Planned for the 1.11/1.12 series.

At the moment, loading textures, sounds, objects, routes and trains, as well as simulating engines and brakes is achieved through functions built into openBVE. This is going to change so that external plugins perform these functions. The safety system plugins have demonstrated well that this degree of extensibility and flexibility is indispensable. The modularization of the source code also means that the individual components will be less interwoven than they are now, leading to smaller, cleaner and easier-to-maintain code in each component. This modularization is an ongoing process that will not be complete until very late in the 1.x series.

The following is an overview of important milestones which were already released, which are currently in development and which planned for future releases.

1.2.10

Runtime train plugins based on .NET can be used on all platforms. They supersede the older Windows-only plugins.

1.2.12

The default safety systems ATS and ATC were outsourced into a plugin in order to streamline the source code.

This series focuses on two major improvements. The first is occuring behind the scenes and advanced the modularization, namely support for textures and sounds via a clean plugin architecture. The existing BMP/GIF/JPG/PNG/TIF loader and the WAV loader have already been made plugins, and support for ACE textures and FLAC sounds was introduced. The second and more obvious feature is the addition of managed add-ons.

1.3.0

The API for textures was implemented. The existing BMP/GIF/JPG/PNG/TIF loaders were made external plugins. The ACE texture format is now supported.

1.3.1

The API for sounds was implemented. The existing WAV loader was made an external plugin. The FLAC sound format is now supported.

1.3.2

Support for managed add-ons was added, allowing users to browse and install add-ons directly from within the game.

A new renderer based on a two-dimensional quadtree will be implemented which will allow to roam the world freely. This is a prerequisite for more than one functional rail which will follow in later versions. Performance will also be greatly increased. The CSV/B3D, X and ANIMATED object formats will be made external plugins. The renderer may too so that it could be reused directly in other applications, such as the various viewers or potential editors.

1.5.0

This will be the first release in the 1.5 series. No details are available yet.

Allow for routes to be loaded via external plugins. The internal track geometry will be completely redesigned in order to allow networked tracks. At the end of this development cycle, routes can be built on which train services can run in any direction, including AI-controlled opposing traffic, an express train passing a local train, and the like. The CSV/RW formats will be expanded so that some of these features can be implemented in existing routes. A route editor is also being considered.

Rewrite all simulation-related components such as engines and brakes, implement new types of engines and brakes, and likely allow parts of these things to be externalized via plugins. All simulation-related components will work on individual cars, which will allow to freely combine individual cars into consists, likely also via the GUI once this has been rewritten. Coupling and decoupling of cars during the game will be possible to allow for shunting operations. Train loaders will be made available as external plugins as well.

Implement a fully OpenGL-based menu system and abandon Windows Forms.