Friday, June 15, 2018

Painting Stuffed Fables

I was very excited when I heard news of Stuffed Fables' development. For those who don't know, it is a miniature-based, narrative-focused, cooperative, tactical board game designed by Jerry Hawthorne and published by Plaid Hat Games. Hawthorne designed Mice & Mystics, the game that drew me back into the painting hobby. The SHUX preview mentioned that each story ends with a series of talking points, reflective questions for family groups who are playing the game. That's a brilliant idea. It looks like the perfect game for me: a game explicitly for families that doesn't sacrifice gameplay, and that comes with some fun miniatures for painting.

I picked up a copy as soon as I could and got the figures primed, but then I went several weeks without touching my brushes. There were a few reasons for this, including Divinity: Original Sin 2 and Pillars of Eternity 2: Deadfire, as well as more professional obligations. I find that there's a problem here where the longer you put the brushes down, somehow they become more intimidating to pick up. When I primed the figures, I was struck by how very round they are. Most of the miniatures are comprised of simple, smooth geometric shapes with very little detail. This means they do look like children's toys, but it also means a lot of trouble painting. Smooth, featureless surfaces are the worst—there's nowhere to hide.

Once I got my head clear and my confidence up, I jumped in with the mongrels. For those who don't know, "weathering" is the process of taking a nicely painted miniature and making it look dirty and worn. It's not something I've ever done. When I paint a miniature, especially if I am happy with it, then I am loath to risk messing it up. Almost all of my colors are custom mixed from a limited collection of paints, and so it's arduous or impossible to re-mix base colors should I need to cover up weathering gone awry. I interpreted the card art of the mongrels to depict old, rusty, mechanical dogs, and I decided this would be a good chance to try painting rust. Regular readers will remember that I've been using zenithal priming on my miniatures since acquiring an airbrush last Fall; the mongrels were the first that I've primed differently since then, using a basecoat of Vallejo Model Air GunMetal and zenithal highlights of VMA Steel. Knowing I could easily brush these back on gave me a bit of courage to move forward with the weathering.

I started very tentatively, adding just a few spots of very thin Vallejo Model Color Flat Brown, then layering on mixes of that with VMC Flat Orange, up to a few very small specks of pure orange. It's a dramatic change to go from an entirely shiny, metallic figure to a flat one! I realized at this point that in my excitement, I had forgotten to add a wash that would deepen the shadows of the figures. I mixed up a wash with brown and black inks and applied that to all three models. The wash helped soften the first weathered mongrel, in addition to the usual enhancement of shadows. Once the wash dried, I jumped in with adding rust to the other three. Happy with the results, I looked back at the first one and realized how tentative I had been; this prompted me to go back and add even more rust to it. For all of the rust effects here, I just used my mixing brush, which is a beat up old synthetic Princeton #2, perfect for dabbing and stippling.

I should also mention, as a note to future self, that all the enemies' bases were painted with a mix of Americana Slate Grey with just a dab of Americana Lamp Black—roughly a 6:1 ratio to get a more neutral grey.
With the mongrels completed, I turned to the crawlies, which are undoubtedly the creepiest of the miniatures.
Crawlies are, of course, rusty metallic hermit crabs that make their homes in abandoned dolls' heads. A fun family game! Anyway, I am happy with how they turned out. I had used a conventional monochrome zenithal prime on these, so I brushed on the VMA gunmetal to the mechanical parts and drybrushed silver highlights before following the same weathering process as the mongrels.

For the dolls' heads, I followed a fairly normal flesh approach except for mixing in a bit of purple to add a deathly pallor. Sure, I know they're not really dead dolls, but they still seemed to call out for such coloration. The hair was the easiest part thanks to the zenithal priming approach, as I've noted in previous painting posts: mix the color, thin with some glaze medium and a little water, and brush it on. The white undercoat gives highlights for free, which can then be touched up by hand in any spots that call for it.

Only one more set of minions to go, and that's the Dark Hearts.
These seem to be stitched-together amalgams of discarded stuffies. The card art suggests that some pieces are striped, but I opted for simple monochrome sections taken from a single palette of green, purple, and pale yellow. These were the first of the rounded, featureless miniatures, and so I used it as an excuse to brush up (ha!) on my wet blending. Each section was wet-blended, using a bit of the magic Vallejo Glaze Medium to add open time and workability. Looking over them, I could go back in and add some polka dots and stripes if I wanted to, but these are satisfactory. The shading and highlighting is decent, but I think the stitching and chest cavities are really the best parts: it's a clever sculpt, despite being uncomplicated, and the painted stitches and stuffing really sell the illusion.

Twelve minions is probably enough minions, and so from here I moved on to the heroes. I was inspired by Duke of the Blood Keep's Stuffed Fables painting series to paint the base of each hero according to the color of die associated with them. I'll show the heroes in the order I painted them, even though I found out later it's not the order they show up in the game.
Given her prominent position in the fiction and the box art, one senses that Theadora is the heroine of the stuffies. Also, remember the trope: fantasy character with sword = leader. She's the one who doesn't have a particular die color associated with her, so she got an off-white base. 

All of these heroes were painted primarily using wet blending, occasionally with a bit of layering to accentuate highlights and shadows. I matched the colors on the card art as well as I could. I think she turned out nicely. Held up close on in the pictures, you can see a few spots where the blends are not as smooth as I would like, but it looks fine on the table (especially considering that my gaming table has rather diffuse lighting). I did not spend inordinate time on any of the heroes, each taking around two or three hours.

This is Stitch, who has a lot more detail than the rest of the stuffies. Stuffed Fables story is about a little girl's transition to her "big girl bed," and while she sleeps, her stuffies protect her from harm. In the game, Stitch is the only intergenerational hero, having been passed from the mother to her daughter. He takes the role of the sage, the wise elder who is mentoring the rest of the party—and some of his lines had me laughing out loud.

Like the Dark Hearts, Stitch is a patchwork of other pieces, and I followed the card art's colors. Unlike the Dark Hearts, I also painted in the stripes from the illustration.
Here's Lumpy, no relation to Chewbacca. From detailed Stitch to the king of plain. I think I did a good job with the blending here. I used cool greys, mixing in some of his thematic blue. Not much else to say about the paint job here, but he is the character I ended up playing. There's a funny bit of ludonarrative dissonance in that the blue dice represent strength and defense, and you can use blue dice to encourage or support your friends. Yet, Lumpy seems to be a whiny coward. I read his voice a bit like Eeyore's, which is funny when the story says something like, "Lumpy lets out a high-pitched shriek." Classic Lumpy moment: in the first Story, the party had to convince an unfriendly character to let us into her house, and we succeeded only through the persistent, devoted whinging of the elephant.

"Lionel" sounds a lot like "Lion-O", but I don't think my kids care about that. I opted for a softer tone than the card art here, which is more brown or tawny. He was a very quick paint job: wet blend the body, thinned paint on the mane, and it's basically done. We haven't met him yet in the game, but he seems like a nice guy, what with the leaning and the pointed teeth.

One piece I am not really happy with is the patch. In the card art, it looks like a green and red plaid or checkered design. I dropped red spots onto a green patch, but they don't pop and are not very even. I may go back and clean that up, but I think it's too small to really get the card art design in place; I would have to do something with similar colors but a slightly different design. Either that or buy new detail brushes I suppose.

My younger boys love Mo Willem's Elephant and Piggie books, so I figured this character would be the first to be selected. However, like Lionel, we have not yet met Piggle. Big smooth areas, with the added bonus of stripes, but I think it turned out good. The card art has the shield as being the top of a Play-Doh can (defensively labeled "Play Clay" instead), but I decided to leave it plain rather than spend the time required to try to freehand such detail. 

This is a good point to mention a particular pet peeve with the game. There are five colors of dice, plus black and white. The colors are called blue, red, purple, green, and yellow. Look at the dice, though:

What colors do you see? I'll accept green, blue, and yellow. The "red" is orange, maybe vermilion if you're feeling generous. Their "purple" though is not at all purple: it's magenta! Magenta is a real color. In fact, it's a primary color when mixing pigments, as in CMYK color space. Why do we, as a society, pretend this color doesn't exist, and call it "purple" or "pink" instead? For this game, it's not clear to me why one would choose these particular plastics to be called by those names when, surely, one could manufacture dice that are actually purple and red instead.


Flops is the last of the stuffy heroes, and he was a nice one to end with, being a mix of some large rounded surfaces like the ears and a few little details like the fletching. Flops suffers from another little bit of ludonarrative dissonance, where the in-game text refers to her as having a bow (as in the sculpt), whereas the game at that point prevents the player from actually using the toy bow item card.

At this point in the painting process, we got the game to the table. I did a bit of research to determine that we would not need any of the boss figures right away, and I wanted to see what the boys and I thought of the game. I've been playing with my 11-year-old, 8-year-old, and 5-year-old, and we absolutely love it. The decisions are quite interesting, much more so than in Mice & Mystics. Being cooperative, we can help each other to sort out what is best for the group. The simple mechanism whereby one player can give up dice to another player has wonderful synergy with the theme: it is really cooperative in that you have to sacrifice to help each other, rather than the style where each person is essentially playing alone toward the same goal. The 5-year-old in particular has been asking to play, and he referred to it as his being able to play a "big kid game." There are lots of other games he sees me play with his big brothers, but this is his chance to join in. Thanks, Plaid Hat!

Inspired by the great time we were having at the table, I painted the boss figures in the order they enter the game. I was hoping to find illustrations of all of them online but had no luck, so I had to dig through the "secret" story cards to find art so I could match the colors.

The first boss is the big, big monkey man, Knuckle. Big, smooth, round surfaces—you know the drill. The card art is a little strange on this one, with his cleaver honestly looking more like it has a few blood stains on it than rust. I decided to kick the rust way up as compared to the art, closer to the level of the mongrels and crawlies. It is a little incongruous, the rust and the smooth green fur, but it's good enough. I do like how the stuffing is visible through the Knuckle's seams, once again selling the idea that this is a stuffed creature and not an organic one.

This is the Snatcher. Or is it just Snatcher? I don't know, we haven't encountered him in the game yet. The card art is just two colors, but it's a huge figure. I did a bit of searching to see how others had painted it, and I see some have added more tones to the limbs. After some consideration, I decided to see what I could do, keeping to the two-tone palette and some weathering. The copper color is a mix of Vallejo Game Color Glorious Gold with VMC Flat Orange and Flat Brown. You know how much trouble getting the right kind of gold can be, but I think I really nailed it here. 

I decided to switch painting techniques on the Snatcher, using two-brush blending instead of wet blending. I started with a base coat over the whole figure, and then I used a spot wash to deepen the shadows, especially in the joints and hands. Mixing more matte paints into the shadows gives some real depth to the shadows, and adding more silver metallics to the highlights makes them really shine. Finally, I used some of the rust colors previously applied to drag some rusty oily lines over the body, and I used a mix of black and sepia inks to add greasy stains around some of the joints and bolts. I'm quite happy with the result.

I noticed in my searching that many people painted the Snatcher and mongrels to match. That's a fine idea, and the card art certainly suggests it. I happened to see the mongrels as being rusty and the Snatcher as being copper. One might see the crawlies as equally ambiguous. I wonder if the story will shed any light on if there is supposed to be a unifying scheme or not. For now, I'm fine with mine mismatching. As a painter, I like how I was able to explore different techniques with the different models and feel good about them.

Here is the Dollmaker. For folks who want a larger version of the card art, Plaid Hat has released a free story expansion to Stuffed Fables, and page 3 has a nice view of it. This image also highlights a curious distinction between the card art and the miniature: the card art gives the Dollmaker a face that is either itself a stuffy or at least in a stitched mask, whereas the sculpt looks like a human face complete with nose and ears. Like other painters I've seen online, I decided to paint these areas in flesh tones rather than the orange suggested in the card art. (Also, I'll point out that many images in Stuffed Fables fall into the Gloomhaven trap of using dynamic backlit illustrations that look good on paper but make it very hard to intrerpret what colors to use!)

I continued with two-brush blending after working on the Snatcher. I am happy with the result for the Dollmaker, but it was a little frustrating to paint him because, after spending an hour or two on the lab coat, I set it down next to a zenithally primed figure and found almost no difference. To be clear, there is a difference, but it sure is subtle. For tabletop play, I probably could have left it as naked primer and nobody would have been the wiser!

What figure was he next to on the painting table? None other than the unnerving penultimate boss, Skreela.

Skreela's card art is more monochromatic, with pale barely-purple flesh being practically the same tone as the top of her frock, and the dress/nightshirt itself being another variation on pale purple. I futzed around a lot with skin tones before settling on something colder and more saturated, a cold blue tone.

I painted the hair as described above and used two-brush blending on the rest. It wasn't until I was getting ready to varnish the bosses that I looked again at her dress and thought it was too clean. The card art clearly has her looking dirty (and more manic, but part of me is glad the miniature isn't as creepy as the card art in this regard). Empowered by my experience with rust and streaks, I decided to add some dirt to her dress, although I laid down a coat of gloss varnish first in case I needed to wipe away mistakes. I used a bit of foam that I had sitting on my painting desk and used that to stipple on two colors of dirt. I forgot to take a "before" picture, but I think the result is good. Perhaps the dirt is a bit too regular around the back, and I could still add some more spots further up to break the circular pattern. 

I have a few options for what I might paint next, but I am definitely thinking more about playing with weathering effects. Regular readers know that I'm a fan of Dr. Faust's Painting Clinic, and I've seen him do some amazing work with weathering products, especially on models. For miniatures, maybe it's overkill. It makes me remember to stop and count my blessings that I can afford to spend a few bucks on streaking grime just to try it out.

Finally, here comes the big bad:

That's Crepitus, whose card art is, once again, strongly backlit. I have seen other reasonable interpretations of his palette, but I decided to go for a very limited color selection. It took several trials to get a flesh color I was happy with, but once I nailed that, the rest came pretty easily. Two-brush blending continued to be the technique here, with the addition of layering to bring out the highlights. At the very end, just before varnishing (as with Skreela above), I decided to add a modicum of what Sorastro calls "tonal variation" by brushing some thinned purple paint into some of the deeper folds and recesses. It was a subtle improvement and something I want to explore more in other sets.

In the continuing saga of camera problems, I was excited to see Ghool post an informative video for his patrons about how he photographs his miniatures. My lovely wife helped me dig up an old digital camera that supports manual white balance along with other materials to recreate Ghool's technique. I spent some time on that this morning, and I didn't have any luck at all, mostly because the old Canon wouldn't focus on a miniature. However, the video did help me understand a few things I really didn't before. One is that the ISO should be low, since I am photographing still items. The other is that the mysterious lines I've been seeing in my photographs are coming from my lamp. The bulb in my painting lamp is flickering imperceptibly, but when combined with the capture rate of my smartphone camera, the result is shaded bands. Of course! I tried a few other bulbs that we had around the house, but none of them are "natural daylight" like the one I use—they were all too warm. Maybe I'll shop around for a better painting lamp or bulb (again, counting my blessings).

In the meantime, my new knowledge helped me sort out a workaround that I used in most of the pictures you see above. OpenCamera allows me to manually adjust the ISO as well as the shutter speed and white balance via sliders. Setting the ISO to 50 and looking at my minis on white paper, I was able to see the banding effect, similar to what I was seeing with the default camera app. However, as I increased the shutter speed, the bands narrowed and, eventually, disappeared. By fiddling with the shutter speed and white balance setting, I was able to get the minis on-screen to look very much like the ones sitting in front of me. Huzzah! OpenCamera only keeps those settings for one shot by default, but there is a lock feature to prevent them from being reset. Huzzah! Unfortunately, if you leave the application—for example, to look at photos or check an email— the lock is lost. That's why a few of the pictures above have perceptibly different background hues: the camera switched to automatic mode without my noticing. Still, progress is progress.

One of Ghool's tips was to shoot on black backgrounds. Toward the end of my shooting this morning, I decided to try that, prompted in part by the difficulty I had getting any kind of reasonable settings for that mostly-white Dollmaker. Compare:

Here's another experiment, using the crawlies:

The black certainly seems more consistent, whereas you can see above what I was talking about before: the camera dropped my settings between activities, and I didn't quite get the balance of shutter speed and white balance right to get a true white. Maybe I should shoot my next set entirely on black? At least I now have some stuff black felt that I could try, since it's one of the many materials my wife helped me find.

It's a bit of an epic post. I'm happy with this painted set, and my boys and I are really enjoying Stuffed Fables. I am looking forward to painting figures that don't have quite so many large, round, featureless areas though. 

Thanks for reading! As always, feel free to leave a comment.

Friday, June 1, 2018

Reflections on the making of Fairy Trails

Last semester, I mentored Guy Falls Down studio in the creation of Fairy Trails as part of a collaboration with Minnetrista. As is often the case, I did not blog as much about the experience as I intended, sharing only this story about a design epiphany, our excellent coffee burn-up chart, and a few words about a frustrating version control oversight. I remember that there were several instances that made me think, "I should blog about that," but as time went on, I would forget what they were.

Here's the TL;DR: Fairy Trails is a free app for groups who are visiting Minnetrista's beautiful campus. You can find it on iTunes or the Google Play Store. It is an app for groups: one person installs the app and leads their group on a fairy-finding adventure. Enjoy!

For the rest of you, read on for a few more stories and reflections about the experience!

Fairy Trails Main Menu
The "Put down the duckie" post does a good job of introducing the essential elements of the background and game design. What I would like to do here, a bit like my Spring 2018 HCI reflection, is to pull out some of the most important anecdotes and lessons. This makes it easier for me to look back and remember what I thought I learned, and I hope it makes for interesting reading for others as well.

Good: Spending time on one scenario

One of the questions that students could address in their final essays dealt with the differences between their expectations at the start of the semester and what we produced. Many of them wrote about how they expected to make a game where you find a wide variety of fairies; in Fairy Trails, we have three. In fact, we almost had only one! We spent many sprints iterating on one scenario, the one which would become meeting Henrietta at the wishing well. During this time, the team was getting up to speed on Unreal Engine, Perforce Helix, and working across conventional disciplinary boundaries. More importantly, they were coming to understand what we were actually doing: making a game for groups that is moderated through an app.

Some of the students get a bit antsy about working on only one scenario for so long, but I kept reminding them that we could negotiate scope, but we could not negotiate quality. I think this was hard for them to recognize since a subset of them assumed their designs were fine in absence of playtesting. Frustratingly, some of these students had gone through my game design course the previous semester. You'd think if you learn nothing else from that experience, you would learn that game design is hard. Maybe that's a call for me to make even more structural changes to the course to drive that lesson home.

I think many other students had a more important realization, though, when they saw that iterative refinement was such a powerful technique. In our final retrospective, we loaded up the initial minimum viable product that the team produced and ran it beside the final version. They laughed about it, saying, "I can't believe we thought that was good!" Of course, at the time I had congratulated them on their accomplishments while recognizing they were on the road to doing much better.
A subset of Guy Falls Down Studio at the Butler Undergraduate Research Conference

Risky: Not spending enough time on the others

As we finally wrapped up the Henrietta encounter, the team started looking at what would go into making two more encounters. It wasn't the student who had the excellent learning experience of leading the design of the first scenario, with all its multiple prototypes and user testing; it was the ones who clearly had not learned the lessons of the first one.

Fairy Trails is a geolocative game that is supposed to be closely tied to Minnetrista's grounds, but it wasn't until several hours into their paper prototyping that they admitted that they had not been to the scenarios' locations. I encouraged them to put on the brakes, to make the half-mile journey to Minnetrista, to go to those locations and seek spatial inspiration. Their response was to hop on Google Earth. I was flabbergasted, and really, I still am. These guys had no sense of the value of space and yet were designing scenarios that were supposed to reflect that value. They charged forward with paper prototypes, reporting soon afterward that they were ready for implementation. I asked if they had done any playtesting—no. I asked if they had done any on-site testing—no. I asked how they knew that these these scenarios were good? They responded that they learned from the process of making the first one, and so these scenarios would be good. You know what I say to that? No.

The end of the semester was approaching, and the team decided to take the creative risk of incorporating the two additional scenarios as-is. The last day of the semester, I sat with the student who had been de facto lead on the wishing well scenario and we edited practically all the text of one of the scenarios. I also improved the usability with a bit of Blueprint scripting after the semester ended, as I was shepherding the app through the iTunes approval process—a simple fix, really, and something that any rudimentary playtesting would have discovered.

It was not an unreasonable risk for the whole team to agree to incorporate these two extra scenarios. Indeed, shipping a title where you only find a single fairy was a worse risk! What is unreasonable, to me, is the lack of rigor in the process from students who should have known better. Was it ignorance, pride, lack of good coaching, or a combination of factors? Is there something I could have done differently that would have had them get off their butts and go to Minnetrista? It's not clear to me.
Henrietta will meet you at the wishing well
Incidentally, I do wonder if past team members read my blog and what they think about my reflections. There should not be anything here that they have not heard from me elsewhere, and hopefully they will leave a comment if they saw or remember something differently. Sometimes events happen in the studio that I don't blog about at all, hoping that I will simply remember my lessons without airing our dirty laundry on the Internet. One of my fears is that I will repeat the mistakes I don't write about.

Conundrum: Having a methodology is different from using it

For many years, I have given my students a "Starter methodology" based on best practices of agile game software development. It includes a mixture of technical and social rules. One item I added several semesters ago—maybe inspired by my work at the VBC in 2012, although I do not quite remember now—was a protocol for resolving design conflicts. The protocol itself is simple and elegant, and it's designed to combat the endless discussions and justifications in which students (at least) are eager to participate. If a design discussion goes on for more than five minutes, then you transition to prototyping; the discussants chose a timebox, build something to show their idea, and then bring that back. Now, you're evaluating artifacts instead of amorphous ideas. When this is followed, it usually doesn't even get this far, because someone will realize their concept just doesn't materialize as they expected it would.

On paper, that's a great idea. In practice, the team has to actually follow it for it to be useful. Let me say clearly and for the record: this was a really good team! Everyone can fall into the trap of endless discussion or analysis paralysis, though, and this team had a hard time with it. Sometimes it was because of ignorance or confusion, and sometimes it was because someone just wouldn't let go of an idea. What's interesting is that the students recognized in their retrospectives and essays, over and over again, that they were aware of the protocol, they did not follow the protocol, and they regretted not doing so. There are lots of tips and tricks in the starter methodology that I have picked up over the years, such as requiring that students who come late to a meeting bring treats to the next one. It's less clear to me how to quickly get students on-boarded, especially since each team is a new team: they have to learn the lesson that is crystallized in the methodology statement before they can recognize that they need it.
Meet Francine at the Rose Garden

Smooth: Unreal Engine and Perforce Helix

Three team members coming into the Spring game studio course had just finished up the game programming course that I taught using Unreal Engine. They were instrumental in convincing the rest of the team that UE4 would be a good technology to use: it was free, Blueprints scripting was eminently learnable, and it could scale up to incorporating advanced augmented reality if we desired. (We would end up not incorporating AR due to the time required and device restrictions.)

I was really impressed with how quickly the other team members were able to get in and get productive with UE4. Of course, these were bright and ambitious students, otherwise they would not have applied to the studio and made the cut. Several of these students had just taken CS222, and one was actually taking CS222 concurrently with the game studio. By the end of the semester, some of these guys were outperforming the graduating seniors, by their own admission. 

The team spent a lot of time creating interactive UIs with Unreal Motion Graphics (UMG). They did struggle a bit in the way that a lot of novices do when given a tool like this: they slapped pieces together until it worked right in one particular configuration and then assumed they were done. Even after showing them how to test different screen sizes, some still struggled to incorporate that into their workflow. Once they learned how to use the tool correctly, rather than hoping random mutations would work, they became more reliable in this regard.

The previous semester, we had used GitHub for version control, but this was not really the right tool for the job. UE4 uses practically all binary assets, which cannot be merged, and git does not natively support file locking. I was able to secure an academic license to use Perforce Helix, which is integrated nicely into UE4; aside from a few hiccups, it was smooth as silk. Everyone appreciated the ability to lock assets, and being collocated or on Slack, it was easy to communicate about who needed what. I think the guys who had struggled with GitHub were most appreciative about this.
Meet Chestnut at the Stage

Clearly: Guy Falls Down Studio

At one point, someone wrote or drew something on the board, and I pointed out that it looked like a stick figure falling on its head. None of this was caught on camera, as far as I know. For several years, I have used a team-building technique where a team only names themselves once they have had their first real success. To my mind, this is evidence that they are a team and not just a group of students. Given the many iterations on the first fairy scenario, it took a while for this group to name themselves. Once they started that process, they collected names on Slack, and "Guy Falls Down" came back up and won the day.

It's a fine name, and folks who don't even know the story have told me they think it's a classy name. What they don't know, though, is that I had proposed the best name. Ball State University started a new marketing campaign last semester based on the theme, "We Fly." The best name for a studio at Ball State would be, of course, "Wee Fly".  How did this one not win?

I suppose it's best that a student suggestion wins, but maybe they should have acknowledged that even if mine didn't win, it's clearly the best.

Guy Falls Down Studio Logo
Incidentally, every year, students suggest a name that ends with the word "Studios," as in "Guy Falls Down Studios." Then I have to ask them, "How many studios do we have?" There are inevitably students who are confused by this question and assume that pluralizing "studio" is just some kind of industry standard as opposed to, you know, plural.

Doomed: The Mac Guy

When I mentored the team that created Children of the Sun, I said I would never mentor another iOS project. You know, we get forgetful as the years go by, and somehow, people still keep buying Apple products and promoting their walled garden. Point is, if we wanted to get this app out to the most people, we had to consider releasing on both Android and iOS phones. This was another reason we chose Unreal Engine: we should be able to have one codebase and simply build for each platform.

Early in the semester, the team sought a volunteer from among them to figure out all the iOS stuff. This guy earned his stripes. The rest of the team was very grateful to him, teasing him a bit at the seemingly-ridiculous loops he had to go through while the rest of the team simply plugged in their Android devices and deployed. We're all grateful that he was on the front lines, teaching the rest of us what to do. I should give an extra shout out to Brandon Smith and Bryon O'Conner of the Ball State University Digital Corps for helping us out with the development, deployment, and distribution process for iOS.

Amazing: People

Speaking of amazing people, all of the wonderful artwork in the game was done by one very talented animation major. Occasionally I work with people and I get this, "I would hire them in an instant" feeling. She was one of them: smart, creative, thoughtful. We got her right into Unreal Engine and Perforce in no time, and her work—as you can see—is top notch.

I also want to mention George Buss, the Director of Experience and Education at Minnetrista, who was our main contact for the project. He was an amazing partner, coming to campus several times to meet with the students and answer questions, really digging into the students' designs, involving more members of his staff, and even putting on a workshop for the students about narrative design for museum experiences. I am glad to announce that he and I will be continuing our partnership next academic year. What form this will take is still on the table: perhaps a parallel project, perhaps an extension of this one. I'm still wrapping up Spring a month after the semester ended, so it's too early to worry too much about Fall! 

Wrapping Up

Come to Minnetrista, download Fairy Trails, and let me know what you think.

I believe, at long last, that this is the last of my Spring 2018 wrap-up posts. I haven't picked up my brushes in about six weeks. Time to remedy that. Happy Summer!

Friday, May 25, 2018

UE4, Perforce, Plug-ins, and Special Characters

Even though I'm not on the university's payroll for the summer, I have spent a lot of time in the lab the last three weeks. I will be writing a project retrospective about the Fairy Trails project in the coming days, but suffice it to say for now that, as in Collaboration Station Enhanced, there have been some complications getting the iOS build together. I estimate that I have spent roughly 15 hours in the studio working on Fairy Trails since the semester ended. The first problem was that UE4.18 contains a defect wherein the shipping build for iOS games accesses a private API for the Metal rendering system. This was supposed to be fixed in a QFE, but it actually wasn't. One alternative is to rebuild the engine from source with the offending code fixed, but I decided to go with what seemed the more prudent approach: upgrade to 4.19.

In order to make sure there was no cruft left over from 4.18, I created a clean workspace. I rebuilt the iOS app and got ready to submit it for review to the App Store, but that's when I noticed something strange: the app icon had changed from the custom one to the engine's default. I looked at the Project Settings for iOS, and sure enough, many of the icons were not set correctly. Why would an engine upgrade change that? I put the new icons in and carried on. I kept running into problems, though, and searching the Web gave me some conflicting information about what was broken in 4.18, what was fixed in 4.19, and what was not quite fixed in 4.19. Many hours were spent fiddling with file names, resizing icon images, and even ripping open an IPA and poking around inside of it.

Frustrated and uncertain whether I had just introduced new problems, I decided late this morning to do set up a new, clean workspace to work in. I had pushed so many bits around in the other one that I wasn't sure I accurately remembered what I changed any more, and it certainly wasn't reproducible. I looked at the settings in the clean workspace... and the icons were wrong again in the project settings! What gives?

As I put the icons back in the settings window again, I happened to have the log open, and I saw that the version control system was actually generating errors each time I set an icon. The complaint was a bit vague, but the essence was that it didn't know how to handle file names with '@' in them. At first blush this seems fine; who in their right mind would put special characters into a file name? However, doing so a convention for Apple icon files, where a standard icon might have a file named Icon40.png for a 40x40 icon, but a high-res version might be called Icon40@2x.png for 80x80 or Icon40@3x.png for 120x120. Here, then, was a source of many hours being lost! When my student team members had set up the icons, they confidently used the UE4 Perforce plug-in integrated into the engine, but (a) they didn't see the messages in the logs and (b) they didn't verify that the list of files in the changelist matched what they had actually touched. Only the low-res icon files were therefore tracked in version control and checked out into the clean workspace. This explains why one of my student team members was able to create IPA files with no problems: he was working in his own workspace, where the files were sitting happily in the Intermediate folder while not being properly tracked in the Build folder.

It was not the first time that blind trust in the UE4 integrated plug-in caused us problems. We follow the recommended convention of having a "ToImport" folder that is in the root folder of the project, and this folder is where we keep raw assets for import into UE4. This way, if someone wants to edit, say, a texture or a sound, they check out the file, make the change, and easily reimport it into UE4. However, the Perforce plug-in does not check for changes in the ToImport folder since it's not within its purview. This led to students making changes and trusting in the plug-in, only to have the .uasset files submitted without the corresponding raw assets.

In the future, I need to be more strict in warning the students against trusting the Perforce plug-in. It provides a convenient view of what assets are checked out by other developers, which is something the team used regularly and found very valuable. However, for the actual check-in process, I need to make sure they're using something like P4V, with it's excellent "Reconcile offline work" feature.

As I write this, the Fairy Trails app is in queue to be reviewed for an App Store listing. I am working on a conference paper with a deadline right around the corner, but I hope to share some stories about this past semester's immersive learning project in the next few days.

Wednesday, May 16, 2018

What would I do in a semester? What would I do in year?

This evening, I have the pleasure of attending a meeting to discuss the state and future of the Virginia Ball Center for Creative Inquiry at Ball State University. Long-time readers will remember that I was  fellow in Spring 2012, mentoring the multidisciplinary undergraduate team Root Beer Float Studio who created Museum Assistant: Design an Exhibit. We transformed the upper floor of a mansion into an independent game development studio with a unique academic mission. This was the most important and defining experience of my career as a professor; there's a real sense in which everything I have done since then has been attempts and experiments in recreating parts of the truly immersive VBC experience. In preparation for tonight's meeting, I was sent the recently-completed external evaluation of the center. Reading this report reminded me how truly superlative the VBC is: it is truly exceptional, unique in higher education. I have been telling people since then that if I could run projects like that every semester, that's what I would do.

Along with the external evaluation, I was sent this question to consider:
If you were given an entire semester, or even an entire academic year, to teach/work on/investigate anything with students, what would it be? What would you do with your time? Why?
My first reaction when I saw this question was, "I would do what I did in Spring 2012, but I would do it even better." The overall scheme from 2012 was a good one: I designed a one-week intensive introduction to educational game design, and we moved very rapidly into an agile approach for building and testing prototypes. With the scheduling freedom that the VBC provides, we were able to couple our production work with reading groups and academic inquiry. I brought in speakers from across campus to talk about game design, games journalism, and storytelling. I spent most of my time embedded with the team, mixing roles of mentor, coach, and producer. Since 2012, I have learned even more about all of these roles, which is why I think I could do it even better now than I did then.

I went back and read the question again, and that's when I saw the "or even an entire academic year" clause. In one semester, a student at the VBC might earn 15 credit hours, or earn something like a minor in game design and development. This gives a good academic-conceptual bounding box for what students might be able to do after completing the semester: they should have a firm foundation, but they should not necessarily be expected to develop proficiency, maybe not even competency, let alone expertise (drawing upon the Dreyfus model definitions). In two semesters, that's potentially 30 credit hours, and it starts to look like a small major. There could be real opportunities to not only make grand mistakes, but to learn from them and then do something even better. I believe in the university as a "safe fail" environment—it's good that students can learn through their failures here, because that's essentially why they are here. With more time, though, you increase the chances that maybe you could make something with extrinsic value. Whether that means widespread dissemination, commercialization, or formation of LLCs, I don't know. Fundamentally, if I had a year at the VBC, I would follow the same kind of pattern I did before, but the scale and scope would be roughly doubled.

The question leads into my broad ideas for how higher education could be reformed. Fundamentally, the best part of undergraduate education is inquisitive students working with active scholars in interesting contexts. Everything else is artifice. A colleague and I wrote about this for an internal report some ten years ago, that in order to innovate, the university needs a skunkworks where students and faculty can engage in collaborative reflective practice. This kind of talk makes the bureaucrats nervous, but their concerns, though legitimate, are accidental to education: credit-hours, accreditation, core distributions, majors, etc. By contrast, the essential issue is guiding students to recognize truth and beauty. That's where I like to spend my effort.

In the next two days, I have the Security & Software Engineering Research Center Showcase, the VBC dinner, and a Google I/O Extended meetup. Should be a thought-provoking few days of "break"!

Thursday, May 10, 2018

A Reflection on Spring 2018 Human-Computer Interaction (CS345/545)

I started a narrative approach to a CS345/545 (Human-Computer Interaction) reflection yesterday, and it came out really negative. It was honest, but too negative—that's no way to be. I'm going to try again today, but with a different format, and see if I can make it both shorter and more constructive. Let's pull a trick from Sprint Retrospectives and start with...

What Went Well

Controlling scope. There's a lot that could be covered in an intro HCI class, and the conventional textbook approach sacrifices depth for breadth. Put another way, it sacrifices understanding for recognition. I wanted my course to center on a few fundamental principles, and ours ended up being Don Norman's Seven Principles of Design (from Design of Everyday Things: Revised and Expanded) and the Double Diamond design model. We also reviewed importance of model-view separation and layered software architectures, although this was not really in any more detail than I would cover in CS222. I had hoped to have more time to talk about software architectural issues, but seeing the students struggle with the other topics, I pulled back on this.

Focus on principles. Similar to the point above, I had to remind myself several times during the course that it is not really about how to design a user interface, but about the principles of human-computer interaction. There's a difference here, I believe: we could spend a lot of time on issues like font choice, spacing, the use of tools to aid in design. We didn't, though, which meant we could talk at a higher level of abstraction and not get lost in pixels and palettes.

Allow for failure the first time. The students completed a small project before Spring Break, a project that was essentially a small version of what we would do after break. It made them put the design principles into play within the double diamond context. They almost all did badly, from an objective point of view, but this was a success from a pedagogic point of view. This showed them that it's a different thing entirely to claim understanding vs. to apply knowledge in context.

Socratic Day. There was one day where I was feeling quite frustrated about my students' inability to show empathy for each other and for me, and so I ran about twenty minutes of class via the Socratic method, starting with the question, "What do you think I see?" We touched on a lot of interesting ground here. Interestingly, they did not really come up with the answer I had in mind, which was "The backs of laptops and the tops of heads." I don't think I've ever gone Full Socratic (tm) on my students before, but it's something I need to keep in mind, especially if I am feeling upset or disoriented.

The "A" Group. Despite my frustrations with the course, there was one team of guys who attended practically every meeting, most of them completing all assignments satisfactorily, paid attention and asked questions during class, followed instructions and applied what they read during class activities, and produced a good and thoughtful final project. None of them had significantly different prior experience from the rest of the class, and not all of them earned stellar grades in the prerequisite courses. This tells me that what I asked the students to do was on target for those students who were on point, if you don't mind mixing metaphors.

Many small assignments. I set up an aggressive schedule of reading and crafted in-class activities to support them. I needed to make sure students were keeping up with the pace, so I set up a series of assignments to be done before each class for the first half of the semester. This worked in terms of keeping people together: I could tell that almost all the participants in class had done the preparatory work. During Spring Break, as I reflected on what I had seen in the first half of the semester, I carried this model over to the second half as well: when there was a day that I needed students to have something particular prepared, I set up an assignment for it. The assignments were graded rather generously by an undergraduate grader, but that generosity was fine since the assignments were more about keeping up than mastery.

I learned. I think I mentioned in my course planning post that I was wonderfully surprised by the revisions in the new edition of DOET. One piece in particular that stood out, as someone interested in methodologies, was the double diamond model. I've never deployed that myself, so I figured I would use the semester to try to understand it. I gave a wrap-up presentation in the final week of classes where I explained my understanding and frustration with the model, putting it in contrast with Scrum and my spin on George Kembel's design thinking framework. I actually started planning out a blog post called, "The Double Diamond is Malarky," and in doing reading and preparation for that post, I came across a different visualization than UK Design Council's—this one from ThoughtWorks.
All the pieces fit together for me now: using this model, the iterative and incremental software development approach sits within the second diamond entirely. At first, I rejected this, since my predilection is to consider each iteration anew, with the possibility of pivoting on the problem completely. Then I realized, however, that this is exactly how I have been running my immersive learning projects! I use one semester with the Honors College to figure out what problem we can actually solve, and then that input is given to the Agile, cyclic development model of the Spring Studio course. Hooray for reflective writing!

What can be improved

One of the biggest surprises of the semester is that I was assigned to teach CS345/545 again in the Fall instead of a section of CS222. This means I have the opportunity to improve the course right away, while the ideas are fresh in my head—an opportunity for which I am grateful. Expect a "Summer Planning" post in the next few months as I sort things out. In the meantime, here are some things I can improve for next time.

Stow laptops or GTFO. That is, put your laptops away or get thine fanny out. Those blasted distraction machines are ruining our students. Attendance is not required for my class, and that's a fact I reminded them of many times. People clearly are engaged in something else and thinking that if they sit in class they will magically collect knowledge. It's ridiculous, it's infantile, and I'm done with it. The lingering question is whether or not I want to incentivize the use of paper notes or not. For example, I could offer a grade or something like an achievement for using paper notes, or I could ask them to keep a design log with their notebooks. I need to think about the logistics of this still, but one thing's for sure: the laptops are going away. 

A quick related thought: I had one guy this semester who, when I asked him and his chatty colleagues to close their laptops and join the group, did not, and instead sat in the back smugly with his laptop clearly open. The question then, is, what should I do in such a case? I don't want to play power games, that's just more juvenile nonsense that doesn't belong in the classroom. I am thinking of making a policy that I will simply leave if the policies aren't followed, which then makes it a matter of social pressure. I'm not sure how that will play out, but I feel like I need a plan so that I react appropriately.

Iterate on the final project. Now that I have a better understanding of the Double Diamond, I want to bring that out in class by having students complete short technical iterations within the context of the bigger design project. This will give them a valuable opportunity to assemble and test an artifact and get feedback about it, from both me and potential end-users. It seems simple enough, but getting this to fit into the calendar may be tricky. It's possible that a small project may not be necessary if instead we allow iteration within a bigger project.

External partnerships. Many years ago when I taught HCI with a focus on mobile app development, one of the best parts of the class was setting students up with external consultants. These were not clients but rather alumni, friends, and generous strangers who agreed to give students feedback on their work. You know how it goes, teachers: you can say the same thing a hundred times, but sometimes students won't hear it until it comes from someone else. This past semester, we were on track to have an interesting community partner for all the projects, but this fell apart in a sea of bureaucracy and red tape. As a result, the student projects were a bit "fakey". This had the immediate result that most (if not all) of the students did not conduct authentic evaluation at the end of the project. Many asked friends and family to evaluate their work, which is absolutely the worst thing to do. Setting up real partnerships would help here, as there would be someone else with skin in the game besides the students—someone with different objectives, not just getting a grade.

More check-ins on the principles. As part of the small and large projects, student teams had to submit project reports, both a draft and a final. The project reports are where students had to explain how their projects manifested Norman's seven principles. What I saw was, by and large, rationalization rather than principle-informed design. That is, students explained decisions they had already made, situating these within the principles, but it's pretty clear to me that they did not consider the principles before or while making the decisions—only after. I designed a final exam question to help students tease these ideas apart, but students who did a poor job in their project reports also misinterpreted the question itself and provided similarly superficial or unjustifiable responses. I should be able to craft additional discussions, assignments, or activities that help students frame their works-in-progress within the principles, which I hope will lead to a better understanding of them.

What still puzzles me

Graders. Since I knew I would have so many assignments, and it was going to be a busy semester, the department hired an undergraduate grader for me. She was a good student who I have worked with before and whom I trust. However, she could not attend classes, so she had a real outsider's view of what was going on. It's still a blind spot to me, if there were opportunities to give feedback to my students that I missed because she was handling the day-to-day assignments. I asked her to report anomalies to me, which she did for most of the semester and which led to some interventions, but this died off as the semester's pressure built.

Bad UIs and Lack of User-Centeredness. As I mentioned above, we focused on principles, but the fact is that some students developed some truly hideous interface designs. Some of these were bad because of design decisions that the students made, and these carried on into nonsensical UI choices; others were bad because the layout was just silly. A lot of students used JavaFX and SceneBuilder with the mistaken idea that because they have a tool to lay out elements, they must be doing it right—a myopic, developer-centered rather than user-centered perspective. The question for me, then, is whether there is a modicum of UI design knowledge that I can help students acquire that would actually help here. My intuition says "no", that if they don't have taste they cannot develop it in the middle of an already-packed semester. My intuition has been wrong before, though. The bigger question is how to get them to focus consistently and enthusiastically on the users. I am thinking of bringing in something like task modeling from Software for Use, which I had good luck with years ago, although that book is now comically dated, with examples drawn from Windows 95.

Empathy. I wrote earlier about a particular example of how one of my students failed to show empathy, but I think this is a bigger problem—as in, a really, really big problem. If you're a junior or senior in college, and you don't know how to build empathy, what in tarnation has been going on in your core curriculum and pre-college experience? What's the point of studying history, culture, or language if you cannot put yourself into someone else's perspective? If you get to an upper-level elective on HCI, and you do not know how to have empathy for others, is it actually possible to learn it? Is it my responsibility to teach it?

There's a related and troubling problem here related to student disabilities. The university rule is that students with disabilities should be reviewed by the Disability Services office, who will then develop accommodations for the student; faculty are given a form that indicates what accommodations are considered reasonable. In my experience, most of these are "Extra time on tests" or "Can take tests in a distraction-free environment." That's all well and good, but that office doesn't actually provide me the information I need about the disabilities that impact the work that I do. If I had a form that said, "Cannot empathize," well I would know I better not count such an assignment against the student—but as far as I know, that office has never produced such a form. It puts me into a bad situation where I have to guess at student disability, despite my having no training or expertise in this area. Yikes. There's a sense in which the lawyers are on my side: if an autistic student sued the university because they failed my course due to unsatisfactory completion of an empathy-related assignment, the university could say, "They didn't have an accommodation on file for their disability." This doesn't change the fact that such a thing seems impossible to have been filed in the first place. Maybe I'll check in with Disability Services over the Summer to chat about such cases.

Wrapping up

This post went much better than the previous one. It has helped me articulate some of my ideas that can feed forward into my planning process for Fall semester. Thanks for reading! As always, if you have questions or ideas, feel free to share them in the comments section below.

Wednesday, May 9, 2018

Collaboration Station Enhanced

I am just wrapping up work on a INSGC-sponsored enhancement to Collaboration Station. Regular readers may remember the game as the main product of my Spring 2015 Game Studio course—an educational multiplayer game about the International Space Station. The game was very impressive for a multidisciplinary undergraduate game studio project, but there were a few things I have wanted to clean up. INSGC agreed to fund a project with three major goals: to align the look and feel of the game more closely with the International Space Station; to improve the quality of materials available to teachers; and to bring the game to iOS in addition to Android. Since last summer, then, I've been spending a enormous amount of effort on...
The game is currently available on the Google Play Store, and we should be within days of having it on the App Store as it winds its way through the approval process. I wanted to record a few of my thoughts about the process here, including technical notes and personal notes, because hey, this is my blog for reflective practice, after all. What did you expect? Miniatures?

Project Overview

The original Collaboration Station was written in Java using PlayN. We used Bluetooth for local multiplayer, developing our own protocol by reverse-engineering some of the tricks used in SpaceTeam. In particular, we figured out how they had used Bluetooth device name mangling to figure out who else was playing the game in local range. This worked fine for our Android version of Collaboration Station, but we hit a barrier when we tried to build the iOS version, since the particular Bluetooth function we needed to call was blocked by the operating system. (I'm still not sure how SpaceTeam got around that one.) For Enhanced, I decided to go with Unreal Engine 4 and the GameDNA Realtime Database plug-in, which brings Firebase support to UE4. I learned about this integration as a result of some conversations at GDC 2016; given my experience with Firebase and the cross-platform builds facilitated by UE4, this seemed like a great match.

Building the core functionality and architecture of Collaboration Station Enhanced took longer than I expected. As I mentioned in my write-up of Fall's Game Programming class, I had hoped to have the basic pieces in place early in the Fall semester so that students could write their projects as ad hoc plug-ins to my system. In fact, I was only able to implement one sample minigame—memory—in the Fall and get roughly half of the multiplayer implementation working. Some of the delays came from the fact I was using a beta version of the Realtime Database plug-in, and I did have to work with the developers on some critical defects. I also ended up having to get the GameDNA Ultimate Mobile Kit plug-in to allow anonymous sign-in to Firebase; this may now be wrapped up in the other plug-in, but it was no great concern at the time since the budget had plenty of room for such expenses.
Experiment Sorting: Memory Minigame

Working with the Student Team

I hired three undergraduates through the grant to work with me in the Fall, using the job titles Game Artist, Game Programmer, and Game Educator. I put together a good team, but there's a sense in which I was not really ready for them for several weeks. I had hoped we could work together for sustained times during the week, but our schedules did not mesh well; there was only one one-hour block MWF afternoon that we could all meet together, so we settled on that. I put the Game Programmer on the task of writing the sequence puzzle ("Simon" game), but I didn't really have the underlying systems in place yet to piece everything together. It took him longer than I had estimated to finish this task, though, and so we never really had any painful merges. I gave the artist some odds and ends to work on, but we never had the right workflow. Technical problems in the studio led her to work elsewhere, but I didn't realize how badly this set us up: she was working mostly independently, and she never got into the workflow of being able to add things to the game herself. That is, she was off version control and outside of UE4. It wasn't until the very end of the project that I realized she was unable to run the game herself at all. A result of all this was that she spent a lot of time on assets that we just couldn't integrate, for technical and aesthetic reasons. The game educator was the one student who worked most independently, but in truth, I let him work perhaps too independently. We sought some feedback from education experts on campus, but he mostly developed the revised Web site and teacher resources by himself. Both of these things take careful design skills, and what he made is sufficient, but I think our lack of communication contributed to a lack of polish.

Looking back, I probably could have handled some of the communication and planning better, but there's not much I could have done to improve the rate at which I completed my tasks. The students did a reasonable job of keeping up with the tasks I could think of, but often I couldn't remember what I asked them to work on! Given that we didn't have much face-to-face time, tracking tasks in something like Trello or even just a spreadsheet could have helped. The main impediment, though, was that my mind was full enough of the work that I had to do on the project, plus my other professional obligations; it was just too much to try to remember where they were as well.
Exercise: Sequence Puzzle Minigame

Game Design 

We did accomplish two significant improvements to the game design. The previous sequence puzzle was based on four somewhat arbitrary ISS factoids, chosen mainly because we could develop good images and sounds for them. We revised this into an exercise minigame, where the sequence of actions represented three authentic exercises astronauts must perform in space. The other improvement was to the sliding tile game, which used to be a single image of a humanoid robot developed by NASA for use on the ISS, but it had no contextualization—a player would have no idea what they are looking at. Now, this game is "telescope alignment", and there are four random constellations chosen from the Southern Hemisphere. We hope to inspire the player to look up more information about them by showing constellations that will likely be unfamiliar.

One significant change between the original and the enhanced game is that the original divided the minigames into "science" and "maintenance" tasks, and each level had a goal based on how many of each kind of point were needed. In post-mortem discussions, we realized that this was somewhat artificial and didn't add to gameplay. In Collaboration Station Enhanced, the minigames all generate the same kind of points, and we rely on players' curiosity to try them all.
Task Selection Screen
The one improvement we didn't incorporate was better contextualization of all the minigames. My plan was to dress up the task selection screen with a short textual description and an animated demonstration for the mini game. As the semester charged toward its completion, however, we ended up having to do something much simpler here.

Technical Notes

One of my personal goals in working on this project was to get a better understanding of the C++ bindings for UE4 and their relationship to Blueprints. The memory minigame is a bit sloppy in this regard, but as I worked on other minigames, I had better ideas about how to separate concerns. My Game Programmer student didn't approach any C++, but this is a specific area where if we were collocated, I would have pushed him. Managing the logic for generating and matching sequences is straightforward in traditional text-based programming and ridiculously messy by comparison in Blueprints.

Speaking of which, the networking code is inelegant at best. It is split among a handful of Blueprints, and the dependencies are not always clear. At one point I tried to separate the Firebase logic from the rest of the multiplayer logic, but I'm not sure even where that boundary is any more. It works, but I'm not very happy about it. First, there's no unit tests: automated testing in Unreal Engine is not well supported—at least, not as I understand it—and this left me in a very slow write-deploy-test cycle. It made me afraid to refactor because of the time I would inevitably lose, the fear that leads to bad architecture. I suspect that, like the sequence puzzle logic, much of the multiplayer logic would have been much easier to express in C++. However, despite an email discussion claiming that the 1.0 release of the Realtime Database Plugin would have documented C++ support, it's still all Blueprints.

What is good about the networking code—besides the fact that it works of course—is that we can run multiplayer games over the Internet without needing to collect any private information. Anonymous sign-in is used together with a clever game code system that my students and I designed. This should scale up to the number of users we expect. If the app went viral, it would collapse, but it can handle dozens of games at once for sure. Well, as "for sure" as one can be without actually trying it, of course. The downside to the Firebase networking back-end is that you need to be able to connect to it, unlike the Bluetooth approach that doesn't require any other routing. On campus, we discovered that the normal, secure Wi-Fi is fine, but if we connect to the "bsu guest" network, something is filtering out the Firebase communications. This susprised me, since I thought they were all simply tunneled through port 80, but we did not have the time to figure out where exactly the packets were being filtered. We are keeping both the original and the enhanced versions on the store, though, so if someone is stuck in a school network situation where they cannot alter their filters, they can always go back to the Bluetooth-based solution in the original.

It was great to work on a project where all the assets already existed. I could focus on writing the logic and simply drop in the right pieces where they needed to go: backgrounds, sprite images, music, and sound effects, already made and ready to go. The time from programmer art to production art was very low. The only exception here were the screens themselves, where I would generally whip up the simplest possible UMG widget to test the flow, and only really design the screen once it was done. This worked well, so I didn't lose a lot of time fiddling with placements until I knew the screen was needed.
Telescope Alignment: The Sliding Tile Puzzle Minigame

Time = Money

I could not have completed this enhancement project without funding from the INSGC. This was a relatively small grant of $15,000. INSGC requires at least 50:50 cost-share from the organization, and I had worked this out with my department and the university prior to submitting the grant; the total cost of the project on the books was roughly $30,000. (Obviously, the 50:50 minimum is interpreted by the university as a maximum as well.) It turns out that for various reasons, we didn't use all the student wage allotment from the grant, and I was able to borrow several tablets from another office at the university, which meant I had a few hundred dollars of supply budget leftover as well. The total amount spent by INSGC ended up being on the order of $11k.

Many times while working on the project, though, I wondered: what did it really cost? I spent some time last summer working on the project, but we can chalk that up to professional development and preparation. So, for this back-of-the-envelope computation, we'll consider only the academic year costs. For those who don't know, faculty member's time is generally divided into quarters; my usual assignment is three units of teaching and one unit of research during any given semester. The college prefers I charge $12,500 for a course release, so let's use that as the cost of one course-worth of my time. I actually had negotiated a lesser rate for this project to allow it to fit within INSGC's financial constraints, but we're not computing the spent cost but the actual cost. In the Fall semester, I used almost all of my research time and a portion of my CS315 teaching time on this project, so let's call that $12,500 as a low-ball estimate. I worked on it several days over the Winter break as well, but I'll also put that in the "freebie" bin, even though the project would probably have failed without it. In the Spring, I spent practically all day (that is, roughly nine hours) on this project on Tuesdays and Thursdays. I also spent at least one to two hours Monday, Wednesday, and Friday afternoons. As an estimate, then, let's say I spent 3/5 of my week on this project, meaning roughly $60k cost. I've also been working on it since the semester ended to wend our way through the iOS process, but again, let's skip that. This means the total cost of my attention on the project, ignoring other project costs, is about $72,500, or more than double what the official budget states the project to cost.

The university would normally charge around 40% indirect costs for research projects, so if I had provided an honest budget for an agency to cover all of the costs, I would have needed a grant of over $100,000. I asked for the maximum amount that INSGC would provide for a project, and that's less than 15% of the actual project cost. I don't know of any agency that would have funded such a modest project for its actual cost. The fact remains, though, that without the small grant, I would not have been able to do this project at all.

I share this to exemplify a point that I've made before: research loses money. The academic research enterprise forces us to grossly underestimate our costs or to misrepresent what we are doing. The one piece of information I do not have is what it would cost for a private enterprise to do this work. I would love to hear from someone knowledgable about multiplayer game development what they would have charged to do the conversion. The general rule of thumb is "industry is more efficient," but I honestly don't know here how my expertise and cost compare to the games development industry. Of course, living in Muncie has its advantages: $100 grand goes a lot further here than on the West Coast.
Circuit Repair: Tile Rotation Puzzle

Wrapping Up

Collaboration Station Enhanced was a great project, and I'm glad to have worked on it. That said, I'll be glad to see the back of it—a lot of other things didn't get done while this dominated my mind the last academic year. However, I learned an awful lot about UE4 development, things I'm sure I would not have learned without being hip-deep in a development project. This investment already paid off in the Spring 2018 Game Studio, who also used UE4 but to make a very different kind of game—expect a post about that in the coming days.

It was fun to revisit this project and rebuild it, but at the same time, I felt creatively constrained. After all, I was not really creating something new from my imagination, interest, and passion: I was recreating a collaborative work but without the original collaborators. I am hopeful that my next project might allow me to deploy these skills in a new context. I do have one such proposal in the works, and it does have a more realistic budget. 

I will close by expressing my public gratitude to several people and organizations who made this project possible: Ball State University's Entrepreneurial Learning Office and Immersive Learning program, for funding the original release of Collaboration Station; Indiana Space Grant Consortium (INSGC) for funding the enhancement project; the Computer Science Department, for not just approving the project but for providing valuable space, computing resources, and staff support that allowed us to succeed; Byron O'Conner at the Ball State University Digital Corps for helping me understand the Apple development and deployment models; Kyle Parker at Ball State for generously loaning several devices that we used for development and testing; and Perforce and Epic for providing academic-friendly licenses for their Helix Core and Unreal Engine technologies, respectively.