I decided to continue my exploration of the exercises in Justin Gary's Think Like a Game Designer which I started writing about in yesterday's post. My plan was to take one of the items from yesterday's list and try the "brainstorming" exercise. The particular idea I pursued is a video game idea inspired by tabletop role-playing games. I realized that before I could pursue my intended exercise, I had to determine whether this would be a single-player or multi-player game. To address this, I decided to try the intermediate framing exercise that Gary puts between inspiring and brainstorming.
As with yesterday's experience, I found the exercise to be both simple and helpful. There are fundamentally three parts to it: naming the target audience, articulating the hook, and choosing constraints. The audience was described in terms of motivation rather than demographic, which I think is a helpful distinction for my students. The hook is one or two sentences at most, what might be considered a concept or elevator pitch. I went through these steps fairly quickly, but they didn't directly get me to resolve the number of players: the two directions are otherwise similar in terms of audience and hook. After some separate online research regarding matchmaking systems, I resolved to focus on a single-player mobile experience.
The intention for the brainstorming step is that it lead to the prototyping step. It may be worth mentioning, then, that this is where one of my constraints puts up a blocker: I cannot actually prototype this idea any time soon due to other obligations. This restriction is a little upsetting since these exercises are getting me really interested in pursuing this idea.
The brainstorming step has three parts: creation, organization, and elimination. The first step is a conventional exercise in brainstorming proper, where ideas are written down without filtering them. The spirit here is to open the floodgates and let ideas flow. I set a timer for twenty minutes and came up with 28 ideas for this game concept. Two of these had nested points, but I tried to otherwise keep the list "flat." Three items had small UI sketches on the side as well, which I think demonstrates the value of doing this on paper. A few items contradict each other, but most of them simply open up the possibility space. I expected more contradictions around decisions I had not made in my idle contemplation.
The organization step encourages the use of mind maps. I have used mind maps before, going way back to when I first read (and was strongly influenced by) Andy Hunt's Pragmatic Thinking & Learning. I like to do them on paper or a whiteboard, but I ran into two problems: to use a large sheet of paper, I would have to clean off my table or work around my kids downstairs (no way), and the whiteboard in my home office is mostly inaccessible because of shelving units. I think whiteboard mind maps are good for generating ideas, but this was really an organizing activity, so the ability to move nodes around seemed more important than hand-drawing.
This inspired me to take a side trek into the wild, wild world of digital mind mapping tools. There are many of them, and I quickly determined that what I wanted was (1) easily driven via keyboard for rapid information entry, (2) plain text serialization format for inclusion in version control, (3) a Web interface would be nice, but no vendor lock-in. I found Freeplane, which I had never heard of before, but it completely filled the bill. Turns out, it was available for Ubuntu Linux as either a regular package or a snap. It looks like there are Windows builds, too, should I find myself traveling and without access to a Linux installation. It took me a while to find the Freeplane Handbook, and after flipping through that, I found several nice features that were not obvious. To get started, though, all you really have to know is that enter drops in a new node, arrow keys navigate, and insert adds a child node.
After some initial confusion, I found the core interaction loop with Freeplane to be pretty snappy. Still, it took me almost 40 minutes to transcribe my brainstorming notes into a mind map. That's twice what Gary recommends taking, although he acknowledges that 20 is a minimum, not a target. The time spent was fruitful, though, because it involved decomposing the rough initial ideas into something like a taxonomy of ideas. At the very end of my time transcribing, I discovered how to add icons to nodes, and I marked alternative paths with question marks. Freeplane includes a convenient summary of the map's statistics, so I can tell you that the map had 90 nodes, including 54 leaf nodes and 14 main branches. The serialized form is 14kB of XML. In fact, I made some changes to the map before writing this up, but because of the beauty of version control and plain text formats, I was easily able to go back in time and find this information.
The last step of brainstorming is elimination, the output of which is a short description of the minimum features needed to prototype the game. One of the curious aspects of Gary's book is that he regularly gives five lines for his exercises, and this is clearly not enough space. During the creation phase, he gave five lines, and I filled three looseleaf pages. The elimination step is one of very few where the space is actually accurate to the task at hand. He even says specifically that if you need more room than you are given, you are probably being too ambitious for a first attempt. My own list ended up including seven short features, listed in bullet points, which I think would take about a two or three work days to complete, depending on one particular technical feature I have never implemented. I think these would indeed give me a functional proof-of-concept that would help determine if this idea is worth iterating upon or not.
I have been impressed with these exercises. Not only do I look forward to using them in my teaching, I wish that I had used them myself earlier this summer. I spent about three weeks working with my boys on a side project, after which point we saw that it would require more effort than we wished to devote to it for the summer. I transitioned from there to my own personal project, again spending about three weeks on it. After that time, I have a tech demo from which I learned a lot, but it's not much to show, and honestly, it doesn't quite tell me if the idea is fun or not. Now it might just be the excitement of starting something new, but I do feel like these exercises have given me more structured ways to think about this particular project than my conventional approach of sketches and CRC cards.
No comments:
Post a Comment