I’ve been labouring mightily with the Boid/Pilot AI system. I had to park it a few weeks ago, after getting so far and hitting a roadblock. As usual, taking a break seems to make spotting the problem a cinch, and I soon found the roadblock and removed it.
I had feared that the entire system was failing, and with the number of concerns and parameters involved, tracking the issues I was facing would be a big job. Fortunately, I found a couple of simple logic implementation issues (one missing bit of wire, and another mis-wired bit of wire). Fixing them has put it all back on track and now I’m tinkering with balancing this for some 1 v 1 dog-fighting.
I’m capturing the dev process in video (hurrah!) and will provide some warts-n-all video blogs as soon as I can get to narrating or sub-titling them. In short, the entire system is working a treat, and proving highly tunable as hoped. I still have to have it all ‘pan out’ mind, so I’m not getting my hopes up too high yet 🙂
Right now, the Pilot computes threat assessments against hostile contacts using feedback from it’s vessels sensors. If these sensors are crap or damaged, then the pilot’s judgement will be impaired, resulting in less than perfect decision making, just like us poor carbon based lifeforms in real life 🙂
Threat assessments are based on a weight from the other vessels scanned weapons, shields, available power, damage status, known reputation, faction, and loads of other things. This is then compared against the pilots own ‘threat assessment’ and used to provide a relative threat level from -1.0 (the other guy is cannon fodder) to +1.0 (run, run, run!). 0.0 being an exact match, like for like. I’ve also restructured the threat assessment code which was being ran every frame for every vessel the pilot could see. Now it’s more orderly and takes a ‘static’ and ‘dynamic’ assessment at predetermined points instead of constantly.
‘Static assessment’ is against the other vessel itself. It captures those aspects of the vessel that won’t change during an engagement, such as the number of weapon mounts, maximum shield/weapon/power capability, and so on. Once a pilot’s vessel scans another vessel, it performs this lightweight static assessment and records the result.
It then immediately does a ‘Dynamic assessment’ which takes factors like current damage, current power, current number of weapons into account – things that will alter during combat as damage is inflicted and shots fired. It then combines both to come to an overall threat level, relative to it’s own vessel. This ‘dynamic’ assessment is performed periodically depending on how quick/smart the pilot is. This means that the pilot will react to changes in status of the vessels in combat around it. Dumb pilots may never check it again, and just presume the enemy is as strong as they were when first encountered. Smart pilots will keep a closer eye on it and be able to pounce on a heavily damaged victim.
This is working really well so far. When I first fired it up with a trader vs myself, and told the trader to attack me, it didn’t. Because we had the same ship, weapons loadout and reputations, factions and soon. So it didn’t see me as a threat! A few tweaks to my pilot/vessel data and it flew away from me to get enough distance, then turned and began an attack run 🙂
It’s suffering a bit from ‘jousting’ at the moment though. This is where the pilot just flies off, then lines up and heads right for it’s target, ad nauseum. This is not too bad against a human player as you always bumble about (unless stationary), but against another NPC, it soon devolves into cyclic head-on combat which is naff to say the least. So, plenty of work to do there, and loads of options on how to improve things. Pilot flying ‘style’ is needed to determine how it will attack, if it has decided to.
To help with this ‘gameplay balancing’ element (I can’t believe I am now at this stage after all this time!) I need some more dev GUI panels so I can tweak things. Having ran out of buttons, keys and key combinations on my keyboard, mouse and gamepad to do all these special tricks, I turned to my ageing 666 engines GUI. It is a fully windowed control based system, but still loads of problems and bits missing which impair my aim to provide GUI based tweakers. I could use the 3D GUI from Dom itself, but the same applies there – far too many widgets to be built.
After bringing the engine Profiling graphs back to life (see the video) I put it on pause again, daunted by the effort involved in providing all the needed widgets for a full GUI – range controlled numeric fields, scroll bars, formatting, and so on. As I often do, I was then browsing the GDC you tube sessions and was skipping through one by Omar Cornut on Indie Tool development out of passing curiosity, when I came across a really nice integral engine GUI / editing system being shown off. It was nice, and the kind of thing I had in my mind 17 years ago when I started my own engine off. Then I noticed that this wasn’t some bespoke game dev studio’s hackery… Omar had created a dark magic called ImGui.
Some digging/browsing later, and I found ImGui is a superb, light-weight, portable, well implemented ‘immediate mode GUI’. Literally 20 minutes of tinkering later, and I had it embedded into 666 and up and running. I can’t recommend this free library enough, the guys who put the effort into all this should be given free software for life, or medals, or something! I will certainly be Patreon’ing them up 😉
I’m intending to do an article on using it, as some people seem to criticise it for ‘not being a sound design pattern’. The whole ethic behind ImGui is not to use it in production code for end-user user interfaces, but for tools, dev hacks, tweakers and so on. With a little code, you can wire up a game object to provide it’s own dev panel so you can directly interact with that objects parameters and settings in real-time. Superb tweakage! It even saves the GUI states so you can restore window sizes, minimised/maximised states when you relaunch the game! Some extra effort (on my side) would allow me to even persist the settings themselves.
For now, I don’t want to get too carried away, but within a few hours (learning curve mostly) I now have a full scene object explorer, which lets me dig into a Vessel, it’s Pilot, and the objects they use to fly as an NPC controlled entity.
Yum!
PS. At the end of the video, there’s a brief on the Velocity Markers, just for you Cornflakes 😉
PPS. This video also trys out the shiny new Mak, Dominium and 666 video stings 🙂 Generated from the awesome renderforest.com – though if you use it please try and avoid the one’s I’ve used! 😉
Comments are closed.