Heroic Uncertainty: A Project for 2018 National Game Design Month #NaGaDeMon

TL;DR: Heroic Uncertainty source and Windows 64-bit builds are on GitHub.

I've had a game design idea tickling my brain for several years. There is an established pattern in fantasy games and stories that a hero receives quests from the imperiled people of the kingdom, and the hero's mission is to go overcome those obstacles. What if the information about the quest could not be trusted? That is, what if, like a game of Telephone, information decayed by the time it got to the hero, who then had to not only decide whether to face the peril, but also how much of the rumor to believe?  Earlier this year, I happened to mention this idea to a meeting of the Ball State University Serious Games Knowledge Group, and everyone around the table thought it was an intriguing concept. This inspired me to keep my eyes open for an opportunity to pursue building a playable prototype.

November 2018 may be better known as National Novel Writing Month (NaNoWriMo), but it is also National Game Design Month (NaGaDeMon). I have been aware of this lesser-known online creative movement for some time, but it was only this past year that I tracked down Nathan Russell's partially-active Website about it and, from there, joined the Facebook group. This game concept struck me as having too much complexity to finish in a weekend jam, but a month-long effort seemed a better fit. I knew that in November, my three classes would have transitioned or be transitioning into group project mode, which shifts my role toward mentoring rather than direct instruction. I figured this would be the ideal time to see if I could get this idea playable—and I did.

I spent a bit of time early in the month considering whether I could build a paper prototype of the core mechanisms, but my mind kept turning to more interesting computational models. I decided to build a proof-of-concept in Unreal Engine 4.20, furthering my own understanding of that tool and its potential for helping me move from concept to prototype.

A Distraction-Free Title Screen!

Heroic Uncertainty is a game where you control three heroes who are protected the kingdom from peril. Every few days, a creature shows up somewhere in the map, which triggers a person from that map to start heading toward the Capital in the middle of the kingdom. When the person reaches the capital, they report on what they know about the peril, which can include its type, size, location, relative power, and whether it requires magical skills to defeat. Each of these pieces of information has a chance of being incorrect, and so the player has to choose how best to deploy their heroes against uncertain enemies. If a peril is unaddressed for too long, it will defile the region, and the game ends when three regions have been defiled.

For most of development, the game was called Split the Party, playing off of the classic bad advice from tabletop roleplaying. I was intrigued by the idea of having multiple heroes rather than one, so that a player has to tactically deploy heroes with different skills to different areas. These three roles became Knight, Bard, and Sage. The only one with a really unique ability is the Bard, who can determine what part of a rumor is false. I was hoping to add special talents to the other classes as well, but as time ran out, the one most related to the core mechanism seemed best to explore.

Instructions in Thrilling Text!

The more information I added to the reported rumors, the more opportunities there were for information degradation. This is a clear area where more work could be done, should someone wish to continue the project. The current relationships between items is mostly random: for example, a peasant has an equal chance to report a bandit as being a demon as being a wolf. I tinkered with similarity graphs, but this quickly got out of scope for getting the game up and running.

Do you believe Chauncy the Thatcher? I wouldn't.

I've been showing builds of the game to my Game Programming students. It's funny to me that each time I show it, someone suggests highlighting the areas where perils appear or showing how long they have until they are overrun. The point of the experimental game is, of course, to see what happens if exactly that information is hidden. There are only two places where I bent this rule. When a region is overrun by a peril, it changes to green, no matter where the heroes are. Given full graphic production, I imagine that this would be shown as the region being set ablaze or shrouded in mystical darkness—something visible from far off. The other exception is that the heroes receive word about rumors when a person reaches the capital, whether they are at the capital or not. If the heroes know where each other are on the map, they must have some kind of magical communication network with each other, so why not with the monarch as well? This could be folded into a narrative more convincingly, but I think what I have is good enough for this experiment.

Combat! Perils!

What's the verdict? Honestly, a week ago, I would have just said that it is not fun. As I added more polish and, particularly, more information that could be degraded, I did begin to enjoy my internal testing more. The game has not really been played aside from my mostly-technical testing. However, I have been talking to people about it during the month, and their responses are revealing. One of them responded, "Oh, you're making Fake News: The Game." Hm, yes I suppose there is some sense of art-imitates-life here. Another response was that I was trying to gamify bureaucracy. Yikes, maybe so. All in all, I'm left with an idea that my wife and I discussed many months ago as I was talking about this concept, which is that it might work as a subsystem in a larger game, but that larger game had better be really good to overcome the frustrations of this subsystem. I do not plan on continuing work on Heroic Uncertainty, but I am glad I built it. I can put the idea to rest and have learned a bit in the process.

Let me turn, then, to some of the specific interesting things I learned by building this game. I've talked some about the innovative game systems above, but here I want to focus on some technical issues.

First and foremost, I've never programmed a game on a hex grid before, and I really didn't know how to start it. I came across Red Blob Games amazing series about hexagonal grids, which both helped me understand the mathematics and gave me a basis for building my implementation. If nothing else, make sure you check out their animation from cube coordinates to hexagons.

The implementation makes use of UE4's Data Tables, which I had never used before. It's a technique I had read about and was curious about, and indeed I even put it on the list of possible A-grade distinctions for my Game Programming class' final project. I ended up using CSV files to store tables of possible peasant names and their occupations, as well as the statistics of the various monster types. To add more of any of these, one simply has to edit the CSV and reimport the data table. Smooth.

The 4.20 release of Unreal Engine included support for Rich Text, something that was sorely missing in the past. Indeed, it would have been an excellent addition for Fairy Trails. It takes a few steps to get it up and running, but the documentation is clear.

A majority of the implementation of Heroic Uncertainty is in C++, particularly the formal game systems, with Blueprints being used for mostly visual and interactive elements. Building games in UE4 with a hybrid of C++ and Blueprints reminds me of how I feel about Lisp. Sometimes, I will work in Lisp for a while, and all the pieces make sense, but those insights seem to fall away as time goes on. It's almost like a peasant with a rumor about an invading orc who cannot quite remember the details when he reaches the capital.

In the original implementation of hex choosing, I had a custom dynamic material instance that used a pixel offset to depress the clicked hex. This looked good, but it did not allow for multiple actions on each selected hex. I'm quite pleased with both the UI and the implementation of my solution, which is to highlight the available actions on the hexes where they are supported. This is done with a custom blueprint that I called an ActionDecal. It consists of a decal that is displayed on top of the hex, tinted in the color of the current hero. I had never used decals before, and I had some trouble with them until I realized they render in curious ways if rotated away from axis alignment. Each decal also has a cube with the same dimensions, and the cube is not rendered but it is hoverable and clickable. This is how I detect the mouse moving over a decal and then, using timelines, highlight the hovered one or detect a selection.

You may have noticed that the heroes and rumor markers are simply the cylinders and cones that come packaged with UE4. Did you take a close look at those hexagons, though? I modeled those myself. Yes, that's right, I made my own 3D model and imported it into UE4. Pretty nice. I also explored UV unwrapping and used that to make custom textures for the hexes before I settled on the ActionDecal approach to action selection. This content, like a little experiment with spline-based animation, did not end up in the release, but it was still a fun area for me to learn about.

In Stunning 3D!

I had hoped to build the game for HTML5 and put it online, but there's a defect in UE4 that is preventing that build from working. The closest information I can find is this thread about 4.15. The author reports that the trouble seems to come from UMG, but I have not made the opportunity to try detaching different widgets to see if one of them is the issue. I do wonder if it's the fact that I am building my own inheritance hierarchy of UMG dialog boxes so that I get consistent behavior from them. I built the Windows 64-bit version and deployed that to GitHub, the only trick to that being that I had to use a console command within the game mode blueprint to get a window of an appropriate size. Designing the game for multiple window resolutions was definitely out of scope!

I did not keep track of how many hours went into this project, but I think 60 is probably a good ballpark estimate. I worked on it on several of my non-teaching days, as well as some nights and weekend hours. The worst times were when I spent several hours on systems that had to be discarded because they were ill-conceived. Indeed, in consecutive days, I started building similarity graphs of enemy features before really having a place to test them. This was a bottom-up design failure that ended up throwing away some six hours of programming. However, even here I got a good story to share with my students, as they were at a point of planning their own final projects.

You can download all the UE4 source files or a Windows 64-bit build of the game from GitHub. Feel free to check it out and leave a comment below. Thanks for reading, and keep on making games!