One of the problems with working on a project with no definite budget, delivery date, or explicit project management is that the project will continually trip over its own iterations of design with no cut-off to make something be a product rather than merely the latest version to be torn to shreds by the quality assurance people. In this case, the play-testers. Which might explain why I'm so reluctant to spend money on a proto-type at the moment, because I'm doing everything wrong. Well, not everything, but everything that makes a game connect with a commercially viable audience.
The first thing is, interestingly, my ability to communicate what the game is about. In part that's because I've attempted to communicate that to people who have their own opinion of what the game should be about. It's not unusual to find that an audience, and particularly play-tests, feel that they know the game better than the guy designing it, and that's because they have the emotional distance from the project to assess it more objectively. Also, because they are the audience and what the audience wants is rarely what the performer wishes to convey; that's the thing about communication, discovering what it is the audience wants to hear and then adjusting the message accordingly. I really do mean adjust: As a communicator I really need to squeeze my content into the structure of audience expectations, and it's something I find really cramps my style.
In part it's because I don't like my audience for the project I want to communicate, and that's a bad attitude to take. The other problem is that I don't particularly like the project I'm working on. Yes, I like playing games, and playing games with the people I've used for usability-testing and editing, and I like the idea of giant robots fighting each other, but...
I'm in the business of making things transparent. Good technical writing, for example, is conspicuous by the fact that users should not notice that it is good. Instead, good technical writing should ensure that the user remains be pre-occupied with accomplishing whatever task the documentation is supposed to enable them to accomplish. Technical writing fails when it fails to help the user accomplish that task, and hence when the user throws the documentation across the room in frustration because it either lacks the content necessary to accomplishing the task at hand, or makes it too difficult to access that content.
Likewise, a good game should have players thinking about strategies, tactics, and all the things they can do within the parameters of the game, rather than wondering about the work they need to do to implement the game, and the mechanics involved in that work. Despite the fact that board games, including table-top wargames, require the players (or some third party) to implement all of the operations involved in running the game as well as the operations involved in playing the game, they do have a definite front-end (tactics, game-experience, models, boards, widgets, etc) and a definite back-end (processes and procedures, etc). The back-end needs to be transparent so that all players think about is the front-end, or the experience of the game.
The art of board games is, in my illustrious opinion, the art of mixing the front-end with the back-end so that implementing the operations required to implement the game is indistinguishable from playing the game. Many games succeed in doing this, and others do not, and do not let that 'clunkiness' interfere with their success because their users, their players, have been trained to expect slogging through a miserable, confounding mess of rules to be a perfectly satisfying form of play.
Which is why I'm having second thoughts about the direction that my Titanomachia project has gone, in that no one I have involved in play-testing has talked about the experience of playing the game. Usability testing always breaks down into discussions of what people want to be able to do with cards or models, or what other games have done with cards or models, and rarely any discussion of what is being accomplished with those elements. I'm inclined to suggest it's like handing someone an iPad and having them say that they would love to have it in cornflower blue, or perhaps with a keyboard and a way of mounting it like a monitor, or perhaps wondering if they can run Windows on it, which in all cases I hope to make the point that having been sold in trying a giant robot game, I have yet to experience feedback indicating the game has had any impact on a user's imagination. I have, it seems, failed to capture the spirit of giant robot combat, and the spirit of card-driven miniature gaming to boot!
Which makes me think several things: (1) My approach using cards and models as the back-end, despite being calibrated to a fairly low attention space and so on, distracts from what I'm trying to accomplish with the front-end; (2) My approach in communicating the objectives of the usability testing needs considerable work if the feedback I'm getting is back-end oriented, rather than front-end oriented; and (3) My disorganized approach to producing what I want to be a fantastic product is sabotaging what could simply be good enough.