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.

A custom timer for P&T secretaries

I am my department's Promotion and Tenure (P&T) committee chair, which means I also have to serve as departmental representative on the College of Sciences and Humanities P&T Committee. My college is divided into three domains: natural sciences, social sciences, and humanities. For historical and somewhat arbitrary reasons, my department is in the natural sciences domain, so I am also on the Natural Sciences Domain Subcommittee of the College of Sciences and Humanities P&T Committee (or NSDSCSHPTC for short). 

The first order of business at the first meeting of the NSDSCSHPTC was to elect a chair. I have not been on the college P&T committee since the institution of a college-level fourth-year review procedure, so I suggested that whomever is chair should be someone who has done this before. My friend Tony mentioned that he had been on the committee last year and was quickly and unanimously elected chair. The next order of business was to elect a secretary. One of the other committee members observed that the secretary's main responsibility is keeping track of time during deliberations and that modern timekeeping devices are powered by software. I was thereby nominated to the position and then quickly and unanimously elected. 

I made a quick joke about how, being a Computer Scientist, I did not trust software. Then I heard about the timekeeping process, which involves strictly timing a three-minute opening statement, a twenty-minute deliberation period, and, by majority vote, theoretically endless ten-minute extensions to the deliberation. My next thought was that software can make this better.

So it came to pass that, on a Saturday afternoon that involved my being up in my office in the Robert Bell building for a few hours, I put together a Promotion and Tenure Timer. It's written in Flutter, is licensed under GPL v3.0, has its sources hosted on GitHub, and you can use it online at https://doctor-g.github.io/PTTimer.