1
Discussion / Re: Theorycrafting! (Because I like competitive metagames too much)
« on: January 18, 2016, 06:01:42 AM »
Interesting bugs... never knew they existed.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
2
Discussion / Re: Theorycrafting! (Because I like competitive metagames too much)
« on: January 13, 2016, 09:42:03 PM »
The points from the chain reaction are calculated using the _get_points() function from the Match class. It is equal to OriginalPoints * (2^Chain). Right now my algorithm delays 250 milliseconds for every chain level, so
"Good Job" results in 1/4 second delay, "Fantastic" 1/2 second, etc. The appropriate delay time would vary based on the lag. My algorithm does overcreate match possibilities. Out of all the possible moves it generates, only about half of them can be made concurrently without conflicts since making some moves will invalidate others. Currently the bot does not try to reset the board.
Right now each "cycle" (which involves screen grab -> OCR -> decision -> make move) takes about 200 - 250 milliseconds. Breakdown is as follows:
Screen grab -- 150 ms
OCR -- 20 ms
Decision -- 30 ms
Make moves -- 10 ms
So screen grab takes the most of the time. 7 screenshots a minute isn't really that fast, I'd rather prefer 20 but it seems unlikely. I'm currently using pyscreenshot module for this which is the fastest library I could find. I tried other ones but they were 2-3x slower.. I think I could definitely speed up each cycle to 100-150ms if I either rewrote the bot in a faster language like Java, or ran it on Windows with a faster computer (I'm currently using a 1.7 GHZ ultra-low-voltage processor which obviously don't help).
Here's a video of the bot in action: https://dl.dropboxusercontent.com/u/32170031/StarJeweled.mp4
"Good Job" results in 1/4 second delay, "Fantastic" 1/2 second, etc. The appropriate delay time would vary based on the lag. My algorithm does overcreate match possibilities. Out of all the possible moves it generates, only about half of them can be made concurrently without conflicts since making some moves will invalidate others. Currently the bot does not try to reset the board.
Right now each "cycle" (which involves screen grab -> OCR -> decision -> make move) takes about 200 - 250 milliseconds. Breakdown is as follows:
Screen grab -- 150 ms
OCR -- 20 ms
Decision -- 30 ms
Make moves -- 10 ms
So screen grab takes the most of the time. 7 screenshots a minute isn't really that fast, I'd rather prefer 20 but it seems unlikely. I'm currently using pyscreenshot module for this which is the fastest library I could find. I tried other ones but they were 2-3x slower.. I think I could definitely speed up each cycle to 100-150ms if I either rewrote the bot in a faster language like Java, or ran it on Windows with a faster computer (I'm currently using a 1.7 GHZ ultra-low-voltage processor which obviously don't help).
Here's a video of the bot in action: https://dl.dropboxusercontent.com/u/32170031/StarJeweled.mp4
3
Discussion / Re: Theorycrafting! (Because I like competitive metagames too much)
« on: January 13, 2016, 07:44:04 AM »
Actually I'll just post the bot code here in case anyone's interested in taking a look. It's open source on Github.
[Admin note -- link deleted ~mc]
[Admin note -- link deleted ~mc]
4
Discussion / Re: Theorycrafting! (Because I like competitive metagames too much)
« on: January 13, 2016, 07:37:23 AM »
Bot is written in Python and uses the following modules: pyscreenshot, autopy, itertools
All testing was done in a 13" Macbook Air with 1.7 GHz i7 (Haswell) and 8GB RAM, running at 1440x900 resolution and medium graphics
Algorithm:
1. Take a screenshot of the 480x480 gem grid using pyscreenshot and store it in memory
2. Go over each gem (60x60 square pixels) and calculate the average RGB value of 20% of the pixels (spread evenly)
3. If the RGB values fall within a given tolerance, predict the color of the gem (right now, this is almost 100% reliable if no gems are falling or text is on the board)
4. Return a 2D list representing the colors on the board
5. Given this 2D list, find all pairs (eg: two gems together vertically or horizontally, or two gems with a gap in between)
6. For each pair, find a gem that can be moved next to it to make a group of at least 3. If it exists, then add it to the move list
7. Go through the move list and calculate a score for each move (Score = Points Gained + Moves Created * 5)
8. Order the moves based on score, from best move to worst move
9. Process all these moves in order by moving the mouse and clicking
Currently some flaws with the algorithm are that some moves can conflict with each other and they are not removed from the move set (however, conflicts don't seem to be too costly in terms of EPM performance), and we don't wait for chains of gems (eg: swapping two gems and then having a match after the gems fall), so this lowers EPM.
All testing was done in a 13" Macbook Air with 1.7 GHz i7 (Haswell) and 8GB RAM, running at 1440x900 resolution and medium graphics
Algorithm:
1. Take a screenshot of the 480x480 gem grid using pyscreenshot and store it in memory
2. Go over each gem (60x60 square pixels) and calculate the average RGB value of 20% of the pixels (spread evenly)
3. If the RGB values fall within a given tolerance, predict the color of the gem (right now, this is almost 100% reliable if no gems are falling or text is on the board)
4. Return a 2D list representing the colors on the board
5. Given this 2D list, find all pairs (eg: two gems together vertically or horizontally, or two gems with a gap in between)
6. For each pair, find a gem that can be moved next to it to make a group of at least 3. If it exists, then add it to the move list
7. Go through the move list and calculate a score for each move (Score = Points Gained + Moves Created * 5)
8. Order the moves based on score, from best move to worst move
9. Process all these moves in order by moving the mouse and clicking
Currently some flaws with the algorithm are that some moves can conflict with each other and they are not removed from the move set (however, conflicts don't seem to be too costly in terms of EPM performance), and we don't wait for chains of gems (eg: swapping two gems and then having a match after the gems fall), so this lowers EPM.
5
Discussion / Re: Theorycrafting! (Because I like competitive metagames too much)
« on: January 13, 2016, 07:29:39 AM »
It seems like I don't have the ability to make new threads so I'll just post this here.
I recently returned to SC2 (again) and got interested in a new arcade game called StarJeweled. It's basically Bejeweled with SC2 units added in. I don't really enjoy playing the game itself though... matching groups of gems repeatedly gets boring and I'm not that great at the game (I average around 1200 EPM). But I found that I really enjoy making a robot to play the game for me.
Currently my bot (written in Python) averages around 3500 EPM, give or take 500 energy depending on luck. And it seems like I've hit a plateau at 3500. I've spent a good amount of time trying to come up with a better algorithm to improve the bot's performance to the mid 4000s range, with no luck. The current algorithms I've come up with involve thinking multiple moves ahead, but they're way too slow and actually end up cutting the performance in half (1700 EPM, yikes) instead of improving it.
I'm curious anyone on these forums have made a StarJeweled bot before that has broken the 4000+ EPM barrier or is interested in helping to come up with a better algorithm.
I recently returned to SC2 (again) and got interested in a new arcade game called StarJeweled. It's basically Bejeweled with SC2 units added in. I don't really enjoy playing the game itself though... matching groups of gems repeatedly gets boring and I'm not that great at the game (I average around 1200 EPM). But I found that I really enjoy making a robot to play the game for me.
Currently my bot (written in Python) averages around 3500 EPM, give or take 500 energy depending on luck. And it seems like I've hit a plateau at 3500. I've spent a good amount of time trying to come up with a better algorithm to improve the bot's performance to the mid 4000s range, with no luck. The current algorithms I've come up with involve thinking multiple moves ahead, but they're way too slow and actually end up cutting the performance in half (1700 EPM, yikes) instead of improving it.
I'm curious anyone on these forums have made a StarJeweled bot before that has broken the 4000+ EPM barrier or is interested in helping to come up with a better algorithm.
Pages: [1]