Node Reactivity Depth Discussion(+10ms per node)

User avatar
LuBeNo
Autonomous Entity
Autonomous Entity
Posts: 532

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#21 » 19 Feb 2018, 22:55

I also prefer a node cap over a node reactivity implementation.
Image
My algorithm of life: if(self.tired) sleep(); else if(self.hungry) eat(); else follow(Jesus);

User avatar
drartimus
Algorithm
Algorithm
Posts: 84

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#22 » 20 Feb 2018, 07:14

I'm probably the only one who's in favor of such a feature. As a software developer, I'm always tasked to improve software performance, either without changing hardware, or operating on cheaper (less beefy) hardware. My company has SLAs which restrict how long web requests can take. If our services don't respond within the customer's response time requirements (within reason of our cloud provider's availability), my company pays penalties. This is a real world problem in software. Case in point, if SpaceX's complex logic wasn't reactive enough, they could never land a rocket on a barge. If a stock trading site's purchase/sell processes take substantially longer than their competitors, that trading company is going to go under.

I think people are wrongly assuming that a complex AI with a high number of nodes can't be efficient. You would solve performance like software engineers do every day. You'd build your conditional chains to fail (or succeed) fast. Put the most restrictive conditions higher up the execution chain and you'll reduce the number of nodes examined. Put your branches with faster, high gain returning logic first and move the long running branches toward the end of your AI to make it process faster.

Now with that said, I get not all players are experience software engineers. I love that, and it shouldn't put them at a disadvantage. I think this feature could be designed a couple ways, and I'd like put out some ideas that could make something like this more palatable to the masses.

1. Beginner levels are exempt from node reactivity. Totally based on online play. The higher up the XP you go, the more node reactivity you face. Win the fight by being the the fastest gun relative to your peer's skill set in your playground.

2. No node reactivity, just give (some sort of) scoring bonus to more efficient (or smaller) AIs. You might lose, but you had a lighter AI so you don't lose as many points as a losing heavy AI. You might win, and your AI was smaller than your opponent's so you get more points than a heavy AI that whooped up on a smaller one.

3. A graduated node reactivity. Something like your first 20 nodes are free, the next 20 cost 5ms each, the next 20 after that are 10ms each... So 50 nodes would take 20*0ms + 20*5ms + 10*10ms = 200ms. 100 nodes would take 20*0ms + 20*5ms + 20*10ms + 20*15ms + 20*20ms = 1 second. Adjust the number of nodes and milliseconds to what ever works.

Well, pick it apart. It's why I wrote it (I guess).
"If it acts like it's not running your code, it's probably not running your code." -- me, I say this all the GD time!

odomobo
Hello World
Hello World
Posts: 6

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#23 » 20 Feb 2018, 19:23

drartimus, you make some good points, so I'll post all of my thoughts on the matter.

TL;DR: it's important to strictly reward players for making smarter AI, even if such AI is much more complex.

The idea of node reactivity is appealing, since it has many real-world analogs. Chess engines which do less work in static evaluations can evaluate more positions (e.g. stockfish). Bio-organisms have reflexes, so certain actions can happen before the signal hits the brain. However, it's important to ensure that such a change is appropriate and beneficial for the game. For example, mandatory code reviews are great for software development, but wouldn make gladiabots much less fun.

Optimization challenges are great in some puzzle games. For example, basically every zachtronics game has several optimization challenges for each puzzle. It works well in those cases, because each puzzle is a closed-ended problem, so it's an extra layer of challenge that you can pursue after solving the puzzle. Since Gladiabots is an open-ended game, adding something like this fundamentally changes the nature of the game, as opposed to just being an additional challenge.

In most games, the enjoyment comes from rewards the player receives. In chess, for example, a player is rewarded by finding a clever tactic, or by having deep knowledge of a certain position, or understanding certain piece interactions. In starcraft, the reward comes from outsmarting the opponent in terms of tech, finding the opponent's weaknesses, out multitasking the opponent, etc. In gladiabots, the reward comes from your AI outsmarting the opponent's.

If you start punishing the player for directly trying to achieve those goals, the game no longer has clear reward feedback, and as such, is no longer appealing to play. For example, if you punished a starcraft player for having APM above 100, then a player who skills up to the point of reaching 100 APM starts becoming punished for their newfound skills. A real-world example is how on launch, battlefront 2 would stop giving rewards if you played too much in the past few hours.

One of the ways we make smarter AI in gladiabots is by adding new logic, sometimes large submodules with complex rules. If I work my butt off and add hundreds of nodes of complex logic, most of which get evaluated each tick, I shouldn't be penalized for my hard work. Personally, whenever I encounter a game that penalizes hard work like that, I tend to quit playing. For example, if I spent a weekend coding up a module that performed some advanced AI, and found that it made my bots weaker simply because it ended up being less reactive, I would probably never touch the game again.

Correct me if I'm wrong, but since much of the game revolves around trying to keep your code maintainable, then having more elegant code is already its own reward. It reduces technical debt. Moreover, additional or redundant logic which helps make the code easier to understand or maintain shouldn't be penalized. There should be no penalty for good code organization, which already has intrinsic benefits.

Node reactivity would punish certain forms of player creativity. For example, someone in the forum posted a fairly strong bot with ~50 action nodes and no condition nodes. It's an interesting challenge, and arguably one which couldn't be competitive if they needed to minimize evaluated nodes.

Node reactivity would reward some bots which are only strong because they are simple. Worse, I believe that any strong sufficiently-simple bot would be very hard to improve in an iterative fashion, assuming any additional nodes would have a large marginal cost.

Node reactivity turns tractable problems into intractable ones. Did my bot lose because it was lacking logic, or did it lose because it was too slow? If I make it smarter, will it hurt the bot or help it? The fact that tagging currently takes a tick seems fine to me, because it's something under direct control of the player. "I will spend 5 ticks at start setting these tags, and a max of 4 more ticks throughout the course of the game." Number of evaluated nodes? Not so much, especially in very complex programs.

The last, but probably least important point: you can currently step through a battle in a discrete fashion, and evaluate the logic at each tick. You can theoretically analyze the state of the game at each step to help determine optimal strategies. If each bot runs at different speeds, then this is no longer possible. This isn't inherently a problem, it would just make analysis more difficult.

Those are my thoughts. I'd be happy to be proven wrong on any points, as the game's success is more important than my ego.

sollniss
Automaton
Automaton
Posts: 175

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#24 » 20 Feb 2018, 20:09

drartimus wrote:I'm probably the only one who's in favor of such a feature. As a software developer, I'm always tasked to improve software performance, either without changing hardware, or operating on cheaper (less beefy) hardware. My company has SLAs which restrict how long web requests can take. If our services don't respond within the customer's response time requirements (within reason of our cloud provider's availability), my company pays penalties. This is a real world problem in software. Case in point, if SpaceX's complex logic wasn't reactive enough, they could never land a rocket on a barge. If a stock trading site's purchase/sell processes take substantially longer than their competitors, that trading company is going to go under.


You are basically arguing that making an AI like this:

[if self is shotgun] -> [shotgun defense logic], [sniper attack logic], [other]
[if self is sniper] -> [sniper attack logic], [sniper attack logic], [other]
etc.

Is better than
[defense logic]
[attack logic] -> [generic stuff], [[if self is shotgun] -> [shotgun specific stuff]], [some more generic stuff], [[if self is sniper] -> [sniper stuff]]
[other]

Honestly, either system is perfectly fine. I'd even say the first system uses more nodes because you need many more conditions.

With instant tags we even have cases where we have to check for the same conditions multiple times in a tree. Adding a time penality for node count would just straight up stifle any creativity at birth. Think about it:

"Hey I have a really nice idea how to keep track of how many resources the enemy has collected, but it needs 50 nodes to implement, so I would probably make my AI worse than before."

Or you watch a replay of your AI and notice a thing that made you lose the match, but to fix it you need 10 nodes. This is literally a lose-lose situation. Don't fix: your AI stays weak, Fix it: your AI gets weaker.

User avatar
drartimus
Algorithm
Algorithm
Posts: 84

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#25 » 21 Feb 2018, 07:35

Wow, odomobo, you win at replying. Well done, I like discussions.

odomobo wrote:The idea of node reactivity is appealing, since it has many real-world analogs. Chess engines which do less work in static evaluations can evaluate more positions (e.g. stockfish). Bio-organisms have reflexes, so certain actions can happen before the signal hits the brain.

Nice examples, I like your thinking.

odomobo wrote:For example, mandatory code reviews are great for software development, but wouldn make gladiabots much less fun.

For the casual player, sure, but could be interesting for diehards. I don't know, that sounds like the beginning of clans and clan tournaments. A group of players could collaborate on AIs and have to pull request changes, github style. Could be interesting.

odomobo wrote:Optimization challenges are great in some puzzle games. For example, basically every zachtronics game has several optimization challenges for each puzzle. It works well in those cases, because each puzzle is a closed-ended problem, so it's an extra layer of challenge that you can pursue after solving the puzzle. Since Gladiabots is an open-ended game, adding something like this fundamentally changes the nature of the game, as opposed to just being an additional challenge.

This also sounds like a fun idea for this game, an alternate game mode could be puzzle challenges in offline player mode. A player could be given a working AI, but to pass the level, they must reduce the AI by x nodes and still pass the level. Or maybe win the match in 10 less seconds, or win by 1 more resource, taking one away from the enemy. It could even be like a the challenge of the day with a leaderboard with quickest time, fewest nodes, best score (like if the puzzle was some sort of ridiculous 100 resource game).

odomobo wrote:For example, if I spent a weekend coding up a module that performed some advanced AI, and found that it made my bots weaker simply because it ended up being less reactive, I would probably never touch the game again.

This is me and instant tags (nope haven't gotten over it yet), except it took way longer than a weekend, and a lot of my code is less effective. Part of me thinks in that scenario, the player is spending too much time on specialized strategies that may not work in most cases. But, it could also mean your opponent has built specialization that capitalizes on certain vulnerabilities that are only expressed in a few cases. So I can see your points.

odomobo wrote:Correct me if I'm wrong, but since much of the game revolves around trying to keep your code maintainable, then having more elegant code is already its own reward. It reduces technical debt. Moreover, additional or redundant logic which helps make the code easier to understand or maintain shouldn't be penalized. There should be no penalty for good code organization, which already has intrinsic benefits.

That's an interesting point about optimization. Optimization doesn't always just mean faster (like fail fast or super specific conditionals), it could also mean smaller footprint (like memory, total number of nodes) or better disk usage (reusing trees, not counting repeating code as new nodes). Maybe instead of node reactivity, there are other metrics that can be rewarded.

odomobo wrote:Node reactivity would reward some bots which are only strong because they are simple. Worse, I believe that any strong sufficiently-simple bot would be very hard to improve in an iterative fashion, assuming any additional nodes would have a large marginal cost.

I kind of hear weight classes in this point. But, I think one thing that's missing in this point is that you can have multiple, nimble simple bots, and one or more slower, complex bots. It's not just about one AI. Part of why I like offline play more than online play is I can mess with my team composition to determine which AIs/bot classes complement each other and which don't. It would be nice if there was a "go back in time" feature in online play where instead of just replaying the same match, you play your opponent's same composition, but modify your bots composition (as a non-scoring match, of course). This could be like another practice mode, a training mode "what could I have done differently?"

odomobo wrote:Node reactivity turns tractable problems into intractable ones. Did my bot lose because it was lacking logic, or did it lose because it was too slow?

I disagree on this point. When you replay a match, especially with the 10 seconds back button, you can determine the events that caused a bot to die, miss a critical shot, mishandle defense/offense/scoring, etc. I believe you can tell if your AI not reactive enough because it's "thinking too much" or getting itself manhandled because it "doesn't think enough."

odomobo wrote:If I make it smarter, will it hurt the bot or help it?

That's already an intractable problem. How do I know that if I implement a change to solve a problem in one online match, that it doesn't create worse problems in other matches? I think what I mentioned earlier about the "what could I have done different" mode could be a good solution to this.

odomobo wrote:The fact that tagging currently takes a tick seems fine to me, because it's something under direct control of the player. "I will spend 5 ticks at start setting these tags, and a max of 4 more ticks throughout the course of the game." Number of evaluated nodes? Not so much, especially in very complex programs.

I agree with the first part, I didn't mind tagging taking ticks, but I believe players do have direct control of number of nodes evaluated. If you find yourself making a lot of choices based on what class you are, maybe you should have an AI tailored to that class. The non-team tags could also be used to short circuit (skip) entire branches. I'm on an aggressive attack? I'm a 5, skip all defense and scoring logic. I'm hurting? I'm a 1, don't attack or score. I'm scoring? I'm a 3, don't defend or attack, but be ready to go either way. You'd need logic to pick your behavior, but everybody has to do something like that anyway.

odomobo wrote:The last, but probably least important point: you can currently step through a battle in a discrete fashion, and evaluate the logic at each tick. You can theoretically analyze the state of the game at each step to help determine optimal strategies. If each bot runs at different speeds, then this is no longer possible. This isn't inherently a problem, it would just make analysis more difficult.

Maybe. I think if reactivity is implemented, the AI step through should show the current reactivity, or time elapsed for that particular cycle. Maybe just a nodes evaluated counter that resets after the action is picked. It should be clear that an action was picked in 10ms, 100ms, or 1000ms.

odomobo wrote:Those are my thoughts. I'd be happy to be proven wrong on any points, as the game's success is more important than my ego.

Bravo. I think a lot of good feature requests are about to shake out of this thread.
"If it acts like it's not running your code, it's probably not running your code." -- me, I say this all the GD time!

pier4r
Skynet
Skynet
Posts: 3278

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#26 » 21 Feb 2018, 07:42

Odomobo, great reply
http://www.reddit.com/r/Gladiabots/wiki/players/pier4r_nvidia_shield_k1 -> Gladiabots CHAT, stats, insights and more ;

User avatar
drartimus
Algorithm
Algorithm
Posts: 84

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#27 » 21 Feb 2018, 07:56

sollniss wrote:You are basically arguing that making an AI like this:...

I would suggest that a player should tailor their AI to their class. If you have an AI that has logic for all four classes and they all contain about the same number of nodes, I would argue that you've made an AI that doesn't scale (hard to grow), violates single responsibility principle (I'm a computer science nerd), and is potentially harder to maintain. If you broke that AI into 4, you've instantly reduced your (worst case) node reactivity by 75%!

sollniss wrote:Honestly, either system is perfectly fine. I'd even say the first system uses more nodes because you need many more conditions.

I agree.

sollniss wrote:With instant tags we even have cases where we have to check for the same conditions multiple times in a tree.

I haven't done this yet, but I think the solution to eliminate all that redundant checking is to put all your AI's tagging at the front of your AI, and then there's no more need for rechecking. I've been catching several hints that you need your highest priority tag later in the AI, and you really don't want multiple bots trying to do the same tagging. That may or may not address all of what you brought up.

sollniss wrote:Or you watch a replay of your AI and notice a thing that made you lose the match, but to fix it you need 10 nodes. This is literally a lose-lose situation. Don't fix: your AI stays weak, Fix it: your AI gets weaker.

That's already a problem with multiplayer. You never really know if you've solved a problem if you can't duplicate it. I kind of touched on this in my previous post, the "what could I have done different" mode. I think if there was a way to "bookmark" an opponent's AIs and team composition from a match, and replay it but change your own AI and composition, you'd know today if your changes were worth it. If node reactivity was implemented, I believe that feature would also express if those 10 nodes (even reacting slower) made the difference or not.
"If it acts like it's not running your code, it's probably not running your code." -- me, I say this all the GD time!

mcompany
Autonomous Entity
Autonomous Entity
Posts: 865

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#28 » 21 Feb 2018, 09:57

drartimus wrote:
odomobo wrote:For example, mandatory code reviews are great for software development, but wouldn make gladiabots much less fun.

For the casual player, sure, but could be interesting for diehards. I don't know, that sounds like the beginning of clans and clan tournaments. A group of players could collaborate on AIs and have to pull request changes, github style. Could be interesting.

There's one big problem with this though: this isn't a collab game. Sure, that sounds interesting, but that is still in of itself is changing the nature of what this game is supposed to be, and I personally don't feel like having my AI build by a clan of people. Not to mention that with a currently dying player base, asking for a system that's better for "diehards" would really hurt the game, and to be honest, I doubt any of my friends would ever consider a move to it being a collab focused game when they complain about the game not having proper variables (so I really don't know what you think "diehard" fans would actually be).
drartimus wrote:
odomobo wrote:Optimization challenges are great in some puzzle games. For example, basically every zachtronics game has several optimization challenges for each puzzle. It works well in those cases, because each puzzle is a closed-ended problem, so it's an extra layer of challenge that you can pursue after solving the puzzle. Since Gladiabots is an open-ended game, adding something like this fundamentally changes the nature of the game, as opposed to just being an additional challenge.

This also sounds like a fun idea for this game, an alternate game mode could be puzzle challenges in offline player mode. A player could be given a working AI, but to pass the level, they must reduce the AI by x nodes and still pass the level. Or maybe win the match in 10 less seconds, or win by 1 more resource, taking one away from the enemy. It could even be like a the challenge of the day with a leaderboard with quickest time, fewest nodes, best score (like if the puzzle was some sort of ridiculous 100 resource game).

The key thing though is that it would be in offline mode. Hell, even if it was an online thing I'd be fine with if it is a separate mode. But, like the whole issue of the node reactivity, I wouldn't want it affecting the whole game.
drartimus wrote:
odomobo wrote:For example, if I spent a weekend coding up a module that performed some advanced AI, and found that it made my bots weaker simply because it ended up being less reactive, I would probably never touch the game again.

This is me and instant tags (nope haven't gotten over it yet), except it took way longer than a weekend, and a lot of my code is less effective. Part of me thinks in that scenario, the player is spending too much time on specialized strategies that may not work in most cases. But, it could also mean your opponent has built specialization that capitalizes on certain vulnerabilities that are only expressed in a few cases. So I can see your points.

I'm going to ignore this for now, because I already have a massive rant on how your wrong about tags that I need to type up. But quite simply, I will say that your issue with tags is less to do with things being removed,and is more of a problem of "the rules changed, and now we're adjusting". And with or without the node reactivity, the top players will always spend too much time on specialized strategies. That usually never changes, even if we made the game as simply as dive kick. And many players gets their fun out spending too much time. So idk how valid of a complaint that is
drartimus wrote:
odomobo wrote:Correct me if I'm wrong, but since much of the game revolves around trying to keep your code maintainable, then having more elegant code is already its own reward. It reduces technical debt. Moreover, additional or redundant logic which helps make the code easier to understand or maintain shouldn't be penalized. There should be no penalty for good code organization, which already has intrinsic benefits.

That's an interesting point about optimization. Optimization doesn't always just mean faster (like fail fast or super specific conditionals), it could also mean smaller footprint (like memory, total number of nodes) or better disk usage (reusing trees, not counting repeating code as new nodes). Maybe instead of node reactivity, there are other metrics that can be rewarded.

I mean, having a smaller footprint is already a good thing (the game lags less), and avoiding reusing trees is something you'd naturally do anyways if you want a chance to be able to edit anything in your code, so... mission accomplished? Not to mention that the subject on hand will punish you for having more nodes by making the AI slower, so no, optimization in this case literally would turn into making a bot faster
drartimus wrote:
odomobo wrote:Node reactivity would reward some bots which are only strong because they are simple. Worse, I believe that any strong sufficiently-simple bot would be very hard to improve in an iterative fashion, assuming any additional nodes would have a large marginal cost.

I kind of hear weight classes in this point. But, I think one thing that's missing in this point is that you can have multiple, nimble simple bots, and one or more slower, complex bots. It's not just about one AI. Part of why I like offline play more than online play is I can mess with my team composition to determine which AIs/bot classes complement each other and which don't. It would be nice if there was a "go back in time" feature in online play where instead of just replaying the same match, you play your opponent's same composition, but modify your bots composition (as a non-scoring match, of course). This could be like another practice mode, a training mode "what could I have done differently?"

On the first part of this, this sounds like some of what was the worse parts of version 5.2 where to do anything you needed massive amounts of mini AIs for every map. But not only that, but to have many bots, you would essentially be gambling on whether or not you want any chance of even maybe winning, because the maps are currently randomized. I'm sorry, but I don't enjoy gambling so much that I want my programming game to have it. As for the second part, once again, this online we are talking about, not offline, and I do think those two should be kept separately. As far as playing against the enemy's bot without it being change, that's already possible with the current auto generation of games *cough*whichIcurrentlystilldisagreewith*cough*, but I know that's also been argued against several times because not everyone wants their AIs to be pretty much fully released to the public and wants their AIs fully secretive (to the point where even the lines showing your current target is considered a problem)
drartimus wrote:
odomobo wrote:Node reactivity turns tractable problems into intractable ones. Did my bot lose because it was lacking logic, or did it lose because it was too slow?

I disagree on this point. When you replay a match, especially with the 10 seconds back button, you can determine the events that caused a bot to die, miss a critical shot, mishandle defense/offense/scoring, etc. I believe you can tell if your AI not reactive enough because it's "thinking too much" or getting itself manhandled because it "doesn't think enough."

odomobo wrote:If I make it smarter, will it hurt the bot or help it?

That's already an intractable problem. How do I know that if I implement a change to solve a problem in one online match, that it doesn't create worse problems in other matches? I think what I mentioned earlier about the "what could I have done different" mode could be a good solution to this.

Your points here is kinda contradictory, and points out why adding reactivity would make everything so much harder. Did I attack too late? Was my attack with the wrong target? Or is it because my attack went through too many conditions? If I remove this condition, I might get to moving faster, but at what cost to safety? What was an extremely difficult problem to solve would turn into an even harder problem to solve, which (like what happened to tags) would be best solved 90% of the time by making the AI dumber but faster in order to react better
drartimus wrote:
odomobo wrote:The fact that tagging currently takes a tick seems fine to me, because it's something under direct control of the player. "I will spend 5 ticks at start setting these tags, and a max of 4 more ticks throughout the course of the game." Number of evaluated nodes? Not so much, especially in very complex programs.

I agree with the first part, I didn't mind tagging taking ticks, but I believe players do have direct control of number of nodes evaluated. If you find yourself making a lot of choices based on what class you are, maybe you should have an AI tailored to that class. The non-team tags could also be used to short circuit (skip) entire branches. I'm on an aggressive attack? I'm a 5, skip all defense and scoring logic. I'm hurting? I'm a 1, don't attack or score. I'm scoring? I'm a 3, don't defend or attack, but be ready to go either way. You'd need logic to pick your behavior, but everybody has to do something like that anyway.

Once again, I think you are severely missing the problem of why the old tagging system was bad and how impossible it was to use, but that's a topic for a different thread.

pier4r
Skynet
Skynet
Posts: 3278

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#29 » 21 Feb 2018, 11:18

my short argument against the view of drartimus, of which I appreciate the elaboration, is the following.

This is a game, and making nodes costly would be an additional challenge. The point is that, per definition of a game, the objective is that it should be fun, at least for the target audience.
Would the additional challenge kill the fun?

Large AIs are enough of a challenge themselves to maintain, debug, improve, refactor and so on (as a large code base). So as Odomobo already pointed out, one has already the technical debt to fight against him. Adding the "tame the code performance" is a challenge on top.

Then comes the point of tactics optimization. Aside from performances optimization, players are pushed to optimize their tactics against the active playerbase (and ghosts in 12.x). So one has already quite a burden to find a viable tactic to be competitive.

If one wants only to play around with gladiabots, to make coreographies and other single player stuff, surely the challenge of the code performance would be welcomed.

But the gladiabot strength is in multiplayer. Already figuring out an effective tactic to win the opponent is pretty hard (in terms of nodes that do the job and are maintainable over time). Given this situation, the node performance is an additional challenge to fit in the the task of finding an effective tactic. I think it is too much. Can be done? Yes. Would be players be annoyed by it? I think yes too.

I myself won't bother much to play anymore. I have my grandiose plan to refactor my AI thanks to the new editor and only thinking that I have to organize nodes as efficient as possible with spaghetti code (because that is, pushing efficiency to the max may come at cost of readability) is pushing me to say "time for a gladiabot clone".

So nice idea, but I think gladiabots is hard enough by itself given the fact, due to the allowed AI size, the great challenge is to keep the AI free from a lot of technical debt.
http://www.reddit.com/r/Gladiabots/wiki/players/pier4r_nvidia_shield_k1 -> Gladiabots CHAT, stats, insights and more ;

odomobo
Hello World
Hello World
Posts: 6

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#30 » 22 Feb 2018, 02:42

drartimus wrote:This also sounds like a fun idea for this game, an alternate game mode could be puzzle challenges in offline player mode. A player could be given a working AI, but to pass the level, they must reduce the AI by x nodes and still pass the level. Or maybe win the match in 10 less seconds, or win by 1 more resource, taking one away from the enemy. It could even be like a the challenge of the day with a leaderboard with quickest time, fewest nodes, best score (like if the puzzle was some sort of ridiculous 100 resource game).


I agree, that would be fun. Adding in levels with unique mechanics like that would be a good way to keep the campaign varied, assuming gfx wants to make a full-fledged campaign.

drartimus wrote:
odomobo wrote:Correct me if I'm wrong, but since much of the game revolves around trying to keep your code maintainable, then having more elegant code is already its own reward. It reduces technical debt. Moreover, additional or redundant logic which helps make the code easier to understand or maintain shouldn't be penalized. There should be no penalty for good code organization, which already has intrinsic benefits.

That's an interesting point about optimization. Optimization doesn't always just mean faster (like fail fast or super specific conditionals), it could also mean smaller footprint (like memory, total number of nodes) or better disk usage (reusing trees, not counting repeating code as new nodes). Maybe instead of node reactivity, there are other metrics that can be rewarded.


I think this is a key difference that we disagree on. I think that rewarding any aspect of code metrics would end up stifling creativity (or at least, I haven't thought of a counterexample). That is to say, the way the game is now, when you have an idea, you're allowed to express it however you like. This is especially beneficial for non-coders; if they come up with a unique (but inefficient) solution to a particular problem, they are rewarded for their creativity.

In the real world, of course, such expression of ideas is rewarded/punished. However, I don't think it's appropriate for this game, at least for online play.

drartimus wrote:... But, I think one thing that's missing in this point is that you can have multiple, nimble simple bots, and one or more slower, complex bots. It's not just about one AI. ...


This is a cool idea. That could be interesting in, for example, a campaign mission where you have one unlimited AI which is slow, and several reactive AIs, but which can only process X nodes per second.

drartimus wrote:
odomobo wrote:Node reactivity turns tractable problems into intractable ones. Did my bot lose because it was lacking logic, or did it lose because it was too slow?

I disagree on this point. When you replay a match, especially with the 10 seconds back button, you can determine the events that caused a bot to die, miss a critical shot, mishandle defense/offense/scoring, etc. I believe you can tell if your AI not reactive enough because it's "thinking too much" or getting itself manhandled because it "doesn't think enough."

odomobo wrote:If I make it smarter, will it hurt the bot or help it?

That's already an intractable problem. How do I know that if I implement a change to solve a problem in one online match, that it doesn't create worse problems in other matches? I think what I mentioned earlier about the "what could I have done different" mode could be a good solution to this.


Let me respond to both points with an example. Let's say I have a fairly primitive bot, and I realize that I can calculate when my bot would be 1-shot by a sniper. I say "if shields are low and health is below a certain point, and I'm being targeted by the enemy sniper, and assuming I'm not just about to kill my current target, then I should back up". With the current system, adding this logic (assuming it doesn't have a bug) should only be able to benefit my bot, and at the worst, have no impact. With node reactivity, I no longer know if this will be a benefit. This code almost certainly adds 1 node evaluation each tick. "I lost; would I have benefited from removing the sniper avoidance logic?" or "If my sniper avoidance logic kicked in a fraction of a second sooner, I would have avoided the killing blow."

I agree that currently, many problems are already intractable, at least with respect to all possible opponent strategies. On the other hand, currently, it should be possible to analyze and determine which specific strategies can beat other specific strategies. Because of this, you can perform objective analysis on how a certain idea will affect your bots in specific situations (see my example above). With node reactivity, you always have to add the disclaimer "but it makes my bot worse overall". Worse by how much? It's hard to say. You now lose some objectivity with your ability to perform analysis.

Some games benefit from not being able to perform objective analysis. For example, in go, it's often hard to perform objective analysis on the board state, in terms of who is winning (hence go being a hard problem in AI for so long). And as mentioned, this is already difficult in gladiabots. However, right now, the difficulty is in determining the strength of the idea itself. With the change, you would also need to perform a cost analysis, which isn't possible to do without knowing the strength of the idea.

drartimus wrote:This is me and instant tags (nope haven't gotten over it yet), except it took way longer than a weekend, and a lot of my code is less effective.


This is the exact feeling that we don't want to ever happen. It sucks that you have to deal with it. Note that you could theoretically just drop an idle after every tag action to replicate the old functionality (if I understand tagging correctly). Then you could slowly refactor your code to be more efficient. Still, that's not something fun to do.

User avatar
drartimus
Algorithm
Algorithm
Posts: 84

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#31 » 23 Feb 2018, 07:01

mcompany, I know you've been around this forum and game for a while, I respect that. But I'm not a big fan of your reductive reasoning and drive by criticisms. I was enjoying this discussion, but your confrontational tone is more toxic than you think it is. That said, I'm still interested in a constructive discussion if you are.

mcompany wrote:There's one big problem with this though: this isn't a collab game... but that is still in of itself is changing the nature of what this game is supposed to be, and I personally don't feel like having my AI build by a clan of people.

If I gave you the impression this is where I think the game should go as it's only mode, you mistook me. I meant to offer that as a possible mode, certainly for when the game is mature enough to support it. I don't understand the dramatic reaction. If this was a feature and you don't want to be in a clan, then don't be in one. They're typically an invite only thing so just don't join.

mcompany wrote:... Not to mention that with a currently dying player base...

I don't know your source, you didn't provide one, so I can neither agree or disagree. I will say if you say something long enough, people will start to believe it. So I'd be careful with doom prophecies if you like this game. It's not a very good point to support an argument against a feature that doesn't exist.

mcompany wrote:...asking for a system that's better for "diehards" would really hurt the game...

At this stage of development, I don't disagree. That's why I said it might be interesting.

mcompany wrote:I'm going to ignore this for now, because I already have a massive rant on how your wrong about tags that I need to type up. But quite simply, I will say that your issue with tags is less to do with things being removed,and is more of a problem of "the rules changed, and now we're adjusting"...

This is an example of what I'm unimpressed with. I'm fine if you disagree, but don't say you're going to ignore it, tell me I'm wrong with no counter response, deflect to a larger issue, then promise to give me a spray about the item you're ignoring, in a time that's more convenient to you. Just stick with your original statement, put a pin in it and talk about it in a separate thread. If it's a good discussion, I'll be there. I'm ready to respond about how changes to the game that break stable AIs is not a good thing.

mcompany wrote:As far as playing against the enemy's bot without it being change, that's already possible with the current auto generation of games *cough*whichIcurrentlystilldisagreewith*cough*, but I know that's also been argued against several times because not everyone wants their AIs to be pretty much fully released to the public and wants their AIs fully secretive (to the point where even the lines showing your current target is considered a problem)

So, I did not know about this feature. When I discovered my pre Alpha12 AIs were misbehaving, there was no way I was going into multiplayer until I fixed it. This is a prime example of what will hurt online play. How many times will people come back if their AIs can't survive a new release? Sure it's an alpha, sure it doesn't happen often, but when I pay to play a game, it better not arbitrarily invalidate my work (that I've invested months into).

mcompany wrote:Once again, I think you are severely missing the problem of why the old tagging system was bad and how impossible it was to use, but that's a topic for a different thread.

Ok, mcompany, tell me WHY you think I'm wrong, don't just hit me in the face and then say you'll explain to me later why I deserved it. Or just don't bash someone in the first place if you're not serious about explaining yourself.

I'm into this game too. There aren't any other games I play where I submit bug reports or make mockups from screen shots to propose UI requests. This forum is great place to share ideas, not shut them down.

<ironic><clever>Let's make Gladiabots Great Again!</clever></ironic>
"If it acts like it's not running your code, it's probably not running your code." -- me, I say this all the GD time!

User avatar
drartimus
Algorithm
Algorithm
Posts: 84

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#32 » 23 Feb 2018, 07:25

pier4r wrote:my short argument against the view of drartimus, of which I appreciate the elaboration

Thank you.

pier4r wrote:...Would the additional challenge kill the fun?

A very fair question. It is a distinct possibility. I think for novice players, expecting highly performant AIs would raise the learning curve to prohibitive levels. I would not suggest node reactivity until the player unlocks enough skill to handle it.

pier4r wrote:...Adding the "tame the code performance" is a challenge on top.

I agree. A good reason this should be regarded as an "expert mode" level feature. Very likely not a feature that should be added in the near future.

pier4r wrote:Then comes the point of tactics optimization. Aside from performances optimization, players are pushed to optimize their tactics against the active playerbase (and ghosts in 12.x). So one has already quite a burden to find a viable tactic to be competitive.

A feature I'm looking forward to trying when I no longer get my ass handed to me by the campaign.

pier4r wrote:But the gladiabot strength is in multiplayer. Already figuring out an effective tactic to win the opponent is pretty hard (in terms of nodes that do the job and are maintainable over time).

Agreed. When I make changes to my AIs, I use the campaign as a unit test suite. I even keep track of finish times and resource/ally/enemy counts per level in a spreadsheet. If my AIs don't hold up in campaign, I don't expect they'll fair much better against online players.

pier4r wrote:Given this situation, the node performance is an additional challenge to fit in the the task of finding an effective tactic. I think it is too much. Can be done? Yes. Would be players be annoyed by it? I think yes too.

I can accept it could be overwhelming. And if it doesn't enhance game play, I can also accept that it's a bad feature. There definitely needs to be a (worth while) motivator for people to make their AIs perform better if it was a factor for winning matches. If it merely acts as a throttle, or as a disk space quota, I agree, that wouldn't be much fun. If you create a better AI that me and you win because you know how to write a leaner more effective AI, you deserve to win, I deserve to learn how to do better.
"If it acts like it's not running your code, it's probably not running your code." -- me, I say this all the GD time!

mcompany
Autonomous Entity
Autonomous Entity
Posts: 865

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#33 » 26 Feb 2018, 07:52

drartimus wrote:
mcompany wrote:There's one big problem with this though: this isn't a collab game... but that is still in of itself is changing the nature of what this game is supposed to be, and I personally don't feel like having my AI build by a clan of people.

If I gave you the impression this is where I think the game should go as it's only mode, you mistook me. I meant to offer that as a possible mode, certainly for when the game is mature enough to support it. I don't understand the dramatic reaction. If this was a feature and you don't want to be in a clan, then don't be in one. They're typically an invite only thing so just don't join.

Well like I've said before, the playerbase isn't exactly active, so even as a side mode, they'd be very few actual clans featuring more than 2 players unless there was some forced incentive. And that's where my dramatic reaction comes from; either this system will serve no purpose and lose meaning before it even had a meaning, or it will be the only system. We don't have enough players for an in-between.
Also, as a reminder, this is still a discussion on the node reactivity plans, which would be a change to all parts of the game, so as interesting of an idea this might be able to be, it is still at the end of the day irrelevant. (Btw, you could just have multiple players sync to their own devices and try that instead)

drartimus wrote:
mcompany wrote:... Not to mention that with a currently dying player base...

I don't know your source, you didn't provide one, so I can neither agree or disagree. I will say if you say something long enough, people will start to believe it. So I'd be careful with doom prophecies if you like this game. It's not a very good point to support an argument against a feature that doesn't exist.

Oh idk, there's always the rambling complaints of PPS. More importantly, there's the thread I've been tracking for over a month that shows that we've been stuck with around 10 players per league for a long while. I'll give you one thing: the game isn't dying, because it's been steady at a "nearly dead" level for a while. But we almost lost basically all of the top players during 11.x. So yeah, the game isn't active enough for such a system.

Any of the tagging or "my stuff changed" related comments has been answered in it's own thread, as per request

TippyTaps
Hello World
Hello World
Posts: 9

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#34 » 13 Mar 2018, 19:05

I actually am eagerly awaiting this specific change, it's the thing I most look forward to in the patch notes!

I feel like rewarding elegance and tricksyness makes for a much more fun game than rewarding high-res world state description. To me (and a LOT of budding programmers -I am a programming teacher) the fun lies in coming up with clever tricks and quickly being able to test them in the field and improve them, not in covering every possible scenario with a giant tree of conditionals.

I think this goes beautifully with how Gladiabots plays, how the UI is designed, everything! I wanna be beaten because my opponent outsmarted me and thought of something I didn't, not because they had more time to sit down and describe every single thing they could think of.

In their GDC talk, the devs of Darkest Dungeon retells how much doubt they were given by the player base, and how happy they are that they ended up going through with their vision anyway.
The Duskers devs talk at length about how they had to defend specific design choices that served the vision from people who thought it was shit!

I could go on with examples by the devs of Into the Breach, Gunpoint and many more but my point is that just like them, GFX is creating something new and unique, and when devs do that they consistently seem to make the better game by following their gut and their vision!

pier4r
Skynet
Skynet
Posts: 3278

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#35 » 13 Mar 2018, 20:15

TippyTaps wrote:I think this goes beautifully with how Gladiabots plays, how the UI is designed, everything! I wanna be beaten because my opponent outsmarted me and thought of something I didn't, not because they had more time to sit down and describe every single thing they could think of.


Sorry but I find this pretty pretentious. While there may be this or that player trying to catch every possible scenario. Top players have AIs that mostly try to be generically fit, without listing every possible case.

Also listing every possible case wouldn't cut it, as one has to have a properly reactive and balanced decision tree.

If I remember correctly in the top 10 the node count should be in average 200, with lower bound of around 80-100 and upper bound of around 500-600. Also it was proven that with as little as 30 proper nodes one can hit 2000 score points. Now if 30 nodes are "a lot", then the argument for me is only provocative.

Now, while I agree that an __additional__ mode with the node count limited is not bad, as it would mostly serve the same purpose of keeping the node count low via "node delay"; I am pretty sure that those claims like "oh look, I am barely 1400 but because all the others had way more time than me" would end up being excuses even in a mode with node limits. As to create large ai that are not just a big technical debt is far from trivial, in contrast with the quoted message.

I can concede that who has more time has also more chances to get better, but the idea of "outsmarting" those with more experience that already battle in the top places over and over is a bit delusional. One does not get in the top places only with a mere list of cases "what to do in this scenario".

I mean, it sounds like a good excuse to accept losses. And if it works then why not, being frustrated in a game is not nice. But to claim that stronger players do not have a smart decision tree, rather an endless list of branches for every case, shows lack of understanding of the game.

It is like saying "I am 1200 in chess not because stronger players outsmart me, rather because they memorized every possible situation and how to react to it. Otherwise they are pretty dumb". If that sounds legit, then there is also a lack of understanding for chess.
http://www.reddit.com/r/Gladiabots/wiki/players/pier4r_nvidia_shield_k1 -> Gladiabots CHAT, stats, insights and more ;

sollniss
Automaton
Automaton
Posts: 175

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#36 » 13 Mar 2018, 21:24

TippyTaps wrote:I feel like rewarding elegance and tricksyness makes for a much more fun game than rewarding high-res world state description. To me (and a LOT of budding programmers -I am a programming teacher) the fun lies in coming up with clever tricks and quickly being able to test them in the field and improve them, not in covering every possible scenario with a giant tree of conditionals.


Please tell me which solution is more "elegant" and "tricky" in the screenshot below. Then could you please tell me which one the +10ms per node penality promotes.

And then please tell me you are not contradicting yourself.
Attachments
asdfg.PNG
asdfg.PNG (95.11 KiB) Viewed 460 times

mcompany
Autonomous Entity
Autonomous Entity
Posts: 865

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#37 » 14 Mar 2018, 07:14

TippyTaps wrote:In their GDC talk, the devs of Darkest Dungeon retells how much doubt they were given by the player base, and how happy they are that they ended up going through with their vision anyway.
The Duskers devs talk at length about how they had to defend specific design choices that served the vision from people who thought it was shit!

I could go on with examples by the devs of Into the Breach, Gunpoint and many more but my point is that just like them, GFX is creating something new and unique, and when devs do that they consistently seem to make the better game by following their gut and their vision!

I almost consider this to be a sort of fallacy. Yes, not every idea a community has is better than the alternative that the developer wants to do. And sometimes, we are better off seeing the effects of a decision more than we should be merely talking about them. However, imo, that would not be something that can be argued in a discussion like this, that would only be possible to consider after the change was made and after the dev put into action the vision of his game. However, until then, the only thing we can argue is whether or not we think that such a change would be negatively affecting us.

TippyTaps wrote:I feel like rewarding elegance and tricksyness makes for a much more fun game than rewarding high-res world state description. To me (and a LOT of budding programmers -I am a programming teacher) the fun lies in coming up with clever tricks and quickly being able to test them in the field and improve them, not in covering every possible scenario with a giant tree of conditionals.

I think this goes beautifully with how Gladiabots plays, how the UI is designed, everything! I wanna be beaten because my opponent outsmarted me and thought of something I didn't, not because they had more time to sit down and describe every single thing they could think of.

I will agree with Pier that this sounds very pretentious and I will say that what you believe to be true is simply not practical for any sort of AI design at all in any sort of complex problem. Many of the top AIs aren't just mathematically solving each and every solution (which given previous examples I'd say that is far from recommended) but instead from only trying to solve the most relevant of simple situations and outsmarting the opponent's AIs in all other situations. And given that there was a change to it to have this sort of change,, I have little doubts that only the best options will be sat down and considered and I would fear that it would make the game easier to solve at a high level

mumpsimus
Algorithm
Algorithm
Posts: 56

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#38 » 15 Mar 2018, 01:32

If Gladiabots wants to be a competitive hobby/e-sport, it stands to reason that ranking and time investment are positively correlated, which is true for most games where randomness doesn't play a large role.

In all such games, though, you can have fun competing without the ambition to be a top player.

Eventually, balancing changes need to keep/make the game fun and interesting to play at all levels. That doesn't mean it needs to be possible for a player who only wants (or is able to) invest a limited amount of time to reach the higher leagues.

I personally think time penalties for number of nodes evaluated will make the game neither simpler for new players, nor make them more likely to rank up faster.

Successful players will be the ones that are able to balance their trees such that important/urgent nodes will be evaluated first always, and less urgent ones when there are no imminent threats. I don't think it will ultimately lead to smaller AIs overall.

pier4r
Skynet
Skynet
Posts: 3278

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#39 » 15 Mar 2018, 04:36

It will lead to uglier ai overall
http://www.reddit.com/r/Gladiabots/wiki/players/pier4r_nvidia_shield_k1 -> Gladiabots CHAT, stats, insights and more ;

User avatar
Tortuga
Script
Script
Posts: 11

Re: Node Reactivity Depth Discussion(+10ms per node)

Post#40 » 16 Mar 2018, 16:52

As the game is currently considered, there is a great variety of possibilities in terms of tactics and strategies. However, due to the limitations of the graphic language used, the number of nodes needed to explore new strategies, beyond the basic ones, increases greatly, making it difficult to maintain.
It is very possible that soon, if not already, one or several people will find an almost perfect AI, which will remain within manageable levels of size. Having arrived at this situation of no progress, you can obtain small temporary advantages that make the first positions are always oscillating, and the game ends up becoming more boring.
Changes in the rules that involve reducing the possibilities, such as limiting the number of nodes, will only cause the situation of no progress to occur sooner. However, other types of changes that do not limit the complexity of the game, but increase it, can make it more difficult or even impossible to achieve optimal AI, and new ideas and creativity will always have their reward. I think that everyone agrees that the introduction of the random field was an improvement over the fixed fields, since it increased the complexity of the problem. Still, I think it would be necessary to introduce more factors that contribute to increasing the complexity to make this game something similar to chess. Personally I think the best thing about this game is when you find those factors that are more decisive than those used by the other opponents and that are the ones that give you the most statistically victories. But if the complexity is reduced, finding new strategies is more difficult and the game becomes boring before.
Introducing a small delay for each node, can give the feeling of making the game more realistic and complex, but only if this delay is very small and allows to maintain a sufficient number of nodes in an AI with complex strategies (which due to limited of the graphic language I doubt that it can be achieved with less than 100 nodes, although this limitation in the number of nodes should be implicit in any player who wants to have a manageable and understandable AI without the need for delay.
What we should consider, is that we can introduce changes in the game, that increase their complexity to a chess level, so that a hegemonic AI can never be achieved and creativity always has its reward.

Return to “General Discussions”

Who is online

Users browsing this forum: BenJV4 and 1 guest