Contrasting Godot Engine and UE4 for use in undergraduate game programming and game production

The university is planning on having all our courses back in-person in Fall, and this means that my CS315 Game Programming class will once again be able to meet in the lab. Last year, I switched from UE4 to Godot Engine in large part because of the lack of access to lab machines: every student has a personal machine that can run Godot Engine, but many cannot run UE4. This Fall, I could just go back to UE4, but I have spent a lot of time with Godot Engine, and it has some distinct advantages for teaching.

I shared with my CS490 studio, via Slack, that I was thinking about the tradeoffs between these two engines. There are students in the virtual studio who have taken CS315 in both forms: some took it in Fall 2019 with UE4, and some in Fall 2020 with Godot Engine. Additionally, several of these people have since started learning different engines, such as some students who learned UE4 in class now using Godot Engine, and some who learned Godot Engine now using Unity. One student provided an excellent overview of his experience, but sadly, no one else has engaged in my request for comments.

Last Friday was the end of the third sprint for CS490, and we all met on Zoom so that the three teams could show their increments to each other. It so happens that during the discussion, a few items came up that are salient to the issue of engine selection. One team, which is using Godot Engine, had underestimated the time it took to write an AI for some of their game characters. In another project, also using Godot Engine, a student pointed out that the original compositions seemed to blend together well when switching between them. This was a happy accident and not by the design of the music nor its playback.

I commented to the students that both of these issues are great examples of the differences between engines. I pointed them to my tutorial video about UE4 behavior trees, which provide a higher level of abstraction for writing AI compared to having to do it directly in GDScript. For the audio, I mentioned that UE4 has a very robust audio framework, again with custom authoring tools well beyond what is integrated with Godot Engine. In a follow up post on Slack, I noted to them that one can crossfade audio in Godot Engine with an animation player, and I also pointed them to a reference about UE4 Sound Cues, a contextual example of crossfading using them, an amazing presentation of the advanced audio capabilities used by sonic artists, and a useful tutorial about how to write a music stitching system. 

So, if UE4 has all this cool stuff, why not just use it? As I discussed with my students during the meeting, a lot of this great engine content is beyond what a student can get to in a one-semester introduction to game programming. They would be useful things to know now, having wrapped up the third iteration of a project and having already studied the basics, but I've never seen a student in CS315 get as far as really needing advanced audio or behavior trees. For behavior trees in particular, when I have offered some A-level credit for exploring them, it's always been a bit disappointing because it's the tail wagging the dog: students make a simple behavior tree to show they can rather than use them to solve an actual problem they have.

Godot Engine, by contrast, makes it really easy to stand up a prototype. Additionally, as one of my students put it, 3D in Godot Engine is fine, but 2D in Unreal Engine is a pain. A student also suggested that most students in CS315 would rather make 2D games than 3D anyway, especially given the extra complexities inherent in 3D game production. 

I am not yet putting together formal course plans for Fall—that will came later. For now, I am undecided but leaning toward sticking with Godot Engine for another year. I have been approved to run another full-year immersive learning collaboration with Minnetrista: we will make prototypes in the Fall and produce a game in the Spring studio. Although CS315 is not part of this sequence, many CS majors come into CS490 via CS315. This will be a factor in my decision. I also have two outstanding grant proposals that would impact how I want to devote my own attention next academic year: it's much easier to teach an engine I am currently using than one I am not.

Magic in Games: The Absence of Mystery and Danger

Why isn't magic mysterious and dangerous in most games? The idea of magic, and the lore of magic, tend to be that it is mysterious and dangerous, yet I have difficulty thinking of games that manifest this idea in their rules. Most of the time, magic is just one power among money, one that is more scientistic than otherworldly.

From the first edition of D&D, the venerable tabletop roleplaying game has suffered from ludonarrative dissonance: the book tells you that magic is strange and weird, but the mechanics around them are a fairly simple metaphysics. In the old days, it was Vancian: learn a spell, cast it to produce an effect, burn it from memory, wash, rinse, repeat. 

There was one exception in my heyday of AD&D Second Edition, and that was from The Tome of Magic. I loved that book, with its expanded list of spells, new cleric spheres, and rules for elemental magic. Most notable, though, was the introduction of wild magic. When a practitioner of wild magic cast a spell, there were all manner of outcomes: one could succeed phenomenally, fail abysmally, or do something completely unrelated to the original goal. Perhaps it is noteworthy that in the campaigns I played, the only wild magic users were ever NPCs. It seems that players were less interested in risking their characters' hides than a DM was willing to tinker with novel systems! Notice also that this was not "magic" but "wild magic", establishing that the unpredictable kind of magic was categorically distinct from the staid kind.

Then, the flood of second edition sourcebooks started making every class gain more and more "spell-like" powers, until with 3rd edition, basically every character was defined by powers. The danger of being a wizard was due to the lack of armor and low hit points rather than due to the properties of their craft, and the distinctiveness of a wizard was their status as glass cannon rather than mysteriousness.

As I understand the trend of D&D, it has continued to move in this direction. Not only do characters have multiple powers, now it seems that almost any class can get access to magic. The stories I hear and the fan art I see looks more like anime than anything that inspired Gygax and Arneson. I'm not making a value judgement here, but is any of this really magical? Memorize this spell and cast it for an effect, or, draw upon your connection to nature or mana or something and conjure up a fireball with your charisma. It is more scientistic than mysterious, more earthbending than arcane.

In video games, it seems even simpler. By and large, "magic" is resource management: save up your mana so you can do your big blast effect against the mini-boss. I think Bard's Tale III was the first game I played with Spell Points, and I can remember delving into dungeons, then running around outside to regenerate Spell Points before I could go back in. Again, there's nothing inherently wrong with this except perhaps the theme. It lacks mystery: magic is simply a predictable force that works in a predictable way.

I have played more video games than I can remember, but of those I could bring to mind, very few give magic any sense of danger. In Nethack, when you find a scroll, you don't know which spell it is, nor whether it is cursed; but you know that it's one from a list of possible spells, and you know that it is cursed, blessed, or neither. In Darkest Dungeon, the occultist may actually do more harm than good when casting his healing spells, but it will be one or the other. The Divine Divinity series contains some interesting effects between the environment and magic such as being able to set fire to a pool of oil, and if you do it wrong, it hurts your own characters rather than the enemies; the casting has some danger, then, but only if you're not careful nor tactical. 

To be fair, the influences of early fantasy games (video and otherwise) included not just Sword & Sorcery but also movies like 1963's The Raven. In Conan's stories, if you meet someone who can sling fireballs at will, that person is evil, corrupt, possessed by otherworldly powers. The Raven is a bit oddball, but here, we see a conflict between good and evil spellcasters, the best of whom can create fantastic effects with just a waggle of the fingers. Why do almost all games take the latter approach instead of the former?

Hold on to that for a moment, and let's return to Dungeon Crawl Classics RPG, a game that has been on my mind a lot recently. (See this post about playing with my family, for example.) DCC uses a system called "Mercurial Magic": when a wizard learns a spell, the player rolls on a table, and there's a high chance that this spell will have some additional manifestation or property that is, more or less, unique to that spellcaster. For example, when we played last weekend, my son's wizard cast flaming hands, and it summoned the attention of an ominous, otherworldly spirit onto the party. Neat! DCC uses a roll-to-cast system, such as advocated by pundits like Professor Dungeonmaster and Hankerin Ferinale. DCC goes further than just success or failure on spellcasting, which only brings magic up to the level of uncertainty that goes into punching and kicking. Rather, in DCC, each spell has its own table of outcomes, and the better the roll, the more wondrous the outcomes. It's like taking "1d4+1 damage from magic missile" and turning it up to eleven, where the damage, the number of targets, the range, and more are all potentially modified by casting. DCC is the first game I have played where I felt like magic is mysterious and dangerous. It's not even that magic is grimdark, as it tends to be in Conan stories for example, but it feels magical.

Why don't we see this in other games? One of the simpler answers for videogames is hinted at in my notes from Burgun's and Ma's discussion of strategy game design: it's hard to program! It's one thing for a tabletop RPG to say, "An ominous, otherworldly presence looks over the party," which the Judge/DM can pick up and run with. It's quite another to program that. Writing the code, creating the assets, and QA testing N spells is hard enough, but if you have M effects for each, that's quadratic growth. Yet, we don't see in video games even the easier things. We have "1d4+1 damage from magic missile," but without variable targets or range, and without passing parameters to shaders for moderate variation.

The other answer that may be the better one. In practically all videogames, and every one I have mentioned here, you can lose. I personally enjoy the random chance that comes up in games like X-Com as well as classic roguelikes such as Nethack. Would I enjoy it as much if I was at the last level of either and my spellcaster suddenly blew up the dungeon? Maybe not. I think, though, that this proves my hypothesis that the problem of integrating magical magic is a game design problem that goes all the way down. The conventional approach is to add magic the way you might add traps for a thief or instruments for a bard. The fact that people make traps is interesting, and the addition of music to a world gives it culture. These are both mundane, though, whereas magic is about changing the nature of reality.

In his essay "On Fairy Stories," Tolkien reserves the word "magic" for that practiced by Magicians who value "greed and self-centered power." It stands in stark contrast to the enchantments of the fairies, which are not just transcendent, but which have the properties to which only the very best of human arts approaches. That is, the best of human effort comes close to the fairies' enchantments, while magic is performed through the worst of vices. Perhaps there is an opportunity then that we game designers might strive for enchanted subcreation by exploring the perils of magic.

A week of design artifacts

What does game design look like? Here's a photo of the papers I just cleared off of my desk after working on Build and Delve for the 7DRL Challenge last week. Most of the small sheets have notes on both sides, especially those with drawings on them. The large sheet in the center was dominated by design ideas, but the covered parts of the paper contain notes from miscellaneous other work-related meetings from the week.

It's hard to read any of the pencil scribblings, but that's OK: the point here is the variety of scribblings, not their individual content. My favorite one is in the bottom center, my reminder to myself to add the focus subsystem with three particular abilities. I believe that was a shower thought that I needed to get on paper before it fled. This particular note is written right on top of an unrelated UI sketch.

Build and Delve: A Deckbuilding Rogulike for the 7DRL Challenge

I just put the finishing touches on Build and Delve, my entry to the 2021 7DRL Challenge. This is an annual event that challenges participants to build a roguelike video game in one week. I had never built a roguelike before, although I did tinker with parts of one in last November's NaGaDeMon. I was inspired to try my hand at combining deck-building with traditional roguelike systems, and that formed the core premise for Build and Delve. 

I heard about 7DRL shortly after last year's event, when I came across Bob Nystrom's presentation on ECS for the 2018 Roguelike Celebration. His talk inspired me to add the 7DRL to my calendar. I did not touch ECS at all in my submission, but I would like to return to my explorations of that architecture one of these days.

I started Build and Delve on Saturday, March 6 and just wrapped up today. Here is a funny story about the timing. The main 7DRL page lists the dates as March 6 to March 14, and so on my calendar, that's what I reserved. When I started my entry on the Saturday the 6th, and for most of the week, I had it in my head that I would be able to finish it on Saturday the 13th. It was Wednesday or Thursday that it struck me: it's the seven day roguelike challenge, and if I work again on the 13th, then I will be working for eight days. I double-checked the Website and discovered that the critical constraint is 168 hours. That is not a number that fits in my head, but if you divide 168 by 24, you do get seven. This struck me as an interesting cognitive phenomenon: if you say 24, 48, or 72 hours, I can immediately understand that in days, but once you go beyond that, it's no longer obvious to me. In any case, after the initial surprise and chuckle, I welcomed the shorter deadline, since it meant I could cut back on some features and plan on spending more time on Saturday unwinding. With the jam starting last Saturday, I've been going pretty nonstop since the previous weekend. It's definitely time for a break.

Part of my inspiration for Build and Delve comes from playing Dune: Imperium. It is a deck-building board game in which each card has two abilities: one that activates when you play the card and one that activates when you do not. My original 7DRL prototype used the idea that cards you do not play give you action points, and these action points are turns in the dungeon. Once you are out of action points, the enemies trigger, and you draw a new hand. The gameplay was a bit unsatisfying, however, so I went back to a different interpretation: that the cards you do not play to build the dungeon can be used to boost your abilities in the dungeon. This is what ended up in the final build. Another source of inspiration has been playing Loop Hero, which combines tile-placement with something like an idle game and a roguelike.

Build and Delve is relatively primitive, but it still took a lot of work to bring these systems together. Some of the points for expansion that ended up on the cutting room floor include: ranged weapons; different focus powers for different character classes; random quality of items based on room characteristics, such as trap cards that increase danger while also increasing item quality; better enemy AI across more diverse enemy types; and cards that modify other cards, such as allowing the trashing of cards, which is a staple in deck-building.

One of the best moves I made was to use Kenney's 1-bit sprites. I wrote a simple tool that would let me extract the frame number via mouse click, and this made it very easy to add monsters, armor, and weapons once I had the engine working. I had intended to add different tints to the sprites, allowing for more variation as in Nethack, but this feature also didn't make it. I spent an hour or two earlier in the week starting to replace Kenney's sprites with Dawnlike, but this was a lot of resource-wrangling for relatively little payoff. I reverted to Kenney's 1-bit and never looked back.

Incidentally, the name and logo for the game were clearly developed after I had already been burning the candle at both ends. I am not proud of them. Looking at the other promo images for entries to the jam on itch.io puts my mine to shame. 

I am glad I had the chance to participate. This week was a convenient lull in the semester since my students are all up and running with their final projects. Come Monday, I will have a pile of project increments to evaluate, but for now, it's the calm before the storm. Well, except that I filled the calm with the alternative storm of game development, but at least I got to choose my storm.

Quick inspirations from Justin Ma's interview on the Clockwork Design podcast

Walking to and from work this week, I listened to Keith Burgun's Clockwork Game Design podcast interview with Justin Ma (FTL, Into the Breach). In truth, it's not a great interview, but there were a few observations Ma shared that I found particularly interesting. Perhaps I should be finishing my 7DRL entry, but first, let me grab these ideas before they run away.

The discussants frequently compared board games and video games. Ma suggested that a player's experience with a video game is about 20% game design, while their experience with board games is about 95% game design. This is an interesting admission from an accomplished game designer that a majority of a player's attention is not actually in game design (which one might also prefer to call "system design") but in other things. In this discussion, Ma mentioned that he's terrified of making a board game because there is nowhere to hide.

Burgun asked Ma what advice he would give to indie video game developers, and Ma's response was, essentially, don't do it if you have any financial risk at all. He offhandedly suggested that the average game on Steam sells 500 copies; that's average, not median. Now, he's not presenting it as statistical fact, but his intuitive storytelling should be enough to give anyone pause.

Toward the end of the discussion, they talked about the presentation of information, and the relevance of information, in game design. A particularly interesting point here was that (roughly) if you do 40 damage, and your opponent has 80 health, then what you really care about is that you can defeat them in two hits. With enough advancement of your damage ability, you might get that down to one hit. The design question is, then, why not just have your damage be one and their health be two? I am not sure that I thought carefully about how this is manifested in Into the Breach, but it is. Burgun turned this conversation toward the idea of taking as much of the system as possible and making it manifest on the grid: he said that if he does x damage, his imagination turns off, but if he can throw an opponent three squares, his imagination opens up. His example of a Sumo-style health system is pretty much exactly what happens in En Garde and its fancy cousin, Flash Duel.

UPDATE: I remembered another interesting piece of this when discussing it with others, and so I came back to this post to add it.

In the comparison of board games to video games, Ma pointed out that in a board game, it's easy to flip a card that fundamentally changes how the game works. When programming, though, that's incredibly difficult. I think built in to this perspective is the idea that when you build the core engine, you likely won't know you even want a particular variation. As a result, parts of the engine become ossified and practically impossible to change in any reasonable amount of production time. Burgun's and Ma's discussion floated around this idea that video games tend to have simpler, conservative systems whereas board games can be more bold in exploring system design. It strikes me as ironic that despite our unbelievably powerful computing devices, it's our own human limitations and native abilities that really determine what is easy or hard. The computer, after all, can only do what it is told.

Learning the wrong lesson from the CS222 Two-Week Project

Two weeks ago, I shared my initial thoughts about splitting the two-week project up into two parts. To summarize, what had been a two-week JavaFX project with one set of requirements became a one-week CLI project followed by a one-week GUI project. My initial post was about how students reacted to having separate submissions for the first week and the second week. Today, I want to share a different perspective based on what has happened in the interim.

Last week, the students formed teams for the final project. They had to complete a pitch by Friday, and by Monday morning, turn in a project plan. The plan was to be in the form of user stories, akin to those that I modeled for them in the two-week project. There were some structural things that every team got wrong: for example, each plan included user stories broken down by iteration rather than what was required, which was to prioritize the stories and then separate the first iteration stories from the rest of the backlog. Keep in mind that the students do all of this work in a shared Google Drive folder, and so I suspect that some team finished their work early and incorrectly, and then every other team copied what they found there, assuming it to be correct. The fact that the documents themselves had similar structures gives evidence to support this hypothesis.

The more substantial problem was this: most of the teams set up their user stories so that the highest priority story involved creating a command-line application, and then a future story added a JavaFX GUI on top of this. That is, they seem have followed my approach to unfolding requirements in the two-week project and mistaken my cheeky turning-the-tables for a best practice. In retrospect, how could they not? They had never seen a GUI before, so my little embedded narrative about a client who asks for a CLI and then changes requirements could not have resonated as I intended: if you don't know that it's odd, then you assume that it's normal.

It's a good example of the unintended consequences of teaching, and it indicates to me that I should do something different next time I teach the course.

Text Resources, Magic, and the 12th FamJam

On Sunday, Febrary 28, my family completed our 12th FamJam, marking one year of monthly jams. The result of the jam is Rescue Writer, a typing game designed by my third son. My wife put it well when she said that this game did not capture the family's imagination, but the two younger boys seem to enjoy it. Despite its being unexciting, there were some interesting happenings in the development, and hence, this post.

I wanted to have a word bank that anyone in the family could edit. Clearly, this could be expressed as an array of string literals, but that's an awful lot of wasteful quotation marks and commas. I wanted to just have a plain text file, but it wasn't clear to me how to do that. After some tinkering, I was able to get the WordBank script to behave as I wanted. I created a text resource file—res://assets/wordbank.tres—that is loaded by the script and processed line by line. I am pleased to report that it works well in the editor and when exported to HTML5.

The original version of that script ignored duplicates, which was fine when we had 30 words. As we kept working, though, different people added to the word bank, and duplicates were inevitable. My wife, who works downstairs from me during the jam, sent a message asking if the script removes duplicates. It didn't at the time, but I went ahead and added the lines to handle it: the script skipped over duplicates and printed a message to the console that a duplicate was found. My wife's response was, "That's like magic." 

This was really interesting to me, but I tried not to get distracted by it while actually working on the project. To me, identifying and ignoring duplicates while reading a text file is completely mundane. Indeed, I am having some difficulty articulating how completely uninteresting detecting duplicates is in my conception of software development. The difference in perspectives is fascinating to me. What other things do I take for granted that an outsider would consider magical? How does this impact my capacity to operate in the world or, perhaps, to teach novices? At one point, removing duplicates from a plain text file was likely impressive to me, but now it's just a thing that must be done in order to do something else.