https://github.com/ThunderAxe31/DankBot
This is a customizable bot mostly thought for RPG games. It relies on a system that does automatically manage branching and progress through the resulting best iterations, while gradually discharging the slower ones. It's similar to Monte Carlo tree search, with the main difference of not using backtracking. Instead, it relies on the generation of multiple branches that are likely to be able to lead to the desired result. In case of failure, the script will display where and why a botting session failed, in order to let the user to be able to figure how to improve the usage of the script, by properly editing the route.lua file attached.
In order to use the script, put it in a folder together with an appropriate route.lua file, and launch it in BizHawk after having opened the movie file that will contain the TAS that will be created. It automatically saves progress, so you can stop it at any time by closing the script, and resume it by launching it again. A file named resume.lua will be automatically created with the data necessary, along with the relative savestate files in the same folder. For this reason, it's suggested to use this script in an empty folder.
All the actions executed by the bot will be decided by the route.lua file, which will contain all the game-specific data and actions to attempt and optimize for the desired TAS to create. The use can use a different route.lua file for each TASing project, it doesn't matter the game or the platform, as long as all the necessary informations are properly coded inside. In order to learn about how to write a compatible route.lua file, see the example files. Every event worth of note will be both printed in the Lua console and written to a log.txt file, so that the user can follow closely the botting session progress.
2-do:
Smurfs Nightmare, The (EU) GBC 10%
fin :
Mega Man: Dr. Wily's Revenge improvement: submitted
Mega Man II Improvement: submitted
Mega Man IV Improvement: submitted
Mega Man V Improvement: submitted
future plan:
-n-
Would this work with FFVII NES? I honestly don't understand how this works.
I'm not familiar with that game, but it shluld work. And yeah, I see that there are a lot of explainations needed, and I will need some time to elaborate stuff. I'm also busy with a lot of other stuff lately, so please wait...
DankBot Treeview, a linked side script that generates a graphic output, in form of .BMP file, for illustrating some useful botting data, in an elegant and comfortable way. This helps in seeing which parts of the route.lua script may be optimized, by removing unnecessary additional waits or by adding more savestate slots for specific actions.
There are also some minor implementations:
Display the amount of frames wait for each savestate generated, in both text log and graphic view
Introduce ability to set a minimum amount of frames to wait for each action attempt
Make check_freeze() compatible with argument-less functions
Minor improvements of code readability and text log messages
Since GitHub isn't the proper place for deep philosophical reasoning, I wanted to give some more extensive explanations in this forum instead. Specifically: What, and Why?
First of all, here is an example of .BMP file automatically generated by my new script, DankBot Treeview (click for zoom):
Strictly speaking, all the information we can get from looking at this image, we can also get from the text log, which is a feature available from day 0. So you may ask, what's the point? Well, take a quick look from text log generated from the same botting session: https://pastebin.com/5XH3efPv
As you can (not) see, there is a lot of stuff that is really hard to figure out from the text log, which instead can be instantly observed from looking at the graphical equivalent. These include:
Which savestate generated which savestate (hence the Treeview name)
Which road was took for generating the fastest final savestate (smallest framecount or cyclecount)
Which savestates lead to dead ends
How many savestates have been used out of how many slots available
Which is the smallest amount of frame wait for an action
Which is the biggest amount of frame wait for an action
What is the overall amount of frame wait for an action
All right, so we now get to the answer to the bigger question: why, and why colored?
Let me start by telling you that the main goal I've desired to achieve with this project, is having a botting framework that can be not only flexible, but also performing. For this reason, I've figured out as many ways as possible to avoid redundant or less useful iterations for the botting sessions. Additionally, I also developed the ability of resuming a suspended session, so that you don't need to keep your PC working continuously for weeks straight, and live with the fear of power outages. Also, it allows the user to change the route.lua settings without having to restart the session from the beginning. However... It is completely useless if your emulator doesn't support any way for automatically storing persistent savestates (or movie files) by Lua functions. In other words: FCEUX. It was a very ugly discovery for me, since I own a very old pc and FCEUX is much faster than BizHawk. So which choices do I had? The first and most obvious choice was just to give up. The second choice was to go around ranting and whining about FCEUX being bad (and still getting nothing). I didn't like either of these, so I've come out with another idea, yet a very stubborn one: making DankBot even faster. But how do I do that? Well, I soon noticed that by tweaking out the right settings in the route.lua, I can optimize the sessions by excluding more of the useless play routes. The only issue was that it was very complex to figure out, since each situation is completely unique and requires an ad-hoc solution. But I had an idea: what if I could "see" the whole "picture" of a botting session? That would make it much easier to figure out which routes are less useful, and which routes are instead more promising. That way, it's possible to avoid routes that lead to overall slower results, while also be able to focus more on routes that are more likely to make a faster TAS. Which gets to why I've coded it to make the table cells colored. You see, each color shade corresponds to a specific wait amount, from 0 to 51 (beyond 51 is just red), so that allows to quickly see how much hard it is in-game to meet the requirements for that that specific action (example: performing a critical hit while also getting the enemy to miss). Lastly, there is one blue line among the rest of the tree: that indicates the road for fastest final savestate, which is what the resulting TAS will consist of, unless you manage to beat it in subsequent sessions by figuring out better settings for the actions list in the route.lua, which is also something that from today will be easier to do, thank to DankBot Treeview.
TL;DR: Graphical output allows you to make the bot faster while also making a faster TAS. Quoting myself: "we're not optimizing movies anymore, instead we optimize movie optimizers."
Next time I'll bring you some extensive route.lua examples, with proper explanation, so that everyone will be able to figure out themselves how to use DankBot. See you again!
Edit: bad news... when the image gets too big FCEUX runs out of memory, so I'll have to rework a lot of code. On top of that, I also noticed a bug with the tree drawing logic.
Edit: good news, I fixed everything! Get the new version here: https://github.com/ThunderAxe31/DankBot/releases/tag/v3.1 I also updated the example image above. Enjoy!
Nice idea. I'm looking at your example route file, and I'm wondering: how would I make the bot try every combination of A, B, Dpad for 1 frame, then if fail after every combination was tried, extend it to 2 frames, and so on? Outside making multiple route files for every frame length that is.
Strictly speaking, all the information we can get from looking at this image, we can also get from the text log, which is a feature available from day 0. So you may ask, what's the point? Well, take a quick look from text log generated from the same botting session: https://pastebin.com/5XH3efPv
As you can (not) see, there is a lot of stuff that is really hard to figure out from the text log, which instead can be instantly observed from looking at the graphical equivalent. These include:
