The Story of Blobbo Globbo: A National Game Design Month 2021 Project

This is my third post celebrating National Game Design Month (NaGaDeMon). The first, brief post described a technical issue with Godot Engine, and the second, longer post described by that first post didn't really matter any more.

Earlier today, I pushed the button and published the itch.io page for my NaGaDeMon project, Blobbo Globbo. If you want the TL;DR, go to that page, download the Windows or Linux builds, plug in a game controller or two, and enjoy!

Blobbo Globbo is a one- or two-player arcade-style game. The core gameplay involves shooting slimes, which captures them temporary orbs. Before the orb dissipates, you can kick the enclosed slime across the screen, running over other slimes for combo points. It is highly inspired by classic games like Bubble Bobble, Snow Bros., and Tumblepop. 

I have wanted to make a game in this genre for years, and in fact, I started one in May as a potential summer project. I spent about two weeks on it before my analysis was that I would not be able to see it through, in part because the art requirements far exceeded my capacity to draw. Getting better and more efficient with asset production is a perennial secondary goal of my projects, but given the complexity of the summer meant it wasn't the time to pursue it. This was, in part, because of an entirely unlikely and absolutely amazing summer vacation. Yes, for once, I chose relaxation over the joy of work! Also, I was pretty burned out from an academic year of pandemic management.

After my first project went sideways, I returned to the idea of making a game like Bubble Bobble. With only three weeks left in the month, I opted to prototype using Kenney's platformer pack, which I use extensively in my game programming class. I briefly considered trying to replace this art with my own, but I'm content having made a game whose play aesthetics match the visual aesthetics of the pack (if I may say so). I also pulled in a few other public domain visual assets, which are all listed in the project documentation on GitHub.

The start of a round

The music is all original, composed in LMMS using exclusively the SID emulator. I wanted to capture a retro sound akin to what I enjoy hearing on Slay Radio. I was also inspired by a talk that my colleague Christoph Thompson gave at the Symposium on Games a few weeks ago, in which he described the history of game audio as being one of compromises. He talked about how the C64 overcame its significant memory limits by including an audio synthesizer, generating audio rather than playing back streams of data. I was able to take some simple themes from my imagination and arrange them in LMMS, but I have to admit that when it came to controlling the SID emulator, I was fairly well just playing around. I understand the four waveforms that are available and generally how different waveforms can combine to make different sounds, but I don't have a clear aesthetic or compositional sense of what makes a song like the theme from One Man and His Droid so amazing and iconic. (Of course, Rob Hubbard probably took more than an hour to compose it...)

I also created most of the sound effects, although a few were picked up from public domain sources. Mine were made using the sxfr plugin for LMMS, which I've used in the past for many jams and projects. Previously, I have created separate project files for each sound effect, which is kind of tedious. For this project, I realized that I could use the "export tracks" feature of LMMS, allowing me to maintain just one project file that contained all the sound effects. This made it easier to compare sounds and match levels, but creating sound effects in LMMS still has the negative side-effect that you cannot export fully-trimmed audio. The exported WAV files contain a lot of silence at the end, which I then have to clean up in Audacity. I looked briefly into SoX to automate this processing, but after some attempts, I realized it was taking more time to automate than to just do manually.

Player 1 has some points and Player 2 is losing a life

About halfway through the project, once I had the fundamental gameplay working, I started scaffolding in some of the other conventional pieces such as the main menu. In my first pass, I found an appealing "splat" image, chose a typeface, pulled in some greens, blues, and pinks, and got the menu working. Playing through, the difference in visual tone was jarring: the ad hoc title screen was saturated and bright whereas the levels—using Kenney's platformer assets—were muted and soft. This emphasized to me the importance of having a palette. Before working on any other gameplay, I picked out the key colors from the asset pack. I put these into the palette in Godot Engine, which I had never used before but seen used in some video tutorials. What a great feature! Now, with a single click, I could easily get my menus, HUD, and effects to draw from the same colors.

My game design courses focus on system design, and my game programming courses focus on technical implementation issues. This means that there's a vast area in between that I don't often get to explore, and that's one of the reasons I stay active in game jams and events like National Game Design Month. Particle effects and shaders are good examples from this project. I show students some basics of particle effects within engines like Unreal or Godot, but we don't spend a lot of time looking deeply into them. For Blobbo Globbo, I am happy with the particle effects used to "warp" between levels. They are not going to win any awards, but they are much more interesting than the usual one-day example I give about making simple explosions. Shaders are an area of game development where I understand some theory but have very little practical knowledge. For Blobbo Globbo, I slightly modified a found fisheye effect that is used subtly when a slime is captured. The teleportation animation includes a simple vertical wipe that I was able to get working myself. There are horizontal and a circular screen wipes used in the early scene transitions. I had to find some tips on how to approach the circular one, and I modified both to use smooth stepping for a softer visual effect. That in particular is a tool I'd like to keep on my toolbelt for future shader work.

Speaking of my game programming course, if you're a long-time reader then you'll know that they have a sort of menu of options they can choose from to earn A-level grades. One of the options it to implement a pause menu. Although I've graded many student projects' pause menus, I've never actually made one myself, so that was one technical feature I decided to include in Blobbo Globbo. It was fun. Not much else to say about it, really.

Finally, a real pause menu

The gameplay underwent a few significant changes over the last three weeks. Originally, if a projectile hit an already-captured slime, it would be ignored. However, this led to a gameplay problem where one could just spam the shoot button with impunity. There is, after all, no limit on the speed of shooting, in an attempt to capture the arcade cabinet feeling of button-mashing. Instead, I made it so that a captured but non-kicked orb, when hit with another projectile, would pop. Since points were only earned by the kick, this meant that a player who overzealously shoots would eliminate their own opportunity for points. It wasn't until playtesting it with my kids that I realized that this was far too subtle: there was no way for the player to see that they were missing the opportunity for points. Instead, it seemed a conservative and reasonable thing to do to just sit in one space and shoot as many projectiles as possible. This cleared the board, which is the implicit goal of the design, but without earning any points, which of course should encourage a particular kind of play. After this test, I redesigned the shooting and capturing system so that shooting a captured, non-kicked orb would pop the orb and release the slime. This makes it more clear that care should be taken with shooting, and that points are earned by well-timed kicks.

There are always opportunities to introduce new enemies and new levels in a game like this, but if I were to put more time into the gameplay, I would start by exploring some other directions. Right now, if you complete all six levels, the game loops but increases the difficulty of the enemies (the speed of all the slimes and the fire rate of the pink ones). I think it would be interesting that if a captured slime is released, either because of the orb timing out or being popped before being kicked, it either increased the difficulty rating of that particular slime or changed it to a harder type. Another improvement that is common within this genre is adding pickups that spawn across the board, either by themselves or as a result of interaction with enemies. These give a reason to traverse the board rather than sit in tactically advantageous places.

One of the design challenges I faced was how to express to the player how to play. It's a simple enough game that one can stumble across the handful of inputs: move, jump, shoot. It's less obvious that one ought to run up to captured slimes to kick them until you've seen it done. I make my game programming students include some kind of instructions in their games so that I can figure out how to play them. Most students meet this requirement by dumping instructions onto the main menu screen in some kind of fanciful font, which has the awkward result of being less learnable than if they didn't include instructions at all. One of my design goals, then, was to do better. My solution was to put in a static tutorial screen, which disappears after seven seconds but can be clicked through, that shows the core loop. The original design used Kenney's Input Prompts pack, but these were designed for pixel art, and my kids pointed out how out-of-place they looked during testing. I found Xelu's free prompts pack and was able to pull in some higher-resolution images that fill the bill. It didn't have exactly what I wanted, which was a controller-neutral depiction of which buttons to press, but I was able to piece together something approximating that by composing blank buttons with labeled ones.

Tutorial screen

The name of the game came from a dinner conversation with my family. I asked what I should name it, and all manner of silliness ensued. When I described it as having slimes or blobs, somehow "Blobbo Globbo" came up, because you sort of glob the blobs. That got enough laughter that I decided to keep it. Conveniently, a poet might also use it as a partial rhyme for "Bubble Bobble," especially of you go full Cockney. Please include your thematic poems in the comment section.

It enjoyed spending time in November creating this game. As usual, one of the greatest delights comes from watching my kids play the game. I hope you will enjoy it as well. Keep in mind that, like most of my games, it is free software licensed under the GPL, so you are welcome to download the code from GitHub and tinker with it yourself. 

Observations from a student workshop on marketing an immersive learning experience

Today, my game design students took part in a workshop given by the BSU Career Center. The workshop was designed to help students market their immersive learning experience when they are seeking jobs and internships. Sitting in the back of the room and observing my students was a great experience. I gained some new insight into the kinds of questions they have and the struggles they face in seeking employment.

The workshop was led by Stephanie Wilson, and she opened by asking the students to write down what kinds of questions they had generally about the job hunt. I decided to capture them in my notebook as the students shared them as a way of describing the how students see the problem. Note that, while this course can be taken by any major, most of the students in the class—and I think all of them present today—are Computer Science majors. This is in part because CS majors can earn elective credit for taking the course.

Here are the questions the students shared:

• Is it more difficult to find a job out of state?
• Is there a best way to organize a portfolio, particularly a web site?
• How do you prioritize what goes onto a one-page résumé?
• Is there something special to go on a CS résumé vs. others?
• If I see a job listing that I want, and it includes a list of skills, only some of which I have, should I still apply, knowing that I want to build those other skills?
• What do you do if you have multiple job offers? How do you fairly evaluate them?
• How do you deal with "entry-level" positions that require 3+ years of experience vs. positions that are basically unpaid internships?*
• If a job involves working with a specific system or platform, and I don't know it, should I still apply?
• Should I put old projects on my résumé to show how I have improved?

She collected the questions, but they were not individually addressed, except for the one about unpaid internships. Her response to this was, "You are Computer Science Majors from Ball State University. Do not take unpaid internships." The rest of them she saved for future use at the Career Center, although several were mentioned during the remainder of the workshop.

Wilson talked briefly about "networking." She explained how, when she was younger, she thought it was essentially an exchange of business cards. As she worked, she realized it was not transactional at all. Instead, she said, it is relationship, and specifically, doing what you say you'll do when you say you'll do it. I thought this was great, and I could tell that the students were attentive and thinking about this. During the workshop's closing feedback session, it came up as one of the three most important things she shared.

We spent some time in small groups to discuss how we had each already thought about framing the course experience on a résumé. I didn't expect this, but it turned out really interesting. I joined the under-populated group as an extra discussant, and it was interesting to hear the students talk about their perspective on what had been going on in class. We brought the results of these discussions back to the whole group, and Wilson helped frame the results in terms of her "Four P's": price, promotion, product, and place. I can't say I'm much for the mnemonic, but it was a useful lens through which to look at the problem.

One concrete piece of advice she shared was how to frame any experience on a resume: with an action verb, a description, and a business outcome. One of the students wisely asked what she meant by "business outcome," and Wilson responded that it's the "so what?" of the work. We worked through some examples, and it was clear that students quickly caught on to the value of this idea. What struck me is that this format is not so different from how we talk about user story articulation and commit messages. 

There were several other tips she shared for résumé constructor that I want to mention here so I can find them later. One was not to list your physical address nor the university's location on your résumé, and also not to use more than one vertical line to list the title, location, and dates of a job. For odds and ends like club memberships, she recommended a catchall portion of the résumé whose name, unfortunately, I cannot remember and I did not write down. She advised strongly against fancy templates, tables, and images as being difficult for automated, AI-driven systems to process. She also mentioned that a résumé has a shelf-life of one: each one should be tailored to each job you apply for, using the language expressed in the job ad. Finally, she mentioned that traditional wisdom was for students or recent grads to put their education first, but that more recent feedback from businesses has been that they want to see experiences first. 

As alluded to earlier, she concluded the session with a quick feedback session. She asked the students about the best parts of the workshop, to which they responded: don't undersell yourself; articulating the good things they had done this semester was helpful in thinking about it; the importance of LinkedIn; and the action-description-outcome format for résumé bullet points.

I am glad I decided to do something a bit out of the ordinary and bring in this speaker. Tuesday before Thanksgiving was an odd day out on the schedule. We have Group A presenting on Tuesdays and Group B on Thursdays, so what was I to do with a short week? I haven't actually hosted a Career Center speaker like this in several years, but it was clearly valuable to the students while also giving me a refresher on how I can help students think about these problems. It was fun to sit in the back of the room and hear how my students talk about what we've been doing, and of course, it's always nice to have someone else show up and tell the students that what they are doing is important and interesting—because it is!

Finding inspirational teaching ideas in a GDC Educators Summit talk

Watching Jason Wiser's GDC talk, "How to Teach 5 Semesters of Game Design in 1 Class," got me thinking about my own classes and whether some of his ideas might make good integrations. I've tried to hold several ideas in my head, but at this point I've tried to re-discover several things from his video that I knew I had forgotten, so it's time to take some notes! The point of this blog post is to articulate some of the ideas that Wiser shares that seem most likely to address some of pain points in my teaching.

At 16:47, he presents the five-point rubric that is used to measure the quality of the game:

• Clarity: do the players know what to do?
• Innovation: What new gameplay to stimulate interest?
• Immersion: Is the "story" compelling (implied in setting, art, music)?
• Flow: Does the player feel constantly productive?
• Fiero: Are there multiple big victory moments for players?

In my game design class, I grade only on process, not on the quality of the product. I don't know that this has caused any problems that I can pinpoint, since those who follow bad process tend to have bad products. Those who follow good process tend to have... well, something playable but amateurish, but that's exactly what one would expect. The question for me is whether a rubric like his would give the students something concrete to reflect on. I have the sense that, if I didn't remind my students to try to connect their games to the theories studied in class, they would not do it. Indeed, conversation during our workshopping practically never brings up any theoretical issue from the first half of the semester. A rubric, perhaps in combination with checklist-based grading, might help them see the connections. I would not take this rubric wholesale since I think it doesn't capture my philosophy of teaching game design, but it is a good piece for reflection.

At 17:56, he talks about accountability. This is something that has had me uncomfortable in my classes the last two years or so—something I feel is ripe for reconsideration. The first part of Wiser's model is weekly playtesting framed by the aforementioned rubric. In my classes, I like to lean on Jessica Hammer's EOTA (Experience, Observations, Theories, Advice) framework, which I wrote about back in 2018. I have asked students to follow that framework, but I've never given direct rubrics for critique; maybe it's worth trying that some time.

The next two parts of Wiser's accountability model is posting weekly task divisions and weekly personal progress reports. Reflecting on the accountability mess in my game programming course, I want to bring in something like this. Unfortunately, given where we are in the semester and the upcoming iteration deadlines, I fear I may have missed an opportunity to let something like this drive team activity. I think I will incorporate something like this in the last 2-3 weeks, but it will look like what it is to the students: a late-semester experimental patch.

In any case, the particular components of the personal progress report is interesting. It consists of one paragraph with screenshots (ah, I already love the multimodality!). They address what they agreed to take on that week, what they completed (with no penalty if it's different from what they took on), who helped them, whom they helped, and links to tutorials that they used. That is a really tight model that covers a lot of the bases that my current approaches miss. Really, I like everything about this and think I will pull this into one or more classes soon. 

I think it's worth mentioning here that, even with my relatively small class sizes, I have too many students to meaningfully respond to all of their weekly task divisions and personal progress reports. I am not sure an undergraduate grading assistant would have the wisdom to know how to read and respond to these, and I also don't think I can add several hours each week of careful reading on these. I would need to look for heuristics for grading in order to keep my own commitments manageable.

The last piece of Wiser's accountability model is peer evaluations, and here is where my ears really pricked up. He credits his model as coming from the executive MBA program at Boston University, but I have had no luck trying to dig up original sources on this. Wiser describes it as covering teammates' contributions to productivity and morale, dividing points unevenly between them. He does this three times during the team project, but only the last one counts on the final grade, and that at about 20%. Unfortunately, I don't have any guidance beyond what Wiser shares, so I don't know how many points are available for distribution, how "productivity" and "morale" are framed for the purpose of evaluation, nor how these translate into grades. If I tried this approach this semester, I would have to approach it as an educated guess. If anyone has more information or advice here, please let me know.

This self- and peer-evaluation model is significantly different than the model I've been using for around a decade, where students evaluate themselves and each other on a five-item rubric, and students' individual grades are capped by the sum of the medians on the evaluations. A weakness of my model is that students are not limited in how they distribute points, and so I know that students sometimes give each other high marks just because they don't want to impact each others' grades. I had a wonderful conversation once with a student directly about why he gave evaluations that were clearly dishonest, and his candid answer was, basically, that he believed in mercy more than fairness. The spiritual dimensions of the conversation were fascinating! Yet, I am called by my employer to grade on fairness, and so I still think it's a weakness of my system that unproductive students can earn good grades on the mercy of their teammates. 

The game evaluation rubric and accountability model were the two things that stuck out most in my memory as being immediately applicable to my own teaching. If I am able to cast these into a form that I can use during this semester, I will be sure to address it in my conventional series of end-of-semester reflections.

NaGaDeMon 2021: Twists and Turns

This is my fourth year participating in National Game Design Month. It's become an annual tradition that my family and I anticipate. I was actually a little disappointed that there are some other coincident events happening, such as Go Godot Jam 2 and GitHub's GameOff 2021. I suspect both of these will be more popular than NaGaDeMon, since they are backed by larger, established communities and organizations. I wish them the best in their events, but there's something about the ideological purity of NaGaDeMon that calls to me. NaGaDeMon doesn't care how you version your code, what engine you use, or if you use an engine or code at all. The elegance of make, talk, play is a wonderful framework on which to inspire people. Maybe we need NaGaDeMon evangelists participating in those other events to help them see that there's a bigger tent that we're all in.

I came into November with just a few scattered ideas. One of them was that I had never made a 3D game in Godot Engine, and this might be fun to do. A recent GDQuest video pointed me to the KayKit asset collections. Looking at these inspired my son as well as me. I had assumed, since they were given GDQuest's blessing, that they would be straightforward to incorporate into Godot Engine. After some time, I was able to put together an integration of Kay's animation pack and dungeon pack as described in an earlier blog post. Unfortunately, after several more hours of tinkering, I ran into several more problems, which I've documented in an issue in my test repo. 

Now along the way, I did get a playable toy working. I recently introduced my kids to Rogue Legacy, and so I was thinking about action platform games with powerups and procedural generation—not that I would necessarily get that far, but that's where my mind was. Here was my first test:

It is pretty basic GodotEngine KinematicBody stuff there, but look closely and you can also see that there's smooth blending between the idle and running animations. Continuing to work along these lines, I was able to get a skeleton that could be knocked down.

The next logical step was to work on jumping, which resulted in the following results.

Behind the scenes here, I had several surprises, not even counting the trickiness of getting the models and animations to work well together. I've made dozens of games, most of them being very small, and I've never made a 3D-rendered platformer before. It's not even clear that I was actually making that, really: I was just messing around. However, I found myself surprised at what I did not account for intuitively. Here are two particulars:

• I originally was using a jump animation that included a little crouch before lifting off. It looked great, but how exactly will this interact with the attack animation? Should the player not be able to attack while crouching? If they can still attack, will they still launch upward at the same time they would if they did not? Does it make sense to blend just the arms' attack animation while using the body's jump animation, even though the result would be that the sword doesn't have the same reach as when attacking on the ground?
• What exactly happens when you go left? In 2D, you can get away with just flipping the sprite, but with 3D models, you really need to turn them. What happens if you start a jump or attack in the middle of turning? Or are these not allowed? 

It reminds me of the door problem, which I've started assigning in my game design class. On one hand, it sounds glamorous to say, "I'm making a game inspired by Rogue Legacy!" and on the other hand, the reality of game design is that you're deciding what really happens when you crouch.

I got in touch with Kay about my troubles with the asset packs in Godot Engine, and she got back to me with amazing alacrity. She welcomed me to join the Pixeland Discord, which I did. The folks there were (and are) very friendly, but the rough consensus seemed to be that to really do what I wanted to do, I'd have to get the Blender sources and convert them into something more Godot-friendly. 

I had penciled out the first week of November as being for exploratory work. I felt like this was a good exploration, but I was not feeling inspired to pursue these designs to a full, working game. I sat down in the evening with my design notebook and a drink to consider where to go next. On November 1, I had jotted down just a couple of ideas. Literally a couple. Two ideas. Turns out, one of them sounded really amazing to me, sitting in my comfy chair late at night with a half-glass of whiskey. How that goes will be the subject of my next NaGaDeMon blog post. 

Thanks for coming by. I hope you're inspired to make, play, and talk about games this month.

Labor and Lies

A few weeks ago, I had an amazing session of CS222. When I got to my office, I wrote down three key phrases on my whiteboard with the intention of writing a blog post about the class. When two weeks or so had passed and I made time to write the story, I could not reconstruct the event from those phrases. Drat! Now, instead of sharing a story of an amazing CS222 class, I'm instead going to share with you one of the great frustrations of last week: the first iteration of the Game Programming (CS315) Final Projects.

First I need to back up a little. I am teaching three different courses this semester, and each one has a similar structure: the first half of the class introduces concepts, and the second half of the class is a deep dive into a project that manifests these concepts. As I have written about before, I am exploring ideas of labor logs, that students earn credit simply by spending time on their work. In CS222 Advanced Programming, students are maintaining project labor logs, where they summarize each week what they did and how many hours they invested. In CS215 Game Design, students are independently maintaining project design logs and submitting weekly labor statements. These labor statements are inclusive of all course effort, including research, attending class, and helping each other, in addition of course to active labor on the final project. One of the reasons for the different policies is that CS222 involves group projects, and their labor logs are kept in a group document; my hope here is that this would give positive peer pressure and accountability. In CS215, students are working on their own projects, so I'm just asking them to tell me how many hours they spent on the class, in hopes that they will reflect on how this impacts their commitment and experience.

As we started the final project in CS315 Game Programming, I had not made any solid decisions about how to ask these students to track or report their hours. This class has a mix of individual and group projects. In fact, I had written on my planner to engage the whole class in a discussion of how they wanted to track hours, but I kept forgetting to check my planner, so we didn't have that discussion until about halfway through the first iteration. 

I showed the Game Programming students how I was managing the other two courses, and I explained my rationale. I was particularly clear about my disappointment with last year's game programming class, when in the final iteration, so many promising projects failed because teams put off their work until the day before the deadline. That is, I tried to impress on them the difference between constant forward progress in an iterative process and submitting work by a deadline. 

I let them huddle up and talk for ten minutes or so with the charge of coming up with a fair process for us. The responses were interesting. Very few—maybe none—were in favor of following the practice I set up for the other classes. This was not surprising, and their rationale was a mixture of explicitly not wanting to have to track hours and, unless I'm mistaken, implicitly not wanting to commit or be held accountable to commitments. Several students brought up techniques that they are using in their capstone courses. For example, one group was in favor of following the path of a particular capstone instructor, who has students keep meeting minutes in the repository. I pointed out that this was interesting but didn't solve the same problem, which they acknowledged. Another group responded that they did not want to follow what they had seen in the capstone because they did not see it as being necessary for the task at hand.

One response resonated most with me: a group pointed out that our environment was significantly different than last Fall's asynchronous online class. Because we are meeting together and having in-person showcases of our progress, we can simply use positive peer pressure to ensure that each group is meeting their commitments: no logging, no reports, simply relying on the human success mode of being proud of accomplishments and being good citizens. I decided to take this approach, at least for the first iteration.

Well, was I disappointed when I graded their submissions late last week. Looking at the git commit histories, about half of the teams made no or essentially no progress until the day before the deadline. Keep in mind that this is my course in which we use checklist-based specifications grading, so in theory, students can know the grade of their work at the time they submit it. Indeed, everyone (or practically everyone) who started work the day before the deadline filled out the checklist and claimed to earn an A. My response to them was that they had failed to maintain the contract of the course, so they were ineligible for checklist-based grading and had to be graded ad hoc instead. I still feel badly about the disconnection between checklist-based grading and this ad hoc management, but it seems like it was the right thing to do.

Unfortunately, my disappointment does not stop here. I also required the students to complete self- and peer-evaluations, following the same format I use in CS222. Indeed, I gave the same policy statement as well, that a student's iteration grade would be capped by the sum of the means of their self- and peer-evaluations. I was shocked when I sat down to my spreadsheet and ran the pivot tables to find these sums of medians: practically everyone had full credit. There were maybe two students with a few percent less than full points, but not enough to be meaningful—and not enough to account for the stories that at least one team told me about the communication problems they had among members. Putting this together with the previous disappointment is a double whammy: not only did half the teams not start working until the day before the deadline, they also claimed that each of them was perfectly fulfilling their obligations for the previous three weeks. 

They lied. There is no other way to put it.

I know that sometimes, under pressure and facing temptation, anybody can make a mistake of judgement. This, however, was a systemic misrepresentation of truth, and now I need to decide what to do about it. I will need to talk to them about it on Tuesday, though I'm still not entirely sure how I want to approach it. What difference will a chastisement from an authority figure make if one does not show them the respect of telling the truth? Or is Dad Mode really what these students need?

I also need to decide if I want to change the policy for Iteration 2. If they do not learn from their mistakes, then the whole enterprise is a failure. Would making them actually track their hours force them to face their deceit or delusion? Or would it only push them toward digging themselves deeper graves?

There is a positive story that came out of this, however. A few hours after I posted grades, I got an email from a student, and the email opened with a statement that they were not looking to change their grade. Instead, the student humbly acknowledged that they had screwed up, that they got the grade they deserved, and that they would not repeat this error. This acknowledgement was, in a way, an attempt to show gratitude for holding them accountable to standards. Keep holding on to hope, friends.

Using KayKit Animations in Godot Engine

I recently learned about Kay Lousberg's CC0 KayKit asset packs, and I thought it might be fun to try to bring them into Godot for consideration in a NaGaDeMon project. However, I ran into trouble following the recommended approach a few days ago. Today, I was able to figure out the missing pieces. All the steps and a sample project are given in a repository I just put up on GitHub.

Some Holiday Board Game Recommendations

I was recently asked by a friend for board game recommendations for her family of four. Her two children are about the same ages as my eldest two. They have already played Carcassonne, Settlers of Catan, and Wingspan, so what else might show up under their Christmas tree? In the spirit of No Wasted Writing, I decided to track some recommendations here on the blog.

One easy recommendation is Quacks of Quedlinburg. I was skeptical that it was really as good as everyone says... but it really is. Watch out, though: if you fall in love with it, you're going to really want those nifty acrylic tokens. Ooh, they feel so much nicer than cardboard.

Some of the most fun that my family has had has been with Charterstone. The game is has a lovely art style, and it features unique mechanisms that are probably unfamiliar to those new to the hobby. A recommendation that is in a similar vein is Pandemic Legacy: Season 0, but I would go with Charterstone first, unless the family has a real love of cold war aesthetics and cooperative play.

Another similar kind of recommendation is My City, which I found surprisingly good. Like the games mentioned above, it has legacy aspects, so you alter the game as you play. It only goes up to four players, and I played with the three older boys last winter. It's so good, and relatively affordable, that I've actually thought about buying a second copy to play with my wife and youngest son. Where Charterstone grows slowly and Pandemic Legacy is intense, My City is relatively breezy.

Everyone needs a deckbuilder, right? My family's favorite is certainly Clank. It combines deckbuilding with a straightforward spatial mechanism. I don't think that a modern gamer has to go through Dominion or Ascension before they get to Clank. If one wanted more deckbuilding, then I might turn to Eminent Domain, which is nice in how it keeps everyone engaged by having to either follow or dissent to others' actions. Fans of Dune might go with Dune: Imperium, but that's getting pretty heavy. Incidentally, you'll probably want some penny sleeves for your deckbuilders. The mash shuffle keeps the cards in shape better than constant, unsleeved riffling.

If you really want more Catan, I still believe that Starfarers of Catan is the best Catan. To be clear, it's not an expansion but a reimagining of the core systems in a cheesy B-grade movie version of the future. Of course I would like that. In my opinion, Catan is superseded by many better games now, but Starfarers is my go-to when I want that "I'll give you carbon for space wheat" fix.

A more interesting economic game, and one of my personal favorites, is Concordia. Although you cannot directly impact other players on their turns, there's always a good reason to keep an eye on what they are doing. The Salsa expansion is highly recommended for anyone who gets a few games of Concordia under their belt and decides they like it.

If the family loves sea life, then Oceans is a really interesting game. The artwork is beautiful, and we have really enjoyed it. Similarly, games don't get much more beautifully crafted than Parks, and the gameplay is interesting even if the theme is a little stretched. (Remember: you can only be on the same trail as someone else if you light a campfire!)

Going a little lighter, we always enjoy Kingdomino and Azul. The former is an easy ~20-minute game, though as Concordia goes with Salsa, if you like Kingdomino, you'll want the Age of Giants expansion. Azul has spawned a whole family of games, some of which I've tried, and I'd probably just go with the original first. It is another fairly simple game but with beautiful production value.

MonsDRAWsity has become of my family's favorite games, and it fits a lighter, "party game" slot. I've only played with six or more players, but I suspect it would be fun with four as well; if not, invite a few friends over. You can even use this handy timer that my son and I made.

Keeping with the lighter side, we also love Just One. My wife and I have a good time playing this one with the older two boys, so I know it scales down pretty well to four players, although it too is better with a few more.

Finally, as simple as it is, you can't really go wrong with Ticket to Ride Europe. My younger boys want to pull this out from time to time. It's not as fancy as some of the other recommendations I've given above, but it's a solid game design. Note that Europe is much better than USA, which has less interesting gameplay and opens itself up toward anti-thematic strategies.

I hope folks find these useful. I had a similar question recently from a friend with much younger children, and I typed out my answers in an email. One of these days, maybe I'll get around to putting those up here too, since my nine-year-old original post along these lines is really outdated.