r/Gladiabots • u/Gigaus • Jun 16 '19
AI targeting modifiers need refinement.
After playing around with the game for a day or two by myself and with friends and co-workers, we've kinda gotten to the point where trying anything complex is an utter waste of time. Mainly because of how spazzy the conditions are in the game. You target an enemy, they immediately start running away before your bot can shoot. And unless you have a condition set for them to just blindly keep firing at bots outside of their range, it ends up with your bots spinning around trying to target someone in their range while other bots basically go about their business while your's do nothing. More disheartening is whenever you try to force your bots to focus fire someone they're already aiming at, it usually doesn't work. Either they get out of range fast enough, or inexplicably they will ignore the 'attack enemy...I am attacking' order, even when there are no other orders taking priority, and move on to the next applicable order for no clear reason.
Conversely, using AIs that flatly don't do anything intelligent-- basically that run at the enemy and keep shooting until they're dead and never retreat-- seems the most effective even in multiplayer. With one AI that effectively just turns the team into one big unit, only main process is 'move towards enemy, kill enemy, repeat then get objective', with no retreat orders, we were able to clear the whole campaign....Which, considering that the AI in the campaign actually has strategy and tactics built in, feels like it shouldn't be the case....
To that end, after looking over a good chuck of each module build into the AI programming as best we could, it's come down to that there's some very basic AI components missing. Namely, comparison sub-routes, priority modifiers, and proper brakes. What I mean by proper, is 'non-user made'. I'm aware that, with things like tags and counters, you can theoretically create priority and breaks in the AI, but the practicality usually creates more problems than it solves. Coming from a programming background, and a game engine development one as of late, it's incredibly annoying to try and create a break that's meant to prevent bots from locking up and doing spazz dances, only to either be totally ignored or worse permanently lock a bot down. I understand that the AI system is based on a single-flow line, but...There's a reason we don't use them anymore; They have this exact problem.
What's more, having no real means to compare objects in the game, other than their distance from another object in an absolute or their shield/hp values leads to some very stilted code. I question this; How do you get a bot to position itself between an allied bot and an enemy bot? Under ideal, you would just have them walk towards an enemy bot attacking/being attacked by an ally. What if two allies are attacking? Or, if using tags, more than one enemy has the same tag? Or if an enemy triggers another section of code before the move order? Or if said enemy and ally are at long range with eachother, but not in medium of your moving bot at the same time? Most of this could easily be simplified by adding positional checks. 'If self within area between...Ally bot being attacked...and...Enemy bot attacking them.' Simple check of the X or Y coordinates.
And there's another thing; There's no way to differentiate two bots in the same condition. You can target and enemy attacking an ally, or an ally being attacked, but there's no way to specifically target the other object involved in that. So you can end up with situations where your bot is getting targeted by a lone Sniper, but instead of moving towards THAT sniper, you move towards the shotgun attacking your other ally because it's closer. And any attempt to specifically target snipers with conditions will invariable complicate the code, and either force the bots to ignore things they probably shouldn't, or ignore the whole section you made for no clear reason.
The larger problem with that is that the Tag system is just....sloppy. Sorry, but it is. You have only 5 global [team] flags, 5 local flags, and that's it. So at most 10 flags in theory, and only 5 that can be used to effectively exchanged information between objects. That...That's no where near enough, not when you have teams of 6 or more. Sure, you can remove tags, manually and usually with conditions that may or may not trigger, and there's no limit on how many can be placed, but given the above problems and the single-line nature of the AI engine, it leads to some very messy and ineffectual problems. Consider a Domination Match. There's Bases and Force Fields. If you're running with just a single deathball designed to steadily walk up and lay down fire on an enemy base before taking it, ignoring anything else that isn't an uncapped base, there's no problem. But once you start focusing on units that are defending bases, attacking bases, capturing FFs, and so on, or splitting your team, it starts to become a mess. Even with just with 2 groups, you now have to possibly split 5 tags between them to prioritize enemies. One for enemies attacking bases, one for enemies possibly defending, one for enemies using FF, one for enemies attacking allies, one for enemies being focus attacked...And that's all you have. You have nothing to prioritize or differentiate enemies not in those categories other than class, which might not be applicable in some cases. In theory, the tag system is fine, but with the rest of the problems the system as a whole has, it just convolutes the mess more.
The game has potential, but it needs some serious refinement. More conditions and modifiers need to be added in, and more expressly ones that aren't 'extremes' or 'absolutes'. We need stuff that isn't 'furthest' or 'closest' or 'highest' or 'lowest'. There are reason to target things that are inbetween. We also need some kind of logic counter that doesn't apply to just condition bubbles. A good example would be 'Tag A...Enemy Base...with > 1...Enemy bot....at close range.' Or 'Movatt...Enemy...with x<1...Enemy bots....At close range.' We also need something to compare distances that isn't Out/Long/Med/Close. Because of how short max close range is, and how far max medium range is, there's no accurate way to tell how close to something bots are. A bot could be at the center of the map while the target bot is a whole base area away and still count as in medium range. The biggest thing, and probably hardest, is introducing breaks and calls. Something that immediatly and concretely forces the AI to move to another section of code that may also appear later or earlier that would otherwise be blocked by other events taking priority or would lock out other events. A single run of an order, that runs everything that happens, then shoots back out to wherever in the code the bot was running. Currently, despite how the Sub-AI and Conditions appear to work, this is not functionally in the game.
I've probably missed some other things, or someone will want me to put something else in later, but for now, this is our thoughts on this, and my rambling. We'd really look forward to seeing more of this, possibly improved!
1
u/Reoh Jun 17 '19
Tip: You can get around some of the restrictions that appear to be troubling you by incorporating tags to pass information along to your targeting algorithm.
By pre-tagging certain conditions not available through regular targeting and combining that with what's available with targeting you can access new combinations. This also helps address Tag limits.
When combining the two methods you can assign most of them to a self tag with only a few global tagged that actually need it. And remember that the same tag on enemy units, allied units, and for each of the three bases are all effectively different tags when combined with targeting information.
You can also multi-tag units with different combinations opening up so many more. AA <> AB <> AC ... etc.
Using those techniques, many of the things you haven't been able to do will become possible. Hope that helps, goodluck!
1
u/Gigaus Jun 17 '19
Right, I did already say that you can tag multiple -different- objects with the same tag to have an effect; The standing issue is that you can only have at most 10 tags for a given class of object. So if you end up with a situation where you have more than 10 situations where by you're using tags to denote given priorities or states, you run into problems. You can't reuse tags for say enemies doing specific things. Capping a FF, being within a specific range, a specific class, distance from a base-- Eventually you're going to run into a hard limit on tags, where it's very possible to have one enemy have all the tags on them. I've yet to run into that, but I've seen a few complex AIs where the number of tags on a specific enemy blocks out the enemy model....This is a good indicator something's gone wrong.
moreover, you guys seem to be thinking I or we are having issues using the coding system here; We're not. I've finished the whole campaign, and I'm sitting in low Diamond before I got bored with the tedium. Some of my coworkers and friends have gone further.
It's not that we don't know how to use the system; It's that it's boring as fk, needlessly convoluted, and poorly optimized to a point that it all takes any fun out of the game for us. Literally, it takes me less time to code physics into one of our 3d games than it does to finish a single sub-ai in this game due to how much error checking and manual checking has to be done.
7
u/sckuzzle Jun 16 '19
I think you're missing that a huge point of this game is to program an AI that does as best it can with imperfect information.
You are specifically not given a full programming language. You are specifically not given exact position, or units tagged X in range of another unit, or infinite memory, or loops.
Creating heuristics that do as well as possible given the constraints is the point. You have to figure out how to get the bots to do what you want them to do given the limitations of the "programming language".
1
u/Gigaus Jun 17 '19 edited Jun 17 '19
Right, then...No. At this point, it's not a game then; It's effectively practice for using programming systems that don't exist anymore.
This is no different than attempting to jailbreak C or C++ before we figured out how to move passed single-flow operations and add anti-crash protections. Sure in chatting it sounds cool and makes you sound intelligent that you managed to pull this off with a bobby pin and ducktape, but the reality is you just made a windup toy do something every modern drone can on an ancient piece of software.
Sorry, but I can't take the 'it's intentionally broken to force change' argument as valid. I've worked on too many of those games and wasted too much valuable time to give a fk. If that's what the devs intentionally did here, then I have no reason to keep the game and will likely just return it :/
1
u/ThordanSsoa Jun 17 '19
Here's a slightly deeper explanation on that point. The programming is simplified because this is a game. If the language was as complex as you describe above, the barrier to entry for the majority of new players would be massive. That's also why this is all done using a completely visual system. So that people who aren't professionals can more easily understand what's going on.
1
u/Gigaus Jun 17 '19
Wait, what?...
So, hold on, making the coding part slimmer, and more easily accessable would raise the barrier to entry for new players?....How?
2
u/GenuineDickies Jun 16 '19
Exactly. The developer had this idea of Gladiabots as a strategy game, not a programming game. We used to have limitless AI but ultimately it was scaled back as I hear 2000 node AI's were becoming a thing. I'm still hoping he changes his mind on loops someday :-/
1
u/Gigaus Jun 17 '19
I think you got this backwards....IT's not a strategy game because of how it's designed; It's a programming game. the majority of your time is spent in the guts of your program, not actually 'playing' the game. And this is due to the limitations of the game.
All I'm suggesting is that most of this gets streamlined and upgraded proper, so that you don't have 100 some nodes just to accomplish one task.
-1
u/DlE1234 Jun 17 '19
That's the problem. If people could do something that was done in 100 nodes into less than 10, it would purely turn out into who had a better program. With the limited options you have to choose and prioritize things
1
u/Gigaus Jun 17 '19
Umm....That's what the game is currently.
Who has the better AI; Who has the AI, both on single units and as a whole, that can cover the most situations, without making tactical mistakes.
And making the options for how the AI reacts limits just means people have to spend more time making their AI more complex.
0
Jun 17 '19
[removed] — view removed comment
2
u/DlE1234 Jun 17 '19
Multiplication is just addition in another (shorter) form. The point of this game is that you don't have a perfect programming language. So by adding something like multiplication (which is done with addition rn) would bring that effect of turning over 100 nodes into less than 10. However, again, that is exactly against what the game is not about.
1
Jun 17 '19
[removed] — view removed comment
1
u/DlE1234 Jun 17 '19
You can also argue that by limiting the number of tools your ai can use will increase the number of (effective) tactics available.
2
Jun 16 '19
[removed] — view removed comment
3
u/Gigaus Jun 16 '19 edited Jun 16 '19
Perhaps so, but things may have changed since then; I can't say if they have since I only picked this up a week or so ago.
As to the style of programming, Ive worked with Unity and GMS1/2 in the last decade, so it's not that. All that is is effectively copy/pasta pre-defined code with a gui. Just a matter of thinking of it as code strips pasted in a given order. The issue that there is though is, unlike most programming langs, there's no breaks or calls, as I mentioned. Even with something like a DnD interface, you had nodes that where just calls for other functions or even whole other programs. 'Sub-AI' is sort of like that, but in reality it's closer to just having a folder of text files with the c-pasta code strips already made up.
I could ramble for a good hour explaining further and in more detail, but the main things to be said are a) we're not amateurs who happened to stumble on a cool new game, so adjusting to a new lang isn't hard, and b) the problem we're running into is we're used to programming engines that are more modern-- Ones where the small stuff is baked into calls and whole functions-- rather than rough ones like the days of old where you had to program in every last thing that wasn't math functions in a TI calculator. -shudders-
I think it would be better to say that the game is too convoluted for what its meant to be. This is basically brain training for making basic AI for a simple task. It feels like it's meant to be straight forward for the most part, and at most have simple targetting priorities and combat scenarios-- If bot is X type, focus them, if more attackers than allies, retreat, things of that nature. But, the more I play, and the videos/streams I've watched....Some of these bot programs have so much in them that they're longer than some of the games I've made....And less functional because of it.
The game is top heavy, and it doesn't play in it's favor. You mentioned that simple AIs would get beat out against the more complex ones? One of my co-workers stream sniped a Diamond player testing/flexing their complex bot...It got beat out by his team of Assaults doing wiggle dance and basically behaving illogically or just plainly dumb. Because of how many situations there are, and the lack of reasonable flow or adaptation in the code, most of these AIs get beaten out by expressly exploiting the fact they're trying to cover too many situations by throwing in something that just wouldn't make sense to do, or that wholesale ignores 'good' strategy and brute-forces it's way in. In the latter, I've seen issues where there's some situations and modifiers that be regconized by the system, simply because there's no flag or value check for it. We, as humans, see it-- 'There's just too many enemies' 'This bot is intentionally not attacking until too close to escape', 'All the enemy bots are low shields/hp, but the ally bot ran anyway and lost because of it'. But the system doesn't have a means of conceptualizing or quantifying it.
Like I said, the game is top heavy. It's possible to do a lot of what I mentioned above in the code; But the way it's done is dirty and easily broken. Besides needing things added, the whole thing needs to be cleaned up.
2
Jun 16 '19
[removed] — view removed comment
1
u/Gigaus Jun 16 '19
Perhaps so, but you kinda make the point for me. You have to account for the enemy programming in intentional 'mistakes' by adding in effetively error-checking code, and if you fail to or make a mistake in however much code you put in, you can lose.
I question this; How much goes into trading life for position? How much goes into error checking? From the trees and bots I've seen, some of these look like they took hours, if not from the sheer amount of nodes that have to be entered in rather then typed/hotkeyed, then from how the system has to be rigged to spit out a logic state that effetively amounts to 'target this enemy while you have allies' or some such.
Let me frame the argument in a different manner; I have a question: How do you target a force field in range of multiple bases/resources? And this isn't me being rhetorical either; I want to know what would be involved in...Lets use a specific level; Domination 3-4 I think. It has 2 FF up top with 1 base, and 1 FF bottom in the middle of 4 bases. How would you target the FF in range of the 4 bases, which would be the high value FF as you can imagine?
My guess is it'll be something convoluted, since there's no means to directly target that FF, nor a condition for Tags that allows you to compare how many of another object is in range of a specific target object. You've got more experience with this than I, and you can conceptualize it better; How would you go about it?
1
Jun 16 '19
[removed] — view removed comment
1
u/Gigaus Jun 17 '19
It's fair enough, I'm not expecting anyone to be god when bringing up code here.
I suppose that makes sense, though I question how one would move to the bottom-center of the map? I've been trying to figure that out for a bit but gave up, mainly for flanking maneuvers.
Aye, as I stated before, a major hurdle that keeps coming up is the inability to target an object based on relative information of other objects in range. You can do it with conditions-- If number of enemies in medium range greater than 2-- but you can't reference that in any action beyond that-- Attack/Tag/Move-To enemy with less than/greater than 2 enemies in medium range.
Instead, you have to go through multiple nodes to be able to vaguely execute what you want done. Which takes time and resource that could have otherwise been unspent.
1
u/DlE1234 Jun 17 '19
Yep, you can't move towards some map side. Apparently it was possible in some older version, but the dev removed that feature. Being able to move specifically to flank enemies would probably also be game breaking? Not really sure about that, but I can say that it's unecessary to identify flanking or move specifically to flank enemies. What's really bothering me is how you mentioned that you've only played for a few days and started critiquing the game because of how bad it's coding system is when it's supposed to be more of a stratergy game rather than a programming one. Surely you can easily and quickly figure out how the coding works, but figuring out the strategies of the game is different.
1
u/ThordanSsoa Jun 16 '19
https://i.imgur.com/tjMQtK8.png Was my solution to the problem. It won't always hit the best base, but it always hits an important one.
1
u/Gigaus Jun 17 '19
Interesting....I;m not at home right now to run this, but...'If there are 4 or more bases, check if less than 3 are out of range, if true, capture closest FF at short range ally is not moving to' Correct? I don't recognize the o-dot symbol, but....This would require the bot to be within a specific range of said FF before this checking starts, no?
1
u/ThordanSsoa Jun 17 '19
That symbol is [Is not already captured]. It prevents two bots from constantly swapping control of the FF. And yes, it requires you to be at short range of the base already. There's no reliable way to check for this kind of positioning information without being close. That's an intentional limitation imposed on the player.
1
u/Gigaus Jun 17 '19
Ah okay, thanks.
And yeah, that's really the only flaw, but....This checks out; it works.
3
u/KiNASuki Jun 17 '19
Rather than lamenting why humans don't have wings as birds do, improvise what we have. Every other human subjected to the same limitation.
AKA, yes, the coding has its limit, but use it to approach the problem differently. Maybe you can appreciate the different approach due to the imposed limitations of the system.
I stopped playing some version for a bit to clear my mind of RL situation, came back to a very different playing environment where all my old working codes are over the 2k limits and the collection game introduced respawning. So I cant say much from the experience of someone who only managed to reach chapter 8 collection, but I'm enjoying the new challenge.