Score:1

# Hiding/Obscuring position information in a board game (Part 2)

This is basically a follow-up question to Hiding/Obscuring position information in a board game which technically answered the question, but raised some well deserved critique.

To quickly summarize the question: Consider a board game with a rectangular 10x10 grid, the player has a position $$(p_x p_y)$$ and a physical token on this grid. Additionally one or more AI opponents roam the board but have no physical token that the player could observe. The question now is if there is a way to tell the player if he is within distance $$d$$ of any AI without disclosing the actual location of the AI. From a game perspective the only interesting distances are $$d=0$$ (AI has "found" the player) and an arbitrary, "close" distance of $$d<3$$ (AI is near the player and he can avoid or engage it).

As this is a board game, no computer is to be involved. All calculations have to be performed by the player (ie have to relatively simple). The (accepted) answer to the previous question involved hashing the players and AIs position, but this would of course disclose the position of the AI to the player.

In the answer I wrote up on the BGG forum, I "pre-scrambled" both the players and the AIs position, obscuring the relationship between $$(x,y)$$ position and the numbers that get hashed to "lookup" the distance. The critique was that any observant player would quickly find out that the pre-scrambled AI numbers corresponded to locations on the map.

My "solution" to that would be to obscure the relation between input and output further, by having only using the current turn order and player field id as the input, effectively hiding the current AI locations behind the turn number.

Still, I feel like there might be a clever scheme to disclose just the current distance (or "something is close") to the player without disclosing the actual AI position. Having the game playing out in a heavily distorted coordinate system or similar.

I would be interested in what you guys can come up with.

What capabilities does the "AI" need to support? Does it make decisions? Move only only a predefined path?
@bmm6o For simplicity's sake I would say the AI just needs predefined paths, think patrols.
How is this different from the last question?
@bmm6o The last question could be understood and was answered as in a way that had the player input the AIs position into the hashing function. If the goal is to hide the AIs position from the player this does not really make sense.
Does this answer your question? [Hiding/Obscuring position information in a board game](https://crypto.stackexchange.com/questions/98226/hiding-obscuring-position-information-in-a-board-game)
@bmm6o I was just going to say that somebody complained there that the answer there does not really answer the underlying question. That was you :-) ... You are right, it does not answer the question in intent, exactly for the reasons you stated. But it does answer the question that I asked and I did not want to move the goal posts after I accepted the answer.
Sorry, that link was auto-inserted when I voted to close this question as a duplicate of your previous one. I also don't understand how that other one answers your question, but the questions are the same and that one has an accepted answer. I don't know what you mean by moving goalposts. You didn't change the question after you got an answer, did you?
@bmm6o You were correct in identifying the flaw in PaulUszak 's answer. Do you think I should unaccept his answer, clarify your critique in the question and delete this new question?
Score:0

The big challenge is how to advance the AI. You could have the AI follow one of several strategies which will be listed in some coded positional notation.You can use more than one, so it's harder to memorize them. Also you probably want the encoded positions to be slightly longer the truely needed. Say make them letters even if you have only 100 values.

You then need a lookup table between the pair of known position and scrambled position to the distance metric(match,near,far). You sort it first by known position than by keyed position so when looking up a location you you may accidentally see the answer for other encoded locations but not for nearby true board locations.

You may also make it harder to scan.the whole index accidentally with physical measure. E.g print the answer obscured so it is only legible when viewed through a small filter possibly even have a few different filters to match e.g last letter of the encoded location. This slows down the lookup.a bit and.ensures we lookup one.value at a time.

Make the encoded.locations map a simple piece of paper so you can ship a dozen different ones so each game is different and if you somehow managed to memorize all of them just go on line.and print out a bunch of new ones.