Having achieved non-trivial, working JUnit tests, I thought I could spend some time improving the UI/UX of my game. Several frustrating hours later, I’m not sure this was a good idea.

Poor UI/UX
The ‘working’ version first asks the user if s/he wants to restart a saved game, and warns him/her that if there isn’t one, a brand-new game will be started. This is presented as a bog-standard yes-no dialog.

On choosing ‘No’, i.e. the user is presented with the first representation of the swamp in a very plain dialog. The user’s only choice is to click ‘OK’ (or force-quit).

Clicking ‘OK’ forces the program to redraw the swamp after the ogre has moved and potentially been joined by an enemy. The user is offered the choice of seeing the creatures move again (by clicking ‘Yes’) or saving the game (by clicking ‘No’). Again. it’s a standard yes-no dialog.

Clicking ‘Yes’ here does make the creatures move as they should. Clicking ‘No’ refreshes the view of the game-state that will be saved. Here’ the user’s only choice is again to click ‘OK’. Doing so terminates the program quietly, cleanly and boringly!

Should the user initially have chosen to restore a saved game, the saved state is displayed, again in a plain dialog with just an ‘OK’ button. Clicking ‘OK’ brings up the yes-no-dialog where the user can carry on moving the creatures.

Road to nowhere
This seemed poor – I wanted to offer the user some kind of menu. It’s easy to create a dialog with text offering numbered choices and a space for the user to type his or her choice. It’s fairly easy to trap invalid numeric input and force the user to re-enter a choice. Alternatively, if the user enters a non-numeric choice, it’s possible to use exceptions to trap this. However, trying to account for users entering random strings of differently incorrect choices led me into a merry hell of nested do-while loops.

So nearly!
Then inspiration struck – while looking for ways of replacing the standard icons in Java dialog boxes, I’d seen a way to ‘doctor’ standard ‘yes-no-cancel’ dialogs with my own text. So I could do away with needing to trap poor user input by offering buttons for ‘I don’t want to play at all’, ‘play a brand-new game’ and ‘restore saved game’. Setting this up took a fairly short time, and so I set about testing whether my better-UI/UX game worked.

The brand-new game worked as it should. Saving and recalling seemed to work, so I set about doing more rigorous testing: starting a game, saving it, recalling it, saving it again, terminating the app, restarting the app, recalling the game…

Hmm – not quite right. In any recalled game, regardless of whether or not the app was terminated and restarted, the ogre intermittently ignores 1 or 2 immediate enemies. Sometimes 2 immediate enemies will kill him, as should happen. Sometimes he kills one of them. If there are three immediate enemies, he may kill one of them or two of them may kill him while the third is ignored. If there are four, the ogre is definitely killed.

Bah encore
So I thought I could go back to the early, ‘working’ version of the game which didn’t have this fault. WRONG! The fault is there – I’d just not tested thoroughly enough at the time! It appears my choice is not ‘working but poor UI’ or ‘intermittently faulty but better UI’. Instead, it’s ‘intermittently faulty but poor UI’ or ‘intermittently faulty but better UI’. So the choice is easier – big hairy wow.

I have to start writing up tomorrow to have time to create a decent report for the end of Tuesday. We also have to demonstrate our programs working on Tuesday afternoon. The lecturer has to see 20 programs and interview their creators in 2 hours. So there’s a chance he might not see the fault. (I’m not relying on this!) I’m wondering whether I should point out the fault and/or mention it in my report.