Mid 2023: What's brewing (development report)

It's about the time for a new release, and there's no new features to highlight. There's plenty bugfixes but none of the "What's up next" points given in the previous release notes are ready - not for the lack of effort, but still. What now?

As I thought about it, I realized I don't have a clear creative direction for this project - the usual annoying "what's so special about your game?" point. I spent a while clicking through game pages and videos on the internet and I got depressed. There's so many games out there that essentially any idea got scooped more than once. To create and test softbody physics vehicles, the go-to combo is Automation+BeamNG+Ange'sEngineSim now. For an open world with vehicle-based missions, there's always GTAx but now also MotorTown where physics rocks and everything is low-poly (or 'submeshed' as we say) as an aesthetic choice - even clouds on the sky! Long story short, I came out empty and it made me recall my old plans and visions, which never really helped - but could they still?

That's when I asked myself a different question: "Since you've worked on it for 10 years (yeah; party's in September), why it's still not fun for you to play?". Well now we're talking:
  • Physics leave a lot to be desired. Collisions are loose, you get stuck in streetlamps. Nothing collides the way you'd expect - graphics are made of non-collision meshes, the actual collision bodies are simple (even crude) and don't always line up well. You can interact with the objects with mouse, but it's finnicky because you don't see the nodes (unless you enable skeletonview) and the force is very large.
  • Modding is ludicrously difficult for current era. It's basically work with a text file, or very old tools (the Editorizer), or Blender exporters (very good but intimidating because Blender) and a common lack of tutorials. I'd mod myself but I don't have time to deal with these complexities. I always hoped I could code a worthy in-game editor... and I'm still hoping.
  • Scripting is for intermediate+ programmers only and it lacks flexibility. We have various triggers in place but limited options of interacting with the game. Debugging scripts workflow is TextEditor->game(fail)->Logfile. It improved signifficantly in recent releases, but it's still labour while it should be fun.
  • Graphics and sounds are too static and repeating (the lack of shading doesn't actually bother me). Tyres don't leave tracks in sand or mud. Driving on rubble doesn't produce the characteristic "crunching" sound, it can't be set up. Each map has the same grass everywhere. We lack ambient occlusion (global illumination) and even have miserable options for faking it. Vehicle damage is faked via global "damage texture". You can't really splash water, neither visuals or audio can be set up that way. Theoretically an answer to all this should be scripting but it itsn't the case... yet.
  • Performance is... disproportional to the result - and it's not because lack of optimization. It's because the lack of performance monitoring and the fragile codebase making it unrewarding to even try optimizing. Or adding new features. I actually know how to do multiplayer collisions and it's not much coding, but it would further tax our already overtaxed collision code and our network bandwidth. Though the bandwidth is also not utilized perfectly, but I haven't gotten to creating a diag UI/script bindings yet.
Yes, it's a lot and basically in all aspects... and yes, I pursue most of these simultaneously, so I'm not getting things done. But the least I can do is to explain where I'm headed to and why aren't things getting done.

What really bothers me isn't that we lack some features I'd like, but that we lack in modding capabilities so users can't overcome any of the limitations themselves. Or they can but it's laborous and lacks examples. Or it's involved (you'd have to write Python scripts) and the game internals aren't known well enough to be relied on. But I'm positively sure that if working "smarter, not harder", most of my complaints above would come down to "I'll just make it out of Nodes/Beams (the physics skeleton)" and "I'll write a script that will apply forces/paint to textures/add or remove things". Those 2 things need to be simple, fun and work together. From a developer's standpoint, this is actually easier to handle than creating each feature separately - no risk of bugs, easier to write/diagnose scripts, easier to make everything connectible together. I'll illustrate:
  • At the moment trees are either no-collision or just static poles. Imagine they were out of N/B (the physics skeleton) and you'd crash into a mid-grown road-side tree with a truck. Whole tree or at least big branches would crack with a loud sound (detacher groups can help), leaves would fly all over (airfoils) and the trunk/branches could get stuck in the truck chassis (cabs, groundmodels). Presently you could try this by generating the N/B offline by a python script or Blender script.
  • Our mud is just static terrain surface you sink into a little. Why not try making SpinTires-like dynamic mud out of N/B (the physics skeleton)? The bottom layer can be fixed, but the top can leverage cabs/shocks/commands+triggers, anything to make it behave demi-volumetrically as it should. Presently, you have about the same options as above.
  • Built-in collisions behave finnicky? Query node positions from scripts and add few your own "repulsion" forces. Or just roll your own collision... it's just applying forces to the cab nodes! it can be as fake as you want. Force support is already in the works.
So what's in the works then?
  • Actor scripts [Ready] - We already have terrain scripts (old) and custom scripts (recent), now you can bind scripts to vehicles and loads too. See demo vehicle on github page.
  • Audio bindings for script [Ready] - play anything anywhere, not limited to soundscript trigger/modulation sources. Comes with demo script in game resources.
  • Node affectors [Beta] - apply forces to nodes from script. You can create your own engines/rotators/actuators/thrusters with this. Combined with the audio/actor bindings above, modding will become a different story.
  • Extended skeleton display/highlights (Alpha, see above)
  • Theme editor (Stub, see above)
  • Dynamically editable actors (internal) [Concept] - this started as a bugfix branch but as I kept finding similar hazzards in multiple actor elements (hooks, ties, ropes...), I figured I need to pay an old technical debt and unify how they're stored and referenced in memory. Now they're all in `std::vector<>`s which, aside of doing bounds checking on Debug, mean elements can be added/removed on-the-fly, at least theoretically. Previously this wasn't possible because of raw pointers, and it was some labour to replace them all with index types, but worth it. There is already a proof of concept - the Affectors mentioned earlier are added/removed dynamically using message queue.
  • Message queue script bindings [Lean and mean] - The internal message queue is my greatest engineering success. It started as a fix for glitching vehicle spawns based on occasion (preloaded with terrain, spawn by hotkey/GUI/script) and I figured I could just gather "requests" and process them at a single place. Since then it's been growing and now you can do practically any state change with it. And now all this power is available to a modder.
  • OGRE scene script bindings [Beta] - We use OGRE Renderer to display graphics (renderers are what games used before game engines became cool). The special thing about OGRE is that it has very well organized internals and lets you traverse the scene item-by-item. Unfortunately, you need to program in C++ to access it (it's also for Python/Java/C# but we don't do those). At one moment I realized I could just bind it as-is to angelscript and modders would find their way because the API is just so simple and clean. Comes with demo script which loads a character model and plays it's skeletal animations. Skeletal animations are the most advanced way to animate anything. For example stick shift :)
  • Shock tuning script [alpha] - Suggested by a modder on Discord a while ago.
  • Script loading from script [ready] - yes, it's this flexible now. Uses message queue.
  • Generic fileformat reader [since previous release] - honorary mention to make this list complete. We have many formats around already (TRUCK, ODEF, TOBJ, TERRN2) and this reader lets you process most of them. However, you can also define your own format using the same datasheet-like syntax and create data-driven scripts which process the format. A good example is the experimental mission system. It cannot edit or write the files yet but I'll work on it soon.
  • Mission system [alpha] - An exhibition of all the scripts can do, plus a few additions. It includes new format .mission which is processed entirely from script using the generic reader described above. The entire feature won't be completed this time, but I can split away and merge the script extensions if there's interest.
  • Moddable character system [Alpha] - last year's project, the thing that made me realize I need more flexible scripting and basically started the train of thought which led to this workload. It doesn't use the generic format reader because it's simply older than it. Neither it's based on the OGRE-skeleton-script bindings I mentioned above - again, earlier work. Alpha status because I need to do renaming in the format, otherwise it works. Example attached on github.
That's about it and yes, it's all about scripting. You'll want to visit documentation at developer.rigsofrods.org. On the main page it's the "Script-side APIs" link. Otherwise it's also a doxy documentation of the C++ codebase, script bindings are interlinked with the C++ originals if you're interested in the gory details. In case anything above made you worried about performance - it got me as well, don't worry. But to optimize meaningfully, you need to have a specific bottleneck, so let's just have fun with what we can do and worry when it actually crawls. I also suspect I'll have to signifficantly remake the physics subsystem, for multithreading and readability, and I have pretty good idea how to speed things up.

This is my first entry to the "microblogs" forum. It ended up not-so-micro but it was worth writing and arranging my thoughts in the process. Hopefully you like what you're reading.