Justin Gary's Framing and Brainstorming

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.

Justin Gary's Inspiration Exercise: By the numbers

Last winter, I read Justin Gary's Think Like a Game Designer. I know Gary from his work on Ascension, although I cannot remember now where I first heard about his book. I took quite a few notes while reading and considered writing a formal review here on my blog. I discussed it with some people on Discord but never assembled those notes and stories into a review.

I will be teaching Introduction to Game Design again this Fall, and so I am going through my notes from last year and figuring out what I want to change. I pulled out my notebook and reviewed my notes from Gary's book, marking particular exercises from it for possible inclusion in my class. 

One of the exercises that interested me comes from Chapter 5. Gary frames game design as a six-step iterative process of inspiring, framing, brainstorming, prototyping, testing, and iterating, and Chapter 5 describes the inspiring step. Incidentally, his model is not bad, and using "iterating" to describe a constituent step of an iterative model reflects the informal nature of the book. The exercise itself is described as having six parts, each of which should be given twenty minutes to complete. 

Today, I decided to try the exercise for myself, and in this post, I will give an overview of my experience. I gave each step a full twenty minutes except the last, but we'll cover that when we get there.

The first step is to "review the games you love." The task is to list your favorite games. I set my timer for twenty minutes, and I came up with a list of 123 games. My list includes board games, card games, sports, role-playing games, and video games. The video games represent titles released on the C64, NES, SNES, and PC. One of the strangest ones that came to mind was 1982's Aztec. I could not remember its name, and when I found it, I discovered it doesn't have an entry at Lemon64. 

I decided to list games I enjoyed, although I wouldn't call everything on it a "favorite." They are all memorable games. There are even a few that I found frustrating for various reasons but still enjoyable. As I continued through the exercise, I realized that I had missed some of my actual favorites, but I did not go back and amend the list.

The next step is to "review the games you hate," which is a clear complement to the first step. The instructions are a bit vague here, asking you to "spend a few minutes" making this list, despite earlier having said that each step should be twenty minutes. My list ended up including only 40 items, and I was stuck at around half that for a while. Some of the things in the list are board games I have gotten rid of, and there is a section of bad mass-market kid and family games. There are relatively few video games on the list, most of these being competitive ones that I played with groups who were much more experienced than I was. I have a few sports and classic games on here as well.

The third step is to "find the gems," to look at the lists of games and identify mechanics and themes that you enjoyed. I appreciate that Gary encourages the reader to try to find the good parts in the disliked games as well. My list included 65 items. Most of the items on my list are mechanisms, but some deal with theme, narrative, emotion, and production quality. I tried to avoid designer jargon, but items like juiciness and game feel still made it to the list. I realize also that some items on my list subsume others, such my listing of "legacy," which includes many other ideas such as campaign play and unlocking content.

I missed a part of the instructions for this step. He encourages you to highlight the items on the list that are the most meaningful to you as you are making the list. In my focus on the list itself, I completely forgot about this. The whole of the exercise is to be done in spirit of avoiding self-censorship, and so I found myself trying to avoid metacognition entirely: just putting down things that came into my mind without judging them. If I were to assign this to students, I might encourage taking a little break here to read the list and then to highlight important items.

The fourth step is to "find the crud," which again presents a counterpoint to its previous step. My list includes 41 things I do not like about games on my lists. Interestingly, almost everything on this list is explained in longer phrases than those on my "gems" list. Whereas the previous list was made in two columns on a sheet of looseleaf paper, this one had to be done on two separate sheets since there was no room for a second column. 

Step five is the culmination of all the previous steps. Here, you are to "look for patterns," going through all the other lists to construct a new list of game ideas. The instructions are to summarize a game concept in one or two sentences, and he is explicit about not self-censoring here. I know it was supposed to be inspiring, but I found myself anxious about his admonition, "If you stop moving your pen for more than thirty seconds, you are doing it wrong." Whether this speaks to my emotional state or my need to do more unstructured creativity is up for grabs.

My list here included 21 items. As I wrote it, I found myself looking almost exclusively at my "gems" list for ideas. His instructions invite you to consider modifying games you did not enjoy by removing the bits you didn't like, but in practice, this felt like it took more mental effort—possibly more than thirty seconds worth, and so I avoided this path. 

Several items on the list are unclear mashups of words, but there's nothing here that I couldn't use as a seed. I kept everything on the list tied to the other lists, and it took effort to force out of my mind those things that have been occupying it. One item is a concept I recently discussed with a friend, but it also reflected the lists, so I kept it. There were a few times where I looked at the list of games I like and then had to stop myself from just writing down a riff on that with no new ideas, but I took this as an inspiration to then turn to the "gems" list to see what could be modified. This didn't happen often, though, and mostly I felt like I kept swimming in the handful of ideas that my eyes kept returning to.

The items on my list emphasize systems and mechanisms over themes and stories, and this is very much in keeping with the ethos of Gary's approach. It is practical, however, since "players form cards to form a whip or chain to grab a resource from the center of the table" is something you can start tinkering with, whereas "a game about hope in the face of desperate circumstances" still has to be refined into something the player actually does.

The sixth step in Gary's list is to "pick your favorite concept and start working on it." That's not a twenty-minute step at all: that's the rest of the book. Perhaps he just needed a better editor.

Note that what I have described here is only the inspiration step of Gary's design model. It is followed by framing, which considers the audience and constraints, and then by brainstorming, whereby specific ideas for the game are considered before prototyping. Perhaps I will return and try these steps in the coming days.

I enjoyed the exercise, and I will be sure to find a way to put it into my class for Fall. I think it would work well as preparation for students' pitching their final projects. There are inevitably students who struggle with finding a starting point for their designs. It may even benefit those who think they already know what they want to do, since such students often find themselves choosing paths that are really out of scope.

Painting Massive Darkness 2: Monks and Necromancers

I am still working my way through the heroes of Massive Darkness 2. Previously, we looked at the base set heroes and then the druids, bards, and tinkerers. Today we are looking at the four heroes from the Monks & Necromancers vs Paragon expansion. 

Riya (front)

Riya (back)

This set contains a lot of interesting sculpts, and Riya is a great place to start. I like how there is a lot of motion around her despite it looking like she is still. I think that's really what you want in monk. Unfortunately, this figure had some pretty bad mold lines, and the face was hard to clean. I think the paint mostly covers it up, but there's something a bit eerie about her lips--not just the cyan color.

The card art is shown from the front, of course, so I had to make a creative choice about the back of the figure. I was actually on the phone with my mother when my eyes caught the front of the box for this expansion, and I saw that there, she was shown from the back. It quite distracted me from what were were discussing! The illustrator had different colors than I do for the back, but I am content with my choice to echo on her outfit the maroon tassels from her head.

Harin (front)

Harin (back)

Harin's pose is also very cool. Of course the plastic of his cape is holding him up, but the sculpt sells the illusion that he is floating. Also, once again here there is a sort of stillness in his pose and yet an action in his clothing. Maybe I'm imagining things, being an old Dragon Clan player. 

With the two monks out of the way, we move on to the Necromancers, starting with the one who took much longer than her compatriot.

Ygraine (front)

Ygraine (back)

I remember when Ygraine was revealed during the Kickstarter campaign. I was not impressed with the direction things were going. I would have liked more emphasis on classic fantasy tropes early in the campaign. Having the miniature in hand, though, is a different matter. This is a really wild sculpt. Like with Harin, we get the illusion of flight through that strange fox/dragon/stole she is wearing. The hat is just plain bonkers: she's basically wearing a peacock. 

I feel like the fox/dragon/stole should be a focus of this piece, but I worked with it for an over an hour and just couldn't get it to be very interesting. At some point, I simply had enough of it. Putting a face on it did help a lot, though, as did just getting some paint on the pieces around it.

I ended up busting out the wet palette for this figure, but I'm still struggling to get the right amount of thinning and the right amount of paint on the palette. Fortunately, the hat was happy to take basically any mix of green, blue, and yellow.

Mortemyr (front)

Mortemyr (back)

Finally, here's Mortemyr, who is really tame in comparison to the rest of the figures in this box. He was straightforward to paint, and I think he looks pretty good. The stitching on his satchel is sculpted in, and I think hitting those little details give this some class.

Here's a party shot of everybody in the box:

Monks & Necromancers

Next up for me will be Kickstarter exclusive figures from the Darkbringer pack. I have some on my painting table already. Thanks for reading!

Summer Course Revisions: CS315 Game Programming

My recent blog post on the topic confirmed my recollection that I've been generally happy with the Game Programming class. I've just published the initial course site, which includes the first three project specifications. I expect these will be followed by a midterm and the final project, but I want to meet the students before I commit to that. I made some minor wording changes to the overview page but no policy changes. 

I did make one important change to the projects: I got rid of a race condition. The students will still be participating in checklist-based assessment, where I give them a checklist and then turn it back in to let me know what they did. They will also be using GitHub's Release feature, along with semantic versioning, to mark the end of each iteration of multi-iteration projects. Previously, however, these two requirements were at odds. The checklist was part of the README.md file, and the requirement to make a Release was one of the items. This means that a student had to choose one of the following:

• Check the box before making the release, commit that change, and then make a release. This means that they have checked the box before doing the work, which is contrary to the idea of checklists.
• Make a release, then check the box and make a commit. This means that the README.md file was not up to date in the release.

I puzzled over this a bit and, after some experimentation, decided that a good solution was to remove the project report (which includes the checklist) from the README.md file entirely. Instead, students will now be completing their project reports using the Wiki feature on GitHub. The wiki is still maintained in Markdown, which means I can keep the model wherein students download the checklists from the course page. However, it is not in the source repository but is actually a separate one alongside it, a fact that can be confirmed by cloning one of the wikis. 

The next Ludum Dare once again aligns with the second iteration of the second project. Like last year, then, I will be allowing students to either complete the second iteration as given or participate in Ludum Dare. Last year, this option was nested into the Project 2 Iteration 2 specification, which left it unclear exactly how it would be evaluated. I have pulled it out into its own heading and given it its own specifications. It will be interesting to see if students take this option.

A quick and dangerous tool for bulk deletion of GitHub repositories from within an organization

I use GitHub for almost all of my classes, and each class has its own named organization. Students and teams submit work through GitHub, which means that there are a lot of repositories built up in the organization by the end of the semester. I always tell my students to make their own copies or forks and then to clean their work out of the GitHub organization, but very few actually do this. Because I reuse the organizations, this leaves it up to me to clean out the repositories between semesters.

Deleting repositories by hand is tedious. For reasons I cannot explain, Repo Remover only shows a small subset of the repositories in the organization, and Repo Sweeper shows none. This morning, after taking out a few with Repo Remover, I started the process of removing repositories one at a time. Two thoughts crossed my mind: "Automate tedious manual work" and "Don't spend more time writing a program than you will save doing it by hand." Well, since I have to do this between every semester, I decided I had had enough tedium.

I've been quietly working on a Summer project using Flutter, and so after confirming that there's a nice library to wrap GitHub's API, I decided to see if I could whip something up in Dart. My major stumbling block was not realizing that a variable exported within Android Studio's terminal would not be available in the execution environment of the IDE. Once I specified my personal access token in the run configuration instead, everything worked like a charm. There's really hardly any code to it, and I've released it under GPL on GitHub at https://github.com/doctor-g/repo_deleter.

The code obviously would need to be modified for others' purposes. Right now, the "bsu-cs315" organization is hard-coded, and there's no UX to speak of. It just deletes all the repositories that start with the letter "P". Of course, I didn't start with that code. I started by having it print all the organization repositories, then I filtered out those I didn't want, and then I changed my print statement to a deletion.

Hopefully this will save me headaches next time I need to clean out an organization. Also, hopefully by writing this blog post, I will remember that I wrote a tool to make my life a little easier.

A Review of Scotty McFarland's EZD6 RPG

Gareth Barrett publicly claimed that Scotty McFarland's EZD6 is the "greatest RPG ever written." That's quite a claim, and he makes it without equivocation. While it's impossible that he has read all RPGs, I'm sure he has read a lot, and he makes specific comparison to some that I am familiar with, including Dungeon Crawl Classics, Dungeon World, Index Card RPG, and The Adventures of Baron Munchhausen. He is comparing this newcomer to some of the most lauded and recognized fantasy role-playing games, and this was enough for me to pick up a copy of EZD6 for myself.

The rulebook was a breezy read. The rules of the game are simple, and they presented in a mostly straightforward way. However, I was quickly disappointed in the quality of the book itself. The presentation is scattershot, with technical terms used before they are defined. The writing is functional but inelegant. The result is that the book feels like a rough draft that should have gone out to external playtesters. The book is published by Runehammer, whose own ICRPG went through several rounds of significant editing after its initial release. That's a great benefit of digital publishing, but I don't get the impression that EZD6 is due for this kind of maintenance; indeed, perusing YouTube comments, I see instead that McFarland is currently working on supplements for separate sale.

Particular mention should be made of the strained metaphors. The book insists that what other systems call "characters" are, in EZD6, called "Pushers and Shovers." That phrase hardly rolls of the tongue, and throughout the book, they are referenced regularly as "characters." There's a good reason to do this: they are characters, as agents in a story. Similarly, the book insists that what most systems would call a gamemaster is a "Rabble Rouser." This term doesn't have the right connotation and so it comes across as a sloppy attempt at novelty. You have a "hero die" that is not a die at all but a token you exchange for a re-roll. The worst offense is the use of "Strikes" to denote health or hit points. "Three strikes and you're out" is an easy and memorable concept. The problem is that characters have three strikes, and when you get hit, you lose a strike. You're "out" when you have no strikes. The metaphor is upside-down. This might be a pet peeve, but I feel like the icing on the cutesy wordplay is the gratuitous use of "k" in the word "magick." It puts the "ick" in magic.

The unprofessional editing and poor use of language is enough for me to say that this is not the greatest RPG book ever written. (For exemplars of "bookness," check out Paul Czege's The Clay that Woke or the aforementioned Baron Munchhausen by James Wallis.) An RPG book is not just a book, though, and the systems of EZD6 are where it shines.

The core system is clear: roll a d6 and beat a target number, usually 3. Situations may get you a "bane" or a "boon" in a manner similar to D&D 5e's disadvantage and advantage system. The math and adjudication are much simpler here, and it's not clear to me that anything is lost in the coarse grain. That is, I don't think it matters that taking a -2 on a d20 gives a 10% difference in outcome whereas having a +1 target on a d6 is a 16% difference: the human brain is too bad at statistics for this to really matter. The real value here (as Barrett points out) is the karma system. Players start with three karma, and they earn karma on each failed roll. Karma can be spent to improve any die roll on a point-per-pip basis. This works very well with the d6 system: each failure means, in a sense, you're banking a 16% chance to succeed at something later. It's simple, it takes some sting out of failure, and it adds up even in a short adventure. It also feels heroic in the narrative. This kind of system would not work with a d20 system because the opportunities and impact would be diffuse.

Given the elegance of this core system, I was surprised that the magic rules muddied it up. I agree with McFarland's stated design goal that magic should, by definition, feel different. I think D&D has always dropped the ball here but that Dungeon Crawl Classics has a wonderful interpretation. In EZD6, you basically roll some dice against some other dice and get what you want, and you can use your hero die but not your karma, among some other restrictions. This system does succeed at feeling different from the rest of the game, but it falls short of feeling dangerous and mysterious. The best contribution here is not the resolution system but the division of magic into circles of sorcery. A spellcaster can come up with any effect they can imagine, within the gamemaster's adjudication, as long as it is within one of their known circles. This is an important restriction on a free-form magic system, preventing the spellcaster from outshining all the other classes.

One of my greatest disappointments with the EZD6 book is that it does not include any scenarios or characters. There's nothing you can use out of the box. Compare this to ICRPG from the same publisher: it includes "trials," which are small but compelling scenarios designed to expose new players and GMs to the rules, as well as sample adventures. 

For my trial, then, I put together a short three-encounter adventure for my family: my wife and my four sons, ages 7 to 15. Not all of them like tabletop roleplaying games, but they were all willing to join in for a one-shot. My eldest son helped everyone make characters while I designed the quest. I decided to pick something that would highlight some of the miniatures we recently painted together—our first batch of mobs from Massive Darkness 2. (Expect a blog post about that once they're all done.) The party were called upon to eliminate a mysterious evil from a haunted cemetery. This involved battling gargoyles, skeletons, cultists, and a summoned demon. As always, I found myself deploying tricks from ICRPG in designing the scenario, particularly the inclusion of "Timers, Threats, and Treats." Everyone enjoyed the game, especially the karma system. We did not get much experience with the magic(k) system since the lone spellcaster only cast one spell, which was to blind the chanting cultists. This didn't really do anything since they were already in a trance. I have to wonder if his own imagination about how to use magic stunted by his reading too many RPG rulebooks that codify spells.

Is EZD6 the best RPG ever written? No. But it is pretty good. Playing this game with my family was a lot smoother than ICRPG or Dungeon Crawl Classics, and it seemed to be equally enjoyable by both the older and younger crowd. I recommend it as a rules-light game for those who want to emphasize narrative but still be in a GM-crafted D&D-style adventure. Rather than compare it to something crunchy like Apocalypse World, I think it would be better to compare it to FATE, and perhaps that's something I can do later this summer. However, if what you really want is a collection of advice about how to run a game, I maintain that Index Card RPG is still the best resource available, even if you don't ever use the systems it presents.

(Did you know I released a free PbtA tabletop roleplaying game about campy superhero adventures? It's called Kapow! and you can read about it here. I ran into some folks at Origins who have a completely different game out called Kapow!, but I can't blame them. It's a good name.)