The Poor Man's Gameplay Cue in UE4

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

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

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

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

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

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

Spring 2013 Game Studio: Modeling the first feature with UML and CRC Cards

Last week, the Spring 2013 Game Studio built physical prototypes to address specific questions about game dynamics. We tested these with our target age group on Monday, compiling and disseminating the results just in time for Tuesday morning's Sprint 2 planning meeting. Whereas the first sprint was all logistics, pre-production, and technological inquiry, the second sprint sees the team facing its first features. In particular, the first feature in the sprint backlog is, "As a player, I want to assign my villagers to farming."

The team identified the following tasks as necessary to complete this story:

• Design the user experience
• Implement the user interface
• Design the domain model in UML
• Implement the domain model with unit tests
• Bridge together the domain model and user interface

In this way, the team set up two roughly parallel tracks: user-facing and domain modeling. I was scheduled to meet with a group yesterday morning to mentor them through the initial domain modeling step, but we ended up postponing this for two reasons: team members encountered unexpected complications in the asset pipeline we wanted to use, and the user experience ideas were not yet sketched in sufficient detail to ensure that we were safe to move forward.

This morning, two of the technical team and I cleaned a large section of whiteboard and began our UML process. I suggested that we start with use case analysis. In our discussion, I discovered that both of these students are also in the department's Software Engineering class, where they had recently had an introduction to UML, so we did not need to start  from first principles. We sketched six use cases.

Use cases relevant to our feature

I explained that it was common to do dynamic modeling next, and that the static models would fall from this. They were both familiar with sequence diagrams and were eager to use them, but I explained that I prefer communication diagrams—especially when I'm not quite sure where I am going. We started with a Village object and began to talk through the use cases to determine the behaviors. We added an object, showed a message, removed the message, added another object, added a new message, removed it, and added another, ... and then I realized that this was the wrong tool for the job. Our conversations were good, but our notation was just getting in the way of the exploration.

It hit me that we needed CRC Cards.

One of the two students had taken Advanced Programming with me during a semester when we used CRC cards, but he was rusty; the other had never heard of them. I gave a primer and made a template to show  the class, responsibility, and collaborators sections and their purpose. We got a stack of orange index cards, put them in the middle of a mid-sized table, each grabbed a pen, and got to work. I showed how once again we could start with the concept of Village, and we marked that it maintained a list of idle villagers. From here emerged our Villager class, which we marked as having a status of "idle" or "farming."

Something seemed wrong, so I stopped the discussion there and looked over the cards. We were defining attributes, not responsibilities. Starting again from scratch, I explained that we wanted to focus on the messages that were passed among objects, not the internal representations. This led us to a nice small set of seven classes that fell out of our conversation.

CRC Cards for the first feature

We picked up the cards and moved back to the whiteboard, where we designed an initial class diagram. This is mostly their work, with my prodding them to consider only the public details for now. The most interesting interaction described in the cards is between Clock and Farm: a farm generates food based on elapsed time and the number of workers. As we talked about it, I pointed out that it sounded like the Observer design pattern: as the clock ticks, it notifies listeners, and they react as they need to. I showed them how to sketch that architecture and identify the pattern using collaboration notation, as I picked up from Holub on Patterns years ago.

UML Class Diagram derived from the CRC Cards

At the conclusion of the session, the two students expressed confidence that they could continue this process with the next feature on the backlog. Notably, they mentioned being confident that they could do it and that they could involve other members of the team. It's a sharp team, and I look forward to seeing how these "big ideas" get disseminated across the group.

All the UML you need to know

Each semester, when I teach CS222, I give a one-class lecture on UML class and sequence diagrams. It always goes the same: I introduce some ideas, then give the students some time to draw some diagrams, and I critique them. It works well, except for the lecturing part. That part is boring, for me and for the students.

This year I am trying something different. I have created a Web site off my BSU space called "All the UML You Need to Know." Actually, I've only half-created it. We already discussed sequence diagrams in class earlier this semester, so I didn't take the time to write that section yet.

I sent out the link to my students earlier today. Tomorrow, we'll talk about class diagrams, and I will direct them to this site as a resource as they play with the ideas. It took about eight times as long to write as it does for me to talk through it, which is actually not as bad as I had feared. Hopefully this will save me time in the long run, but more importantly, it will give the students accurate notes about the parts of UML I expect them to know.