Friday, February 28, 2020

Managing the lifetime of child actors created from C++ OnConstruction methods in Unreal Engine 4

I have been working on a little example for my UE4 video series based on Space Invaders and designed to talk about some issues in object-oriented decomposition. Along the way, I ran into a technical problem that I know I had seen last summer, but it took me hours to find the solution. I may make a video about this later, but for now, I just want to get the basics explained here on the ol' blog.

The specific modeling problem I am dealing with is the swarms of enemies in Space Invaders. It's pretty clear to even the most novice programmer that "alien" should be an object. The Alien class would be an Actor, and it would be a great place to deal with things like collision detection and explosion effects. However, it gets a bit tricky when dealing with the movement patterns of the aliens: the whole swarm changes direction when one of them on the edge hits the side of the play area. This leads to a less obvious object-oriented modeling idea: that the swarm itself is another kind of Actor.

In my sample solution, I wanted to be able to create a swarm with any number of rows and columns and have it create that many aliens in a grid. In Blueprint, this is pretty easy to do. BP_Swarm has Rows and Columns variables that specify the size of the swarm. Its construction script can loop through all the "cells" of the grid and add a child actor of type BP_Alien for each. Presto, this allows you to drop a BP_Swarm object into a level and configure its placement and size.

The trouble arose when I decided I wanted to do this in C++ instead of in Blueprint. I added what seemed like the right code to the OnConstruction method. Here's the basic idea, leaving out for the moment the code that handles the individual placement of aliens:

void ASwarm::OnConstruction(const FTransform & Transform)
    if (AlienClass) {
        check(Columns >= 0 && Rows >= 0);
        for (int i = 0; i < Columns; i++) {
            for (int j = 0; j < Rows; j++) {
                UChildActorComponent* AlienChild = NewObject<UChildActorComponent>(this);

When I dragged a swarm into the level, it showed up, but its children persisted every time I moved the swarm or changed its parameters. This is clearly a different behavior than in the Blueprint construction script, but it wasn't obvious to me at all how to get that behavior to work in a C++ implementation. I remembered having come across it when working on the building logic in Kaiju Kaboom, but it took me hours to find it again. Indeed, I even posted to the Unreal Engine 4 Developers Community on Facebook, but the best answer I got was one I was aware of and left me unsatisfied: manually check for and destroy child actors at the beginning of each call to OnConstruction. After stepping away and searching again this morning, I found the forum post that I'm sure is the same one I tripped over last Summer—the post that mentions a barely-documented feature of UE4 called the component creation method. Here's the magic line that saved my ability to trust my memory:
AlienChild->CreationMethod = EComponentCreationMethod::UserConstructionScript;

EComponentCreationMethod has four possible values, and this one must be what is used internally by components created via Blueprint construction scripts. It aligns the behavior of the C++ implementation with the Blueprint one.

For reference, here's the full implementation of OnConstruction from my working demo. It uses a designer-configurable Spacing value that specifies the distance between aliens in the grid, and then it makes use of range mapping to translate from array index to geometric space. One other bit of weirdness here that I'll mention is that while UE4 is generally an "X-forward" system, with the X-axis pointing in the direction an actor is facing, UPaperSpriteActor by default has sprites facing in the negative Y direction. Hence, the horizontal placement of aliens is along the X axis and the vertical placement of aliens is in the Z.

void ASwarm::OnConstruction(const FTransform & Transform)
    if (AlienClass) {
        const int Width = (Columns-1) * Spacing;
        const int Height = (Rows-1) * Spacing;
        const FVector2D ColumnsRange(0, Columns - 1);
        const FVector2D RowsRange(0, Rows - 1);
        const FVector2D HorizontalRange(-Width/2, Width/2);
        const FVector2D VerticalRange(-Height/2, Height/2);
        const FTransform ActorTransform(GetActorTransform());

        check(Columns >= 0 && Rows >= 0);
        for (int i = 0; i < Columns; i++) {
            for (int j = 0; j < Rows; j++) {
                UChildActorComponent* AlienChild = NewObject<UChildActorComponent>(this);
                const FVector Location(
                    ActorTransform.GetLocation().X + FMath::GetMappedRangeValueUnclamped(ColumnsRange, HorizontalRange, i),
                    ActorTransform.GetLocation().Z + FMath::GetMappedRangeValueUnclamped(RowsRange, VerticalRange, j)
                FTransform AlienTransform(ActorTransform);
                AlienChild->CreationMethod = EComponentCreationMethod::UserConstructionScript;

One other note about this code, potentially for future-me who comes back to remember how I fixed this problem before. I had forgotten for a while to call RegisterComponent, which omission makes the whole thing a bit squirrely. Also, there is temporal coupling in the component's methods: calling RegisterComponent at the end of the loop creates strange editor-time behavior as well, whereas calling it immediately after NewObject gave the expected behavior.

Tuesday, February 18, 2020

The Poor Man's Gameplay Cue in UE4

I have some time this morning to collect my thoughts, so one thing I want to do is share a quick post here about something interesting I encountered a few days ago.

On Feb 13, Epic hosted a Live from HQ stream on Game Jam Tips and Tricks, which you can find archived on YouTube. In this stream, Michael Noland introduced a useful pattern for UE4 Blueprint programming that I had not seen or thought of before. He mentions that it is inspired by the Gameplay Abilities system, which I am sure I have tried to learn more than once, and each time I think, "This is amazing and also way out of scope for my project!" Then, I forget the important details and carry on. The Gameplay Abilities system is still (or again?) something I want to invest some time in understanding, and I'm hoping in part that by recording this smaller version here, I'll give myself and others an anchor to understand the more complex version.

At 54:15, Noland begins an explanation of why Sound Cues are a useful extension of normal Sound classes. I've been a fan of Sound Cues at least since working on Kaiju Kaboom, where I wanted variation on sound effect volume and modulation. He builds on this, starting around 56:26, explaining the value of decoupling game effects ("juice") from the core game rules. In particular, he mentions that certain blueprints will be high-contention, such as pawns, game modes, and player controllers. Separating the game effects from the other rules means that multiple people can be working simultaneously without version control conflicts, since these behaviors are now in different files.

After a few minutes, he ends up with a hierarchy like this (changing his naming scheme slightly to follow the Gamemakin Style that I prefer):

When the BP_StandardGameplayCue is spawned, it plays any sound, particle effect, or camera shake that has been set, checking via validated get. Noland points out that a slightly more robust system would have to account for who instigated the effect so that it could, to cite his example, do something like set that character on fire or give him a halo.

I hope that write-up is useful, if for nothing else than to help me remember this interesting pattern next time I'm working on a collaborative jam project or trying once again to make sense out of Gameplay Abilities. I wonder if I had known this a few weeks ago if I could have unleashed my son a bit more freely to work on visual effects in Disarmed.

Monday, February 3, 2020

Global Game Jam 2020: Disarmed

I hosted Global Game Jam 2020 last weekend at Ball State University, with generous cosponsorship and co-organization from the STEM Living Learning Community, Office of Housing and Residence Life. The theme, as announced in the keynote address, was Repair. I thought this was a good theme, being broad in interpretation yet clearly constrained.

My oldest son came with me again, and like last year, we planned on working together on a project. We have been enjoying Brief Battles and Towerfall recently, and so we talked before the event about trying to create some kind of local multiplayer competitive arena game. After hearing the theme (and taking care of a bit of site administration), we hit the whiteboards and started sketching ideas. My son pitched the idea that you were robots trying to repair yourselves, and you could use the things you pick up as weapons against the other robots. That became the core gameplay, and the rest emerged from there.

We called the result Disarmed. Here are the title and gameplay stills from our Global Game Jam project page:

The players click in from their controllers, and the game runs with a 60-second timer. You start with no arms, but you can jump to a nearby platform to grab a harpoon gun arm. That gives you three shots with which you can try to hit the other robots: a successful hit on an armed robot knocks its arm off, and a successful hit on a disarmed robot counts as a kill. After the 60 seconds are up, you get a report about how many deaths and kills you accumulated.

My son and I were using found audio, but right across the table from us was a composer working with just one other person on a project. On Saturday, I showed him what we were working on and invited him to create an original soundtrack, if he felt so inspired. His name is Nathan Cobel, and it turns out he's a professional musician and tutor. He ended up creating two pieces for the game: a short loop for the title screen and a longer one for in-game—pieces much nicer than the placeholders we had tossed in from browsing the Web.

We used Unreal Engine 4.24 to make Disarmed. My son ended up drawing all of the art using Piskel, which I had only shown him once before, many weeks ago. He quickly came to like it and became able to export sprite sheets and bring them into the engine. The only place where I really got my hands dirty in the artwork was in making a simple custom material to tint the single grey robot into the four different player colors. It may be worth mentioning that my son has made his own pixel art using Construct 2 in the past, and he's played a little bit of Dead Cells, but I'm sure he's never really studied pixel art. I don't know a whole lot about it myself, and in fact, I'm not really a fan of the genre. There were a few cases where I asked him to redraw some things to improve the contrast, and I think the final result is pretty good for a pair of guys who were winging it on the visuals.

In the project page, I checked the two diversifiers that matched this game. One is "!Coding", which is defined as " Don't write a single line of text to create your game. Only use game engine built-in features and visual scripting." I checked it even though I don't agree with it, since we technically followed it. However, it repeats a dangerous idea that visual scripting is somehow not coding. UE4 Blueprint is as much programming as any other programming language. Making a video about this is on my list for the semester. The other diversifier I selected was Protip, which is defined as "All members of your game jam team get 8 hours of sleep, 10 minutes of exercise and eats a meal that includes vegetables each day of the game jam event. Upload a brief development diary along with your game upload to document these actions." I checked that even though we technically didn't get it. First, we didn't upload a development diary, although maybe this description counts. Second, I know from talking to my son that neither of us slept eight hours the first night of the jam despite spending eight hours in our beds. If I had known that he also was not sleeping, we could have done some middle-of-the-night development! Since we live a ten-minute walk from campus, it was easy to get the exercise, and we do always make sure to eat our veggies.

I want to share a few technical notes about the game, in part so that others can understand how it works, and in part so that I can come back here and remember how it works :)

Local Multiplayer in UE4. In order to allow a player to "click in" to join the game, they have to already have a PlayerController created. There's always one player controller (number 0), and so the title screen game mode creates three extra controller objects. These controllers listen for the player to click in, and then tell the game instance to increment the number of players. This worked except that then when going into the main game mode, we always got four robots in the level because there were four player starts. Our solution was, just before leaving the title game mode, to remove some of the player controllers. This did the job, although we realized in testing that it's a bit sloppy. We should have kept track of which controller ID was clicked in, because our current approach is prone to a problem if there are more controllers plugged in than actual players: someone might "click in" on controller #4, then the game starts, and it removes controller #4, leaving that player high and dry. Aside from some of this management, local multiplayer was really a breeze to set up.

Physics vs Projectile Movement Component. The harpoons were launched by enabling physics on them and adding an impulse. This seemed to work fine when testing in editor, but when we launched the game from a built executable, we saw weird things happen: the harpoons would often get stuck in the robot who was firing them, despite the fact that our collision handling should not have let this happen. It wasn't until just before the end of the jam that I realized I could try to work around the problem by switching from physics to projectile movement component. This solved the problem, although I'm still unsure as to why we would see different behavior in PIE vs in the packaged game. The rule of thumb that I forgot was not to mix and match physics and non-physics ideas into the game.

Spreading sprites across an area. This is a pretty minor point, but it struck me as interesting. I have an object that is responsible for spawning one sprite onto the screen for each player, such as at the end of the game to show the scores. There's a horizontal range over which I want to spread the objects, and so I started trying to determine the X positions of each sprite algebraically. It dawned on me that this is really mapping from one range (player number, which goes from 0-3) to another range (X coordinates, in this case -300 to +300 from the position of the spawner). This can readily be done with the Map Range node. Here's an example from BP_RobotSelectionSpawner:
Like I said, it might be kind of obvious, but when you've been jamming for 40 hours already and your brain is a bit addled, it feels good to remember that if you think about a problem declaratively, you can solve it more elegantly than with ugly math nodes.

You can download Disarmed from the project page, although it will require 2-4 controllers and Windows to be playable.

I don't think I'll have the time to write up any more thoughts about the Jam, but I will say that we had the best turnout at our site in four years. There was a lot of energy in the room. I think that offering catered lunch on Saturday was a big influence in having people come back and work. I was very pleased to see the first analog game created at our site, too; it's something I've encouraged for years, but this is the first time one was finished.

Thanks for reading! If you have a chance to try Disarmed, let us know what you think. The folks who played it at the Jam seemed to really enjoy it.

Tuesday, January 28, 2020

Painting Journeys in Middle Earth: Villains of Eriador

My father-in-law taught me the wonderful tradition of hiding your own presents under the Christmas tree. This year, I had a nice surprise from myself on Christmas morning: the Villains of Eriador expansion pack for Journeys in Middle Earth. I painted the core set back in September, and my two older boys and I enjoyed playing the Bones of Arnor campaign with Legolas, Gimli, and Bilbo. We knew we wanted to play again; in fact, my second son was ready to start another campaign the night after finishing the first. Knowing that Villains of Eriador adds three extra villain miniatures and a handful of cards, I set up a plan to get it around the holidays so we could get back into Middle Earth.

The Bones of Arnor campaign is free with the companion app, but the other available campaign is a separate purchase. I am mentioning that here because that makes me a little uneasy: separating out three villain figures for separate purchase and charging for a second campaign feels like nickle-and-diming the fans. I find myself curious about how this financial decision played out. I know as well as anyone that software costs money to make and maintain, but on the other hand, you're really buying access to the software whenever you buy the physical content as well. In some ways, it's not like the old days when you bought computing hardware and the software came with it—the days that gave rise to innovations like Unix and the Free Software Foundation.

As with the base set characters, I started by cleaning the miniatures. They were then prepared using zenithal priming from my airbrush.

The game expansion contains no illustrations for the three villains: they do not have any card representation in the game, unlike their spiritual predecessors Descent or Imperial Assault. There are a few threads about color schemes over on BoardGameGeek, and in one of them, I discovered that there is one illustration presumably of Gulgotar in the app, at the point where you choose your difficulty level. I grabbed a screenshot from the Steam version of the app, and I am including it here for other painters who might want quick access to it.

As you can see, Gulgotar has uncommon blue-tinted skin. For my figure, I decided to match this tone. There are two failed attempts under my third and final attempt. The others were too blue and too saturated: adding grey into the mixture helped. My color-matching attempts were both aided and frustrated by Sorastro's excellent video tutorial about this miniature. I didn't want to just copy his recipes, but in the end, I did copy his skin recipe pretty closely. Here is the result.

The first pass at Gulgotar was "clean" with no weathering, and it looked pretty sharp. That metallic girdle and the ... shoulder spikes? ... looked like they needed a little something, so I went in with some stippling of thin orange and browns. As I've said before, I still get very nervous about weathering, but I'm glad I did it here. The only part that stands out to me as incongruous is that the rusty effect on the blunt side of the sword is a bit too intense for the rest of the blade; I may yet go in and add a little more grime or, perhaps, stipple in a little more metallic.

I am happy with how his furs came out. I used a technique I learned years ago from Sorastro's Chewbacca and Ghaarkan video—a technique that has served me well. I mixed up shade and highlight tones and wet-blended them on the furs, and this effect was enhanced by the zenithal priming. Adding a wash of sepia and black ink brought all the colors together, and a modicum of manual highlighting finished the job.

I'll mention here that the figures were based using the same mixture as the base set: black tea, burnt grass fine turf, and medium green fine turf, followed by static grass after varnish. It is literally the same mixture, since I had some leftover in a little sealed plastic cup.

Here is Coalfang, on whom I used the same basic approach as described for the furs above but with much more manual highlighting. The first pass left him looking much too dark, but I was able to brighten him up considerably. It's a simply monochrome paint job, with a little blue washed into the shadows, but I don't think that really shows.

My commentary about Coalfang is another critique of how the expansion was packaged and sold, as well as how it relates to the DLC campaign. My sons and I started the second campaign last night, and it turns out (minor spoiler ahead) that Coalfang is introduced in the very first mission. Coalfang is described in text as being russet with black fangs. When I painted it, all I had to go with was "coal fang", which sounds to me like it should be black, not potato-colored. We enjoyed the first mission, but I couldn't help but be a little miffed that I spent hours on this wolf with no color guidance, and then the first thing we find tells me that it doesn't match the designer's vision. I don't know if anyone from Fantasy Flight will come across this post or not, but seriously: consider your painters.

As I told my boys last night, I could always repaint it. I'm not real keen on it, though. [UPDATE: But I did. See below.] It's already varnished and flocked. To reprime it, I'd have to strip it or peel away the flocking; to paint it again by hand I'd have to cover all the black and revarnish. Pride is probably not worth it when I have plenty of other figures to paint, and monochrome wolves aren't really as exciting as some other things in the queue.

This is Atarin. (Minor spoilers ahead.) Now, if you've played the Bones of Arnor, you may be surprised that this is Atarin. The figure is not quite how Atarin is described in the campaign text. I don't know if he shows up in armor and a cape in the paid campaign or not, but it is definitely jarring compared to Bones of Arnor.

In any case, one of the BGG threads I mentioned previously commented that the armor could fit a silver-black-red paint scheme, going with the idea that he's a Numenorian Nazgul. He was pretty straightforward to paint after this decision. The dark areas are a mix of black and deep sea blue, and the silver is a mix of regular paints with my Vallejo Metal Air Silver. P3 Armor Wash added some depth to the shadows of the armor. The cape was basecoated in red with the shadows and highlights painted in with two-brush blending. There are some parts of the figure that could be interpreted as leather, around the belt and what look like pouches, but I decided to keep all of these black anyway to maintain a stark, three-color effect.

If you look at his face, you can see that the figure actually has a nose and lips sculpted inside the helmet. I painted these, because it seemed like the right thing to do. It's a bit silly, though: black, silver, red... and a little bit of a pink nose. One could paint the face jet black and have a more sinister effect, more in keeping with a ringwraith rather than a dude in fancy armor.

There's a family photo of the three villains. Gulgotar was clearly the most fun and interesting one to paint, while the other two are more like palette explorations. Still, it's always fun to bring out a special miniature at a climactic moment in a board game, so I'm glad to have them. Coincidentally, I'm posting this on the day that Fantasy Flight Games is announcing the new big-box expansion to Journeys in Middle Earth, and from the discussion I've seen about it, I'll say they have my number.

Thanks for reading!


We are a few sessions into the campaign now, and the dissonance between the description of Coalfang in the app and my paint job was just too much for me.
Coalfang Revised

Coalfang Revised
She's now properly russet with black fangs and claws. I also repainted the undamaged eye to be red, to match the other wargs, although I gave her a yellow pupil where the others had none. Her left eye looks more deadened by contrast with the red one, which I think is a subtle win. I was able to redo the thick tufts of fur fairly quickly, and I spent much more time on the lighter brown areas. Some paint ended up on the rocks, of course, so they were touched up pretty heavily.

Wednesday, January 8, 2020

Painting Posthuman Saga

I backed Posthuman Saga on Kickstarter after talking to a gaming buddy about it. I knew relatively little about the game, but I had never painted any post-apocalyptic minis before. I think I must have been one of the first North American backers to get my copy, and over the past few days, I've been painting the characters from the core set. Turns out, painting post-apoc figures isn't that much different from medieval fantasy characters—more glasses, fewer fireballs, and about the same amount of backpacks.

I started out by working on the bases. I used the technique I talked about in my post about the Thunderstone Quest miniatures, where I laid down superglue, sprinkled in a little coarse, medium, and fine grit, and then set the glue with baking powder. Here's a process shot of how they looked before priming. (The Deluxe Edition mutant doll figure is shown here too, but I haven't painted it yet; that will be part of the next batch.)

I followed this with zenithal priming from the airbrush, although I'll quickly mention that I've been having some trouble with my airbrush. It's not clear to me if I need to replace some particular part or if this cheap brush just needs to be replaced and upgraded. I'll think about that a little harder on my birthday, perhaps.

I believe I drybrushed the bases with Beige Brown, although it may have been Flat Earth. The two colors are very similar. Increasing amounts of Ivory were added to get decent highlights.

Here are the figures in the order I painted them.

I started with the Guard. I had been away from all miniature painting for months until Christmas, when my family and I did our one-night painting of the miniatures from Clank Legacy. My family and I have also been working on something of a secret project that I look forward to writing about later, but suffice it to say for now that it involves short painting sessions as well. Working on the Guard reminded me how pleasant it is to sit in my office in the evening, listen to a podcast or some tunes, and make a plastic thing a bit prettier.

I started in on this figure by doing thin layers over the zenithal priming, something of a speedy approach as I used on the mobs in Journeys in Middle Earth. Really, I was thinking that I would get these characters done pretty quickly so I could get the game to the table. As I set into my chair and made progress on my Watch Later list on YouTube, I decided I would take a little more time on them. This was an in-progress decision, and it turned out having an interesting implication: the pants are done in a thin layer over the zenithal priming, whereas the rest of the miniature is painted in my more conventional style, mixing two-brush blending and layering as needed. It gives him a subtle kind of contrast that the other miniatures don't have.

I will also quickly mention that up until not long ago, his sneakers were bright white and red. I couldn't decide if I wanted to do any light weathering on these figures or not. I decided to do a little around the feet before varnishing them, and he definitely looks better this way than when he had out-of-the-box kicks.

The glasses were fun to paint. I borrowed from Ghool's Quick Tip about how to paint glasses, and I think the results are pretty good.

This is the Cage Fighter. I think she's the most visually impressive of the lot. The sculpt is good, and I think I did a good job pulling out the contrast.

All of these figures have prominent card art, which you can see on the Kickstarter campaign page. The art for this character has her in checkered pants, but I didn't want to take that deep a dive. I picked the most prominent orange color and used that. I thought about going in and adding more weathering to all the metal spiky bits, but I decided to keep them pretty clean.

Here is the Scout. His pants caused me some grief because they're so incredibly wrinkled, like they just don't fit. I suppose one must scavenge what one can. On my first pass, I painted it a solid color and then used a wash, but this got it too dark. I repainted in a more appropriate tone, but not completely opaque, and then painted in the shadows. After one more glaze of orange, I got it where I wanted it.

From the front, I think he looks pretty darned good. The back of this guy is another story. There's just nothing happening there. His jacket is almost completely smooth, and the bag over his shoulder is wholly uninteresting. I could have painted in some more details here, but again, I was feeling a tension between beauty and time. I decided it's good enough for now. If this guy turns out to be a favorite figure in a favorite game, maybe I'll address it again, but for now, he's table-ready.

This is the Scavenger. He's a really interesting character, and I love the combination of dark skin, pale clothes, dreadlocks, and overflowing backpack: he has a lot of texture. I still struggle to paint dark skinned miniatures from lack of practice. There can be so much rich tonal variation, but the highlights can still go all the way up. I need to be careful not to exaggerate or make it look cartoony. I think I did an OK job here, and fortunately, there's a lot of other focus areas to take away from just the flesh colors.

I saw another painter's rendition of this figure where he gave him different colored shoes. There's ambiguity in the card art, which has a sort of graphic novel style. I decided to echo the colors from the rest of his outfit back down into his feet, and I think this helps tie some of the pieces together. For example, the purple backpack color is repeated on his socks, which I think gives some balance. Like the Scout's pants, I like the idea that this tough-looking apocalypse survivor doesn't care what you think about his purple backpack: it's big, it fits, and it works for carrying odds and ends.

Painting glass bottles is always tricky, since you cannot paint clear. I decided to make it look like he's carrying along a half-empty Bombay Sapphire. The blue comes out of nowhere in the composition, but it makes me laugh.

Finally, here is the Scientist. Her skin is more of a milk chocolate tone, but very little of it is showing in the sculpt. The art has her peering through the glasses, but again, you can't paint clear. Originally, I did the glasses in black transitioning to magenta at the bottom, but there was an unclear edge at the top of the glasses then: not much contrast. The more I looked at her, the more I thought about what the future used to look like: magenta and cyan. Like the blue on the Scavenger, she gets an out-of-left-field shock of cyan on her glasses. It draws attention to her face and makes her look like a synthwave album, both of which are good.

After a first pass at the jacket, I ended up doing a black glaze over the whole thing to tone down highlights gone too far. The glaze medium left her jacket looking shiny, but I couldn't shake the idea that the highlights were still not right. I'm glad I revisited them, even though it was kind of tricky to paint: once she was matte varnished, it confirmed that the extra highlights on the upturned parts of the jacket were needed. It would have been too much black otherwise.

Here they are, all together. It was a fun set to paint, and I think they will look good on the table; I look forward to trying the game this weekend. I'll mention here (so I can look it up later) that the bases were ringed in Americana Dark Chocolate, which is a nice color but took three coats to get anything like good coverage. Usually I just slop on some black craft paint and am done with it. I thought about gluing on some burnt grass flock, but the more I looked at them, I decided I liked the spartan wasteland as it was.

Thanks for reading!

Tuesday, January 7, 2020

Thinking about High Impact Practices

I have been selected to be part of my university's High Impact Practice Implementation and Assessment Task Force. The task force chair has been good about sending agendas along with work for us to do in preparation for the meetings. In preparation for a meeting next week, we were asked to prepare responses to a few questions. I decided to write my responses here on the blog, in the spirit of No Wasted Writing. (Of course, I am doing this after having sent a novella of an email back to a student, so clearly, I need to be more prudent about No Wasted Writing.)

For some context, it's important to know that the university's strategic plan has defined High Impact Practices to include undergraduate research, immersive learning, study abroad or study away, and societal issue or global challenge. This is a subset of those talked about as HIPPs by AAC&U.

I'll typeset the questions in italics and then give my answer to each below it.

What is the purpose of high impact practices to you? To you, what do high impact practices endeavor to accomplish?

High-impact practices engage students in authentic knowledge work. Student learning is strengthened and deepened by having it take place in the context of meaningful work. The credited learning experience becomes focused on an extrinsic, persistent goal rather than an intrinsic, ephemeral one.

The goal of the experience remains learner enrichment rather than community impact. If external audiences benefit from high-impact practices, this is of course beneficial. However, our real focus is on the transformation and enrichment of the learner. This perspective allows us to form partnerships and accept risk, rather than recruiting clients and becoming risk-averse. My experience has been that students often learn more from failure, and that the transformations in the students far exceed any extrinsic benefit.

What are THREE strengths of BSU's high impact practices? (You might have hundreds of ideas—please identify the top three)
  1. The Provost's funding for Immersive Learning projects gives faculty support to experiment with new ideas prior to formalization in the course catalog.
  2. Many of the faculty involved in high-impact practices are talented and committed scholars who want the best for their students.
  3. There are resources devoted to celebrating the success and spreading the word about projects, for example, through the Immersive Learning Awards program, Community Partner Awards program, Immersive Learning Showcase, and other university marketing efforts. These frame this work as important to the university's identity and narrative.
What are the THREE weaknesses of BSU's high impact practices?
  1. Creative projects are subject to the tyranny of higher education conventions such as 15-week semesters, scheduling around other courses, letter grades, and the inability to "fire" students from a team. These directly contradict most of what we know about how knowledge work gets done.
  2. There is dissonance between the message that we value high-impact practices and the advice that is given to junior faculty.
  3. Departmental and college control over the implementation of high impact practices is a disincentive to multidisciplinary collaborations. The de facto standard is to design experiences for your own majors, regardless of the problem being addressed. Anything else requires inordinate, unrewarded effort.
Bonus answer: Failure to hyphenate the adjective phrase "high-impact".

When students (undergraduate and graduate) graduate from BSU with at least one high impact practice...
  1. What do we want them to know?
  2. What do we want the students to be able to do?
  3. What do we want students to value?
I assume the author wants discipline-agnostic answers rather than discipline-specific ones, which makes this a little challenging to address. However, I was able to pull from my notes about my own department's search for a vision, and this gave me a way to frame my answers.

We want them to know:
  • Fundamental concepts, vocabulary, and techniques of their academic majors and minors.
  • Some advanced topics within their academic majors.
I realize that these items are not clearly related to high-impact practices: they could be said of any student who graduates. It was originally unintentional, but upon reflection, I think it is right. The high-impact practices should strengthen and secure a student's knowledge—even if that is because the experience made them question or doubt it.

We want them to be able to:
  • Self-correct
    • That is, a student should be able to reflect on what they are making or doing, identify their assumptions, and change direction based on this analysis. This is the competent level of the Dreyfus Model of Skill Acquisition, and it is an indicator of reflective practice.
  • Communicate ideas clearly and effectively to different audiences.
  • Ask good, clear questions.
  • Work respectfully and productively on a multidisciplinary team.
We want them to value:
  • The responsibility they have to their team, their employer, and their community
  • The dignity of the individual
  • Lifetime learning
  • Virtuous living: that virtues are habits of the mind developed through intentional practice and self-mastery. Essentially, this is beatitudo, the classic question of what is good in life.
Please feel free to share your own responses or reactions in the comments.

Wednesday, January 1, 2020

The Games of 2019

Happy New Year! As has been my tradition the past three years (2018, 2017, 2016), I am pausing to reflect on the board games I played this past year. I logged 526 plays, which is slightly less than last year. Honestly, I'm shocked, because I don't remember any dry spells here. In the last few days, I logged 17 plays of BONK, which takes just a few minutes to play, and I thought that would inflate my numbers. Perhaps it was because I worked like mad this summer on Kaiju Kaboom, whereas the previous year I spent many afternoons with Gloomhaven.

These are the games I played at least ten times this past year. I've combined families of games where I have logged them separately but they are really the same game, just with expansions or legacy forms.

  • Kingdomino (41)
  • Pathfinder Adventure Card Game: Core Set and Curse of the Crimson Throne (41)
  • BONK (19)
  • Clank! A Deck-Building Adventure and Legacy (23)
  • Azul (14)
  • Dungeons & Dragons: Tempe of Elemental Evil (14)
  • Quiddler (14)
  • Thunderstone Quest (14)
  • Call to Adventure (13)
  • Arcadia Quest (12)
  • The Lord of the Rings: Journeys in Middle-Earth (12)
  • Fabled Fruit (11)
  • Gloomhaven (11)
  • The Mind (11)
  • Fireball Island: The Curse of Vul-Kar (10)
One of the major milestones this year is that my second son (9) has been able to join in much more of the "core gamer" games. In some ways, this started Christmas 2018, when he joined my wife, my oldest son, and me in playing Charterstone, which remains one of my favorite gaming memories. Over the year, he learned Middle Earth Quest, Castles of Mad King Ludwig, and Thunderstone, Quest. My two older sons and I played through the first campaign of Journeys in Middle Earth and a campaign of Arcadia Quest, and with my wife, we played a campaign of Temple of Elemental Evil and got 7th Continent back out and played—and beat—the first curse. My wife and I had tried that one when I first got the game and had no such luck. The four of us also played through the new core set and expansion for Pathfinder Adventure Card Game this summer. That was probably too much PACG all at once, as we were pretty burned out by the end. 

One of the other big winners this year was clearly Kingdomino. This game is fun for everybody, including my youngest son (4). The fact that he plays it, and generally plays it well, makes it a go-to game for family board game time.  My third son (6) is showing great promise in games as well. He learned to play Ticket to Ride this year, and he also learned the basics of deckbuilding games, including the mash shuffle. He loves to play Clank!, which is great, because that also is a consistently fun game. Perhaps there is some irony, then, that as much as I am enjoying Clank! Legacy, I am finding it less consistent than vanilla Clank!. Just last night, I messed up a rule, which had material consequences; every legacy game I have played fails the robustness test in the face of tired or confused players.

My oldest son and I hit a wall in Gloomhaven recently, where neither one of us is about to level up, and we're just not sure where to go next to solve the deeper mysteries of the world. I bought the expansion but still haven't painted the figure. One of us would have to become the new character, and the other person would stay locked in their other, which is already at or near maximum level. I feel like we should try the expansion anyway, in part because I just read Childres' end-of-year blog post about it, but part of me wonders if we would have more fun with a reboot once the sequel releases.

As of today, my games h-index is 22, meaning that there are 22 games that I have played 22 times. My player h-index is 17, meaning that there are 17 people with whom I have played 17 times.

Let's look at how my top games of all time have changed. Last year, I included those games that I had played 20 or more times, but that list keeps getting longer. Hence, I'm going to make the cut at 25 this year.
  • Gloomhaven (66)
  • Pathfinder Adventure Card Game, all versions (57)
  • Crokinole (56)
  • Animal Upon Animal (54)
  • Clank! A Deck-Building Adventure and Legacy (53)
  • Carcassonne (44)
  • Kingdomino (41)
  • Camel Up (40)
  • Rhino Hero: Super Battle (37)
  • Labyrinth (36)
  • Thunderstone Quest (36)
  • Quiddler (33)
  • Runebound Third Edition (33)
  • Reiner Knizia's Amazing Flea Circus (32)
  • Terror in Meeple City (30)
  • Dungeons & Dragons: Temple of Elemental Evil (28)
  • Stuffed Fables (27)
  • Go Nuts for Donuts (25)
  • Obstacles (25)
  • Race for the Galaxy (25)
I think that this is a healthy mix of kids' games and strategy games for someone with four boys. It's still the case that one of my very favorite games is Mage Knight: The Board Game, but that one is harder to get to the table, so at 21 plays, it didn't make the cut. It's at the same level as Champions of Midgard, which the four older members of the family all love and which, despite its preponderance of pieces, we can get set up and torn down faster because everyone can help.

This year, I also logged some of the video games I played (and also, some of the books I read), inspired by Michael Bayne's post and project last year. I even started the year logging my general activity, but I found this too cumbersome and not interesting enough to continue. There were a few games that I dabbled in, particularly free ones from the Epic Games Store. Other games, I played more seriously as a hobbyist. Briefly, these were Just Cause 3, Star Control Origins, Slay the Spire, Donut County, Dead Cells, Mutant Year Zero: Road to Eden, Thimbleweed Park, Minit, Defense Grid: The Awakening, SteamWorld Quest: Hand of Gilgamech, and Disco Elysium. I could write more about these video games, but I think for now I just want to mention the contrast between the last two. Hand of Gilgamech was entirely competent. I enjoyed playing it, but the writing, characters, and plot were absolutely uninteresting. While not painful or cringeworthy, the dialog felt completely uninspired. Compare this to Disco Elysium, where in the first three minutes of gameplay, you have a rich vocabulary, distinct character voices, and a compelling hook. Disco Elysium, which I bought because so many people have said it's really good, is really good. There are parts that I think are incongruent, which I would like to write about at some point, but that's not going to be today. The fact that one can talk about incongruity, though, implies that the world and story are worth talking about. One final video game note: Mutant Year Zero's story surprised me at one point, which was a great delight for a jaded grognard like me.

Thanks for reading. May you have an excellent year in games!