Project Cube On : An OU bot. (currently OU no mega) [Asking for ideas !]

[Artemis Fowl]

huge graphical skills were needed for that

Approved by Ginganinja​

Summary​

Hello, I've been programming for about ten months, randomly stopping and resuming the project, a battle bot, which has now reached the level of a beginner that never anticipates. Clearly not enough to win matches, but I thought it was interesting to present anyway, especially to show how the AI thinks.

It is written in python, and the code is at the end. It does not depend of the tier, only needing a set database to work in any tier. It also adapts to the given team.

Let's jump straight to the AI :

How the AI proceeds​

The bot will use two databases according to the tier he's playing in. (Right now, ou.)
One of them is the huge statistic DB available to all : http://www.smogon.com/stats/2015-04/
And the other is one I make myself. It contains the most common sets about the most common pokemons.

Using this, the bot will, as soon as it sees the opponent team, make a "guess" about their sets. In the case he's dealing with a pokemon that is in the precise database, he will assume he has its most common set. If it is not in the handmade database, he will create a (most likely stupid) set using the statistics : most common item, ability, EV spread, and 4 most used moves. This leads to some stupid situations, for instance, if a pokemon use half the time Fire Blast, and otherwise uses Flamethrower... the bot could end up guessing he has both. But that is easily solved by extending the database.
(Add 23/5) If he meets a Pokemon that isn't in the OU database, he will look for him in the UU, then RU, then NU database, and proceed alike.

This having been done, the bot thinks he approximatively has a knowledge of the situation. This leads us to the core of the matter : the bot works by situation rating.

In any situation, the bot will be able to rate it, and that is how the entire decision protocol is decided. When reviewing its possibilities, the bot will then replicate the game mechanics in order to imagine what the situation would be, if this - a specified turn - was to happen. It will then choose what heighten the "situation rating" the most, which ultimately leads to wiping out the enemy team.

That is where the AI is at first different from what would be the most basic (and future-less) way of thinking : looking one turn away, if you're able to inflict more damages than taking.

Let's take several real exemples of what should a situation rating thinking protocol fulfill :

- A fast pokemon that has barely any hp is not worthless. It can still outspeed something and strike. The bot shouldn't throw it away for nothing.

- A slow pokemon that has barely any hp is worthless, priorities apart. No matter the situation, it will get killed before being able to do anything. Thus, it is a death fodder : if the situation gets bad, the bot should sack it, to regain the upper hand.

- Let's say there is one sweeper in each team threatening each other highly. A fast one in the ally team does 50% to the other, and the other, slower, kills it in one hit. If the opportunity comes, the bot should rate very high inflicting 50% to the opponent opponent, because it knows it will completely flip the result of this decisive fight.

- In short, if the opponent has something that threatens the team, it should be ready to make 'losing' trades to weaken it.

There are several advantages to proceeding this way, and mainly the fact that as long as you define what each move does, plus giving particular ratings to weird moves such as hazards, the bot will have an objective sight of the thing. It will use a healing move if its situation is better after a healing move than after doing something else. (heals aren't made yet tho)



And so, here's my situation rating function :

Imaginating every possible 1v1 between allies and enemy, even if they're dead (that's 36.) and have them fight to the death. Then, take the remaining %hp (if both are dead, that's 0 and 0), and add the ally's positively to the score, and the enemy's negatively.
So, the "Situation rating" is a number, between -3600, and 3600.

This method, in addition to fulfilling the cases stated upper, and not being so heavy to calculate (it's pretty much a complexer euclidian division, you keep substracting things), gives an insight of long-term strategy, which is extremely hard to teach to a bot. Toxicing the tanks makes sense when thinking with this method, because it will heavily modify every fight in favor of the bot, since these are long fights (Also, it will make even more sense toxicing those that can heal, once heals are implemented).

There is however one downside to it : this function ignores what's currently happening on the field. Because of this, switches are fucked up without modifications : the bot would switch to someone else only if the current fight is so bad he'd rather take the hit with another mon and not answer. ... That doesn't happen often. Switching isn't only about tanking the hit, you've also got to think about the situation that is about to come. You don't switch in heatran against Mamoswine because it will make you able to tank Ice Shard.

To correct that, I had to add a subjective rating modifier when rating switches : the bot will look at the score modification once he has switched, plus each mon have hit each other once ! Tho right now, it's a bit retarded and only consider that each mon will hit each other once with their best damaging move - not their best move which could be a status one, for exemple.

This isn't randomly dropped : the idea is that if you've got a positive score with this, the opponent will switch out once you've switched in and got hit : the situation being perfectly symetric, this is likely to lead to a global score modification of 0, which is better than keeping on losing your fight two turns before.
Then again, all this is modified by the importance the situation rating gives to each pokemon, if your tank sucks against the opponent team and is only able to tank the pokemon on the field, he will throw it in right there : him getting hit barely changes the score not in your favor. If your pokemon on the field musn't get hit as it would flip the 1v1 with other mons, he will attempt to save it.

This ends my explanation of the AI.

I can see two downside to this method : the first one is that the bot has to assume he knows the situation, and base his entire reasoning out of it. But he doesn't. For instance he will think that all Latios when first met have the four moves he has in mind. But Latios has a coverage that far wider than four moves, thus, if he thinks for exemple the latios don't have earthquake, he will repeatedly throw heatran in ... and die every time latios happened to have earthquake. That is one of my main concern right now and is the real flaw this AI carries everywhere, which I don't know how to fix.

That's typically a problem that I doubt the programmer of this probability based bot : http://www.smogon.com/forums/threads/an-ou-bot.3529338/ has. The way our approach to the problem differ is what had me want to present mine.

The other one is that the bot isn't aiming to wipe out the opponent team, it's aiming to keep the highest situation rating. This can cause weird stuff at game ends, where the bot has an obvious way to finish the battle, but will not proceed as it would lead to a situation rating drop (and victory ._. ). I've never seen it happen (since he never wins >< ) but I can guess that if the opponent has setup moves, this can cause disasters.

What currently lacks​

- Heal knowledge. While this is very easy to program (about 2 minutes ..), this implies I would have to remake the "1v1 confrontation to death" part, which currently takes one move for both pokemon and imagine them spam it until eventual death. (Which is a bit dumb, i mean, priorities exist, so the best move changes over time). Also, endless fights management inc...

- LEARNING APTITUDE !! I currently have the structure made to exploit the learning part but no data acquisition part ready ! I mean by that that the pokemons in the main db have several sets stored in and so, the bot will, once it's done, look at the sets that do not contradict what has been seen already. (The idea about this is that something with LO has most likely an offensive set, while something Leftovers will have a defensive - and this is seen through the sets).

- Boosts. Well, the bot will rate the situation where the opponent pokemon is boosted ... but before putting that, I gotta make a cleverer "switch then 1 turn" evaluation. The entire point about boosting is that you will want to put the mon that can boost itself on someone it can boost on. Currently, the switching evualation is taking the upcoming move + having them hit each other.

- Mega-evolution. Well ... I don't know how to do on this part. The enemy pokemon litteraly changes to another ._.

- Hazards.

- Heal bell. Tho this shouldn't be too hard ... "reset all status to normal". But far on my priority list.

- Proper understanding of multi hit moves. Right now, he thinks they all hit once. (except bullet seed, for testing reasons)

- Almost all abilities.

Currently implemented :​

The bot knows, aside from damaging moves :

- Paralysis, poison, toxic poison, burns

- Choice items

- Every damage-modifying item

- Priorities on moves, except ability-related ones (hello talonflame).

- Immunity abilities (Volt asborb, levitate, etc)

- Most end-turn hp modifications : Leftovers, Sludge Bomb, weather damage.

- Contact damage : Rough Skin / Iron Barbs / Rocky Helmet

Known bugs​

- Alternative forms regrouped that do not have their specific entry in the databases are unknown. For exemple, Keldeo-Resolute needs an abstract rename, as only Keldeo has associated datas, in both smogon's DB and my handmade set DB. Well, handmade, it's a copypastes of smogon's analyses' sets.

- Having one of its mons killed by a pivot-move makes the bot crash. He tries to answer as soon as he witnesses the KO of its mon, except the opponent has something to choose first.

- Choice items do not work with Hidden power. "The opponent just used Hidden Power, so he won't be able to use that "hiddenpowerfire60" that is in his set... right ? RIGHT ?" - Cube.

- Multi hit moves only proc contact damage once in the head of the bot. Well, they only hit once in his head anyway ...

- The bot isn't aware of the toxic poison stacking on his active pokemon. Like, he will consider at every turn that the stacking starts now, from 6.25%.

Code​

I'm french, so don't be surprised if there are half the annotations (# stuff) you cannot understand.

Core code (Connection + AI) : http://pastebin.com/hZriU1xX
Surge (Extracts string data and makes it usable matter for python) : http://pastebin.com/84dtu4db
Datacalc (calculation data) : http://pastebin.com/6qMErixR
Datasets (the set pasted data) : http://pastebin.com/DKSPheYJ
I couldn't put the pokedexjs one because it's too heavy for pastebin, but its nearly json.loads(the PS files available on Zarel Github)
To put an exemple for each : http://pastebin.com/nuZKg403

Replays​

http://replay.pokemonshowdown.com/ounomega-234254752 (First Cube match on the official ladder)
http://replay.pokemonshowdown.com/ounomega-234387090
http://replay.pokemonshowdown.com/ounomega-234412684
http://replay.pokemonshowdown.com/ou-234412678

Test matches where I was the other player:
http://replay.pokemonshowdown.com/pokestrat-ounomega-2980
http://replay.pokemonshowdown.com/pokestrat-ou-3169

---

This thread is a copy of my thread on Technical Projects which is a dead forum, but given this forum has shown interest in OU bots before, I thought I would put it here too. Don't hesitate to comment on / suggest/ask anything !

 

[Analytic]

Looks good man, good luck figuring out the rest

 

[Erza98]

Wow, although I thought it was a moderating bot, I'm really surprised how quick you managed to build a battling bot which seems to be way more performent than the others cc1v1 bots. I hope I'll someday face it to see how good its actions are... or how bad I am . c:

 

[AM]

People like reading through and analyzing stuff like this so I'll let it slide just ask for mod approval next time since it's always interesting to see how programmers create this. Gonna edit OP to say I approved it so don't worry about that.

 

[Anduril]

Mad props dude, this looks really cool. Good luck figuring out the rest!

 

[Artemis Fowl]

Uh, actually, I forgot to state in the post I had mod approval. I pmd ginganinja for approval yesterday, who answered positively.

 

[Imperator Romanum]

Dude this insanely cool. But also kind of frightening lmao. If you truly figure this out it'll be very difficult to beat it

 

[Exeggutive]

This is really impressive. Do you ever think that it will become so dominat and efficient that the ladder would become over run by bots?
I know in some mmorpgs (Runescape is the only one I remember but I'm sure there are others) macros have become a huge problem in the community and kinda ruins it for everyone. Do you think that this could happen in Pokemon? Like people doing well in tours/suspect reqs could have a negative impact. Not so much laddering but it does effect the experience a bit

btw I think this is cool as hell. Not hating at all. I suck at programming so I would never be able to do this :(

 

[Rhayader]

Couldn't even beat Ridaz... Obviously there's much work to be done. Wish you good luck with that, probably the most important thing to implement is understanding of healing moves and hazards. Additionally, I suggest you use a better team to raise the bot's chances of actually winning, as the replays show it using stuff like regular venu and wisp-hex gengar. Good luck!

 

[Random Passerby]

Well, I can see the bot has potential but can it be equipped with a better team? Vanilla Venusaur is very bad especially without Sun support

 

[Artemis Fowl]

Rhayader and Random Passerby , actually, it's mega-venu, but the bot has no knowledge of mega-evolution yet. Also, this team is a tournament one given by a friend, but it obviously doesn't fit a bot that doesn't know about phazing (yet uses dtail), doesn't know about hazards (yet has sr chomp) and doesn't know that hex power doubles when hitting a statused mon.
I should indeed change the team to a basic, straightforward one, where the bot knows how to use everything in it.

Exeggutive I really doubt it, for several reasons. First, because <0,1% of showdown can code a bot (i think), yet alone code a battle bot. Also, even if most bots, including this one, are open-source, it isn't enough for anyone to run them. I've been trying for months to get my chat bot (on another server) to be hosted by someone, but each time someone could, we never succeeded at running it, because it requires plenty of modules ... in short, to run someone else raw code, you gotta be competent at coding, and that's often not even enough.
Finally, a bot can become really good in games anticipation has no grasp over : chess, backgammon, etc.
What a bot can at best do to replicate anticipation (i think ?) is applying its own decision tree to the opponent's situation (which is what i plan on doing btw), and even that is flawed : men think differently, so there's no way a bot will correctly think like the opponent.
You probably already met cases where you knew your opponent and so knew he tends to play in a certain way in a given situation : that's proof enough human decisions follow no perfectly rational paths.

 

[yuruuu]

You couldn't just add an evaluation function like if StealthRock not on field SituationRating -= 1000 or some arbitrary value?

 

[Artemis Fowl]

yuruuu I could give an arbitrary value to stealth rock. But this is a terrible way to do it. If the bot happen to put the spiker only at the game end, where both teams have 1 mon left, should it put stealth rock which heighten the situation rating by 1000 when all other (fighting) moves modify it by something between -100 and 100 ? Hell no.
Stealth rock interest varies as game proceed, and particularly depends on the opponent team : you will want SR at all cost if he has zard.

Right now, I don't really know what to do about hazards. I could simply go for a situation rating protocol that starts the calculation with the opponent %hp - % taken on SR, since they will eventually have to come in, but that doesn't really reflect the reality, because it only thinks about the next time they'll come in, not the fact pokemons can come and leave several times during the battle.
On the other hand, it would reflect properly the fact that when you switch out with SR rock, you're kind of inflicting the leaving pokemon its SR damage.
Well, i have no better ideas, so I might go for it if i don't find something better by the time i come to hazards. Right now i'm teaching it to learn, i mean by that, to store the intel he gets on the opponent mons and thus, rechooses a set.

Edit : you just learnt me -= existed. Now i can replace my army of "+=-" ._.

 

[yuruuu]

Possibly the value could be a function based on how weak the opponent's Pokemon are to Stealth Rock? Adding up the values would probably work fine, the more Pokemon they have the more benefit Stealth rock is likely to have anyway. This can also exclude things like putting SR when the opponent has only 1 mon, etc.

 

[Artemis Fowl]

Possibly the value could be a function based on how weak the opponent's Pokemon are to Stealth Rock?

And, in the method I just explained, this function would be "SituationRating of a battle where opponent takes hazard damages when coming in - current SituationRating"

Also, no, adding the values isn't clever in my opinion. If putting stealth rock turns 2HKO in OHKO on a slow thing, it's for exemple far worthier than the usual.

 

[PK Bash]

First of all, props for doing this as well as you have, this sort of thing's never easy to do. I'm not a Python programmer (I'm one of the 12 or something people in the world still using Virtual Pascal, which everyone else stopped using sometime in the 1980s) but I've started thinking of a possible solution to the Toxic bug. Whether it could work in your bot I don't know, but it might be a good starting point. In short, it reads one turn into the future and partially bases it's assessment on that turn.

So basically what I've just done is written an algorithm (in VP) that calculates the active Pokemon's HP after Toxic damage each turn (accounting for scaling damage), and what the bot's active pokemon's HP will be at the end of the next turn. It seems to work in my isolated code. The principle I was thinking of was it would calculate the active mon's HP next turn, taking into account the scaling Toxic damage using this anticipation method, and base an assessment on that.

To get the scaling damage, I went about it in a slightly different way to you but ultimately led to the same sort of thing - I created a Boolean variable "Toxic" and an Integer variable "ToxTurn". If Toxic = true, ToxTurn is assigned a value of 1. At the end of the turn, the active mon's current HP := current HP-(6.25*ToxTurn). To get the predicted HP for the end of the next turn, Predicted HP := current HP-(6.25*ToxTurn+1). ToxTurn increases by 1 every time the repeat loop representing the whole turn runs. Including the damage of the opponent's attack eschews this somewhat as you then have to calculate probabilities of HP (or damage) being a certain value within parameters, but it can be done. (Something I'm about to try is incorporating an algorithm inspired by the basic principle of Euclid's algorithm, modified slightly to get the statistically most likely HP and/or the worst-case scenario after the opponent attacks but as of currently I have no idea how well this is going to work.) (Incidentally if it made a mistake predicting the HP (say, critical hit), it would still acknowledge it's actual HP in successive iterations, and not use the Predicted HP as a reference for what it thinks it's HP is if it was incorrect.)

This would make the bot aware that the Toxic damage has already started stacking and will continue to stack, and could be incorporated into the situation rating(which I haven't got because I didn't fancy building a fully functioning bot) - based on whether or not it decides it needs it's current active mon, the ideal HP the active mon would need if it decides it needs it, and so on. If the predicted HP falls below the HP it decides it needs, it would withdraw the active mon to preserve HP. (Once another variable, Active1, denoting if a party member is the active pokemon or not, = FALSE, if Toxic is TRUE ToxTurn is assigned equal to 1 to reset the algorithm when it comes in next time, or in other words when Active is TRUE again)

There are problems with my Toxic algorithm (such as ignoring weather damage and hazards) and the steps taken to decide whether or not to switch, but I hope this gave you a few ideas in teaching the bot how to acknowledge stacking Toxic damage. If it was completely useless, well, sorry for wasting your time.

algorithm if you're interested

Annotation marked with {}. There are a couple of semantic errors here but it's perfectly legible and the important bits function correctly. The cool thing about VP is it's basically pseudocode, just with semicolons to mark ends of statements.
PROCEDURE PredictHP;
VAR
OppDamageOutput: REAL;
PredictedHP: REAL;
EndChoice: CHAR;
ToxDam: REAL;
{there are more variables which are global, such as HP(Real) and ToxTurn(Integer). I have many procedures running different calculations and serving different purposes}
BEGIN
Active := TRUE; {Would already be so, but has to be specified here for my code}
HP := HP; {this is just a thing I do, I know it makes no sense, ignore it}
OppDamageOutput := 0;
WRITELN('GARCHOMP is badly poisoned!');
Toxic := TRUE; {changed to true in program when hit by Toxic poison} {ignore that annotation, it refers to a separate procedure}
ToxTurn := 1;

WRITELN; {blank line}
WRITELN('Enter HP: ');
READLN(HP);
{bot would already have a HP value}
WRITELN('Enter opponent''s damage ouptput');
READLN(OppDamageOutput);
{Bot would already know this. Mine is heavily simplified for testing purposes}
REPEAT
WRITELN('HP = ',HP:3:2,'%'); {:X:Y specifies number of significant figures before and after decimal point to display}
WRITELN('Opponent uses attack!');
WRITELN('GARCHOMP takes ',OppDamageOutput:3:1,'% of damage!');
ToxDam := 6.25*ToxTurn;
WRITELN('GARCHOMP takes ',ToxDam:3:2,' % damage from poison!');
WRITELN;
WRITELN(HP:3:2); {this line is solely for testing purposes}

WRITELN('CURRENT HP: ',HP,'%');
PredictedHP := HP-OppDamageOutput-(ToxTurn+1)*6.25;
HP := HP-OppDamageOutput-(ToxTurn)*6.25;
PredictedHP := HP-OppDamageOutput-(ToxTurn+1)*6.25;
WRITELN('CURRENT HP: ',HP:3:2,'%');
WRITELN('HP AT END OF NEXT TURN: ',PredictedHP:3:2,'%');
WRITELN;


IF PredictedHP <=0 THEN
WRITELN('GARCHOMP will faint next turn.');
WRITELN('Continue procedure?(Y/N)');
EndChoice:=UPCASE(READKEY);

IF PredictedHP >0 THEN
WRITELN('GARCHOMP will survive next turn.');
ToxTurn := ToxTurn+1;
{I'm forced to use separate IF statements for Real numbers, don't judge! There's a couple of errors when it comes to displaying the WRITELNs for the two IFs but they're not important for this}
UNTIL
EndChoice='N';
WRITELN('Press any key to terminate');
READKEY;
END;

 

[Artemis Fowl]

PK Bash
Thanks for the help ! Actually, I agree with you on the creation of a ToxTurn variable linked to Ally/EnemyInstance classes, which would reset to 0 when switching out, and, when poisoned, start at 1 if the pokemon came with a switch-in, and 0 if he came after a death. It would then heighten by 1 every turn stayed on the field.

Actually, I expressed myself wrong about toxic damage, i doubt anyone beside programmers would read if i had written down all the details, so i made it short, and I also realized that toxic wasn't "wrongly" programmed, there were simply two parts where toxic had an effect : one is correctly done, the other isn't even begun yet.

There is, first, the situation rating.
To rate the situation, the bot thinks of the 36 possible 1v1s as if the began now, in an 'alternative' battle. Let's now say someone is toxicd. The bot will consider the toxic damage application starts as if they both began fighting now, which means, at 6.25%. And it does this for the 36 battles ... even if he's imaginating the two pokemons currently on the field fighting, and their poison "counter" is NOT at 0 !! That can be surprising, but it's important not to forget that what matters to the situation rating protocol is the power relation between these pokemon in an abstract situation, not the fighting they're doing right now. Deciding what to do "right now" is the job of the RequestAnswer part, which is supposed to imagine what is going to happen should he do "this move" or "this switch".
And we're coming to the core of the problem ... My RequestAnswer part sucks really, REALLY, bad. It's simple. The pokemons hit each other. :) Sandstorm damage ? Contact damage ? TOXIC PROCS ? Never heard of.
While the "abstract 1v1s" part is kind of clever, takes toxic damage in consideration, item recovery, weather damage, and so on, the 'what happens if i do this move' part is utterly stupid. What I should do is modifying stuff so I can use the 1v1 calculation function to calculate only one turn away.

In short, when imaginating what happens one turn away, the issue is not that it fucks up toxic damage. It's that he isn't even aware they exist.

However, the 1v1 calculation takes toxic in consideration, and actually, does EXACTLY what you wrote.
You use a Boolean variable called Toxic, I use a ['status'] entry in the dictionnaries AllyInstance and EnemyInstance are, that's pretty much the same. I prefer grouping all status in the same attribute as it's easier checking whether one has a status or not.
And your "ToxTurn" is my "lenght" variable in the confront method.

Toxic application :

if loop_Instance['status']=='tox':
loop_Instance['%hp']+=-(lenght+1)*6.25

Toxic damage increase (confront works recursively) :

if Instance1['%hp']>0 and Instance2['%hp']>0 and lenght<40:
return self.confront(Instance1,Instance2,fastestInstance,lenght+1)

Thanks for helping anyway, you were clearly right on the process. I will indeed create a "toxturn" attribute to pokemons and proceed that way once the RequestAnswer part does a bit more than simply substracting hp depending on damage. I hope now at least it's clear, sorry for terribly expressing myself earlier :')

 

[Phione]

Could you find a way to edit (in the bot's eyes) the HP of every mon, subtracting a value based on SR damage, giving the bot a different outlook and situation value? I don't know too much about coding, however, so this might be impossible. Either way, good luck!

 

[Karxrida]

My only question is can it play Baton Pass successfully? Otherwise awesome job with your magic.

 

[Artemis Fowl]

Phione Yes, it is possible to explain to the bot that switching substracts to the switching mon the damage hazards do. Was this to happen, his calculations would end on a different situation value. Actually, hazards are rather easy to add, but I haven't done it yet, I first want to add 1. a clever switching evaluation ; 2. indirect damage when looking a turn away ; 3. an ability to deduce the opponent's set

Karxrida No, actually it doesn't even know what a boosting move is.

 

[Artemis Fowl]

Asking for ideas

Hi again, for those that scrolled down here, this time i'm not answering questions but asking some !

When working on huge projects, I think (since I have no experience lol) that one should plan nearly exactly what he wants to achieve in the beginning, so did I with Cube On here. That is because adding precise things at the end often implies you've prepared the field for them earlier, by not making choices that contradict what you're trying to implement later.
I've clearly reached here what I wanted to do at first, more, actually, and so it's starting to fuck up rather badly : each time I add something that wasn't meant to be here, it's harder and harder having everything work together.

That is why I'm starting to think about creating a 2nd version, with this time, well, higher goals. I set my goals about this bot 9 months ago, see :p With this time, obvisouly, a data architecture prepared for these goals.

These are the points I am willing to implement :

• A cleverer guess protocol. I mean by "guess protocol", everything related to what the bot believes about the opponent's team, mainly about the pokemon sets.

1. The bot shouldn't assume the enemy has the most common set on every pokemon. That's dumb, sometimes it's obvious it's not the case.
2. The bot should learn, when he sees a move used, he knows the opponent has the move ...
3. Establishing relations between moves. If the bot sees the opponent has flamethrower, well, even if the usage say 55% Fire blast and 45% Flamethrower, the bot should know that having one implies not having the other. This kind of relation must be manually input, but there must be something to use them.

• Improving the "abstract situation" realism

1. Switching from a function that makes 2 pokemon hit each other until death to a single function that have them give each other a single hit, and use that function in the after-hit situation creation, and the post switch hit exchange situation creation, but that's programming stuff, in short the switches won't be as stupid (no switching on something with 2% hp without realising he won't be able to answer)
2. Setups. I have absolutely no idea how to implement this.

• Anticipation ? If possible :l Anticipating humans is like, the ultimate level of AIs.

Currently, I am thinking of how to create a better guess protocol, and since 200 brains is better than one, I thought I'd ask for your help.

To set the problem clearly :

- What does the bot assume at first about the opponent's sets, when seeing its team, at team preview ? It isn't possible to have it hesitate, he must believe clearly in one thing, otherwise, 2 possible sets for each pokemon in 2^6 = 64 team possibilities, and he would see how good his actions are for every possible team ? Hell no.

- How does the bot react when getting an information ? This can be an item, a move, or abnormal stats : too low/high damage, unexpected outspeeds.



My current thoughts about how to proceed go this way :
Store several sets
Each set will have 3 attack categories : "Mandatory moves" ; "Secondary moves" ; "Possible moves"
Secondary and possible moves will have their usage asked for on online databases
The bot will fill the attack slots left by mandatory moves with secondary moves, and in order to do so ... I was thinking of looking at how the opponent's team, given it only has mandatory moves (so 2 or 3 moves most likely) fare against the tier's main threats, and if it appears nobody in the team is able to fight a given threat, then the pokemon that have a secondary moves that make them able to fight the threat probably have them. But I haven't established any quantified protocol yet.
Finally, each set would have a list of "move relation" who would each countain 2 moves, and a relation to be used by the set update protocol. For exemple, Rest "implies" Sleep Talk, Sleep Talk "implies" Rest, Flamethrower "implies no" Fire Blast, etc.

That is where, if you have any ideas, go ahead. Creating a bot implies having ideas, and being able to turn these ideas into code. ... Anybody can have ideas !

Also, if you have a question about the actual bot, I'll still answer !

 

[Taliheim]

Well, I don't know too much about programming, but I can give my two cents on the information and predictions aspect.

What I would do is create a set of variables meant to represent the opposing team, which is reset at the end of every match. This set would include variables describing pretty much everything about the opposing team; What the six Pokemon are, their revealed moveset, their extrapolated EVs/Nature, their revealed Ability, etc. While coding this might be a pain, you could have the bot reference this set while it checks what to do for the turn. Extrapolating EVs is probably easier to code - just compare base numbers to the real numbers to get a possible range of EVs - but would probably still annoying to try and make the bot actually use it.

Maybe you can use the SmogDex instead of the usage stats? It would take different code to read, but it would be able to predict its opponent's set through process of elimination a lot easier, so it won't be expecting stupid sets like you say it's been having.

It's probably easy to code in something that says "If the Pokemon that you have out has a button called "Mega Evolve", select it", but that's probably just me.

Anticipating Megas should be another thing it should learn, so it doesn't Fire Blast M-Venu or something; just make it recognize the possible Mega-evolutions on the opposing team, and assume that the most popular mega is the mega on that team. Something more ambitious would take forever to code, having to do with relations to the other team in general.

Finally, I would implement a system where when figuring out its decision for a turn, if it has a Boosting move, it will also take a second route, calculating the possibilities if it boosts. A more complicated version of it could also be created for hazards.

 

[yuruuu]

I would have to assume that most are the most common sets at team preview, with no other extra information. The only thing I take into account for not being the most common set at team preview is whether or not the Pokemon in question is the only one that can set Stealth Rock.

For instance, if the only Pokemon that can set SR on his team is Landorus-T, guessing that it is not a Choice Scarf variant is probably quite a good one.

 

[Artemis Fowl]

yuruuu I just said the current bot assume that everybody has their most common set at the team preview, and it's shitty <.< Although, you just stated something very interesting about stealth rock, I think i'll add that.

 

[PK Bash]

Something I've thought of off the top of my head is implementing a sort of coverage "calculator" -thing. I might try coding this later in the week, since this week is going to be nuts for me.
What I'm thinking is Cube has his own type chart sort of thing. He looks at the opponent's team and assumes the most common sets at the moment. What I'd try and do is get the total coverage that said sets would get. For example, a team of Garchomp/Hippowdon/Breloom/Heatran/Landorus-T/Manectric(disclaimer: THIS IS NOT A LEGIT TEAM) would have lots of ground coverage in it's default sets but no Water coverage and a stupid amount of possible Stealth Rock setters. Cube would recognise this gap in the coverage, and would then proceed to test different sets to try and fill this gap. Using this logic, he'd give Garchomp Aqua Tail as it's the only possible Water move on the team (thus probably confirming no Rocks on him). If it gets multiple possibilities... well, I dunno. It would have to do a million tests to get the most optimal coverage, I guess, and work with that. If you incorporate this with other logical operators like Yuruuu's Stealth Rock thing, you could probably paint a pretty accurate picture of the opposing team at team preview.
A variation would be taking the common sets, seeing what Pokemon absolutely trounce the team in that state, and then decide which mon would have the best chance of dealing with said threat and go with the appropriate moveset. A million things could go wrong with that - seeing as there's like 700 pokemon or something ridiculous, chances are there will always be some kind of massive threat and then you'd just be doing calculations forever and then you'll lose humiliatingly as the timer runs out before you've even started. Even if you limit it to OU only, most teams I've seen are flat-out weak to something and you'll end up with a similar problem.
As Cube learns the sets of each mon, he can increasingly build an accurate picture in his coverage chart, and maybe even decide on likely switch-ins, getting in some of that anticipation it needs.
I dunno, it's just something I've thought of literally now and I haven't tried it, so I don't know how well it would work.