Wednesday, April 17, 2019

"Who Would YOU Rather Work With?" A classroom game show for my HCI class

On Tuesday last week, my HCI class gave their informal reports for the first iteration of their final projects. I neglected to post any real guidelines about the presentation, and so it was ad hoc. We did have two guests in the room, though, one being an expert user for the projects and the other being a software development professional. There were several points in the students' presentations when I cringed at how they presented their status and ideas. I considered for a while how to address this, and I ended up coming up with a classroom game show called Who would YOU rather work with?

This is a rhetoric game along the lines of The Metagame and CARD-tamen. There are two teams, each of which sends up a player for the round. The two contestant are shown a pair of fictional quotations, and based on these, must argue for who they would rather hire onto a team. We alternated which team went first, and each player had 30 seconds to make their cases. The winner was determined by popular vote. Even though a team could just vote for their own representative, I think the students understood that it should be a fair vote.

The original idea for the game was Is it User-Centered... or Not?, but I realized as I started working on the game systems that user-centeredness was only part of the equation. More of the problems were with students' rhetoric than with their technical or procedural approaches, and hence my choice to make this a rhetoric game.

We played the game last week Thursday. I had the students count off by twos in order to shuffle them around, so they would not be on a team with the person they usually sat with. The two teams named themselves The One Before Two and Los Dos. (Important note: The One Before Two insisted that the short name of their team was TOBT, pronounced "tot" with a silent "B".)

Here are the prompts that I gave them:

1.
"The images take a long time to load, so the user just has to learn to wait."
or
"We will show a spinner to signify to the user that the system is still working."

2.
"JavaFX is a pain. It's really fiddly."
or
"We thought we knew the JavaFX API better than we actually did. We talked about it and identified our main misconceptions, and we are working to overcome them."

3.
"We were all really busy so we did not work on that feature."
or
"We documented that feature as a user story to consider for the next iteration."
[or, in a bonus round, "That feature is out of scope."]

4.
"Git kept on destroying our files. It doesn't do what it is supposed to do."
or
"We had problems managing version control, and one of our impediments is our own understanding. We have prioritized finding the root cause so that it doesn't happen again."

5.
"We are making this application using Java and JavaFX because Dr. Gestwicki provided an example with these."
or
"We have analyzed our target population's needs and have chosen a development platform that allows us to deploy a solution that meets their needs."

6.
"We did a lot of work that you cannot see exposed through the UI right now, but it will be incorporated into the next iteration."
or
"Our source code provides the simplest possible solution for this iteration that maintains our standards of quality."

7.
"We are not sure if this is an SRP [Single Responsibility Principle] violation or not."
or
"We have evaluated our code for compliance with SRP and, where we were unsure, we consulted with the professor to evaluate the structure."

8.
"We know that what we have planned for iteration 2 is going to solve our problem."
or
"We learned from iteration 1 to help us improve our product and processes for iteration 2."

9.
"We based our work on Dr. Gestwicki's example."
or
"We built a solution for this problem based on our users' specific needs."

The last one is quite a bit like #5, but that was in part to handle the case where everyone actually showed up to class and would get a turn. Of course, not everyone showed up to class, so we had enough questions that some people got to answer two.

One of the students hypothesized out loud, in round three or four, that the bottom answers were always "right." I pointed out that this was a rhetoric game: there was no objectively right answer, but rather a challenge to persuasively argue your position. Once the game was over, I explained to them that there was indeed a pattern, of course. The top item was more or less what I heard people say during their presentations, but the bottom is what I would have like to hear instead. This caused a murmur in the crowd as they considered what this means. It gave us a good excuse to talk about how you present yourself when applying for a job or internship: that the applications will be sorted into two piles, and you want to make sure you end up in the "Let's talk to this person" pile.

For the most part, students argued that they would rather work with the second person on each slide, using the kinds of arguments you would expect. The statements on the bottom tend to show capacity for reflection, eagerness to learn from mistakes, honesty, professionalism, accountability, and user-centered rather than developer-centered. However, it was not the case that everyone argued for the bottom. On #3, a student argued that the person on top was simply being honest, not really making excuses, while the person on the bottom was being political to the point of dishonesty.

In the end, it was a close game, with TOBT winning 5 to 4 over Los Dos. I think the students appreciated the interactivity and how everyone got a chance to speak their piece. When it was all over, I walked through the slides again to talk through some of the issues that came up, so I guess they didn't really get a reprieve from hearing me lecture to them. However, I think they felt like they had some skin in the game now, since they had already shared their thoughts about each issue.

Tuesday, April 16, 2019

Mapping Introductory Game Design to CS2013

Regular readers may be wondering why I was looking at the learning objectives of CS2013, the ACM/IEEE recommendations for Computer Science curricula. The answer is that I am in the process of putting together a proposal for a new Introduction to Game Design elective in my department.

For the past several years, I have been teaching an Honors Colloquium on Game Design in the Fall semester. This has been very rewarding, but it is only made possible by internal funding from the Immersive Learning program and the good will of both the Honors College and the Computer Science Department. I believe it is time to formalize this class and bring it into my home department. This has a few implications, one being that I have to explain to my colleagues the relationship between Game Design and Computer Science. I suspect that they, like many outside the discipline, have never carefully considered the distinction between Game Design and Game Programming—the latter of which is an elective that I teach here. If I can get their approval for the course, it will allow me to build a more reliable pipeline of prepared students, which means we can explore more ambitious game development projects.

One of the ways I am planning to make the course appropriate as a departmental elective is to give it a one-semester programming prerequisite. While it's true that this will allow us to do a little programming in the game design course (such as in Twine), primarily I want to be able to use programming as a lens for considering system analysis. One of the real values of learning to program is that it teaches you to think through complex problems and serialize the steps of a solution. This is, essentially, writing the rules of a game. It's something that I've seen some of my past non-CS Honors students struggle with, and it's a skill that I see good programmers take for granted.

That's sufficient background for me to get back to the CS2013 mapping. Below is a list of the knowledge areas and topics that I see as being covered in an Introductory Game Design course that would be housed in a Department of Computer Science. With each topic, I have indicated whether the ACM/IEEE recommendations include minimum contact hours and at which tier.

  • Human-Computer Interaction:
    • HCI/Foundations [4 Core-Tier1 hours]
    • HCI/Designing Interactions [4 Core-Tier2 hours]
    • HCI/User-Centered Design and Testing [Elective]
    • HCI/Collaboration and Communication [Elective]
    • HCI/Design-Oriented HCI [Elective]
  • Platform-Based Development:
    • PBD/Introduction [Elective]
  • Software Engineering:
    • SE/Software Project Management [2 Core-Tier2 hours]
  • Systems Fundamentals
    • SF/State and State Machines [6 Core-Tier1 hours]
  • Social Issues and Professional Practice
    • SP/Professional Ethics [2 Core-Tier1 hours, 2 Core-Tier2 hours]
    • SP/Intellectual Property [2 Core-Tier1 hours]
    • SP/Professional Communication [1 Core-Tier1 hour]
For most of these, the course could cover all the core hours. For SE/Software Project Management, which I wrote about last week, team-based projects in introductory game design could hit the objectives as well as anything else, despite the products being analog rather than digital. The only place where the proposed course would clearly not fully satisfy the recommendations is SF/State and State Machines. These provide useful tools for describing the behavior of games, but we would not use a rigorous form of them and probably not spend more than an hour on their explicit treatment. It may be worth noting that some past offerings of my game design class provided an optional exercise with the formal design tool Machinations, but no one ever took me up on that.

It may be worth noting that all the core hours of those objectives above are covered elsewhere in the curriculum, although not all in required courses. HCI/Designing Interactions topic is only met in the HCI elective course, and this deficiency was noted in my department's recently-written self-study. The SE topic is ostensibly covered in the senior capstone, and the SP in our required one credit-hour professionalism class. However, I think it's worth repeating aphorism that it doesn't matter what we cover in the curriculum: it matters what our students uncover.

Of course, introductory game design primarily is teaching game design. This mapping exercise is to help me frame this work for any potential skeptics in the department. The result of this exercise belongs in the Course Rationale portion of the master syllabus. My next step is to define the learning objectives and assessments for the course proposal, which defines more clearly what the course is about. Here, I can focus more on fundamental principles of design, which I was disappointed to see are not directly addressed in CS2013. 

Saturday, April 13, 2019

Questioning the value of CS2013

I recently had cause to re-read the ACM/IEEE CS2013 curriculum recommendations. This document is created by a large committee of content experts to provide guidance to Computer Science undergraduate programs. On one hand, it's a useful articulation of the body of knowledge that constitutes "Computer Science". On the other hand, well, let's take a closer look.

The CS2013 document breaks down Computer Science into knowledge areas such as Discrete Structures, Human-Computer Interaction, Operating Systems, and Software Engineering. Within the Software Engineering (SE) topic is a section called SE/Software Project Management. The section contains "2 core Tier2 hours", which means there are two recommended minimum contact hours on the topic, and they should be in a non-introductory course. For those who don't know the higher education jargon, "contact hours" means "students and faculty together in a formal meeting" such as a lecture. According to US financial aid legislation, and therefore according to practically every domestic institution of higher education, a student is expected to engage in two additional effort hours for each contact hour. For example, a student is expected to read, study, or work on homework for two hours for each one-hour lecture.

The core topics contained within SE/Software Project Management are as follows:
  • Team participation
    • Team processes including responsibilities for tasks, meeting structure, and work schedule
    • Roles and responsibilities in a software team
    • Team conflict resolution
    • Risks associated with virtual teams (communication, perception, structure)
  • Effort Estimation (at the personal level)
  • Risk (cross reference IAS/Secure Software Engineering)
    • The role of risk in the lifecycle
    • Risk categories including security, safety, market, financial, technology, people, quality, structure and process
That's a lot of topics to cover in two hours of lecture and four hours of studying, but I could see it being all combined into a breakneck chapter of a Software Engineering textbook. Note that there are additional elective topics within SE/Software Project Management, but we won't consider those for this discussion.

Part of the ostensible value of CS2013 is that it doesn't just provide a topic list for each section of a knowledge area: it also provides learning outcomes. These are classified in a system inspired by Bloom's Taxonomy of the Cognitive Domain, so each outcome can be at the level of Familiarity, Usage, or Assessment. These are defined on page 34 of CS2013, and we can summarize them as basic awareness, ability to deploy knowledge concretely, and being able to consider from multiple viewpoints—as one would infer from the nomenclature. These, then, are the learning outcomes for SE/Software Project Management, as listed on page 177 of CS2013:
  1. Discuss common behaviors that contribute to the effective functioning of a team. [Familiarity] 
  2. Create and follow an agenda for a team meeting. [Usage]
  3. Identify and justify necessary roles in a software development team. [Usage]
  4. Understand the sources, hazards, and potential benefits of team conflict. [Usage]
  5. Apply a conflict resolution strategy in a team setting. [Usage]
  6. Use an ad hoc method to estimate software development effort (e.g., time) and compare to actual effort required. [Usage]
  7. List several examples of software risks. [Familiarity]
  8. Describe the impact of risk in a software development lifecycle. [Familiarity]
  9. Describe different categories of risk in software systems. [Familiarity]
It's pretty clear to me that it's impossible to meet those nine objectives in two contact hours and four out-of-class work hours. Even if we assume that each student is perfectly capable of independent learning and studying, the time required to make any meaningful knowledge about these items is certainly greater than the recommended hours. I recognize that I am making assertions here and not arguments. In an earlier draft of this post, I tried a more rigorous argument, but I realized that a true skeptic could always counterclaim that they could meet these goals within the timeline. The real difference would not be the time required but our mutually exclusive definition of what it means to meet a learning objective.

It seems to me, then, that there are only two ways this could be approved by a committee. The first is that the committee has no functional understanding of contemporary learning theory. If that were the case, then why should anyone take their recommendations for curricula seriously? The second option is negligence, that the committee as a whole knew better, but they did not verify whether their recommendations and the learning objectives actually align. If that's the case, then why should anyone take their recommendations seriously?

Saturday, March 23, 2019

Rolling 2d6 in PDQ and Apocalypse World: Learning the Numbers

I am supervising two students in independent study projects this semester. One of them is working on a tabletop RPG, and I want to share here a topic that came up on our group's online chat.

I have fiddled with Chad Underkoffler's PDQ a few times over the years, running some short-lived campaigns with my boys. I wrote about one of my favorite aspects of PDQ several years ago, how it models the psychology of learning in a more realistic way than many mass-market games. You can find the PDQ Master Chart in this free PDF, and I'm reproducing it here for convenience:
I remember that every time I played a PDQ session, I would have this simple chart in front of me. I never got to the point where I internalized it, although I'm sure I would have with time. Let's look at some of the structural properties that make it learnable. First, "average" quality is 0, which is simple: a regular person has no bonuses or penalities. Going up or down in quality is in steps of two, which I like from a mathematics point-of-view because it's statistically meaningful in a way that, say, a +1 on a d20 is almost insignificant. For the Difficulty Ranks, there is a sensible centering on 7 as "a straightforward task." Anyone who picks up the rulebook is going to know that 7 is the most likely result on 2d6, so this gives a memorable default. Difficulty Ranks also move up and down in steps of two, which again I think is a much better choice than fine-grained quanta, especially since this is supposed to be a narrative-heavy game rather than a simulationist one. (PDQ stands for "Prose Descriptive Qualities" after all.) I never had problems with the centers of these scales, but I did find it hard to remember, say, the difference between a Difficulty Rank of 11 and an 13. Also, for reasons I cannot quite explain, I find -2, 0, +2, +4, +6 to be much easier to remember than 5, 7, 9, 11, 13, even though they are the result of the same function, just applied to different inputs.

My student who is exploring tabletop roleplaying game design has been inspired by the Powered by the Apocalypse movement, which, briefly, describes a family of designs that are inspired by Vincent and Meguey Baker's Apocalypse World system. I backed the Kickstarter for the second edition of Apocalypse World a few years ago on a forgotten recommendation from a respected designer: I think it was someone like Robin Laws or Richard Bartle who posted about the campaign, saying that anyone serious about game design should support it. It's a riot to read, but it's certainly not the kind of thing my kids are quite ready for yet!

The mechanisms of Apocalypse World that I want to focus on here, though, is resolution of moves through rolling 2d6. These are the only dice used in the system, and it works like this: with less than a 7, it's a failure; between 7 and 9, it's a partial success, and 10 or higher is a complete success. That's it. This is truly elegant for a system that is designed for narrativist gameplay.

A funny thing happened when my student was testing his RPG with the research group. In order to make the game learnable to new players, he put this dice resolution system into a chart and set it in the middle of the table. He himself referenced the chart a few times while we played the game, despite his being the designer and a regular player of Blades in the Dark, another PbtA game. Curiously, the Bakers don't actually have a chart in Apocalypse World second edition at all; they just describe it in prose.

This got me thinking about the specific values used by Apocalypse World, similar to how I analyzed the PDQ Master Chart. Once again, we have 7 as a prominent number: it's the most likely value on 2d6, and it sits at the threshold between failure and partial success. It is, in a way, the easiest number to remember as being significant on 2d6. The next threshold value is 10, which marks the lowest value that represents a full success. Ten is the first double-digit number possible on two dice. It's also, for most people, the number of fingers you have. It's the base of our counting system. A "perfect 10" cannot be beat. 7. 10. Got it. Two numbers, that's the whole system in a very small amount of memory.

Just to be clear, I think this is brilliant. I don't think you could pick two different numbers that would be better for breaking down 2-6 in a more memorable way. I wonder if the Bakers chose these numbers because of their interesting properties or if it was done with intuition and luck.

We had a brief discussion in my research group meeting last week about adding 2d6 vs. counting success on variable numbers of d6. For example, the question was raised, can most players more quickly add 2d6 or count how many of an arbitrary number of dice have rolled above 4? I argued that for anyone who had spent any appreciable time playing tabletop games, rolling 2d6 can be done purely with pattern matching: I don't add five pips and the three pips, I just see a representation of the quantity "8". I mention this here because I think it's a good games research (or perceptual learning) question, but I haven't checked to see if anyone's explored this yet.

Finally, I'll mention that, with the little bit of testing we've done on my student's game, I've grown quite fond of the "partial success" idea. My favorite expression of this as a story device is that you succeed, but at a cost.

In case you were wondering about the dearth of posts here: I've been meaning to write more about my research group activities this semester, since it's been very rewarding. I hope to write up some kind of summary at the end of the semester at least. However, the past few weeks, my attention has been pulled away into a departmental self-study report. I think the sections I have been spearheading are strong, but it's had a significant impact on my research time as well as my reflective writing time.

Saturday, March 16, 2019

Painting Middle Earth Quest

Here's a project that was years in the making: painting the miniatures from Middle Earth Quest.
Middle Earth Quest is an asymmetric one-vs-all game, one player as Sauron and the rest as heroes of the Free Peoples of Middle Earth. The setting is between The Hobbit and The Lord of the Rings, as Sauron is establishing his foothold while the Free Peoples are trying to rally to face him. This is a game that I remember being fun, although I haven't played in years. How do I know that? Well, if you go way back to a post from December 2014, I mentioned that I had painted Argalad, one of the heroes, and I know I primed and based them all in one go. I have another post from July 2015 in which I described how I painted the Witch King. Some time after that, I painted Gothmog, and I started the Ringwraiths, and then the figures sat around for years, first on my painting table, and then in a box. Some time in between, Fantasy Flight Games removed all reference to the game from their site, so it looks like there won't be any more printings or expansions; it must not have sold well.

I actually had Argalad, the Witch King, and Gothmog sitting on my desk the whole time, at first because I liked how they looked and wanted to inspire myself to continue the set, and then because of inertia. A few months ago, #2 Son finished reading The Hobbit, which got me thinking about this game again. Would he enjoy playing this game, now that he's older and knows a little bit of the LotR lore? Maybe it was time to finally get back to the Ringwraiths and finish this set.

Without further ado, here's a quick summary of each of the figures from this game. I'll start with the ones I painted some years ago and then move through them in the order I addressed them.


Argalad is the token elf. Or is that Tolkien elf? I remember being quite pleased with him at the time, and I spent quite a while on him. It's worth noting that all these figures were primed in black, because that's how I was working at the time, when I was less than a year back into the hobby. I'm sure it was all done with layering and some washes, but the only part that really sticks in my memory was the silver embroidery on the cape. That was done by mixing silver paint with Future Floor Polish, which flowed really well into the engraved pattern on the cloak.


There's a whole post about the Witch King of Angmar, so I'll just leave you to check the link if you want to read about that.

Here is Gothmog, who I painted some time between winter 2015 and now, but certainly nearer then than now. I know I gave him quite a bit of time, but I don't remember much else about the process. He's pretty dark, but I did want all the villains to have clearly dark color schemes. I remember that, playing the game, it was sometimes hard to tell at a glance who was heroes and who was villains. This is particularly difficult for the two upcoming horse-riding figures. As you'll see later, I think I did meet the goal of having the "sides" of the game clearly contrast.

Now we move into the figures that I have painted in the last few weeks. It was interesting, but also frustrating, to come back to these figures—especially the Ringwraiths. At the time I started this project, I thought it was a good idea to prime in black (as Dr. Faust does) and also to work on the bases first. All of these figures were in jet black primer but with painted bases. If I were to start the project today, I would build the bases, use zenithal priming over the whole figure (as I started with Massive Darkness), paint the bases, and then paint the figures. I thought about re-priming the figures, but I decided it would be a fun to try to keep them as I started them, as a sort of artistic archaeology project.


Getting into the Ringwraiths reminded me why I stopped this project. Horses are the worst. These figures are pre-assembled, so there are lots of hard-to-reach areas on the miniature. The sculpts are not very good, with flat-faced hooded men. It's also black-robed guys on black horses. It's hard to think of anything that could make this a worse project! I had indeed started painting the horses some four years ago, but it was hardly noticeable: I had done very faint layered grey highlights and then given up.

I recently watched Dr. Faust's episode on highlighting black in which he mixed a few different tones of black onto one figure. (Ironically, that figure is not primed in black!) He suggests that in most cases you wouldn't mix blacks on one figure, but looking at the Ringwraiths, I thought this would be good exercise if nothing else. I mixed a warm black by adding some VMC Flat Brown, which I used for the horses, and then a cool black by adding VMC Deep Sky Blue, which I used for the robes. I overhighlighted the robes in the first pass and then used a black ink glaze over the whole thing to bring it down. Unfortunately, I used my Liquitex Glaze Medium for this, which left the robes super glossy. I knew my matte varnish would take that away, but it made it really hard to compare the blacks of the robes with the blacks of the horses because the glossiness contrast dominated the viewing.

These guys sat on my desk while I painted the rest of the series too, but in anything but the best light, they really just looked like a black blob. I did go in and touch up the highlights on the robes, even before varnishing, and I also punched the leather parts way up. I had been going with a dark leather look, because wouldn't you put dark leather on your black horse if you were a black rider? Yes, you would, but it wouldn't help your miniature any.

In the end, they still look like a bit of a black lump, but at least they're done, which is better than they have been in years.


Here's the Black Serpent. The last thing I wanted to paint after the Ringwraiths was more horses, but decided that getting the horses done was actually the best thing for me to do. I think it turned out fairly well, although it was working on this one where I made a conscious decision that the rest of them would only be "good enough." I was much more interested in getting this set done than in making any showpieces. Also, these sculpts are not very good. The game is from 2009, which is before these sorts of miniatures became centerpieces of marketing strategies a la Kickstarter. The frustrating was exacerbated by the fact that I didn't used to spend as much time cleaning mold lines and flash off of the minis, so some have some awkward tags and creases.

Let me mention a funny thing about the capes. All the caped figures have designs on the capes, but these designs are actually etched into the cape. This makes them look decent unpainted, but it's not actually how a design on cloth "works." Also, this is a place where the detail is not very clear, so it's hard to see the real edges. Argalad's cape turned out pretty good, and I thought about doing something similar with the Black Serpent. However, as I worked on the cape, I realized that if he's truly "The Black Serpent," then he really should have a black serpent on him, shouldn't he? I'm glad I used the etched design as a border here rather than anything else, since it provided convenient lines to paint in, and the paint job makes the actual etching invisible.


The last of the villains is the Mouth of Sauron, who I remember being one of my favorite cards in Middle Earth: The Wizards, which of course remains the grandest Middle Earth game adaptation ever created. In any case, in keeping with the "make the villains wear black" theme, I decided to go with a cool black and warm, maroon trim. This provides a nice contrast both in temperature and in hue but keeping relatively similar saturation. I think the metallic and bone provide more visual interest to the figure as well, so although he's only a few colors and relatively simple, the result is nice.


Which hero to start with? The one one the horse, of course. This is Eomer, clearly from Rohan. He took the most time out of any of them, in part for his size and in part because of his detail. There are lot of greens, browns, greys, yellows, and golds on the card art that don't exactly match those of the sculpt, but it comes close. I also think I did a decent job of the horse, which was done almost entirely with layering.

The cape is the weakest link. I tried to reproduce my approach from Argalad and make it look like there is gold embroidery on his cape. The details on this cape were too ambitious for the casting, however, and it's kind of hard to tell what's going on there, unlike the simple border of Argalad's. I decided to keep it rather than repaint it. Good enough, I say, and most importantly, no more horses.


Next up is the figure that I have long considered the worst of the bunch: Thálin. He's basically a lump of plastic. All right, maybe he's not all bad, but if he stood up and let his arms rest, they would reach past his knees. Also, his back is clearly sculpted to be a natural material of some kind, but who would want to leave their back so unprotected? It's an odd piece.

Whereas the cloaked heroes have etched designs on their cloaks, Thálin's are in his ... is it a tabard? A loincloth? I'm not sure. Anyway, on the card art there's a clear yellow-on-red pattern here, and I copied that idea onto my painting. This part is actually really strong, adding visual interest to an otherwise leather-and-metal warrior.


Berevor is a ranger who provided a chance to play with shades of green. I think the different greens look good together, with enough difference to be visually interesting, and the brown leather bits give her a good earthy tone. The slightly bluish color also adds a bit of cool contrast to the more dominant warm greens.


Last up is Eleanor from the White City. She has really sharp contrasts between her dominant colors, which I think came out strongly in the painting. I originally had the tree on her chest painted in white also, but looking again at the card art, it was clearly silver. I painted that over in silver, while the rear is simply white. I think hers is another case where a fairly limited palette makes her visually distinct and interesting, without needing lots of bells and whistles.

I'm glad to have this set complete, and I look forward to getting these to the table some time soon. Re-reading the rulebook, I was reminded about how it is a bit fiddly, which makes me question whether #2 son would find it interesting or frustrating. We'll see. A nice thing about games is that they don't go bad, so I can always put these guys back in the box they were in for so long, and revisit them when the kids are at the age and interest to want to try it.

As seems to be customary for many of my painting posts, I want to close with a comment about the photography. My first two rounds of photos did not turn out well for the usual reasons: using the default camera app, I was getting light and dark lines from my lamp's frequency, and using Open Camera to adjust the shutter speed, I was getting poor color temperatures and washed out images. I ended up doing a different physical layout, as shown in the photo below:
I tried to make sure the lamp was pointing at the figure, which leaves the background slightly in shadow. If you look again at the photos, you see a slight gradient, which I think is fine though not artistically intended. Using Android's default camera app, I was able to eliminate the lamp-lines by raising the exposure to 0.7. Doing so manually meant that I could not refocus without it dropping back to 0.0, so I tried shooting all the figures without refocusing. This worked on some but not others, the latter of which I had to shoot again. If I were to do it again this way, I would have just focused each time and then adjusted the exposure, so as not to waste time taking out-of-focus shots.

Thanks for reading this tale of my multi-year project to paint Middle Earth Quest! As always, feel free to leave a comment.

Friday, February 15, 2019

Counting plays with a specific player on Board Game Geek

I started logging all my board game plays on BoardGameGeek in January 2016. In writing my end-of-year game reports (2016, 2017, 2018), I have wondered how many games I played with specific players during the year, but this proved to be a difficult number to find. The unofficial BoardGameGeek app that I use tells me how many games I have played with players in total, but this cannot be filtered by date. (Incidentally, I just discovered, when attempting to link to the app, that it is currently missing from the Google Play Store but that the author is working on getting it updated.) I asked a few friends over the years, but nobody knew of a way to get the data I wanted back out of BoardGameGeek. However, I am working on a scholarly piece for which this is important information, and so I decided it was worth some effort to figure it out.

BoardGameGeek provides an XML API for programmatic access to its content, including play data. Let's say for the sake of example that there is a user named "sample", and I want to get all their plays between January 1, 2016 and December 31, 2018. This query will provide a good start:

 https://boardgamegeek.com/xmlapi2/plays?username=sample&mindate=2016-01-01&maxdate=2018-12-31  

The results are limited to 100 per page, but there is no way to ask how many entries exist. Hence, to get all the data, one has to go page by page until the page is empty. Accessing a particular page of data is a simple matter of adding a page=N parameter to the end of the query.

I'm not interested in all plays, though; I am only interested in plays with a particular user. In my case, I am looking for matches by a given name and not a BoardGameGeek username, since this is how players are most easily added through my app. If I wanted to get all the plays with, say, Norm, than I need to dig into the XML and only count those where there is a "player" element with the value "Norm". For this, I can use XPath via xmllint.

After refreshing myself on some Bash fundamentals and finding this beautiful, idiolectic way of creating a do loop, I ended up with this script, which counts plays between BoardGameGeek fake user "sample" and his imaginary friend "Norm" between January 1, 2016 and December 31, 2018.
 #!/bin/bash  
 COUNT=0  
 PAGE=1  
 while  
   echo "Processing page $PAGE"  
   xml=`curl -s "https://boardgamegeek.com/xmlapi2/plays?username=sample&mindate=2016-01-01&maxdate=2018-12-31&page=$PAGE"`  
   plays=`xmllint --xpath 'count(/plays/play)' - <<< "$xml"`  
   pagecount=`xmllint --xpath 'count(/plays/play/players/player[@name="Norm"])' - <<< "$xml"`  
   COUNT=$(($COUNT + $pagecount))  
   PAGE=$(($PAGE + 1))  
   echo "Page $PAGE result is $pagecount out of $plays, so total is $COUNT"  
   [ "$plays" -gt 0 ]  
 do  
   :  
 done  

I learned a few interesting things writing this script and sharing it with friends. Script-wizard Ben Dean helped me revise the script so that it would not generate temporary files on the filesystem, and in pursuing this goal, I learned about bash herestrings. I had also not previously scripted with XPath via xmllint, only within larger applications. This script got me what I needed to know: I logged 937 plays with my eldest son in the three full years I have been keeping track, but not counting the plays since January 1 of this year.

Hopefully this script will be useful to you. If nothing else, it will be useful to me next time I need to ask this question!

Tuesday, January 29, 2019

Global Game Jam 2019 and Kaiju Homecoming

This past weekend was Global Game Jam 2019, and I was the site organizer for Ball State's location. It was my third time serving as site organizer here. I want to capture a few thoughts about the weekend's events here before they get too far way.

We had 21 people register, almost all of whom showed up. There were several people who came on Friday but then didn't return, unfortunately. I have seen this each year, and I think it tends to be people who are interested novices. They don't know how to move from idea to implementation, and they are not familiar with the little failures that are to be expected along the way. I take a laissez faire approach to site organization: I don't manage teams or themes, but instead I encourage people to use the whiteboards around the room to gather interested people. I've thought about whether I should include more didactic interventions, but the truth is that teaching is already my job: the jam is about jamming after all. I would never kick an amateur musician out of a jam session if they wanted to participate, but I would also not be surprised if they left. Perhaps it sounds a bit harsh when I write it out, which makes me think I need to work on better packaging for my pragmatic philosophy.

This relates to something I want to share about this year's keynote. I had a sense that none of the four speakers were actually talking to my audience: mostly novice jammers. The thoughts they shared might resonate with people who already know what they are doing, but that's not helpful if you have no grounding. Let me pick on one particular example. Rami Ismail was the most on-point of the three speakers, but he made a claim in his presentation that you cannot do a game jam wrong. I firmly disagree: there are many, many ways to do things wrong. Here are several: being an unpleasant team member, for example by refusing to compromise on your ideas or by not keeping your commitments; focusing on accidentals such as title and credits screens rather than the essence of the game; taking too long to get to a minimally playable state; thinking that ideas have value rather than implementations; not considering packaging or deployment until just before the deadline. These are the kinds of mistakes that I have seen jammers make and, more to my point above, that I see novices make in my game design and game programming classes. In fact, I think it's much easier to do it wrong than to do it right—regardless of the quality of the final product. I think a rhetoric that says you cannot do things wrong sets novices up for mistakes and frustrations.

At the end of the jam, we had four playable projects. There were two more that were "done" but not uploaded, one of them because the jammer disregarded my and others' advice to stop trying to add features and instead to figure out how to package and upload his work, and the other because he could not make it on Sunday and didn't get around to uploading his.

Last year, my oldest son came and participated in the jam, making two games of his own in the time it took me to break one. This year, I encouraged him to come again, but I told him that I really wanted us to work together on something. He actually started working on his own anyway right after the theme announcement, but once I reminded him that I really wanted to collaborate, he was up for it.

We struggled to turn the theme ("What home means to you") into a game idea. One of our best sketches was of a game where the family stands around the counter, waiting for Mom to look away, reaching out and grabbing tidbits to eat before the siblings can. I imagined we might even use a polka soundtrack and be able to name it after the Shmenge hit, "Who stole the cabbage roll?" As we kept talking, though, we somehow pulled inspiration from Terror in Meeple City and the idea that kaiju have a home as well... and there are people in it, and we don't want those people there. This was the idea that became Kaiju Homecoming.

We built a minimally playable version in Unreal Engine just to make sure the pieces would fit, just dropping a plane onto some cylindrical columns and throwing a ball at it. We laughed from the get-go. I asked my friend Emma if she could make up some digital meeples, and so she and her friend Jessica provided these models. The next day, my son worked on some more original art for the floors and he did all the level design. We had to tweak the level a few times because we couldn't get the floors to stack nicely on the columns in the UE4 editor. Playing the game, you can see the physics solver create wobbles and even occasional collapses as a result. There are probably snapping or simulation sleeping settings that we could use to fix that, but I am really happy with the look and feel, given our constraints. My son was also in charge of all the audio direction except for the soundtrack: I found the music on Kevin MacLeod's site, and he reviewed sound effects using the free weekend access to SoundSnap. We had the game mostly finished on Saturday, and because of other family obligations, we only had a few hours to work on Sunday, right before the deadline. We got as much polish in as we could, and the game was complete.

The game runs best as a Windows 64-bit executable, and you can download the project for Windows from the Global Game Jam site. We also produced a Web build that I've hosted on GitHub: it's more accessible, but lacks the performance of the native version. All the source code and assets are in a repository on GitHub as well, although we actually used Perforce Helix for version control during development. Finally, for those who want the quick overview, I recorded this short gameplay video:


It was a fun weekend jamming with my son and seeing what the other jammers put together. I've started some conversations that might lead us to a different location for the 2020 jam, but that's a long way off to worry about planning. Now, I need to return to all the tasks that I put in the "I'll take care of this after Global Game Jam" bin.