Trial and error in simulation design

I left you last week teetering on the edge of what passes for a cliff-hanger on this blog. I was preparing a game for some international agents and worrying about not offending them.

In the event, I didn’t offend them. Mainly because I was confusing them instead.

“He wants us to do what..?”

One of the most difficult things about running simulations is that until you actually run it, with participants, you don’t really know what will happen. Even talking it through beforehand (by yourself, or with a colleague) isn’t the same, especially when it’s a multi-player event.

The reasons are obvious. As I’ve discussed at more length elsewhere, simulations are simultaneously simplifications of the world, and invitations to explore complexity. you set out some rules, then let participants play with the possibilities. By that simple fact, we have to acknowledge that this process of exploration requires us to accept that there are very many ways to skin the proverbial cat and we won’t have thought of them all.

Last week was a case in point. The game is one that I have taken through a number of generations of development, since each time, the resolution of one unforeseen issue causes another unforeseen issue.

This time, my endeavours to avoid offence and to reduce confusion through being overly abstract ended up with a totally different dynamic to the game. By asking players to allocate funding, they engaged in (surprisingly comprehensive) pork-barrel politics, paying out everyone. The game is about satisfying individual preferences, but this was such an off-the-wall way of doing that I’d not considered it an option at all. Indeed, until the changes I’d made, it wasn’t possible at all.

To that extent, the game was a failure: the lovely dynamic that the earlier versions had produced was totally absent and my feedback had to make trips into areas it had never done before. What might have been a subtle lesson on the self-organisation of parliaments became something very different.

But to stop there and write it all off would be wrong.

In this case, I had the luxury that this was outside of a teaching module, had no assessment and very diffuse aims (mainly, to impress the agents, if I’m honest about it). As such, despite being a totally different experience to that which I’d thought it would be, it was still a valid and valuable one. I found myself taking plenty of notes on what happened (and why) and my feedback was in part about why things turned out the way that they did. The agents still enjoyed themselves (more engaging than my Powerpoint presentation beforehand, no doubt) and had something to talk about for the rest of the day. In these terms, it was a success.

Moreover, I’ve not had the chance to see how this version of the game works, so I can work on it some more. Indeed, in the writing of this blog today, I can actually see two paths of development. One would be to return to the original concept, but the other would be to carry on down the pork-barrel path to consider how that might be developed. Both options are interesting and both carry new opportunities to explore (and to mess up).

In retrospect, last week might have been as bad a game as I’ve run, in that it didn’t work how I thought it would. But even then, there was much more than enough that was positive in the experience – both for the participants and for me – for me to say that it still worked.

That’s something worth bearing in mind as you develop what you do with simulations: ‘success’ is multi-faceted, just as it is also not assured.

2 thoughts on “Trial and error in simulation design

Leave a Reply