Binary: TODO Source Code: https://github.com/zzymyn/TgmTasHelper - requires Visual Studio 2013 (may work in 2015 or Mono; I haven't tested) I'll keep this top post up-to-date as I make changes. Last Update: 2016-06-29 What is it? This is a tool I'm working on for my next TGM2+ DEATH TAS. It allows me to more easily try different block placements to see which results in the fastest time. My goal is to eventually get it good enough so that we as a community can collaborate to create the fastest possible DEATH TAS, basically a "segmented run" of the game. What's left to do for the tool? At the moment, File > New always results in the same initial state, need to add a dialog so this can be set by the user. Add a new UI to help find the best initial RNG state for the game. Maybe reorganize the UI a little bit and add some more keyboard shortcuts so you don't have to use the mouse so much. Hard: Completely reverse-engineer the RNG in TGM2+ to figure out how the game RNG is seeded. I have reverse-engineered the RNG once the initial state is seeded (see TgmRng.cs in the source code), but don't know where this seed comes from yet. What is a TAS? A TAS is a Tool-Assisted Speedrun. The aim is to complete a game as fast as possible, using tools that are not allowed in normal competition, such as frame-stepping and backtracking. The previous TAS can be viewed here: What is a segmented run? This is a run where each segment is run by many players, the best time is then chosen as a starting point for the next segment. For TGM, the segments would be 0-100, 101-200, etc...
Cool stuff. Have to try this out. When I read the last TAS thread I also thought about a tool like that. I never started because I do not have enough time and I would have to work out to many details, so maybe I give your code a try someday. The idea was to let the program create the whole TAS without user input. So you could try out all the different seeds to find the best one.
Creating the whole TAS without user input would be cool, but pretty HARD to do. Although Death may be easier due to the restricted piece placements.
"Hard" means it will work with a quite simple algorithm but it might either take very to long or you have to leave out some of the search space. So I was curios to find out how far I could optimize it.
No. The LCG used in all versions of TGM is not random at all, so you get a relatively small search space, which is narrowed further by the history re-roll algorithm.
AFAIK the piece sequence would be fixed. An optimal solution could pick good sequence without figuring out the placement of all 700+ pieces.
It's interesting to consider how many of the sequences are "viable" for some definition of viable. What restrictions would there be on the sequence? Stuff to consider: Where do tetrises vs singles matter? Where do low stacks matter? (Every section until 500?) What is the theoretical minimum number of pieces for each section (100-400 and 999), and is the last piece forbidden from being certain types? (Can't get triples with S or Z.) Anything else you can think of? If restrictions were defined it would be fast to search the entire sequence space for all viable sequences. I'd be willing to write such a script. I'm assuming there would still be many viable sequences. Next, of all viable sequences, we can probably do something to rank order how "fast" they are. Do the pieces have the same average active time frame cost? (O and I pieces can't wallkick for example, and I in particular is "slow" to place vertically.) Some fleshed out version of that would be a pretty darn good start.
What is is "viable" sequence? And do you need them? You can finish with any sequence. One sequence (or very few are tied) will be the fastest. You do not need any other sequence beyond this one (one of these). Only use of it would be to have a lower bound for the time, but you can do this with picking random sequences too.
I agree that there's probably just one optimal sequence. I don't think it's viable to brute force every play of every sequence just to find it though. So my post is really just talking about a tangible approach to find a nearly optimal sequence.
Yeah, if you can roughly find an ordering of the sequences, it would be possible to check the faster ones first. With this you can bail out earlier with an heuristic if you compare the progress to the best solution found yet.
