A bit of Unreal Engine and the Benefits of Source Code

Several years ago, I looked into Unreal Development Kit for use in my game programming courses. At the time, you had to know C++ to get the most of it, and my students generally didn't know C++, so I invested hardly any time in pursuing UDK. I had heard in Spring 2015 how Epic made Unreal Engine 4 completely free for developers, including making the source available. It wasn't until about two weeks ago that I was inspired to take a look at UE4. Turns out, it is extremely easy to access the source and build it on Linux, and so I've been tinkering with a project for two weeks or so. I have been keeping notes about my attempts to learn UE4, and I may blog about that more later.

This story is about how I got some core gameplay working and decided it was time to slap a HUD on the game. I checked a few pages of documentation and proceeded to create my first HUD blueprint. Upon trying to open it, the editor crashed. That's pretty uncommon, so I restarted it and tried again, and it crashed again. That's really uncommon, so I restarted again,  but I asked Google about it while UE4 was starting up. Turns out it's a known bug in the latest release. However, someone posted a workaround, which is to revert a specific commit from the repository.

I've never actually done that before, but a little bit of searching revealed that it was pretty easy. I didn't actually clone the whole UE4 project history, only the latest release, but I was able to get the patch for the commit by appending ".patch" to the github URL. (That is, it's https://github.com/EpicGames/UnrealEngine/commit/8fba9bbdc3cc4105d7c3de24adc94f7304c7d90b.patch, although you need to sign in and agree to Epic's terms to get source access; note that you can do this with any commit URL on github, which I did not know before.) I saved that to a file and reversed the commit via:
git apply -R

Couldn't be easier! Rebuilding the project via 'make' took just a minute or so, much less than the full build. Now, I can edit HUD widgets! I am still not good at it, but hey, we have to take this one step at a time.

Sources of joy

Six or eight years ago, I went to a SIGCSE talk by Jesse Heines in which he mentioned, offhandedly, that he knew all of his students' names. After the talk, I asked him how he did this, for it was something I struggled with. The trick he taught me is one I've used for several years when teaching larger classes: have everyone write their name on a sheet of paper and take mugshots. He printed his up into a poster, but I just have mine set as a screensaver, so that when I haven't touched my input devices for ten minutes or so, students start flipping through my screen, one second at a time.

Now, it seems if one is going to have students come to the front of the room for a mugshot, then it seems they should say something about themselves as well. I used to ask them to say something about how they first became interested in computers, but this turned too quickly into "XYZ is my favorite video game." Last year, I asked instead for students to share something that made them smile. In one of my sections, it was quite nice, but in the other one, it turned very dark in the dark-comedy sense: smiling at bad things happening to other people.

I happen to be in the middle of C. S. Lewis' Surprised by Joy, and so I've been reflecting on what "joy" is and where I find it. In this spirit, as I set up and explained the mugshot routine, I asked my students to share something that recently brought them joy. To kick things off, I told the story of how the previous day, my one-year-old had picked up a baseball cap, put it cockeyed on his head, had one sandal on, and was lopsidedly parading through the hallway.

I was moved by my students' responses, and so I decided to share some from memory here. Here are some things that bring my students joy, in no particular order.

• I found out we are getting a German Shepherd puppy.
• When I was home, I got to see a cousin I had not seen in three years.
• My kitten does the cutest thing, where it lays on its back and I rub its tummy.
• I have a Web development company, and yesterday I secured a great contract.
• My baby said, "I love you" as I left the house today.
• Last semester, I found a quarter at the bus stop.
• The new FIFA comes out next week.
• My friend made an outfit for her cat.
• I saw a great movie that really moved me.
• I won a costume contest at a comic convention.
• I hit max level in World of Warcraft.
• I am a TA for the intro CS course, and I was in the lab with a student who was on the verge of tears, he was so frustrated. I looked over his code, and it was just missing a semicolon. He was thrilled, and I felt like I really made a difference.

I know there were more, but these are the ones that come to mind as I think through it. Only one student, toward the end, offered the slightest schadenfreude, and that was, "Last week, I saw Jimmy fall off his bike," but at least Jimmy was right there, and they are clearly buddies.

White point selection in Snapseed

I was very excited to see the new white-balance features in Snapseed. I use a low-fidelity set-up for photographing my miniatures: I use a white backdrop, lower my painting lamp, and snap a shot with my mobile phone camera. The color temperature was never quite right, and it got worse with my transition to my Nexus 5X. The default camera on the 5X does not support changing the exposure, which is how I used to get slightly better images on my Nexus 4. I have been using Open Camera to photograph my miniatures since it allows for manual setting of light quality as well as macro focus, but even here, the temperature was often wrong.

Of course, I can always download my images and use Gimp to select a white point, but this makes photographing and sharing process much more cumbersome. Going this way, I would have to download the images, process them in Gimp, export them, and re-upload them to Google Photos—and remove the old ones to eliminate clutter—just so that I can easily share the images here on my blog and over on the Facebook. When I spent hours with my new Nexus 5X looking for solutions, I asked, "Why don't any of these mobile photo editing tools allow white-point selection?!" (Yes, I even went looking for algorithms to see if I could just write my own!)

One of the tools I tried was Snapseed, and I never got around to uninstalling it. I know it updated the other day, and when I opened it, I saw a little "new" marker by a WB button. Hope against hope, could it be? Yes! The new white balance tool allows picking of white points! It required a little poking around to see how to back up the Snapseed images into Google Photos, but now I think I have a good workflow.

Here's an example. I just finished up my two Stalkers from Myth—a GenCon acquisition that I played once and decided deserved a nice paint job. The big, round surfaces of the Stalkers gave me a great opportunity to practice two-brush blending, and I am really happy with the results: I think it's some of the smoothest blends I've ever painted. I took a photo and shared it to Facebook:

They look nice, but the temperature is all wrong, like so many of my photos posted here. This was the impetus to check out the updated Snapseed. One white point later, we get this:

That is much better! I think they still look better in person, but for my cheap-and-easy photography set-up, this is a huge improvement.

Thanks, Snapseed team!

Is there a fix for the first three weeks of CS222?

We just finished the first three weeks of CS222, and the truth is, I don't like it. There's so much to love about this course, but it all happens after the first three weeks. Indeed, I think by the end of the semester, I'm generally content with the course, so I tend to forget how these first three weeks need attention.

This semester's course description lays out a plan much like I've used in past semesters. The first three weeks consist of a rapid introduction to course topics while students complete a series of three assignments. The next two weeks are devoted to a two-week project, where students work in pairs on a challenging project, bringing to use all of what they learned earlier in the semester. The final ten weeks are devoted to the final project—a project created by teams of undergraduates and completed in three iterations.

During these first three weeks, there's too much of a disconnect between the assignments and what I'm talking about in class. It works fine when students are keeping up with the reading and asking good questions, but that seems to only happen by chance, not by planning. Each assignment asks students to refactor with increasing sophistication, and I'm also asking them to look at either their own "legacy" code from previous semesters or Open Source code. I can tell that a great majority of them are trying to refactor on paper, without the help of the compiler, but almost none of them have the experience to pull this off. (Indeed, they don't have the experience to recognize that they should be using a compiler to check their work!) Because they are focused on the point-granting assignments, I am sure it is very rare that they take my end-of-class advice, where we are working on a case study and I say, "Try writing the next test yourself!" or "See if you can fix that UI problem." These mini-challenges never come up again: no one asks about them, unless it's me in the next class, when I am met with blank stares. This leads to what always strikes me as the most significant problem for our Advanced Programming class: in the first three weeks, the student are not programming. In particular, the weaker students are not getting the practice they need.

Before using three weekly assignments, I used to give daily assignments in CS222. This actually worked very well, in part because I could tweak them based on what we did in class. Why not just go back to this? Well, the course used to be Tuesday/Thursday, so that meant two assignments per week, and we used to have half as many students. Now, we have an exciting growth in majors, and despite my protestations, CS222 is now MWF. If I gave daily assignments—the interesting kind, that require me to read and give thoughtful feedback—I would drown in grading.

I am certainly open to suggestions, but really, the point of this post is not to plea for help but for me to remember today's thoughts in ten weeks when I'm prepping for Spring. In that spirit, here are some of the ideas I've had about dealing with this.

• Request a teaching assistant for the first few weeks of the semester. I generally have avoided them because I like to know what my students are doing and to give them expert feedback. If I could get a teaching assistant who has taken my course, though, maybe I could get them to do some of the more menial checks.
• Use more tooling to help with identifying refactoring opportunities. What if we had a static analyzer that would flag students' code based on some heuristics of code quality? For example, Clean Code talks about avoiding nested control structures: that's imminently detectable, but we would need to have the right tool to do it, and that would mean teaching yet another new tool to the students. (Also, I am not sure that this is better than learning to see it yourself, similar to how using spellcheck doesn't help you actually learn how language or spelling work.)
• Incorporate peer-evaluation. I did this a few semesters ago with achievements, where students needed to get peer-approval before sending work to me for evaluation. It did not work at all, in part because there was no incentives for evaluators to know what they were talking about. That's a systems problem, and I could try to improve that system, but I fear that this approach still leads toward blind-leading-the-blind.
• Remove the requirement that students find their own code to evaluate. The reason for introducing this was twofold: first, it gets students thinking about Open Source code; second, there are no issues of copying, since each student is doing different work. If I were to, say, create some repositories of code with Clean Code violations, then I would know that they can easily check it out (learning fundamentals of git) and actually run it in the IDE—and I could even provide unit tests! However, then the whole class would be working with the same code, and that invites the weaker students into the temptation of not thinking through the hard problems for themselves.
• "Flip" the first three weeks more aggressively, moving more presentations to YouTube with graded clicker-style multiple-choice questions at the beginning of class. This would eliminate the assignments entirely, but it has this problem that the clicker-style questions don't get at the kind of process knowledge I want them to be developing.
• Completely change the first three weeks, having them do individual programming assignments, relatively simple ones to make sure they know core Java ideas, and evaluate these on strict subsections of Clean Code. This probably would not take much more effort than what I am doing now in terms of reading and giving feedback. It echoes the problem above, though, that it could tempt the students who most need the practice to copy approaches rather than apply the processes we're trying to learn.

CS222: Teaching students to talk to the client

The theme for the second week of CS222 was Test-Driven Development, particularly the process of determining what test cases should go onto a Beck-style to-do list. I chose the context of a simple text analyzer—a tool with a simple JavaFX UI that takes input text and does some computation over it. The first example I walked through was word counting, just breaking up a string based on whitespace.

The second example I chose was average word length: given a string of words, what is their average length? I explained this to the students and, as an in-class exercise, they broke into ad hoc groups and started coming up with test cases. I gave them fifteen minutes or so, and then we shared our lists. Many of the groups realized that, in order to do average word length, we needed to be able to compute word length, although none of them explicitly extracted this as a separate problem. As they started sharing their test cases, they realized there were ambiguities: some groups were counting apostrophes and dashes as part of the word length, and some were not.

This was a great hook for me to intervene and talk about the dangers of assumptions. Rather than make something up that they wanted, they need to work with the client—or, in this case, the professor as client-surrogate. We also talked about how working on one task may reveal another dependency, and that we can make a separate TDD task list for that. We had some time left, so I told them to shift gears: come up with the list of test cases one could use to write a word length function.

They started, and I wandered the room, giving them about five minutes to complete the task. Then, I stopped them, and informed them that they had all failed. The students looked up at me with a combination of confusion, terror, curiosity, and amusement. "Why," I asked, "did you all just fail?"

With a smile on her face indicating she knew exactly what had happened, a student said, "We just made stuff up. We did not ask the client how word length should be defined."

"Exactly."

It was one of those moments where you can feel the learning in the air.

I wrote down a shorter version of this story in my notes. It was a happy accident this time, but I think it's something I'd like to try to do again.

Playing Frostgrave and Family Terrain Crafting

I don't remember where I first heard about Frostgrave, but I fell in love with the idea of a fantasy-themed skirmish-level wargame that I could play with the miniatures I already have. I have been painting for almost three years now, and so I've built up quite a collection of good-looking miniatures who never see the table. I ordered the rulebook over the summer, and my eldest son and I started a campaign. I created an Enchanter, using my Ezren miniature that I painted for the Pathfinder Adventure Card Game. I expected my son to go with something like an Elementalist or, given his penchant for buying undead creatures, maybe a Necromancer. He actually went with a Witch, I think in part because he had a nice Feiya miniature he painted up a while ago. To play the first game of our campaign, we simply raided the box-o'-blocks and made sure not to have long lines of sight.

First game. Watch for the Statue of the Mayor in the middle of town---the orange conical shape with red tip.

Ezren bravely hides behind a wall

We had a fantastic time, each of us securing three treasures, building strongholds, and leveling-up our wizards.

For our second game, we added some height-variation. The changes in elevation added a lot to our enjoyment. I came away with four treasures to his two, thanks to the amazing enchanter spell, telekinesis.

We actually got part of the climbing rules wrong, but we still had fun jumping and running around the multiple levels. Also, a good view of the Statue of the Mayor in the center of town.

A frost giant, played here by an Ettin, appeared right in the middle of my reserves. The archer and war dog are about to take one for the team.

Our board designs got a bit more sophisticated as we moved to our third game, and this was also where we started using scenarios from the book. This is the Worm Hunt, where there's a chance each turn of a giant Herbertesque worm emerging from the ground and attacking the treasure hunters. I feel kind of bad about this one, since a worm came up right around my son's guys, and in an amazing twist of luck, he got it down to one health. He sent in his war dog to finish it off, but missed (and the dog was eaten). I won initiative and was able to pick off the worm's one health for the XP reward. We both agreed it was lame but also that there was no good reason not to do it. He is very gracious, and I got away with four to his two again, plus two giant worm kills.

More of a ruined city, especially in the front and center areas of the right-hand side.

The view from the famous Statue of the Mayor's Dog

Our fourth game involved a scenario with a magical well in the middle of town. We envisioned it as a market center, with an old grand arch and ruins around it, including a collapsed temple and stores. My wife walked through the room and commented that this was our "best-looking" table yet. I agree!

The paper strips are Fog markers. We both have the spell and end up with a lot of fog on the board.

Around the time we started playing Frostgrave and realized we both loved it, I started looking for cheap terrain or tutorials on how to build the same. The search for the first is easy: there really isn't any "cheap" terrain. We looked at some options at the exhibit hall of GenCon, but nothing really caught my eye. I turned to YouTube and ended up watching several videos by Mel the Terrain Tutor, which were really helpful. In particular, his series about making cheap terrain using foamcore is excellent; I look forward to trying these techniques sometime, although some specific elements of his design are more modern-urban than the kind of fantasy-urban we're going for in Frostgrave. I came across Luke's APS purely by chance, and I find his cheerful demeanor infectious, and he pays special attention to making things nicely but cheaply. However, It was watching Mel's videos where I first heard about DMG and, more importantly for our purposes, DM Scotty. 

DM Scotty has a two-part series (part 1, part 2) on how to build cheap ruins, mostly from ruins and hot glue. Oh my, does this guy have a lot of uses for hot glue. I've used the stuff to hold my miniatures to corks for painting, but that's been the extent of my adult experience with hot glue, ... at least until a few days ago. My son and I watched his videos and decided that we would give it a shot. Family crafting time!

In the videos, DM Scotty uses two-wall corrugated board for the main body of the ruins. We only had single-wall, so we started by just gluing cardboard flats together using some white glue. I took a tip from Mel's video about cheap basing materials and turned the corrugations orthogonal to each other, hoping that this would give a solid body. Then, we set to cutting out our shapes and hitting the hot glue. For most of these steps, I went first, and my son gave it a shot next, although he would frequently remember things from the video that I didn't. In both pieces, I think we were both a bit overzealous with the vertical glue effect, reflecting our exaggerated recollection of the video: DM Scotty's is much nicer, and so shall our next pieces. We also didn't remember his trick of adding more cardboard verticals to appear like support beams on the walls. Again, a note for next time.

Mine's on the left, with the doorway cut out. It also has a small second level, which you cannot really see here.

After a trip to the store to pick up some all-purpose sand, we added texture to the pieces using white glue and sand. We also used play sand to fill in the corrugations on the side, which does indeed make the finished project look more like a ruins than like a corrugated cardboard!

I took these outside and painted them black using some black primer spray paint I have for miniatures. The weather here in Indiana is not always good for outside spraying, but we hit this at just the right time.

Next up, we used some sponge-brushes to stipple on our medium grey and light grey highlights. I dabbed much of the paint off of mine, leaving a much darker color. My son had a lot of paint in the sponge, and so even stippling, he got a lot more paint on the walls. He also took some time to paint on some cracks, but I decided to skip that step, in part because my overzealous hotgluing didn't leave a lot of central surface area.

We added some burnt grass flock that I had from painting miniatures, something I often use with my grey-rubble bases as a subtle accent. My wife pulled out some assorted mosses that she acquired for an amazing ent costume she made my second son for Halloween last year, and we used these as the finishing touches. 

Here are the final results!

While we both agree that there are things we would do differently, we are also very proud of our first terrain pieces. I'm sure we'll make time in the coming days to use these in a Frostgrave game.

I am reminded of what I wrote about when I first returned to the miniature painting hobby. When I was young and playing a lot of D&D, we didn't have a lot of resources to connect with a community of players. Now, it's amazing what you can learn from a combination of YouTube, reflective practice, and whatever your wife pulls out of the closet. I am grateful for guys like Mel, DMG, DM Scotty, and Luke for what they bring to amateurs like us—a family that enjoys playing and crafting together.

Cheers!