Voltorb Flip Solver Program - In Need of Crowdsourcing for improvements!

[DeltaLogic]

So one day I was strolling around GDC and decided, 'ya know what, I want an Axew'

little did I know it was behind a 30k coin wall, and me being the stingy being I am decided my poke$ would be best spent elsewhere so I'll play voltorb flip until I can get it!

 

Now I'm a patient person... but not that patient, so I decided my time would be better spent making a program do the work for me!

I present to thee, the flipper bot...

And its not bad!

pretty consistently gets me up to level 4/5 before hitting a bomb but its decision making is much faster than mine (the video is slowed down a bit by my recording software and sleep timers but its actually fairly fast!)

However, this post is not simply to brag, no no no.

I wish to improve the flipper bot.

Into a FLIPPERTRON 3000!!!

 

and I seek help.

 

Currently its decision making is very basic. It doesn't work out probabilities or anything fancy, it first picks all the safe options, then it selects the lowest risk, highest reward tile based off the number of bombs then points in all the columns and rows, I struggled to find any of the maths behind VoltorbFlip.com or the other online solvers while scouring the web, and so I present a half baked program to the community in hopes you bright sparks can improve on it!

 

P.S. This program is designed specifically for my setup and hasn't been tested on other devices, in theory, it should work for anyone running the game in large with a 1920x1080 resolution screen, but otherwise you'll have to edit alot of values to make it work. (sorry not sorry, its 00:30am)

SetTheStage.py

[R.B]

Cool program; I think you can get significant improvements without much math by randomly generating boards that satisfy the row and column constraints and using those for a simple estimate of which tiles are safe.  

[DeltaLogic]

On 12/14/2021 at 3:53 AM, R.B said:

Cool program; I think you can get significant improvements without much math by randomly generating boards that satisfy the row and column constraints and using those for a simple estimate of which tiles are safe.  

So...

I got carried away...

I now have 24 files listing every possible combination of a board with the known number of bomb (you can tell this by summing the number of bombs in the rows or columns).

And a program which checks every possible combination and then gives me a probability of a bomb being in a spot.

 

BUT IT STILL MAKES MISTAKES.

 

AND IDK HOW TO FIX IT.

 

 

so this output is one of its decision tables, here's an explanation:

 

The Bottom table:

is the board on the screen, literally a read in of the current board.

'o' marks a spot that is either a bomb or a one and therefore pointless...

1, 2, 3, mark where a tile has been flipped over and its actual score...

and 'None' are tiles that haven't been flipped over yet, I.e, the spots the program needs to analyse to see if they could be bombs or points.

so far so good

 

The Middle table:

This is the a table showing all the possible combinations of bombs given the current layout of the board, and the respective weight of a bomb being on any given tile.

For example: of the 2,042,975 possible 5x5 grids with 9 bombs on, there are exactly 167 configurations which could produce this exact board of bombs (ignoring the points)

of these 167, exactly 93 configs have a bomb in the slot 2, 3 and exactly 69 configurations have a bomb in the spot 5, 3. Nice. This is fine and dandy!

 

what is not dandy though is that this does not make sense when you consider there are points involved.

 

Lets look at column 2 for example:

We know:

slot 1 = 2 points,

slot 2 = 3,

slot 3 could currently be anything

slot 4 is a bomb or 1,

slot 5 = 1 

The total points for this column is 8, and bombs 1.

Cool... Except not really.

Because this means that we know slot 3 = 2 and slot 4 is a bomb!

Otherwise its impossible to make up the 8 points!

And I don't know how to code this!

So my code picks slot 5, 3 instead because less configs have bombs there!

SPOILERS: IT WAS A BOMB.

Send help!

I need it!

please! :)

 

it took literally 24hrs of runtime to generate all the permutation files btw.

and it couldn't be run multithreaded because you can't write to multiple flies simultaneously...

:) :) 

[DeltaLogic]

1 minute ago, DeltaLogic said:

So...

I got carried away...

I now have 24 files listing every possible combination of a board with the known number of bomb (you can tell this by summing the number of bombs in the rows or columns).

And a program which checks every possible combination and then gives me a probability of a bomb being in a spot.

 

BUT IT STILL MAKES MISTAKES.

 

AND IDK HOW TO FIX IT.

 

 

so this output is one of its decision tables, here's an explanation:

 

The Bottom table:

is the board on the screen, literally a read in of the current board.

'o' marks a spot that is either a bomb or a one and therefore pointless...

1, 2, 3, mark where a tile has been flipped over and its actual score...

and 'None' are tiles that haven't been flipped over yet, I.e, the spots the program needs to analyse to see if they could be bombs or points.

so far so good

 

The Middle table:

This is the a table showing all the possible combinations of bombs given the current layout of the board, and the respective weight of a bomb being on any given tile.

For example: of the 2,042,975 possible 5x5 grids with 9 bombs on, there are exactly 167 configurations which could produce this exact board of bombs (ignoring the points)

of these 167, exactly 93 configs have a bomb in the slot 2, 3 and exactly 69 configurations have a bomb in the spot 5, 3. Nice. This is fine and dandy!

 

what is not dandy though is that this does not make sense when you consider there are points involved.

 

Lets look at column 2 for example:

We know:

slot 1 = 2 points,

slot 2 = 3,

slot 3 could currently be anything

slot 4 is a bomb or 1,

slot 5 = 1 

The total points for this column is 8, and bombs 1.

Cool... Except not really.

Because this means that we know slot 3 = 2 and slot 4 is a bomb!

Otherwise its impossible to make up the 8 points!

And I don't know how to code this!

So my code picks slot 5, 3 instead because less configs have bombs there!

SPOILERS: IT WAS A BOMB.

Send help!

I need it!

please! :)

 

it took literally 24hrs of runtime to generate all the permutation files btw.

and it couldn't be run multithreaded because you can't write to multiple flies simultaneously...

:) :) 

Here was the board btw

 

[Jolteon0]

I wrote something similar a while back.

https://github.com/DDriggs00/VoltorbFlipCalculator

Feel free to copy some/all of the math from this (it's MIT Licensed). It basically restricts what can be done using a *lot* of math, then brute forces it from there. All the actual work is done in C++, and the app just uses JNI to pull the data and export it as a usable format.

 

Edit: This also looks promising:

https://github.com/forrestbicker/VoltorbFlipSolver

Edited December 21, 2021 by Jolteon0
Added additional data

[Cyphre]

The problem i always had with VF is the fact that eventually in every attempt you WILL inevitably encounter the 50-50 situation, the bomb is either here or here. It WILL happen, cannot avoid this. And in those cases no program or decisionmaking skills can help you, just a literal coin toss and blind faith. 

 

That said i do hope you can work it out to be a better version of existing sites.

[DeltaLogic]

So I decided to simply introduce a line that checks if a potential spot is the only potential points spot on its row or column and er... I think that fixed it?

I put it on loop and in ~50 minutes, it played out 118 games win 71 wins and earnt ~22,000 coins.

Meaning it averaged:

• 186.4 coins per game which means it was roughly staying just around lvl 3/4.
• 26,400 coins per hour, much better than I can do tbh.
• 141.6 games per hour.

So overall I would say that was pretty successful! I now have around 56k coins so don't really have a use for it after all the testing it took to get here...

But oh well! This was a fun project and I'll leave the code in a github below.

https://github.com/DeltaLogic010/RejuvVoltorbFlipper

It is worth pointing out that sometimes the pixelreading misreads the top right point counter for some unknown reason and this will cause the code to crash (hence why it stopped after 50 minutes). Currently no Idea why and literally stopping the code, resetting the position to the top left most position manually and restarting it fixes the issue. I and my new Axew are also no longer invested in this code enough to work out and fix it. But if you want to use the code to get your own Axew in just over an hour, I felt like I should mention it.

 

Now I want to say thank you to the kind commenters who helped me get here, you did certainly help me optimise the code quite drastically.

I also want to leave some things I learnt about the Rejuv VF because it is not the same as the main game series as far as I can tell by looking at the wiki, first, each round has 5 + the level Voltorbs, tested up to round 8, meaning it doesn't cap out at 10 voltorbs like the main series games. Also the points are in ranges, i.e. Level 1 gives 24, 35 or 48 coins when completed, Level 2 gives 54 - 96, 3: 108 - 192, 4: 192 - 288 which means you can get the same number of points in Level 3 as 4 if you are lucky/unlucky. Ultimately these aren't massive differences and you probably wouldn't notice them unless you are trying to code for them, but something to keep in mind if you are trying to code based off the game mechanics listed in the Wiki.

 

And there we have it!

Journey over!

I hope that this endeavor of mine can help someone else, even if it only ends up being 1 dex hunter in a rush with enough knowledge of coding to use it and not enough time to make their own, it'll be worth it.

~Delta