Something like a Summer DevLog, Part 2: Gameplay Ability Systems and Me

After tinkering with simple burndown charts for the Web, I found myself thinking about whether and what kind of game I could make over the summer. I was inspired by A Short Hike recently. It was a freebie from Epic Games Store, and I played it to see if it would be appropriate for my kids. I was surprised at how it pulled me in. After finishing it, a GDC video was posted about it, and the original release of the game was made in only three months. There's an inspiration! Of course, as with Kaiju Kaboom, I don't think I can afford a success, so my exploration will likely be more academic, in the good sense of the word.

I have been intrigued by Unreal Engine's Gameplay Abilities System (GAS) since watching a livestream about it over a year ago. It sounded fascinating, and at the same time, the dearth of scaffolded instruction gave it a sort of mystic air, like some arcane wisdom that's just out of reach. Several times, I glanced through some docs or watched a video and thought, "That sounds really interesting," but it never fit what I was trying to accomplish. Enter the summer, and I'm thinking about some of the digital RPG bugs that have been crawling around my head for years. Could the Gameplay Ability System be the kind of technology that, if I invested in learning it, would reap the benefits of faster iteration times, or would it be a sunk cost?

Let me take a step back for a moment and explain briefly why GAS is interesting to me from a scholarly point of view. I've been studying games, design, and patterns for around fifteen years now. It's certainly the case that traditional OO design patterns can be applied, as explained in Bob Nystrom's amazing book that I wish I had written. There are also patterns specific to games, including such fundamentals as the main game loop. Game engines provide solutions to stock problems like loading assets, rendering, networking, and accessing the operating system; there is a sense in which these building blocks are also patterns. Beyond that, though, there always seemed to me to be something of a grey area in game development. That is, there seemed to be a point where there likely were patterns, but in practice, it seemed like each thing had to be built anew each time, in contrast with what the engines generally provided. GAS, then, is intriguing because it is an engine's attempt to grasp at this ephemeral thing of game design. I think this, fundamentally, is why GAS is so hard to learn, as every presentation and document I've seen about it echoes. It's a much bigger thing than, say, an Observer or a Builder. Perhaps it's a reification of an architectural pattern, but one that has not been widely grasped, from what I can tell. (Caveat: There are limits to my professional network here, and if there's a community of practitioners already addressing this, I'm outside of it. Perhaps, at some point, when I get my head more around GAS, I will reach out to the engineers at Epic and see if we can have a more serious conversation about any of this.)

Bringing it back to my summer project, I spent around a week oscillating between a few different states. First, I would excited explore some aspect of GAS, get it barely working, and then get excited about using it. Then, I would think that GAS is overkill and that I should just write the minimal system that gives me what I want so I can determine if the project itself is worth pursuing. Then, I would realize that my hand-written approach was so inspired by what I had just read about GAS that I should buckle down and use it. Wash, rinse, repeat.

As I repeated this process, I was able to find the absolute best resource for learning GAS: Dan Kestranek's GASDocumentation project. After finding that, I only rarely had to go look for supplemental information from other sources. Matt Edmond's talk from Unreal Fest Europe 2019 is also good for approaching the concepts and business case, but it's Kestranek's work that really gives you the details you need to build something from scratch.

My experience last week was complicated by the fact that I didn't really know what I was building: I was doing feasibility analysis but only for ideas that were in my imagination. At first, I was thinking of my project as a tech demo for a single-player computer RPG with deckbuilding mechanisms. There are some great inspirations in this area, including of course Slay the Spire and Griftlands, which is technically still in alpha but which I bought and thoroughly enjoyed. Both of these take a tabletop mechanism and wrap it in some ideas that are only possible in digital, especially Griftlands' use of cards that gain experience and level up. 

As I kept tinkering and oscillating, I found myself reflecting on the positive experience my boys and I have been having with For the King and comparing that to some of the cooperative board games we have played. This caught my fancy, so by the end of last week, I had a tech demo built of a four-player cooperative game that runs on my Steam Link. It's really raw, but it shows how each player is connected to its own controller, which each separately control a UMG-driven action menu, and the actions themselves have cooldowns that are shown in progress bars. You can't even really "play" it, but it all the pieces are in place to be able to explore this direction.

I did encounter something strange that I will share here, in part so that I can remember it later. When my son and I made Disarmed for Global Game Jam 2020, we had local multiplayer working fine on a Windows PC, but when we tried running it on the Steam Link at home, it did not work at all. I am not entirely sure why it doesn't work, but even more strangely, with a slightly different approach, I was able to get last week's tech demo working. When the game starts up, in the default game mode, my tech demo creates four players using the Create Player node. Then, it finds the Player Start on the map with corresponding Player Start Tag that corresponds to the player number, spawns a pawn, grabs the Player Controller with that index, and possesses the pawn. The only major difference I can see between this and Disarmed is that in the tech demo, the game mode has no default pawn class specified but creates them manually, whereas in Disarmed, we rely on the default pawn class specified in the game mode. I have not (yet?) gone back into Disarmed to see if this change would make it work, but I was delighted to get my tech demo working in my living room, even though testing it took several runs up and down the stairs.

My next step is to more seriously sketch the design of the game project itself. Over the weekend, I've been reading rulebooks and online threads and talking to a limited number of people about what I'm trying to do. I started writing some notes in an old notebook, though they are pretty haphazard. This coming week, I want to try to organize them to more carefully articulate some design goals, then see if I can turn my tech demo into a minimally playable game. I was thinking also about throwing together a one-man project for the seasonal Epic Jam, in which I have never participated, but it looks like the Spring one has been postponed.