but you still need a mistakeless representation. Isn't something like this a use case where you are lost without TDD?

I really fail to see why you think that particular example is amenable to TDD, or unamenable to any of the other non-test-driven development methodologies?

Nor why a game's internal data representation should be any more "mistakeless" than that of an automated drug dispenser, or a traffic control system, or fingerprint matching algorithm?

But as you've chosen that example, here's a little thought experiment for you. You are charged with writing a replacement board representation: write your first test.

Chances are, you simply haven't a clue where to start; and you'd defend that by saying that you need a specification.

But how do you write a specification for something you have no idea how to write? So maybe you read this (if you haven't already). So, now you know a little about the possible representations and requirement of them, so write that first test. Once again you (probably) cannot.

One thing I can guarantee, Robert Hyatt didn't use TDD back in 1968, and -- having read a few of his papers -- I doubt that, even given his 50 years of experience and knowledge, that he used it when they switched from rotated bitboards to magic moves circa 2004.