Can you believe this bot has been around about 10 years now? I started this bot just before I left my game dev school in Florida in 2004 to exercise my passion and to build up experience that would help me get into the game industry. Not only was did this bot account for the primary demonstration that got me both of my industry jobs, it was fun as hell to work on(and still is really).
I know the community may by dwindled down to almost nothing these days given the age of these games and such, but as a developer who still has that passion, I am still working feverishly behind the scenes on the bot. Primarily this work has been in integrating the fantasic recast navigation system that is available on github, and pulling together and writing code that extracts map geometry from the bsp files and props of the map so that the raw collision geometry may be used automatically to build a properly automatic navigation mesh for the bot in real time. This includes rebuilding tiles of it when the location of things change and such. For some examples of this, see
This work has not been without major refactoring of many areas of the bot. After all, I'm 7-10 years more experienced(depending on which code) than I was when i wrote most of this code initially, so as I go I'm trying to simplify many areas of it as well.
Other than getting a nice automatically built navigation mesh(outside of possibly needing to set up tricky custom traversal links manually), my eye would then turn to the scripting system. In the domain of scripting I have an itch to take a radically different approach than what we've seen on the bot thus far. I wanted to air these ideas to get a feel about how the community(if there's anyone left), feels about this possibility.
Game Monkey script is still probably my favorite scripting language, syntactically and feature wise. The issue for me is that I suppose I've 'out grown' the appeal of interpreted scripting languages. The binding is often at least a bit annoying to maintain and interpreted languages in general are frankly very slow. In the history of Omni-bot itself, nearly all of the persistent crash bugs we've had over the years have been attributed to the garbage collection of the scripting language. Those types of bugs are hard to debug.
One obvious option to at least address the performance aspect might be to switch to Lua JIT(just in time). This version of lua is actually JIT compiled, rather than interpreted, so that its performance is generally much better. My issue with this option is that frankly I'm not a big fan of lua, and performance isn't really my primary motivation anyhow.
The preferred options in my mind are to stick with C++ code and use it for 'scripting'. MSVC 2013 community edition is free these days, and although it's not a small tool compared to like notepad++ or whatever you use to script with now, using 'native' code solves the performance issue, the binding complexity issue, and greatly simplifies the debugging by taking advantage of the high quality debugger that the tool already has. If I went this direction, I would do so still with coroutines/fibers(what GM calls threads) that still provide the great benefits of being able to write top down serial code, yield, wait, sleep, block for events, etc.
The biggest hurdle to work out with going to native c++ 'scripting' would be whether or not I can sandbox it enough where people cant code malicious stuff. That's one benefit of a scripting system that isn't so easily solvable in native scripting. If I can make the bot responsible for compiling the code(such as with http://runtimecompil...s.blogspot.com/), I could perhaps secure the code by disallowing linking with anything not provided with the bot(not even the c standard library)
Anyways I wanted to see if there was any feedback on the topic, especially from scripters themselves. To users the changes would basically invisible. The bot would load dlls or obj files rather than .gm scripts, to users any noticeable benefit would likely be in a significant cpu reduction.
Scripters would feel the brunt of this change. They would be writing and debugging their scripts in C++ using interfaces provided by the bot.
This change is pretty far out, but I want to spark a discussion in the mean time. I plan to get the navigation improvements to a stable state first.
- Niek, Mateos, Gramp and 2 others like this