M-TTar simulation

[ottersfish]

I notice that when using mttar there's no reccomendation on where to tap, is this feature currently unimplemented or is it on going? If it's so I will try to implement one.

[Loreinator]

The problem with mttar and other tap-based megas is that there are so many options it is difficult to efficiently simulate them. It is a work in progress currently in the design phase - that is, deciding how to best simulate it.

[ottersfish]

I might be wrong in my calculation but isn't it only 36^3 possible tapping? I was thinking to save the affected cell as a 'hash' to reduce the number of simulation but 36^3 should be fine isn't it? Probably if the case was chained mttar then it probably suck up the cpu.

[Loreinator]

That's 36^3 times more combinations to compute, or around 46 thousand times more possibilities. To even hope of doing a brute force solve of each moves best taps it will need extensive pruning rules. Otherwise the results will be quite useless if it is under sampled.

On Feb 4, 2017 11:42 PM, "Fendy" notifications@github.com wrote:

I might be wrong in my calculation but isn't it only 36^3 possible tapping? I was thinking to save the affected cell as a 'hash' to reduce the number of simulation but 36^3 should be fine isn't it? Probably if the case was chained mttar then it probably suck up the cpu.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Loreinator/Shuffle-Move/issues/252#issuecomment-277497255, or mute the thread https://github.com/notifications/unsubscribe-auth/AI0RQya_htWI71vqwF8p3Erg9hebTgorks5rZVM5gaJpZM4L3J0u .

[ottersfish]

Yes, but this is only computed if icon is matched, for the worst case is 36^5 around 60M (36^2 to make the pair and 36^3 if all of them is mttar) with assumption that matching other icons will be in constant time (O(1)). But it isnt, is it? I don't know how complex to implement the matching icons but is it heavy? since if there's 60M combination it should be done under 1 sec.

If I miss something please let me know and how can I help :)

[Loreinator]

The simulation works by identifying each valid move, then simulating each move's result. If any randomness is detected in a simulation then it gets re-run for a set number of times to average out the results. I re-did the calculation, and there are 7140 ways (36 choose 3) to pick 3 tap points. Still, that's 7140 times more simulation time for those tap-involving moves. To make the simulation feasible on all systems (even those with a potato for a computer) it will need to refine the 'good' moves down a bit.

To that end, we could reduce the set of taps down from 7140 by putting in logic to ensure that the set of real options is what a real experienced player might choose. Ideally it should be brought below about 50 to ensure the averaging works out most of the time. The only problem with that, is that it is rather difficult to reduce them down without possibly eliminating great options.

[ottersfish]

If the aim is to create a program that works for every potato machine will be hard. Maybe it should be implemented first then run a benchmarking using vps I guess, easiest way to simulate in every kind of machine.

[Loreinator]

Well, I don't mean it should work well on a potato, but any typical machine built in the last 5 years should be able to run it in a reasonable time. I'll look into just how significant the performance hit would be if I go with the best guess as it stands right now.

[ottersfish]

Ah now I get clearer understanding, I see I would glad to help if is there anything I can do, I haven't read the code base yet tho so it might require bit more time to contribute here :) Regards.

Notes: as I think the issues is answered feel free to close this issue. Thank you!