I'm a long established add-on developer for BVE (since late 2000), and I moved across to develop for openBVE soon after the project was started, as BVE Trainsim development seemed to have stalled back then and it had been a dead-end for some time previously for me anyway, and now I'm co-developing the successor to openBVE called "openBVE 2" for now, with reschanger (Michelle), so I thought I'd share some of my thoughts and comments.
Firstly, speaking purely as an add-on developer, I don't find openBVE any more difficult to develop for than BVE Trainsim when it comes to achieving comparable end results in both programs, and actually, thanks to openBVE's stricter parsing and more informative error messages (and better development tools), fixing problems with my add-ons is much easier than it is with BVE Trainsim. The stricter parsing also prevents some wierd and frustrating problems which I experienced with BVE Trainsim, that were a pain to fix because the program didn't always tell me what was wrong, from happening in the first place with openBVE. Loose or lax parsing isn't necessarily a good thing, especially when it comes to the quality and reliability of add-ons.
I think the issue here is rather one of how the documentation is presented and explained; openBVE's documentation is very comprehensive and valuable to the proficient developer, but I also agree that it's too daunting for the beginner, so I'm hoping to do my bit to help create more accessible documentation for novices when openBVE's successor is ready. The other issue I think, is how much time one has available to make use of some of the features which openBVE provides
beyond BVE Trainsim's capabilities (such as being able to look backwards along the route as well as forwards), which makes developing for openBVE
seem more difficult, simply because there's a bit more work to do if one chooses to make use of those capabilities.
I moved from BVE Trainsim to openBVE, largely because I found the former to be far too limited in terms of it's 3D rendering capabilities and performance, which could have been somewhat better with the hardware on which it was running, although I don't think this will be an issue with BVE 5. Another reason, is because I wasn't able to properly communicate with BVE Trainsim's developer (mackoy) to request fixes, enhancements or new features, which might have helped BVE Trainsim to realise more of it's potential long ago (and I tried), or indeed my own potential as a route developer. Likely the language barrier was the most significant factor, but maybe for whatever reason, mackoy wasn't interested, or wasn't able to implement what was suggested, I don't know. I haven't found any such problem with openBVE, and as it's an open source project, it's also less likely to be abandoned like it seemed that BVE Trainsim development had been for some time - partly why the openBVE project was started in the first place. Mackoy created a wonderful simulator despite my criticisms and frustrations, but in my view it never reached it's full potential, and almost became history because hardware, drivers and operating systems moved on without BVE Trainsim being developed to move on with them; time will tell whether the same thing will happen again with BVE Trainsim in future, and it's less likely to happen with openBVE as it's open source and uses OpenGL rather than DirectX.
With openBVE, Michelle also single-handedly accomplished some rather incredible programming achievements within the space of only a year, namely replicating much of BVE Trainsim's functionality based on observation, experimentation, study and self-written code alone, while adding new features developers had wished for but which mackoy seemed unlikely to ever give at the time, all without a single line of BVE Trainsim's source code to refer to. That's amazing. For me, being able to communicate with openBVE's developer and work collaboratively to improve the program, as well as knowing that her remarkable software architectural design and programming abilities, and open source/cross platform philosophy are what underpin openBVE and openBVE 2, all helps to make the choice between openBVE and BVE Trainsim a no-brainer for me, no matter how popular BVE 5 turns out to be.
Speaking instead as a co-developer of openBVE 2 now, yes, we're designing the program to allow for more immersive environmental simulation, expansive scenery, and time-of-day along with meteorological effects (partly because it's more realistic this way, and also not least because this gives far more flexibility in terms of what you can do with the program, whether it's simulating trains or something else). However, in-the-cab realism is a high priority, along with facilitating the simulation of railway operations and procedures, and hence realistic safety and braking systems, electric and diesel traction simulation, power supply, signalling, physics, and so-on, which are the kinds of areas where the mass-market commercial simulation games are more likely to fall down because they don't appeal to the casual gamer.
The new program should also be able to load and run anything which is designed to work in openBVE, and likely many BVE Trainsim add-ons too, and there are plenty (please see
http://wiki.bve-routes.com/index.php/Category:Routes), while having much more potential for future expansion and development, as any programmer will be able to write a plugin which adds functionality, such as in-game communications with the signaller, country specific implementations of safety systems, and so-on. The new program will also allow for consists, coupling operations, and opposing traffic, and some initial work to facilitate this is being worked on at the moment, which many people have long wanted to see.
I agree there is an issue where a lack of GUI route and object editors in particular are concerned, and we are hoping that the open source nature of the project, combined with it's plugin based architecture and API, will encourage other programmers to come forward and help the project by developing tools for easier content creation, or plugins for loading existing file formats created by tools like popular 3D modelling software. This is a longer term aim, although it's just starting to happen already, and ultimately, the difficulty of developing will become rather less of an issue with the new simulator, while it will still be able to do what openBVE and BVE Trainsim can do so well, namely simulate driving and operating a train, as well as whatever else one's imagination and skill allows for. It will also have the advantage of being able to simplify the installation of new add-ons if developers want to make use of the planned in-game content management system.
In the end, the train simulation community is going to have more choice, and developers will have more options for how to create routes, trains and objects, and users will have more flexibility in how these can be viewed or used. There will hopefully be more innovation as a result, and those who don't want to use Microsoft operating systems won't be left out, either. I will also be interested in seeing which way openBVE and/or BVE Trainsim add-on developers go - some will stick with BVE Trainsim I have no doubt; I hope those who have adopted openBVE more fully will move across from openBVE to the new program of course, but some might even go back to BVE 5 when it's released, although with suitable plugins, openBVE 2 could load BVE 5 add-ons in future as well. Once we have more file formats supported via plugins, and tools for content creation in the longer term, we might have a new generation of developers and add-ons instead. It will be interesting to see what happens.
)
