yufeiliu / mirroruniverse Goto Github PK

Put all the configurations in the tournament in the game config file so it's easy to test manually.

We don't do that well on the spiral board because of the way the board is structured.

Right now, it's a little slow and uses too much heap space.

Ideas: micro-optimizations where appropriate, only consider "relevant" subsection of the graph.

You mentioned that this needs to be done, so I'm adding this here.

On

1, 30, 2, -1, maps/g7maps/map_50_50_illusion_1.txt
1, 30, 2, -1, maps/g7maps/map_50_50_illusion_2.txt

we get stuck in a corner.

Only create states as needed. This introduces a lot of GC overhead, but I think it's the only solution that preserves optimality. This requires a lot of modifications to the DFA stuff, so this will be done on a separate branch.

If the DFA can't solve it and we've explored everything, we should be able to step on the exits. Probably just get both players close to the exit and find the shortest path for one of the players or something like that. Thoughts?

Sometimes it things a suboptimal solution is optimal. Can't repro consistently. Using:

35, 35, 2, 6, 0.4, 5
35, 35, 2, 7, 0.2, 6

gets it to fail sometimes.

We must do this before launch.

The optimized DFA doesn't do this right now.

sometimes it gets stuck in circles. I'm thinking of adding a way to detect if both players have been confined to a fixed radius for several turns. if so, take random walk to get out of it

Make sure to merge master to see updated comments.

they are currently in the new_exploration branch in maps/g6maps/

Cap number of expanded states

Solve for one, then the other.

We also need to recompute solution more often. It should be recomputed before we step on an exit. Right now, I think if we don't find a perfect solution, we're returning null and then solving for each individually.

There's a bug in exploration. We very frequently go over the same few spaces even though it doesn't uncover everything new. I guess this is the random walk issue.

I tried running it on

1, 30, 2, -1, maps/g2maps/PipeMaze_A_51_12.txt
1, 30, 2, -1, maps/g2maps/PipeMaze_B_51_12.txt

and got results between 290 and 3250. If you look at the player in the worse runs, there are a ton of wasted steps. If we can fix the random issue bug we'll be in pretty good shape (at least on that map).

It's in Utils. See comments for details about the contract I expect it to fulfill.

Not sure if this is currently handled, but it needs to be. I can't test given the current bug.

We might want to make a map with this property if one isn't submitted with this property already.

Only create states as needed. This introduces a lot of GC overhead, but I think it's the only solution that preserves optimality. This requires a lot of modifications to the DFA stuff, so this will be done on a separate branch.