On this page, I want to summarize what started to motivate me into creating openBVE, what has been done from day one to the present, and what might follow eventually in the future. I want to make sure that you understand that anything depicted on this page about future stuff is pure speculation. Whether or not the things turn out as depicted in this document mostly depends on the interest in openBVE by the community.
↷ 1.1. The animated object architecture ↷ 2. The next incarnation: Advancing to version 2.0 ↷ 2.1. The version 1.0 architecture ↷ 2.2. The anticipated version 2.0 architecture ↷ 2.3. New route features ↷ 2.4. New train features ↷ 2.5. Managed content ↷ 2.6. New user interface ↷ 2.7. When it this all going to happen? ↷ 3. An ultimate dream: Arrival at version 3.0
As of March 2009, about 11 months have passed since I first started to write the first piece of code for openBVE, and I can tell you that the KISS principle is the exact opposite of what I followed in order to arrive at a fully usable train simulator within not even a year. I always had a long-term plan, and I designed every part of openBVE with this long-term plan in mind. This often meant to prepare for an architecture that would not even be fully used for months to come, but eventually, unraveled and presented itself to the users.
Basically, the train panel is a series of animated objects: There are textures that change occasionally (e.g. lamps), then there are objects performing a rotation around a predefined axis (e.g. needles), and so on. Users have always been asking for the introduction of opposing traffic, some want to perform shunting and more. With the concept of only one train on a non-diverging piece of track, this is quite illusionary. And yet, what does it all have to do with panels and animated objects? Well, in order to visualize a preceding train or to visualize any opposing train, you will need to have a train exterior, not only a panel. And in addition to that, I always felt restricted by the fixed view of the 2D panels, and wanted to have 3D panels instead. So I realized that I could prepare support for all of these things at the same time by using a generalized animated object system for the visuals. The idea of a single animated object in openBVE is this: There is a repository of ordinary static objects (most often only one), called states. The animated object is then assigned functions that control which of the states to show, how to move them around, how to rotate them, and how to shift the textures on them around. The functions can employ arithmetics and flow control, and have access to a wide range of variables to read data from, e.g. the speed of the train, the acceleration, the pressure in any of the cylinders, the state of the doors, and so on. By combining the primitives (translation, rotation, etc.) with arithmetics, flow control and variables (speed, pressure, etc.), you can create a wide range of animation, like a speedometer in the train interior, a spinning wheel on the train exterior, but also objects like crossing gates, clocks, cars and a lot more. By the time I realized the potential of this generalized approach, I knew that openBVE could be brought to a richer life. Of course a lot of people still ask why I have concentrated on allowing for train exteriors and on some animation, and why I offer support for high display resolutions and the like, when the main focus of a train simulator should be realism. While I always try to understand how setting your display to the lowest resolution possible increases realism, I can tell you for sure that opposing traffic is definately not possible without train exteriors. As a consequence, the animated object approach not only allows to visualize your own train, not only the preceding train and not only the panels in front of you, in the future, it will also serve to visualize opposing traffic, while the main beauty is that any object regardless of which one we talk about can be fully animated in a lot of ways. For me, this approach saved a lot of time as I don't have to handle panels, train exteriors and so on in any special way. For the underlying engine, there is virtually no difference between these things. Of course, for performance reasons, the static scenery is handled specially, and for compatibility, the panels are not fully 3D either. But still, developers will hopefully find it to be a positive addition that animation is not restricted to the panels, but can be freely used anywhere else, too. While I originally thought of version 1.0 as the point where to achieve an acceptable degree of compatibility, it now also exposes major parts of the animated object architecture. As such, scenery objects can be animated with the current version, as well as train exteriors. I have had a lot of thought of were to move next. Surely, 3D panels are not exposed yet, and with a train simulator at hand, the most obvious thing to do in the future is to increase realism in the actual simulation part. However, for a long time, I didn't know which things should have priority. Should I implement a greater variety of brake systems, allow for more signalling flexibility, work on 3D cabs...? Then it came to me that ultimately, adding built-in features to source code is a dead-end way as far as extensibility is concerned, which is why I have completely restated my priorities for an upcoming version 2.0.
From the top, in openBVE version 1.0, we have a main menu that is separated from the actual simulation. This was done for a variety of reasons, including easier graphical user interface creation via WinForms (the windows, buttons, drop-down menus etc. you are so familiar with), and adequate support for Unicode. Inside the menu, you can set your options, select your route and train, and then start the simulation. What happens next is a relatively strict sequence of built-in functionality: First of all, the built-in route parser for CSV or RW routes is used to load the route, which in turn makes use of the built-in parsers for B3D, CSV, X and ANIMATED objects. Route loading includes creating the scenery composed of a lot of objects, creating the track to drive on (which is a geometric description of where curves and gradients are), and creating signals, stations and miscellaneous other little things. Once this is done, we have a route to drive on. But without a train, this is not much fun. Thus, the built-in parser for trains is used in order to load the train characteristics, sounds, etc. The parser might in turn use the built-in object parsers in order to load exterior objects. Once all of this is done, we have a train to drive with. Finally, the simulation is running, and openBVE does a series of things in order to bring the train to life: Built-in physics allow the train to follow the track, while taking toppling, derailments, gravity, torque, friction, air and a lot of other things into account. Built-in brake systems allow to simulate air brakes and some more modern forms of brakes. Built-in coupler mechanisms allow the individual cars of a train to collide with each other, as well as with other trains. And finally, built-in security systems fetch data from transponders, present some indicators to the driver, and take over control of the train if deemed appropriate. Now by the number of the phrasing "built-in" that I have used in the previous paragraph, it does not seem that 1.0 has a very extensible architecture. Well, one thing is the ability to integrate external plugins that mainly allow for custom security systems, as well as for some graphical gimmicks to appear in the train panel and for some custom sounds to play occasionally. These plugins are limited to some degree. First of all, they are 32-bit C/C++ DLLs that can only execute on 32-bit Microsoft Windows, which goes against openBVE's philosophy of being cross-platform. Second, they don't allow readouts of a lot of train internals, nor for those of different trains, the upcoming track geometry, etc. Many modern security systems need continuous transmission of such data, which the plugins don't offer (although a nifty enough developer can approximate such systems relatively well). Basically, to sum that up, much of the functionality provided is built-in, and there are relatively little ways to extend that functionality without integrating it directly into the openBVE source code. Now even though openBVE is open source and could be modded by anyone, a simple problem would arise in such a case: Content developed for a modded program is unlikely compatible with openBVE. It should also be pointed out that unlimitedly expanding the source code with new features is unlikely going to work in the long run. The reason is simple, and can be relatively well illustrated with the security systems: Currently, openBVE offers the built-in ATS and ATC systems, or actually, just rough approximations to the endless variety of the original Japanese systems. Visit the UK and find ATP, AWS, TPWS and the like. Go to Germany and find PZB, LZB, and the like. Go to France and find KVB, TVM, or to Europe in general, and have ETCS. You can hopefully imagine that while other simulators from their respective countries offer generous built-in support for such systems, no simulator will ever have adequately detailed and realistic support for all of them. This is why the plugin-architecture allows to simulate things that the main program does not offer out-of-the-box. Ultimately, this guarantees that other systems can be simulated, given that someone writes a plugin. Let's assume that you know what the main difference between openBVE 1.0 and all of the other simulators is: hand-coding one track vs. 3D-editing a whole network. You might be aware of the fact that I tried to address some of the limitations associated with the existing formats in which is being hand-coded - without much success, just to mention that, too. This made me think about why all of the parsers need to be a built-in in the first place. Given the power of a plugin architecture, not only could the security systems be extensible via plugins, but also all of the object, route and train parsers, the physics, the brake systems - and why not the signalling, too?
And again, let's start from the top. Via a menu system fully integrated into the simulation (more about that later), you can select a route and a train as usual, but then, things are a bit different compared to the 1.0 architecture. The first difference is that none of the parsers are built-in. Everything is external and can thus be expanded with features not currently possible. Let's take a closer look at the objects. The currently built-in parsers only allow to process B3D, CSV, ANIMATED, and something called X (a subset of Microsoft's DirectX object format). Not only might you want to have a parser that can process the whole range of DirectX object files, but you might also wonder about why not to have a parser that can load completely different formats you are used to from your favorite 3D editing tool? Or even files originally written for other train sims? There is a lot of stuff available for, say MSTS. The only thing that prevents us from loading an object originally written for MSTS into openBVE is the lack of support for the file formats, possibly including object and texture formats. Via a plugin, you could load any format, as long as a plugin is available for that format. Given a plugin architecture, the currently built-in parsers would become external plugins that communicate with openBVE through a powerful application programming interface (API). In the case of an object parser, all that needs to be done is to present the parser with a nice file name and to have it process the file for data that openBVE can understand. The data passed back can be used wherever required, e.g. in the route. Likewise, a route parser would have the job of creating a track in the form openBVE requires, and to populate the world with a lot of objects. If the currently built-in parsers for CSV and RW routes become external plugins, nothing would prevent us from having plugins that could import routes from other simulators, or any new format you might come up with. Ultimately, just to stick to the MSTS example for illustration, an MSTS route is complemented with an activity file that tells which path in the route to take. Even if you imagine the one and only functional track to drive on, a motivated programmer could still write a plugin that loads an MSTS route activity into such a track structure, with everything else being visual only (e.g. other rails). Just as with the objects, loading routes through a plugin mechanism allows the community to import different route formats than currently available out-of-the-box, or to invent their own. All that needs to be present is a plugin that can load a given format. The most noticable different between openBVE and other simulators is, however, that one functional piece of track to drive on. I have come to the conclusion that it would be too much of a work to transform the current openBVE 1.0 into a fully functional railroad network. However, having an unlimited amount of functional, but independent tracks, is something that would be easily possible, and would also allow for the much wanted opposing traffic. As such, while importing routes from other sims into openBVE does not seem to be much fun (was just an example anyway), it would still be possible. And that is what the architecture is mainly about. I am not focusing on allowing content of other sims being reused in openBVE, but merely to create an architecture that is extensible to such kind of a degree by having the simulation part separated from the content-loading part. Let's take a look at the possibilities of custom brake systems and physics, and let's start with the latter. While the inter-connected pieces of track would still be managed by openBVE, and while "axles" or anything else that is intended to follow the track would still be managed by openBVE, there is a lot that can be done besides that. First of all, a car needs exact coordinates to appear in 3D space, affected by toppling for example, or inaccuracies in the track. On a collision or derailment, you might want the car to completely leave off the track and make some swirly movements. You want a bus simulation? Well, the bus would need to leave the "track" entirely and be freely controllable. That's one of the jobs of the physics component. Others include the simulation of gravity, wind, air resistance, friction, and so on. Or, in other words, basically anything that tells how the train has to move, where for it to appear, and so on. Even the most rudimentary things like "speed" would not be a thing that openBVE would internally understand any longer, but would be simulated at the sole discretion of the physics plugin. Different kind of vehicles need different physics. I doubt that a friction-based simulation would be appropriate for a maglev, for example. That's where extensibility could pay off, not to mention a bus simulator for those who are interested enough. And regarding brake systems... Well, there are a lot of brake systems, although the most prominent one is probably any derivative of the classical air brake system. I have spent much time on the creation of a brake system that exceeds the realism found in other simulators, even though I was confronted with some challenges which I eventually didn't solve yet: To implement a good brake pipe pressure propagation algorithm, for example. That would have meant to simulate the flow of air and all associated delays and fluctuations due to leaks and pressure "consumption". Nonetheless, if you have come to the conclusion that the whole plugin-based architecture is ultimately meant for integration of other sims into openBVE, then let me make things a bit clearer. I, as a single person, cannot possibly create everything people might want to have in the future, and with all what I create, openBVE would still be limited to that particular functionality. A plugin-based architecture would allow for other people to remotely join the development of a train simulator by writing components that can be later reused. Given other means of installing content (more about that later), any object loader plugin could be used by any route loader plugin to load objects, for example. Likewise, any route or train could use any physics plugin deemed appropriate, just as any train could use any brake system or security system applicable. With plugins that have such distinct purposes, combining them in the appropriate way would allow for much more and detailed content than possible with solely built-in functionality. That's what the architecture is about: extensibility, in whichever way ultimately used. Of course there are a lot of questions needed to answer on how to design the architecture itself, especially in order to accomodate different needs. The upcoming time might well be spent on the discussion of the API, from designing it from scratch, to arriving at the first thought-through and usable one. Almost obviously, I have already thought about most of the ramifications, and have a particular design in mind. Now you might think that my job ends at providing the architecture, and leaving the rest to others. Well, one of the most important goals is to always provide backward compatibility for the things already created. This means that a set of standard libraries (plugins) will be available to address CSV/RW routes, CSV/B3D/X/ANIMATED objects and the trains, and I would of course continue to maintain them. More than that, there are things that I want to arrive as already mentioned earlier, from the possibility of individual car simulation, 3D cabs and more flexible train characteristics. A possible new route format for hand-coding is also not off the table (although I have noticed a relative lack of interest). This means that I will be both pursuing the job to create and maintain the architecture, as well as the set of standard libraries that will be extended compared to the current version 1.0. The core engine should provide a series of interesting new features for that, which will be presented in the following.
The other aspect is weather and time of day. I want to introduce weather effects such as rain, snow, thunder and wind, which are mostly visual effects, but also partly functional due to associated resistances. For example, if the wind is blowing into the direction of travel, air resistance will be lower as the speed difference between the train and the wind would be smaller. On the other hand, wind would press against the exposed frontal area of the train and accelerate the train in that direction (small force though). Then, there is time of day. Currently, all routes and objects are built to depict a specific time of day. With the introduction of daytime/nighttime textures and emissive light, the same object can represent either condition, or actually, even a continuous transition between them. Currently, light sources are fixed in position and color, but a simulated sun would shed different colors from sunrise to sunset, just as the moon would. Support for these rudimentary Earth-effecting light sources should be included in openBVE in order to let any route depict any time of day without a change in the route and object files. Of course different seasons are another problem, but not currently intended to be addressed this way. For better performance, level of detail systems are also likely to be featured in the future, along with an object management system and renderer more broadly targeting the needs of a free-roving 3D world instead of a 1D piece of track.
I have been wanting fully 3D cabs for a long time. Compared to many other simulators, I have never had any particular interest in extensive geometric detail. There are a lot of programs out there which offer geometric detail at the expense of textural detail. A general rule that I have observed is that the higher the amount of polygons, the less likely it becomes that the authors use good textures, if not any at all. I think that 2D cabs look particularly good especially because they don't use geometric detail, but solely textures. I don't want 3D to be at the expense of textures. In the worst case, I would consider a cube with six faces centered on the driver's eye a 3D cab, provided good looking textures on the cube's faces. Arguably, there can be better stuff created here, but I want to emphasize that 3D has to look good, be it with the bias of engineering geometry and textures to only look good from the driver's usual point of view. The main thing associated with 3D cabs is obviously the higher degree of freedom. You can look around freely, observe all the indicators where they actually are supposed to be, and look to the left or right to stop more accurately at stations, to observe scenery elements or to enable operations that would not be possible otherwise. I have been playing some flight sims lately (including Orbiter, a space flight simulator) and noticed that I like best those where all elements in the cockpit can be fully operated with the mouse. Given a vehicle of a particular complexity, it feels somewhat unrealistic to always hit on key combinations when you - in reality - would have to stretch out your arms into all directions of the cockpit. Via mouse control, all levers, buttons and switches could likewise be operated in openBVE, provided of course that users want to do that. Consider the following screenshots of Orbiter. The one on the left is interactive, the one on the right unfortunately only visual:   There are not all that many elements to interact with in a real train? Well, any modern cockpit of a high speed train is usually full of controls, not to mention steam locomotives and their various components. Of course, the amount of controls and their locations in a cab varies greatly between trains. Here is an example of a modestly modern cab:  This also illustrates another interesting possible addition: Support for multi functional displays (MFDs). If they are to be animated with text, an actual text and graphics drawing API could be more practical than working with a bunch of individual bitmaps. Although that would probably be just some sort of a bonus and not a necessary feature. If you followed the development of openBVE up to 1.0, then you can probably imagine that support for 3D cabs is long available, just not exposed yet. The animated object format provides all means to create objects in 3D and to animate them accordingly on a low-level basis. With the architectural changes planned for 2.0, there needs to be a thought-through interface first though in order to allow animated objects to depict all the various train components. The reason is simply that while we currently have brake cylinders and power notches, this might be well different with a plugin that uses other things.
As a user, you are presented with the option to download individual files or folders and have to assemble a working configuration yourself. Sometimes, installers are wrapped around distributions, and often, it is unsure where they extract the content to exactly, and you have to check against or install into a temporary folder just to make sure the content is extracted in the way you would expect it. Upon route updates, you are often instructed to go to folder XYZ and delete all the files stored in there before attempting to downloading and install the new version - all manually of course. Quite a different problem is where to get new add-ons in the first place. Most of the users are probably searching forums for links to homepages they don't already know, assembling a large list thereby. And still, even after years have passed, you might eventually find content that was long present there, only that you couldn't find it earlier on. It is thus not only about the nuisance of how to install stuff, but also where to get it from. I have been playing other games but simulators lately, too, including The Battle for Wesnoth, a turn-based strategy game (which follows KISS very strictly by the way). I think content management couldn't be easier in that game. Inside the main menu, you click on Add-ons, select the campaign you want to download, and that's it. Then, at any time later, go to Campaign within the main menu in order to select a campaign for playing. I think it couldn't be much simpler to get add-ons (which here too are developed by third parties):   How does it work? Well, developers create their add-on, then upload it via an add-on server, then you can download it. I have thought about this numerous times and think that even with the openBVE community, a similar concept can be used, albeit with some differences. First of all, let's go back to the way content is stored on the hard disk. In openBVE, the content is unmanaged, meaning you have to assemble the content and put it into the right place yourself. Sometimes, one piece of content (e.g. a route) has a dependency (e.g. a signal pack). Of course just installing one piece of content without the other will lead to unwanted side effects. The first thing that I would want to introduce (all optionally though) is managed content. Managed content would basically be packaged into a single folder with a unique name and would include information about the content, such as the dependencies, but also additional information such as the setting of the route (country, city, operator, etc.). A developer who wants to provide content in managed form could still offer the download on their own homepage, thus requiring no add-on server (even though one would be favorable in order to prevent the content from ceasing due to the developer's homepage becoming unavailable eventually). The managed content would be given a special description file that is downloadable from the developers' homepage, say www.developer.org/openbve_content.txt. The file would include the exact URLs of the actual content the developer provides, e.g. links to all the routes downloadable, and also information about the content (see above paragraph). Now, the developer only needs to make that content description file public so that visitors can take it. If you could follow so far, continue with the next step. Directory providers, which are people who seek out to find new content on the web, would collect all the description files they can find (just as collecting links to homepages), then create a special directory description file, say www.volunteer.org/openbve_directory.txt, which includes the URLs to all the developers' content description files known, and update this list regularly. Of course, the directory providers would make the link to their directory public. If you could follow so far, continue with the next step. Users get to know the URL of a directory provider, enter that link into openBVE, and then the magic starts to happen. openBVE now retrieves the directory, thus knows about all developers' content files available, queries the content files, and thus gets a list of all the content available. Let's take a look at the information again that is provided along with the content. With country and cities given, openBVE could sort the content by country, by city, by train operator, etc. You could easily find the content you are interested in just by browsing the content. If interested, as with The Battle for Wesnoth, now just click a Download button, and openBVE could automatically retrieve the content from the developer's homepage and install the package into its managed content folder. But not just that, as the content is flagged with the dependencies, the now known network can be searched for the dependency, which is then downloaded as well. If not interested in a piece of content any longer, you could just as easily uninstall it by browsing a list of content already installed. openBVE could keep track of dependencies and uninstall them too if not needed by anything else. However, how could we guarantee that the directory provider you got only one link from has actually indexed all available content? Likely, a Japan fan, probably natively speaking Japanese, is more likely indexing Japanese content, while an English speaking person might be more likely to index US/UK content. Well, if directory providers not only index to content, but also to each other, then, with just one link known, you could gain access to all available content world-wide. I have actually spent much more thoughts on the actual exchange formats and get everything to at least work on paper. Obviously, there are questions left to answer, e.g. how useful it would be to contact all developers just to check for new stuff or updates. That could take a long time. If the directory providers cached the information, that would be easier. But these are implementational details. The more important question is whether such managed content would be useful or not.
If you have ever played a Densha de Go! title (demo or full), you can probably better follow what advantages I see both visually and functionally in a structure as used by that program. Basically, you have a menu on top of a nice fullscreen background image, then you select your route. Upon doing so, maybe another background now shows depicting the selected route, then you can choose the daytime, season or any other variation of the route, and proceed, while the background image might further change to reflect the settings. In Densha de Go!, you can now select from a series of trains that are compatible with that route, and proceed this way until the simulation can start. Compared to the manual folder/file searches in dialog boxes as currently known, I think that route variations could be more easily accessed by such a hierachical approach. With more powerful route-building mechanisms, e.g. time of day (as illustrated earlier on), developers might in many occasions only need to provide one route file, while you can select from a series of options available for that route file from the structured menu.
Either way, if development continues, I would want to brake down the goals into workable pieces. Presumably, the 3D cabs and car-based trains would be a good start. Either way, during the development process, the existing formats are likely to be mixed with new formats in order to provide a transition. The other alternative would be to develop the whole architecture at once, but that is too much work to do and too risky either way.
|