Very nice post, it was well worth being a two parter.
mcompany wrote:...No matter how good your leader picks it's target, it still could never have any reassurance that it's pick was even slightly useful...
I ran into this too. At best my leader(s) were influencers. My best luck was each bot had its own targetting and attack, but let itself be influenced into following the leader in hopes that other bots also were influenced, so as to better improve killing a single enemy. I was developing a tagless system to do the same (a lot like you suggest), but had a perfectly working tag system that was getting the job done.
Luckily I had well organized subtrees that I could just disable. This Alpha12 is making me reflect on which modular designs have survived and which didn't. (I'm trying to come around.)
mcompany wrote:...there is still the already mentioned problem that on many of the maps, you woul dnot have the option of starting with the leader system active. More specifically, on Mind Game, CoD, or Barred, the old tagging system would have meant that you couldn't designate your leaders until late into the battle because you need to be attacking immediately...
This I liked about tags. Old tags were a double edge sword. That's pretty rare in a game to have a feature that's a simple concept, yet hard to wield for a novice and effective to use for the well practiced, without adding a bunch of BS limitations to it. The only limitations were a max of 5 tags (unless you combo them to make a bitfield, A=1 B=2, AB=3, C=4, AC=5...), and that it took a tick to process, but that limitation was the same for all actions. It was a simple rule to grasp about how the game works. Now it's all actions work "this way," but tag actions don't take a tick, and processing resumes right after, not reset. Not a fan of sideways, one-off exceptions. It's a code smell, usually indicating an inflexible design.
As for initial reactivity in a match, this was also a great balance of thinking too much and getting shot to pieces vs not synergizing an efficient attack to save bots now and not have everyone weak later. It was fantastic that tags aren't always better. This made the game dynamic. Instant tags guts that out.
One solution to the close quarter starting maps like Barred was to make tag participation optional, based on how many enemies were either in immediate range, or acting on the bot. Bots would resume when they were healthy and not swarmed. This game is very flexible, bots don't have to go all in on one strategy, even during a match.
mcompany wrote:...you couldn't tag your leaders until late into Lake Rushtown...
No disagreement. Tagging leaders was expense (and should be), and optional. However, leaders can be based on explicit things like class, or by who's not busy attacking, taking fire, or scoring (that leaves idle, moving, or what most bots do, deciding what to do), or in my case both. One leader means you have to build a succession, which can also be expensive. Again, features like tags with natural strengths and weakness should be celebrated in a game like this, not held in disdain. If your AI is complex, it should cost you at least a little. And I'm talking more than maintainability. In any fighting game, hesitation should be expensive.
mcompany wrote:...Focus fire: One idea you might have is to use tags to target a specific bot so, that you maximize the damage on who you attack. However, I was already finding somewhat solutions to that during 5.2 and 5.3. All you need to do to more likely have focus fire and pick vulnerable bots is attack the lowest shield ...
I like that you can implement coordinated attacks with or without tags. That's one of the most fascinating things about programming is that so often there are multiple ways to skin the same cat. Picking the best one boils down to requirements (speed to market, hardware constraints, response time, scalability, etc). I suppose instant tags don't necessarily impede this, but I like that if it's hard to do one way, try another. That's what programming is like every day. Taking away the processing delay just for tags and no other actions to make tagging more advantageous is just lazy, in my opinion. I consider it bending the physics of the game for an unworthy special case, and I don't like it a lot for that reason. I agree, instant tags are more powerful than pre-Alpha12 tags, but at the cost of the game's consistency. It's like a cheat code. I think it degrades the game's quality.
mcompany wrote:...Speed up resource collection: You really aren't speeding it up by much, not to mention that this isn't that much of a big deal simply because this isn't something you do mid battle, but instead after a battle is already basically won...
Not true in all cases. If I have a bot or two, or more who are opportunistic scorers (meaning they can switch between attacking and scoring) I don't want both of them going for the same resource. You think that's only for the end of the game? My AIs can win a game without killing all of the enemy. This gives me a greater chance at victory if I face an equal or maybe stronger opponent, where it should go down as a draw because time runs out, but I "stole" resources earlier when enough enemy bots were retreating or out of range from my scorers.
mcompany wrote:...State machines...
I found state based AIs to be a steep slippery slope. I suppose with instant tags, not so much. I still say thinking too long in battle should get you shot. Bots can be reactive and think, you just have to build the AI to be flexible.
mcompany wrote:And untagging is much harder than tagging simply because you need to avoid many possibilities of loops that leave you idle for full seconds, which means any systems that untag either almost never tag in the first place, untags so little that you forget that you have a way to get rid of the tag, or is pretty much is guaranteed to not win you games.
I agree about the difficultly and debugging it takes for untagging to be accurate (I find to be a hook for the feature, not a turn off), but I disagree about the guaranteed no win part. If you're losing, it means you have an AI to fix. If you have bots that have contradictory rules about tagging and untagging, it's not the tag's fault, it's the implementer. If you leave a bot tagged that confuses or makes another bot inefficient for some reason, that's an AI design problem, not tag one. If you waste too much time tagging/untagging and get shot up, that's a flaw with priorities, not tags. In all cases, they aren't problems with the tag feature that make you lose all the time, they're opportunities to improve your AI. (I know I used it, I don't like the "problems are opportunities phrase," like I don't have an eating problem, I have an eating opportunity.
But it fits here.)
Honestly, I didn't follow your points very well. That might just be me.
mcompany wrote:...And now that it's random maps only, any argument about decorators is irrelevant
Are you saying that random maps make decorators irrelevant? I would disagree with that, based on how I've use tags to mark enemies based on their observed behavior (scorer, retreater, etc). Maybe "decorators" means something else to me.
mcompany wrote:Yes, you've invested months into this game. Yes, you paid to start playing. That doesn't mean that any massive change is a bad thing simply because it messed with your work ...
If the change was for the better (benefiting everyone), I don't disagree. Random maps for example, that affected everyone the same, no advantage. If you built AIs specifically for maps, you gambled on maps staying stable, which if you played the game enough, you knew maps could change. Who gambled on tags being overhauled? That was an integral part of several of my AIs. It was like if counting was changed (granted that's a later feature, but it would still hurt).
mcompany wrote:Hell, with real programming languages, this is very much likely to happen unless you restrict yourself to an older version of the language (which might then mean possibilities for some things not being as polished as the latest version and others not being as fast).
Important difference that invalidates your point, languages do version breaking changes (Python, PHP, Golang) and upgrading is not imposed. If a vendor's update breaks you code, you wouldn't want to go to production with it, would you? If it's a patch that fixes a vulnerability, but breaks something else (*cough* Apple, *cough* root access, https://www.wired.com/story/macos-update-undoes-apple-root-bug-patch/
) then it was a shit release. Stability for languages and OS architectures is based on pinning to versions and upgrading (or not) is your choice. This is not an option in Gladiabots, or most online games for that matter. Some games deal with restricting users to playing other users who match expansion packs and so forth, but this game ain't one of them.
mcompany wrote:So really doubt this is as much of a problem for the game as it is just a personal problem for you.
I've seen fledgling games on steam go belly up for making breaking changes to their game play (I was a huge early adopter of RoboCraft, and it went to shit when they lost sight of their original vision). I doubt Gladiabots is impervious to the same thing. If mainstream players have to deal with their AIs becoming invalid one too many times, they'll lose interest. I'm not the only one to experience it. Knowing this is "Alpha" is what gives it a free pass for me, but how many strikes are others willing to give?
You are very much welcome to your opinions. I like hearing them. It opens a good discussion that I hope is informative to GFX47. If the new tagging works for you and many others, then I'm probably an annoying minority.
Thanks for the change log notes, you too peir4r. Is there a thread where those are captured? It'd probably be best as a readonly thread (for those with rights) without too much commentary in it. I suppose climbing through the releases in trello works too.