BoardSpace.net

[AdamS]

OK, I've fired up the Hex game and can play! Generally looking good, although one minor glitch.

I don't believe I have changed a thing yet, but I keep seeing the following error (it does not terminate the game or appear to have any adverse affect on play). The error itself is in the super class which I don't think the source is included for in what I've got access to.

I can see that I could comment out this error checking code, but it seems best to check in case it indicate a more serious problem.

Thanks
Adam

[admin]

This is a common thing to see during development of a new game, but you shouldn't be seeing it with the sample. Bugs are always possible of course.

Generally speaking, here's what's going on. After every move/ gesture, some machinery creates a duplicate game board, replays the entire game, and verifies that it gets back the "same" game that it started with. This execises huge amounts of the machinery in the game to create, copy, execute moves, compare two boards and so on. The purpose of doing this is to catch any problems as soon after the gesture that caused it as possible. In the live system, information you're seeing, plus more, is logged. In your development environment, it's just an opportunity to debug.

Two built in debugging aids for this situation:

Use the actions/show raw output menu item. It shows the official game log followed by a slightly annotated long. This should have recorded exactly what sequence of gestures you did, so you can do it again.

Use the options/show alternate board menu item, this switches fhe main board display to the copy that came up wrong. You frequently can see exactly what's different.

I generally run with Eclipse set to invoke the debugger on java errors. All the internal error reporting and consistancy checking starts by throwing java "Error" with a message. It's useful to intercept the error in the debugger rather than let it be thrown.

[AdamS]

Thanks for all the tips.

Well it seems to work perfectly when I try again today! I guess I'll never find out what the original problem was.

[AdamS]

I can now reproduce the bug reliably:

- Start a new game from Eclipse
- Don't yet click start for either player (i.e. stay in edit mode).
- Put a stone on the board.
- Put it back into the pool.
- Click start player 1.

In fact any sequence involving putting a stone back into the pool in edit mode hits the bug. The problem is that EditHistory discards MOVE_PICK and MOVE_DROP. Whilst this is fine in normal games, it breaks in edit mode, and any edit to remove a stone back to the pool fails to get into the history.

[admin]

Yes, the logic in the MOVE_DROP clause of the editHistory method
needs to be more comex to both leave the history tidy and consistent.
It will be fixed in the next update of the kit.

-- this illustrates the problems implied by editHistory nicely - you have
to anticipate all possible sequences of gestures, and not over-prettify the
history.