An Evening with Friends and Dungeon World

Periodically, I pick up a rulebook for a tabletop roleplaying game and imagine myself running a session, like the old days. In October of last year, I was inspired to pick up Dungeon World, and I remember finding it very interesting. Yet, like most of the RPGs on my shelf, it was filed away without being played. It was instrumental in my making Kapow during last year's National Game Design Month, but it never actually got to my table.

There's something mysterious and alluring about tabletop roleplaying games, and despite some reflection, I'm not entirely sure what it is that draws me to them. Certainly, I spent an enormous amount of time planning and running such games in my youth, all the way up through undergraduate, but then it took a precipitous drop from my time and attention. My relationship with tabletop RPGs is a topic for another day, but suffice it to say that the pandemic gave me a weird sort of inspiration to get a group together to try Dungeon World. I could play with anybody, regardless of distance, using online tools that I really wanted to learn anyway as I get ready for a mostly-online Fall semester. We used Roll20, which was impressive although awkward in many places. For what it's worth, about an hour in we gave up on the integrated peer-to-peer voice chat and just set up a Google Hangout instead.

I thought it would be a fun bit of reflection for me to go through the DungeonWorld agendas,  principles, and moves for GMs and see what I hit and what I missed. DungeonWorld was released under a Creative Commons Attribution license, so I don't feel bad about including these rulebook excerpts here. You can even crossreference my notes against the relevant part of the book online if you can handle the ads. Of course, if you like what you see, buy the book to support the creators.

Another bit of preface before I get into the details. I didn't talk to the other players about whether I could write publicly about them and the game. I won't mention the players by name; I'll be referring only to their characters. There won't be enough here that you could reconstruct our story because these are just my notes. My goal in sharing here is not that you can rebuild our adventure, but that you can see how I think through what happened and compare it to other experiences. Getting into it, then, it's sufficient to know that Serah is a halfling druid, Brandon is a human ranger, and Tristan is a human thief of the con-man persuasion.

Agendas

Portray a fantastic world

I think I did good job here. Since I didn't know what kind of characters the players would make ahead of time, I couldn't prep something attuned to their particular skills. Instead, I drew upon the Eye of Clune dungeon I had designed two years ago for my kids. It, in turn, was inspired by design advice from Runehammer / ICRPG.

Fill the characters' lives with adventure

I made sure to ask a lot of questions during character creation. Although none of the players mentioned this, I think it was more questions than they expected, but it served exactly the right purpose: building up a world around the characters that was filled with potential adventure. It was just one session, so I'm not sure if I "filled" them with adventure, but the possibility is there.

Play to find out what happens

I had created the dungeon ahead of time, and although they surprised me with some choices, it was still kind of pre-made. I don't wish to sell short their innovations within this space, but I also think it's the case that once we went past character creation, I turned a bit more toward a "I am the GM who made the adventure" mode, not asking enough questions that could have given them some agency. For example, they were attacked by harpies, but it didn't have to be harpies, and the cave was set in the side of a cliff by the canyon, but it could have been anywhere. I'll say more about this in a discussion of the principles.

Principles

Draw Maps, Leave Blanks

My memory of this principle was that it was metaphorical, but re-reading the principles this morning, I see that it is literal. We played most of the game without a map, but when there was some confusion about what I was describing, I sketched it on the board. In our post-game debriefing, one of the players mentioned this as a good move and encouraged the use of the map. During preparation, I had decided against predrawing anything in part because I didn't want to fall into the quagmire of assets and fancy dungeons, but I definitely think my player was right: a simple sketch of the room shapes made a huge difference. In retrospect, we should have done this with the town, the cliffs, the river—just laid out roughly how pieces fit together. On the other hand, we could call this all a blank that we can fill in next time, if we play again.

Address the characters, not the players

When I think back to the tabletop roleplaying games of my formative years, I cannot remember if my DMs or I did this, but since returning to the hobby with my kids, I've definitely done my best to follow this. None of the players commented on it, but I did notice that some preferred to refer to their characters in first person and some in third, which was interesting.

Embrace the fantastic

Like I mentioned before, I think I did a good job here with the setting, the mystery. ICRPG calls this the DEW: Danger, Energy, Wonder. It's this kind of thing that excites me about creating more stories.

Make a move that follows

I think I did a good job chaining the pieces together into a believable fiction. There was a logical structure.

Never speak the name of your move

I mentioned to them that I made moves, but I never told them what my moves were, only that they were "hard" or "soft." I had printed up a list of my moves to have on hand during the game, but I never referenced it. There were just a few spots where my improvisational system was shutting down, perhaps from fatigue, and maybe having the list on my table would have helped inspire me faster to come up with something to do when they failed or got a middling success.

Give every monster life

The aforementioned harpies were guarding their nest, which I think I described in a believable way. They weren't interesting but one could see how they fit into the ecosystem. The adventure didn't have many other monsters, not in the conventional sense. Maybe I should have added more "live" things that had their own agendas: everything else, like the magical hallway creature and the skeleton guards, where really reactionary.

Name every person

The only people besides the players who came up were those mentioned during the backstory. Too many of them went without being named. I'll have to remember that so we can fill in the blanks with some kind of flashback or retcon should we have a chance to play again.

I'll mention that I took a bunch of notes on paper, and I thought about putting them into a binder or something. However, I think what I really ought to do is put them in my GM Notes in Roll20.

Ask questions and use the answers

As mentioned earlier, this went really well during character creation, but I think it fell off a bit during the adventure portion. Here's an example: the druid came from the river and could change form into river animals, but we never established the climate of the river. At the end of the adventure, the druid wanted to turn into something big and strong, but what was that? A hippopotamus? A musk ox? We even said out loud that we never really established the climate, but I did't ask them to specify. In retrospect, I should have (although in my defense, it was already about an hour later than I said we'd run, so I was trying to help us wrap up).

The easiest part of this principle is asking "What do you do?" to the players after making a move. That was easy, and falls right into my normal mode of running a game.

Be a fan of the characters

I think it was clear to the players that we were all telling a story together and that I wanted them to succeed, although this wasn't explicit. However, being a fan of them also caused me a bit of systemic consternation. There were a few points where the players described their characters doing something really interesting, really fantastic or heroic, and my instincts were to want to give them some mechanical benefit, like D&D Advantage or ICRPG Hero Coin—something tangible they could turn in later for a benefit. Indeed, during our debrief, I mentioned this specifically. After doing a bit of reading and thinking about it this morning, however, I think this was my defaulting to a D&D/ICRPG view of the game rather than a PbtA one: I probably could have used my moves in ways that rewarded them for heroism and cleverness in a more subtle way. Maybe I did and didn't think of it that way at the time? This is one area, clearly, where I'm still seeking to understand the system.

Begin and end with the fiction

This is another case where everything made sense in the game, but the context was, by necessity, a bit small and impersonal. That said, during the End of Session move, the player had interesting interpretations of their bonds' resolutions. Also, after a little thinking, they came up with an insightful answer to the question of whether they learned something new or important about the world: they learned that the old secrets that they discounted may actually be true. That's a nice hook!

Think offscreen too

I really didn't do this at all. There was an important opportunity that I had missed here. Early in the adventure, the ranger was separated from his companion, which kind of left him without one of his major class bonuses for the whole adventure. I could have taken an opportunity to "move the camera" to show what his animal was doing while they were down in the cave, whether it was worried or in danger or simply at peace. I imagine, though, that this particular principle comes into play more when there are developed fronts.

GM Moves

Use a monster, danger, or location move

Harpies attacked, traps triggered, a tremor started—this is an easy one.

Reveal an unwelcome truth and Show Signs of an approaching threat

I put those two moves together because I'm not sure I've distinguished them adequately in my mind. When I thought of cases where I did one, it could have just as well been another. Perhaps what this really means, then, is that I really did the latter and not the former.

Deal damage

We did a bit of this, although I kind of forgot about debilities: there was a good case where I could have done that instead of a d6, in retrospect.

Use up their resources

I did not do this at all, not through the GM's power over the world. They were in a dark cavern and they used up adventuring supplies as torches, but I never invoked this in response to something they did. Re-reading the move's description, it mentions that the "using up" need not be permanent, the example being a sword flung across the room. That's a good aspect that I had not considered, although thinking back on the story, I'm not sure if there was an opportunity for this or not.

Turn their move back on them

This seems like a good place to use those tricky 7-9 results. I am not sure I did this move explicitly, since I reached almost exclusively for Offer an Opportunity with a Cost. I think perhaps this tells me that I could sometimes make the world simply turn their move, without my having to present them with a dilemma—which, as mentioned, sometimes was hard to come up with when it felt warranted.

Separate them

I did not take this move as part of my actions, but they ended up separated several times due to their own actions. When I was involved, it was part of giving them a choice: you can climb down to safety, but it will put the rest of the party at risk, so do you save your own skin or warn them of the danger?

Give an opportunity that fits a class' ability

Honestly, I was expecting a more stereotypical adventuring party, not a Druid, Ranger, and a Thief. I did not think about this being a move I was taking, although they were able to turn the situation into places where at least the Druid and the Thief could really shine. Maybe if I was quicker on my toes I could have set up situations for the others? It is something for me to consider, though again, I wonder if it would be easier after sleeping on the party composition.

Show a downside to their class, race, or equipment

This did not come up. I love the idea of it, but it never really crossed my mind.

Offer an opportunity, with or without a cost

The idea of "success with a price" is part of what intrigued me about the whole PbtA movement. Maybe I need to actually scale back my use of this move, but I think the players did enjoy all the choices I offered. (At least, it looked like they were enjoying the choices, which were almost all of the "save myself or the party" variety.)

Put someone in a spot

Now that I look at the list, maybe this is more of what I was doing than offering an opportunity? I nee to think more about this taxonomy perhaps.

I should mention that I watched quite a bit of a Dungeon World one-shot on Roll20 that was led by one of the codesigners of the game. I was actually trying to figure out how best to use Roll20 when I watched the video, but it was also enlightening to see how Adam Koebel ran his game. However, because the GM never speaks his move, it's hard to see how he's deploying the rules vs simply improvising. I wonder if anyone has tried, as a sort of qualitative evaluation of a session, to code his actions as moves to see which he is using. I need to hold on to that idea for next time someone asks me to supervise a qualitative games research project.

Tell them requirements or consequences and ask

This is probably the move I should have pulled out when a player failed a roll and I wanted them to succeed anyway. Again, it has shades to me of the other two, and it's not completely obvious to me that I can see that I did or did not blend this with those other two. As such, it's not completely clear to me if it would be valuable for me to disentangle them or not. (But, you know, finding these cases is the point of this reflection, so this is progress.)

Dungeon Moves

I can keep this section short. I didn't really account for the dungeon moves as different from the GM moves. I suppose this points to the fact that I should have had that list of moves front and center to help me navigate my options, or perhaps it points to my having a bit of a linear, pre-built adventure for them instead of something more reactive.

Wrapping up

As I've worked on scheduling and prepping for last night's game, I also found myself wondering whether my kids could play this game. The older ones would do fine, #3 Son might get it, but #4 Son is still pretty young. He could not read his own sheet, and I'm not sure that a 5-year-old's "Yes And" is quite like a 13-year-old's. I'd hate to cut him out, though. I admit, I was kind of shocked to go back and look at the post I mentioned earlier, about the Eye of Clune adventure. That wasn't last year, it was two years ago. The littlest guy did not play with us as he was only three, but #3 Son played, and he was only five. #4 Son played our games of Kapow back in November, but in sort of a made-up sidekick role. Anyway, I'm torn: I like the idea of building a world together, but I'm skeptical of the boys' ability to have it make sense and be fulfilling for everybody. I suppose part of my point here is to say that I was really grateful to be able to play with some adults who were willing to work together on a world and a story without fighting with each other or picking their noses.

That's it for today's blogging. Thanks for checking it out. My next step along these lines is to re-read the chapter on Fronts and try my hand at those. If you have any insights to share about the system, observations about the game, or responses to my reflections, please feel free to leave them in the comments.

Summer Course Revisions 2020: CS315 Game Programming

Earlier today, I wrote about some of the constraints and unknowns I'm dealing with as I move forward with Fall course planning. Here, I want to share a reflection about how I've thought of my Fall 2020 Game Programming course (CS315). The course plan is online, and I welcome you to take a look and let me know what you think.

Godot Engine

The most obvious change is a switch from Unreal Engine to Godot Engine. I have spent a lot of time getting to understand UE4 and how to teach it, and so it was no small decision to make the switch. When we first set up Fall's schedule, my plan was to teach the class in our computer lab with our nice desktop rigs. However, with the shift to online instruction, I have to face the fact that not every student will have equal access to machines that can run UE4. We looked briefly into remote desktop solutions, but that was not possible either.

Godot Engine was a clear runner-up. It is free software, being licensed under the MIT License, and it is multiplatform. The documentation is astoundingly good, and it seems that there's enough people working with it to find good answers to common problems online. It has a small footprint, both in terms of the editor and deployment, and it doesn't take a workhorse desktop machine to get good performance. Indeed, when you look at the actual features my students have used from UE4, they rarely even use what makes that engine so powerful. Godot also publishes to the Web, which is one of the main reasons I've been happy to use it with my family. Its scripting language looks a lot like Python, which our CS majors learn in their introductory course. The node and scene system may at first be surprising to my students, but I am hopeful that I can use to explain concepts of object-oriented design. I think its approach may be like studying Lisp: you may not use it all the time, but it gives you a different way to think about program structure.

Course Project Structure

My intention for the course is that the students start by working through the well-known Dodge the Creeps tutorial before going into a tightly-scaffolded Angry Birds-style project. I struggled a bit with how to scaffold the experience, but I decided to go with weekly submissions with well-defined steps. I think that this series of steps should help students learn what I want them to learn, although I freely acknowledge that this is not the only series of steps that could do so. Most of my students coming into the class have no real game development experience, and so small steps with check-ins is probably worthwhile. It will mean I have to spend more time reading submissions, since each student will submit one per week, but this is mitigated by the use of specifications grading and checklists. I have written before about this combination, indeed sometimes positively and sometimes negatively. Regardless of whether or not a subset of students struggles with conscientious completion of checklists, it is a lot easier for me to verify a checklist than to grade a submission from scratch.

A challenge with this approach arises if a student falls behind. What if a student is content with a C on the first iteration but seeks an A on the second iteration, but their previous work has not set them up for success on the subsequent? At this point, I am going to accept this as a possibility where the answer has to be that they go back and retool the previous increment to support their higher aims. There is a possibility that I could drop reference solutions after each iteration, or ask successful students to share their implementations with their peers, but I think I'm going to go with the more direct, linear approach. There's a lesson within it that is hard for students to learn: your choices when writing software have consequences. Even after CS222, when students always proclaim that they have seen the light, I still see students not building up solid foundations from which to work. Since the project will only last about a month, I think it's OK for there to be some pain around mistakes, since it's the kind of pain that leads to growth, and without too significant of consequences.

My plan on paper is that once we finish the three iterations of Project 1 that you can currently see online, we will have a class discussion or vote about whether they want to have a final iteration that lets them pull all the pieces together, or if they want to jump into a second, 3D project. Until I get to know the students, I don't know which they will prefer. In any case, my plan is that the second project last 2–3 weeks only, so that they can see that 3D is basically 2D but with an extra dimension. I mean, that's literally what it is, though it has a mystique about it. This will then position the students to be able to move into a final project, which I have not yet specified. Right now, I think I will make the final project group-optional, and I expect to give the students plenty of opportunity to give input on how it will be graded.

Community

I am concerned about our ability to form a community of trust and respect without being able to hang out together in the lab. When I teach game programming in the lab, I spend some time doing direct instruction and worked examples, but I moved a lot of that to my game programming playlist on YouTube a while ago. (I have not yet put any Godot Engine content onto that channel, although I expect I will do some in the Fall or later this summer.)

My solution for this class is to award course credit for “community participation,” and to allow students to get these credits in various ways. The simplest and default case that I plan for the course is that, after a major milestone, students will post links to their games and repositories to a discussion board on Canvas. Then, other students will be able to earn community participation credit by reviewing and responding to three other students' projects. I am sure this will be nowhere near as exciting as our showcase days in the lab, but at least it will get students thinking outside of themselves for a bit.

I have written up a few other ways for students to earn these credits as well, drawing in large part upon my experience designing achievements for CS222. As of this writing, these alternatives include: participating in jam; creating a tutorial, blog post, vlog, stream, etc. relevant to course goals; serving in a leadership role in a community or campus organization relevant to course goals; or anything else they pitch that I approve. I'm hopeful that this will help students remember that while they are accountable for their own work, we're all in this together.

The Weekly Schedule

Of course, we will have to roll with the punches in the Fall, but I also need some kind of plan to get started. Right now, that plan looks like this: on Tuesdays, we'll do a live, synchronous meeting that is recorded for those who cannot attend. Here, I'll introduce the project for the week, explaining tricky parts, and perhaps showing the first couple of steps to get moving forward on it. On Thursdays, I'll do a sort of workshop / Q&A session. I am not sure exactly how that will go, but it will give me a chance to address to the whole class any patterns of questions I have seen. Maybe it will be like last semester's optional Zoom meetings in CS222, where I had no sense that students even knew I was there, but I'm hopeful that we can try to make it worthwhile for students to drop in. Unlike CS222, when each team was doing their own projects and could rely on each other, CS315 will have many people working separately toward the same goal, and I think this will mean more incentive to come and talk to each other.

A missing piece here is something like “office hours.” I have essentially given up on traditional office hours for various reasons that will derail this post—including even an argument that they are counter to social justice, believe it or not. I have been inspired though—and emboldened by an article on Medium recently written by my friend Travis Faas—to do some kind of less formal, streamed experience. A student who needs confidential help can always set up a traditional meeting via email, of course. This alternative would be something more like “Pints with Paul” if my students were all over 21, or if we didn't have ridiculous alcohol laws. “Programmin' with Doctor&nbsplG” doesn't have quite the same ring to it, but the idea is that I would be on something like YouTube or Twitch, actually actively working on something. Students could stop in and see what I'm doing, how I work, engage with the process, or ask about something currently happening in class. At that point, I would put my own thing down and we'd work a bit on theirs. I don't know exactly how that would work, but it's an adequate description of where my head is right now.

Over 4000 Words and Counting

I will mention briefly that the projects page for the course right now has over 4000 words and only specifies up through the third iteration of the first project. It contains more direct instruction than would normally put onto such a page, but I need students to be able to work primarily from it rather than from lab interactions with me and with each other. It struck me as I was working on it that I was in a sense writing a short book about Godot Engine project development, including self-evaluation exercises. It makes me wonder whether I can generate any additional value from this effort beyond what will help twenty or so undergraduates in one semester. For example, I could post the link to the course more broadly, or share it Godot Engine discussion boards or something.

Licensing

Another change to the course plan is that I (finally) have an explicit license included on the page. I regularly fight with students about intellectual property, frustrated in their lack of education in this area despite the ubiquity of digital media. At the same time, my own publicly-shared course plans never really said anything specifically about what I was allowing other people to do with them. There is now a clear statement that the plans are licensed under the Creative Commons Attribution-ShareAlike license. In fact, my original plan was to also include the NonCommercial restriction to the license, but the license selector pointed out that this would mean my work was no longer part of free culture, so I removed that clause.

As always, thanks for reading, and feel free to leave a comment or a question.

Summer Course Revisions 2020: Platforms for Publishing Course Content

I took a little break after completing Flying Leap and then, about two weeks ago, I switched to full-time planning for the Fall semester. I figured that the easiest course to revise would be my game programming course (CS315), and so I started with that. However, as I wrote up my preamble to the actual course content, I realized it was long enough, and coherent enough, to be its own post. So, rather than jump into CS315, I will share with you how I ended up back to web components.

In the first week, I spent a lot of time thinking about how to present information to my students and guide them through a good experience that will likely be online and with some synchronous meetings. Neither of those variables have actually been specified by the university administration, but it is what I expect, given what I know so far. The curious reader may be interested to know that the university seems to be prioritizing the use of in-person meetings for freshmen, while upperclassmen get shifted to online courses. The default stance seems to be that classes will be online and asynchronous, which essentially removes all scheduling restrictions from students. My department (and at least one other) have petitioned to keep the schedules in place, having regular synchronous meetings with students. We expect this to be approved as long as we agree not to make attendance mandatory and to record all sessions for students who need to watch them asynchronously. I'm still not sure exactly what tools I'll use for this, in part because the university is promising some support as well... but again, we don't have official word yet. Even our Canvas pages for Fall are not available yet. So, I move forward with planning, hoping I'm not stumbling into a trap.

I didn't get much real planning done that first week because I spent more time feeling out my options. I discovered a few months ago that my go-to starting place for course sites—the PWA Starter Kit—is no longer under development. The project site recommends using OpenWC instead, so I looked into that. Although I understand web components and lit-html, the other pieces were all new to me. It was not clear if it would be a worthwhile investment in learning or a quagmire, so I wanted to make sure I understood my requirements and the implications of my decisions.

I looked into scripting content directly into Canvas after my friend and Taylor Computer Science professor, Dannie Stanley, pointed out that they have a well-documented Web API. Looking into this, I was also surprised to find that Canvas is free software. I tinkered with it a bit, but I decided it was not for me. I would have to bind too much of the structure of my course to their epistemology, which of course would not fly. I like the idea of being able to write my specifications once and publish them to Canvas, rather than my current approach of maintaining a Web site and then adding slots for submissions on Canvas, but it's not worth the shoehorning that would be required.

I also looked into simply using Markdown for everything and hosting the content on GitHub pages. I actually starting writing up the CS315 course plan this way in order to get a sense for it. It was very fast to write and easy to host and modify, but it broke down once I started thinking about grading. I expected to use specifications grading or digital badges (or both), and this is where my traditional web components approach really shines: I can define the content of this kind of course artifact as data and then write programs that manipulate it into different forms, including HTML+CSS for presentation and Markdown for documentation.

In the end, I decided to buckle down with OpenWC and rebuild my course sites in lit-html and web components using their toolchain. It took a bit of work, but now I have everything set up. Since I was getting my hands dirty, I switched parts of the site over to material web components rather than Polymer, even though there's a big warning on those repositories that says they may change while in development. I am a wild man.

It would be dishonest of me not to mention that I spent an embarrassingly long amount of time trying to get source code highlighted properly on my course pages. I tried highlight.js as well as prism, but both had problems integrating with my toolchain. After many hours of work, I got prism working good enough for the minimal use case... then I abandoned it and just left the code unformatted in a <pre> block. Maybe you've had that happen before, each attempt saying, "This will probably fix it and then I'll be done," and then you finally do fix it after two days of work, and then you say, "This was not worth it. This is not important. Where is my beer?"

The next blog post in this series will talk about the changes I'm making to my CS315 Game Programming course. See you then!

Fam Jam #4: Get the Food (and a few words about #3)

I will start with a few updates. We did do a Fam Jam in May, but I did not write a blog post about it. #2 Son surprised us by wanting to create a game around mechanisms of practicing arithmetic, and the result is Math Traps. It was a fun jam, but perhaps the most interesting part is how excited #3 Son was to make the soundtrack using LMMS. I also recently put together a public-facing page for the family's github organization. http://the-g-force.github.io/ shows all of our fam jam games.

Now, though, I turn to the main focus of this post: your June Fam Jam.

The Jam was yesterday, and we all worked together to create Get the Food. The game was the second one for which my youngest son (5) served as creative director, his first being Joe Johnson Gets Captured from our first jam. We decided to give him the reins once more rather than moving up in age order, since my oldest son is really already capable of building pretty much anything he can imagine.

It was a kind of difficult to get the youngest to focus in on an idea during our morning meeting in the living room. He started by describing a guy who goes through a magic portal to a campground, and he has to avoid the traps in the tents. Then he gets on a motorcycle and goes somewhere, I cannot remember. Also, he's fighting bad guys, and also he fishes. I'm pretty sure he just unwittingly designed a Zelda game. In any case, we tried to encourage him to rein it in, to focus in on one idea that we could all get behind. The fishing idea seemed to get some traction from the family, and in the course of the discussion, it changed from fishing to being a fish.

#2 Son was excited to apply his recently-developed skills with Piskel to create pixel art. His first fish was created before we settled in on the right screen size, and it was a frustrating conversation to point out that we had our cart before our horse. Once we got the screen size sorted, he made all three animated fish that are in the game.

#3 Son was very happy to work on the soundtrack. His first pass was very busy, with a lot of pasted blocks between tracks. That is, he would lay down something like a bass track and then copy that to the drum track and another bass track, just playing them at different times. It's not all bad, but it's very busy. I worked with him more yesterday than in the past, trying to help him understand a little bit more about composition. In particular, I tried to show him that most instruments just hit one note at a time, especially things like the bass. At one point, I pulled together a simple set of five tracks and challenged him to write something where none of them hit more than one note at a time. Somehow, however, he lost this file or something, since when I came back to where he was working, he was doing something completely different, with some instrument patches I would not have chosen for an underwater game. We worked a bit more, with me trying to encourage him to move notes just to the white notes, in hopes we could at least get something in C Major. It was during this process that I had an epiphany: instead of encouraging him to put everything on the white notes in the piano roll, why not encourage him to use only the black notes? The result would be a pentatonic scale, with significantly less opportunity for dissonance than without this constraint. We were both happy with this result. If you listen to the main theme of the game that plays in the background of gameplay, it is all pentatonics (after I helped him move a few errant tones to the black keys). The theme that plays on the title screen is an excerpt from the first piece he wrote that morning.

#1 Son, as mentioned earlier, has become fairly adept with Godot Engine. The code that he writes is still pretty messy, though, with names that don't always match functionality. He also makes amateur mistakes of perspective. We had an interesting conversation around the relationship between the player-controlled fish and the aquarium scene. I suggested that, instead of having the Aquarium script manually move the player fish around, instead we just have it tell the fish where the player touched. He said, "That sounds complicated." I responded that his perspective was upside-down. Coupling the player-controlled fish to the aquarium was complicated, but putting the fish's behavior into its own script was simpler. There's a sense in which we are both right, and it's just a matter of experience and its concomitant wisdom. Using my approach, though, I explained how we could then reuse this fish behavior in our enemy AI: both the player-controlled and AI-controlled fish had behavior determined by having a destination specified, but it was only a difference of who specified the destination.

We ran into a strange problem late in the game development. #1 Son and I had set up what we thought was a robust approach that would allow for easy adding of different kinds of enemy fish. However, when we got the new art from #2 son for the second enemy fish, it was a different size than the other. This meant that it needed its own collision shape, so we ended up making it a subclass of the original enemy fish. It felt to me at the time like switching to a delegation rather than inheritance approach would be better, but it wasn't clear that we could make this change fast enough for a jam. This approach worked, but we also had trouble that I still don't completely understand. The second fish was not detecting the flakes, but it seemed to have to do with its proximity to the bottom of the tank. We never did figure it out, but #1 Son came up with a workaround that involved using multiple physics layers and masks. Honestly, I struggle to think through the layers and masks system—it is not intuitive to me, so I was grateful that he was able to come up with a workable solution.

I hope you enjoy the game. We went for a nice family walk when we were done. Everyone shared something they learned during the day, and then I also asked each person to share either a question they had or something they wanted to try next. It was a fun, casual reflection session. I also mentioned to them that we could try a different jam format, such as giving everybody the same assets and seeing what they can make with it. #1 Son is adept with Godot Engine, and #2 and #3 can both use Construct. #4 Son and my wife would be left with paper prototyping perhaps. The big idea, anyway, is that I think they're excited to keep making things together, and maybe to try some different modes. Of course, I think #3 is just waiting for his chance to be in charge again so he can draw from his love of rockets and enjoyment of Totally Reliable Delivery Service.

Comparing the dice of D&D and PbtA with Math

A post by alumnus Austin Tinkel got me thinking about dice and probability, and by extension, how these things are often misunderstood even by those for whom rolling dice is an essential part of their avocation. His is a thoughtful post that covers a lot of ground, and I encourage you to read it. My point in writing this article is to address a fallacy that I see in his and many other RPG essays on the Internet, particularly those comparing Dungeons & Dragons to Apocalypse World and the Powered by the Apocalypse (PbtA) movement.

Here is a summary of the difference between these two systems. In the D&D line of games, random outcomes are determined by the roll of a d20 against a target number. For example, you might need to roll a 16 to hit a bandit with your greatsword. In this situation, any roll of 16 or higher is a success and any roll 15 or below is a failure. A character's environment or attributes might alter their role positively or negatively, but we can ignore those modifiers for now without loss of generality. Personally, I am keen on the ICRPG approach in which an entire encounter has a threat rating. For example, an abandoned castle may have a threat rating of 12, meaning that for any roll the players make, they need a 12 or better on a 20-sided die, whether that is to pick a lock, topple an evil shrine, or strike a zombie.

Games that draw on Apocalypse World use a different resolution system. Players roll 2d6 for any situation where there is a chance of failure. On a total of six or less, it is a failure; on 7–9, it is a partial success; and on ten or higher, it is a full success. Note the obvious property that this is a ternary system rather than a binary one. As in D&D, difficulty can be modified by the environment or character attributes, but as before, we can ignore this without loss of generality.

Here is where I see a lot of people make a mathematical mistake. I see fans of PbtA claim that these games are more likely to get partial success outcomes because of the outcome distribution of 2d6. There's a problem with this claim, though: more compared to what? It's true that 2d6 will give you results in the middle of the distribution more often, whereas a d20 will give each result with equal frequency. However, that does not imply that you get partial successes more often with 2d6 because it entirely depends on the target number for the d20 system. Remember: our simplified PbtA fixes the partial success target at 7, whereas the D&D approach leaves it unspecified.

The distinction can be clarified by using (you guessed it) math. It's helpful to switch from thinking about distributions to thinking about probabilities. The advantage that mathematical probabilities give us is that they are actually independent of the distributions that produced them. Consider: whether you are going for a six on a d6 or trying to draw one of 17 white cubes from a bag that contains 83 other colors as well, it's still a 17% chance. That's the beauty of math. (Note that I'll be rounding my percentages to the closest integer for this discussion, since that's all the precision we need.)

On 2d6, there is a 58% chance to roll seven or higher, and so there is a 58% chance to roll some kind of success in PbtA. This breaks down into a 42% chance of a partial success and a 17% chance of a full success. In D&D, you could get basically the same chance of success by setting the target number for a roll to 10, since there is a 55% chance to roll a ten or higher on a d20. The minor differences between percentages (58% to 55%) is certainly below the threshold that any player would notice the difference. Remember that the pertinent difference between the two systems is not in the dice themselves but the fact that D&D has binary outcomes while PbtA has ternary. If you wanted to set up a situation in D&D that mimics the mechanical structure of PbtA, set it up so that 10-17 is a partial success an 18-20 is a full success. This lacks some of the beauty of PbtA dice that I wrote about last year; namely, that 7 and 10 are memorable threshold values in a way that 18 seems arbitrary. It is important to note, though, that you end up with a mathematically equivalent system, because chance of success is a matter of probability and not distribution. Whether you want to let 20 still be a critical hit in D&D—or let 12 be a critical hit in PbtA—can be a topic for future religious wars.

It is interesting to turn our attention to the effect of bonuses in either game. In PbtA, if you have a +1 to a roll, your chance of getting at least a partial success jumps from 58% to 72%. Interestingly, because of the distribution, each successive bonus provides diminishing returns: the first +1 gives a difference of about 14%, while successive bonuses give 11%, 8%, 6%, and 3%, until you hit 100% chance of success. In a d20-based system, of course each bonus gives a flat +5% bonus. It seems like this should be a significant difference, whether your smallest possible bonus gives a +11% or a +5% boost. However, I suspect that our human brains are so bad at statistics that, in practice, the difference is undetectable by human experience. Another way to put that is that the psychology of a bonus is probably much more important than the distinction between perceived effects. This is only a hypothesis, however, and I think it would make an interesting study.

There is an important corollary to the previous point about bonuses. In a d20-based implementation of ternary results, you can move the goalposts more subtly than you can in a 2d6 system. In the same way that ICRPG has you set a target number for the whole ruined castle encounter, one could independently set the partial success target and the full success target in order to propel the narrative. I can imagine a pair of oversized dice to indicate each boundary value, starting at 10 and 18. When the players knock over the evil shrine, they release a curse that reduces the chances of anything going well, so the 18 becomes a 19: more partial successes, fewer full successes. Most of the time, that 5% difference would go unnoticed, but it becomes like a critical hit in traditional D&D. When someone rolls the boundary value, there will be excitement and fear.

That sounds a bit fiddly to me, and I would just play Dungeon World if I wanted a PbtA-style fantasy adventure rather than hacking the d20 system. However, if you have tried playing with variable outcomes in a D&D game, I'd love to hear from you.

I used AnyDice.com to help with the probability calculations for this post. It's a nice tool that I wish I had when I was working on my too-many-dice RPG in the 1990s.

Something like a Summer Devlog, Part 4: Flying Leap

The TL;DR

I made a thing! Download it from the itch.io or check out this short gameplay video:

The Whole Story

As predicted in my previous post, I decided to participate in the 2020 Unreal Spring Jam. I have never participated in this jam before, but it seemed to come at the right time for me to explore something new. My May prototype had essentially been abandoned, and I wanted to make something interesting and publishable before having to switch gears to preparing for an as of yet uncertain Fall semester.

The jam was supposed to have started with a livestream, but for undisclosed reasons, Epic simply posted the theme to their variuos channels. I expected the same kind of theme I've seen in Global Game Jam or Ludum Dare, so I was caught off-guard by this one: "What is hidden in snow comes forth in the thaw."

About the Theme

It was amusing to watch the confusion on Twitch that went along with this theme announcement. I think many people were not expecting something like this. It could be interesting to see how much of the confusion was from people whose English is weak versus those whose poetry is weak. There were plenty of comments like, "So we have to have snow in the game?"

What struck me as most interesting about the theme, though, was how it seemed, inexplicably, to have a dark tone. Despite my efforts at whimsy, my mind kept turning to themes of people with secrets they never wanted revealed, but which would inevitably be revealed. The theme also pushed me toward storytelling, toward a narrative style of design, to capture these dark themes. This struck me as interesting because I know what actually is hidden in the snow that comes forth in the thaw: life! There's nothing dark nor morbid about spring blossoms and vernal pools.

Perhaps a key to this interpretation is the use of the passive voice: "what is hidden..." It implies an unknown actor with agency rather than natural systems. It would be an interesting experiment in creativity to take another group and give them the variation, "What emerges in spring," then see what kinds of games they make.

I spent a few hours thinking about the theme, comparing it to my mental lists of genres I want to explore and technology I want to try. It got rather frustrating, which is likely why I escaped too frequently to look at the funny comments on the jam Twitch page and Unreal Slackers channel.

One of the difficulties I had in conceiving of a good idea for the jam is that, as usual, I wanted to make a game in which the mechanisms reinforce the theme. I'm not as interested in making narrative games as I am in system-based ones, but the narrative edge of that theme kept cutting at my imagination. Eventually, I decided to punt and make a game about an idea that had been kicking around in my head for a few weeks anyway, and I could wrap it loosely in the theme as I went.

Flying Leap

I had a vision a few weeks ago of a game in which you control the arms and legs of a humanoid character as you hurtle through space toward your opponent—think wire-fu meets ragdoll physics. I had heard talk of Unreal Engine's Control Rig system, and I finally found an excellent explanation of how to use it on a little-known podcast. Finding this link was one of many times I have been grateful for the helpful folks on Unreal Slackers. I had actually built a very minimal tech demo of Control Rig in the days leading up to the jam, so it was fresh in my mind. I decided to go for it.

Unfortunately, not long into the development, I ran into a bug. I had actually seen it in my little tech demo leading up to the jam, but I had dismissed it as my own misunderstanding. After getting into it with a project in mind, there was no avoiding it: something seemed to be wrong with Control Rig's "propagate to children" option. To make a long story short, I lost a few hours to this before deciding to just abandon Control Rig as an approach, but that didn't stop me from pulling together a bug report. As of this morning, the bug has been recognized by Epic's QA team. There's a certain relief that comes from having someone at Epic tell you that, indeed, something is wrong, and it's not just you doing something wrong.

If I could not use Control Rig to manipulate a character's limbs, what's another option? I came across this four-year-old live training video from Epic that gave me a path forward: physical animation. A quick tech demo showed me that I could use the physical animation component to control the limbs of a character while blending that with forward kinematic animation, and then when necessary, flip over to ragdoll physics.

Another of my goals for the jam was to use some of the low-poly assets from Synty that I had bought as part of a Humble Bundle deal. Browsing my library, the Samurai pack caught my eye, and I could see a far-eastern theme matching the crazy control scheme. I brought in a few characters from the pack and retargeted the Mannequin animations to them.

I built a test level using other assets from the pack, enough of a level that I could get the gameplay working. Later into the project, I rebuilt the level more intentionally. I had never really done any significant level design before. The levels in Kaiju Kaboom were my first time using the landscape tool, but there wasn't much to them. For Flying Leap, I created the level out of meshes, placing scenic items here and there. It was also my first time using the foliage tool to place some flowers and bushes. I wonder what a level design professional would think of it. I'm sure it's not great, but I think it suits the purpose. The one part I am particularly proud of is the arch set back in the mountainous area, which implies a path through the mountains that doesn't actually exist.

Here's an interesting technical detail that I discovered which really surprised me. In the game, you control your left arm with the left stick and your right arm with the right stick, and you control your legs with the shoulder and trigger buttons. At first, I used axis mappings for both sticks in order to read the values and apply them to the physical animation. It was not behaving as expected, and I discovered that on the left stick, pushing forward was positive Y and pull back was negative Y, but on the right stick, pushing forward is negative Y and pulling back is positive. While it may be true that this matches a conventional use of game controllers, where the right stick is controlling a camera, it is really counterintuitive for development. Why should the two sticks map to different values? Fortunately, there's an easy way out: if you listen for events instead of axes, the problem goes away.

Fun

Is it fun? Well, my four boys think so, and there's a real sense in which that's all that really matters. I did have something of a crisis of faith around Sunday night. I had hoped to have core gameplay done over the weekend so that I could spend two days just on polish and juice, but technical problems and misjudgements meant I was still struggling with the core gameplay. For example, one thing I should have seen coming is that there's no technical difference between my punching your torso and your torso “punching” my fist. In any case, around Sunday I was developing misgivings that the game was not fun. It certainly worked as a toy, but I had a hard time finding the game. In the spirit of jamming, I decided to charge forward and just make it as fun as I could.

The core mechanism I ended up with is that you have to strike with your hands or feet in order to get any points, and that first strike will give an impulse to the opponent that scales quadratically with the speed of the strike. This has some fun effects when you pull it off, but recognize that because of the unconventional controls, it is kind of hard to pull off. Also, there's a related problem: in order to get any kind of reasonable collision in mid-air, both characters have to go ragdoll at the time of the first strike. Otherwise, the ragdolled one will fly right through the kinematic one. The result is that if I hit you with great force, you spin out of control, hit me with a very-fast-moving limb, and then I spin out of control as well. I ended up having to clamp the possible impulse values in order to mitigate this. It seemed like the right thing to do for the game, even though without it, the results were pretty funny.

Points aren't earned directly for the strike, although perhaps that would have made sense. I liked the idea of trying to push the opponent back as far as possible, so I made points earned for the distance you travel from your starting location. Originally this was measured in centimeters, but right before the end of the jam, I pulled it back to meters. In retrospect, decimeters probably would have been a good value, since now it's hard to differentiate and you get more ties than intended.

There were many ideas that I did not have time to pursue in the game. For the sake of sharing, here are a few that I think would make for good experiments and potentially add enjoyment.

• Give bonus points for varying how you hit the opponent (right foot, right hand, left foot, left hand).
• Allow for varying speeds of approaching the leap, to permit aggressive vs conservative strategies.
• Allow slight left or right deviations from a straight line path, so you can try to line up an intentional strike with the other side's limb.
• Headbutts, butt-strikes, and related acrobatic bonuses.

This is a good place to share one of the most interesting things I discovered during the design and development process. As the characters approach each other, there is a time dilation effect that I quite like. It probably should be more obvious in the finished game, since I had toned it down a bit during testing. In any case, during development I decided to add a soundtrack, and I was glad to find some wonderful public domain arrangements of traditional Japenese music. I chose one to play as a theme during character selection, and I set up another three or so to randomly play during the battle. However, during testing, I realized that this was actually working against the time dilation design: because the music proceeded at a continuous rate, it made the intentional dilation look like a buggy slowing down of the physics simulation. I ended up pulling out the music and instead just playing a subtle wind sound during the battle, and the music comes back after the round is over. Indeed, I think this alternate audio design is actually better, but I wouldn't have gotten there if not for the observation about how the music and the gameplay were working against each other.

Another feature that I would have liked to add is a way to access what I called “Limb Test Mode.” I have a level set up that loads up a character and lets you just experiment with the control scheme. It's actually kind of a fun toy in itself. I just ran out of time to incorporate it in a useful and accessible way into the game.

Let me wrap up my thoughts on fun my sharing what I think is the best part of the game: the narrative. Another thing I'd never really done before is add any kind of authored story to the game, but in Flying Leap, there is one that plays on the main screen. I had experimented with some different approaches of trying to convey the minimal story of the game, and I ended up with a simple text overlay. If you have the game, even if you cannot play it with some friends, I'd love to know what you think.

Other Thoughts

Five days is too long for a jam. Five days is a job, not a jam. I put an unhealthy number of hours into Flying Leap. Sure, I took some time to walk or bike with my family and throw the frisbee around, but I figure I worked about thirteen hours a day on average. It was fun, and I learned a lot, but I'm still not sure it was good. A 48-hour jam like Ludum Dare or Global Game Jam is a good timeframe to put your head down and sprint. For five days, though, this project absolutely dominated my attention. It's a bit much. That said, I don't know if I would do it differently if I could go back. When I think about the things that I would change, they are mostly about not wasting hours going down blind alleys and dead ends.

To sum up, through this project, I was able to explore several ideas and technology that I had never used before. While Control Rig didn't work out, this was the first project of mine that included: physical animation; incorporating ragdoll physics into actual gameplay; level design; retargeted animations; 3D gameplay with local multiplayer; incorporating explicit authored narrative; sublevels; C++ implementation of custom UI widgets; and level streaming.

Now after having spent ridiculous number of hours on it over the past five days, I've spent all afternoon on this write-up. Time to call it a wrap. Thanks for reading, and if you have a chance to try out the game, let me know what you think.