Saturday, March 17, 2018

How I'm Redeeming a Terrible Game (Monsterpunk Devlog #15)

Here's a story about an ongoing misadventure lasing several years, player progression systems, efficient problem solving, inefficient problem solving, and the creative process.

Your Boy was in Trouble

The last time I touched Monsterpunk was April of last year. Higher priority projects filled my time since then - namely, festival applications, game launcher software, graduate school applications, The Giant Robot Blues, and Monster Truck Power Fantasy

When I finished Power Fantasy, I breathed a deep sigh, re-opened Monsterpunk's project file, compiled it, and played it. I was mortified. 

I softly screamed into the internet:

I can't think of another game I've made, no matter how old or awful it is, that I haven't been able to enjoy on some level. Even the trash I made in middle school has entertainment value in the same way your kindergarten doodles of Jedi stabbing each other and gushing fountains of blood has entertainment value.

The main problem with Monsterpunk was that it was simply boring.

I don't think the game is destined to be boring. Often, it shows in the finished game if it had a troubled development cycle, but this isn't always the case. For example, Looking Glass Studios didn't have a working game a year and a half into the development of Thief, and the project almost folded. In order to save the game, they had to reprogram many of the its fundamental features from scratch. They went on to release a highly-influential classic.

Fixing Monsterpunk requires me to do the same. The game's problems aren't hidden in the details, rather, they're rooted in some of the game's central premises. Fixing the game has been similar to stripping away the foundation away from a building, replacing it, and hoping the structure still holds. So far, it's been a daunting, but rewarding process.

Writing about the awfulness your yet-to-be-released game is not a conventionally sound PR strategy. However, I think there is much to be learned from an experience of producing a strong piece of art after a long and troubled creative process, and I can provide a more accurate and useful account of the process by writing about it as it happens, rather than as a post-mortem.

My game was bad, but it's better now. Let me tell you why.

The Context

Before I describe my solution to the problem, I want to provide some more of its context. I've been creating Monsterpunk since the fall of 2014. Originally, it was a small life-simulation RPG titled Toilets, Meat, and Drugs that I made in a week for a game jam. It was inspired by the mechanics of the life-sim game Digimon World and the aesthetics of punkgames by developers like Porpentine and thecatamites.

Digimon World, 1999

Armada, Porpentine, 2013
Space Funeral, thecatamites, 2010

Unfortunately for my game, the MS Paint-esque punk aesthetic was a lot more relevant in the early 2010's than it is today. All I can do now is continue to embrace it.

Toilets, Meat, and Drugs, even in its earliest form, was a boring mess. Jupiter Hadley, who does the fantastic work of covering and recording footage of every indie jam game she can come across, recording the opening minute or so for one of her compilations of game jam entries.

The opening of the game consists of you character slowly moving in front of a series of signs, reading through a full explanation of the game's rules, before slowly backtracking to use a toilet. The writing is cringe-worthy.

Toilets, Meat, and Drugs intro, 2014

In one of my less-proud moments, I made a comment to her asking why she recorded such a dull segment of play, and we had a brief exchange, toward the end of which she made some comment along the lines of, "if you want me to record something interesting, make something interesting."

Her actual wording was a lot gentler, and please make no mistake, I was being an asshole. I was pissed and confused following the exchange, but eventually, I came to understand her point. The opening minute of the game (and much of what followed) was boring, it was a serious problem, and it was my fault. Generally speaking, a game, like any other form of entertainment media, should be engaging from the moment the player boots it up. If it isn't, it better be justified. Toilets, Meat, and Drugs did not offer that justification.

The Core Problems

The problems with game, both in its 2014 and 2017 iterations, are numerous, but the two largest problems are its tutorial (which sours the beginning) and its pacing (which sours the middle). The 15 minutes of fun I referred to in my tweet  happened during one of the game's ending sequences. That particular sequence is very good, but it takes an hour and forty-five minutes of unrewarding play to get to it.

It should be common sense to even a novice game designer that verbally conveying all of the game's rules to the player at the very beginning without any context is a terrible idea. It's too much information, it usually can't be referenced later, it isn't interactive, and the player has no reason to give a shit about any of it. One of the earliest changes I made to the game was replacing the tutorial with something more interactive, simplified, and user-friendly.

Monsterpunk intro, 2015

That said, it's still a boring way to start the game - its opening minutes are still slow and information-heavy. I've only just begun to remake the game's beginning, and will write more about it once I've finished.

I have, however, solved the game's pacing problems. The game's sluggish pacing and excessive downtime are the result of its player progression system.

In most role-playing games, your character progresses via an experience point (XP) system. Most of you know this. Your character completes challenges, are awarded a number of XP, and when they get enough points, they level up and become stronger, allowing them to complete challenges that were previously impossible.

Monsterpunk is not like most role-playing games - most of its mechanics, including its progression system, are inspired by Digimon World. The full manner in which the player gains abilities and becomes stronger over the course of Digimon World is surprisingly layered, but the most obvious form of progression is through the passage of time. Digimon World's protagonist is a human with a monster partner. That monster partner goes through different life stages, usually becoming more powerful each time it grows, until it dies, is reborn as a baby, and the cycle repeats. A monster's progression through its life stages is directly linked to its age, and time in Digimon World progresses at a constant rate. It's a form of progression that, for the most part, occurs irrespective of anything the player does.

On paper, this is an idea that can work thematically, and it does, but it sounds terrible from a conventional game design perspective. As described above, outside the context of the game's other systems, the monster aging mechanic removes agency from the player. However, Digimon World makes it work. When the player hits a wall of difficulty that requires a more powerful monster, instead of simply waiting for the monster to grow older, they can pass time by taking the monster to the gym, thus increasing its physical strength. Incidentally, training at the gym also accelerates the game's clock. An hour in World is normally the equivalent of a real-world minute - an hour of training at the gym, however, is nearly instantaneous. In other words, if the player's monster isn't powerful or old enough for them to progress, there's a single fallback mechanic that solves both problems. It's still a tedious solution, but it does have a certain elegance to it.

In Monsterpunk, I similarly linked player progression to play time. This was a life simulation, after all, so it made some sense to adopt mechanics that most closely resemble real-world aspects of being alive. As time passes, the player character passes through different life stages, with each stage being more powerful than the previous. However, Monsterpunk does not have a fallback mechanic analogous to Digimon World's gym. If you hit a wall of difficulty that requires a more powerful character, your only option is to wait it out. 

This would lead to situations, for example, where a player would progress too slowly through the game, and their character steadily age and advance through life stages earlier than necessary. Their power level would be ahead of the difficulty curve, diluting much of the game's tension. More frequently, however, a player would progress too quickly, accomplish every challenge they could at their current power level, and then find themselves hitting a wall of difficulty that could only be overcome by waiting to age.

This threw the player into a state of tedium in which they lacked an immediate objective. Even worse, few of their choices mattered until they passed a growth threshold.

The Solution


In the end, I came to understand why the traditional XP progression system is so widely adopted.

While we take this system for granted, it works for numerous reasons. By attaching an XP reward to certain behaviors or challenges, you can incentivize the player to do virtually anything. Not only that, but it allows the designer to make any interaction rewarding, even if in a superficial way. Most importantly, though, it directly links the pacing of the game to the player's mastery of it. The more efficiently the player overcomes challenges, the faster they become stronger, allowing them to access more of the game's content sooner.

In the case of Monsterpunk, implementing an XP system did everything it was supposed to do. Not only have I eliminated most of the game's downtime, but every action the player took that awarded XP now has a little extra meaning attached to it.

Where Monsterpunk's XP system diverges from most other games is that it places less emphasis on killing other characters. While combat, and the decision to abstain from it, are central parts of the Monsterpunk experience, the game must have a means to reward players who pursue any play style. Therefore, I attached XP to nearly every system in the game I could think of, from flirting with other monsters, to growing your own food, to pooping in toilets.

Every time the player gains XP, their progress bar briefly flashes alongside the amount of points earned.

I was reluctant to thoughtlessly fall back on a classic set of game mechanics that most designers and players take for granted. While conventional design ultimately served as a solution to Monsterpunk's core problems, it was only through a blind rejection of convention that I was able to better understand its merits.

I booted the game back up, played through it, and was amazed by how much my game had transformed. All of the tedium and downtime once plaguing the game was gone, and just as well, everything I achieved as a player felt a little more substantial, and every interaction that lead to an achievement felt more enjoyable.

Wait! It gets better!


Monsterpunk's new XP system proved to be a gift that kept giving in unexpected ways. Adding inherent rewards to most player behavior allows me to trim superfluous features from the game that have become obsolete. The best example of this is the game's reputation system.

I added a reputation system to the game to address some of the problems with its flirtation system. The player's character is capable of flirting with other monsters in the game - those whom they successfully flirt with will no longer be hostile to the player. It's the game's primary nonviolent means of problem solving. This mechanic is inspired by skill check system of Dungeons and Dragons - the player character has a score that represents how good they are at flirting, the target has a score that represents how easily affected they are by flirtation, a random number is generated based on these scores, and if the number is high enough, the flirtation attempt is successful.

In narrative-driven games, it's a really effective system, but in most cases, if you want the player's choices in a game to feel like they matter, you should avoid designing with output randomness. That is to say, the result of a player's choices shouldn't be random. If a soccer player kicks a ball into a goal, and the referee flips a coin to determine whether it was actually worth a point, it would be a frustrating experience for everyone involved. The outcome of the soccer game would cease to be wholly representative of the either team's skill, and instead be largely left to chance. The players' decision making and physical feats would feel as though they didn't matter.

Unfortunately, early in Monsterpunk's development, I designed the flirtation system to be heavily dependent on chance, and replacing with a new skilled-based system isn't very feasible this late in development. Instead, I opted to make it so that there was some guaranteed reward attached to every flirtation attempt, regardless of whether it was successful - a guaranteed non-random outcome.

This was the basis for the reputation system. Every time the player flirts with another character, regardless of how well it goes, their reputation goes up. If their reputation reaches a certain level, their flirt attempts become more effective. Furthermore, acts of violence decrease reputation, making flirtation less effective, and the player's reputation naturally resets over time.

Ultimately, the reputation system didn't make the game any more compelling. It was a needlessly complicated mechanic that required me to frontload the game's tutorial with yet another long-winded explanation of a system that the player didn't have a reason to care about, because it wasn't fun.

Just wait until I clutter the screen with a fourth goddamn bar!

After I implemented the XP system, I was relieved to have realized that the reputation system was now obsolete. Instead of awarding the player reputation for their flirtation attempts, they were now awarded experience, which is just as effective at providing consistency to their decisions' outcomes. In this case, an experience-based reward was more meaningful than a reputation-based one, as advancing a life stage is much more exciting to the player than building a short-lived flirtation bonus.

It should go without saying that it is almost always better to solve multiple design problems with a single system than to create a new system for each problem. This is what makes games elegant.

The Downside


My original goal with Monsterpunk wasn't necessarily to make a "fun" game, but rather, an interactive experience that's compelling on multiple levels. I think that game designers are just starting to explore what else can be achieved artistically with digitally interactive pictures and sound besides "fun," and I think life-sims have a lot of potential to thematically relate to the human experience in numerous ways by the nature of their content. One of the reasons I am obsessed with Digimon World is that, for a flawed, buggy, poorly-translated children's game, it mechanically explores the passage of time, death, and the existential angst they cause better than anything else I've played.

My current goal, however, is simply to release something worth playing as soon as humanely possible. That means I have to sacrifice some potential for thematic depth in exchange for raw quality. Right now, it's better for me to release something that's fun, but relatively shallow, than something that aspires for depth, but fails to engage the player on any level.

Monsterpunk's time-based progression system had potential to explore existential themes regarding the passage of time, but ultimately, it failed to do so. The new XP system lacks this potential, but makes the game worth playing. Could I have found a way to preserve the time-based system and make it compelling? Absolutely. Would it have been as efficient, simple, or viable as implementing an XP system at this stage of development? Probably not.

I'm a little sad that Monsterpunk, however good it may be, will not be the game I originally intended it to be. But, confronted with that reality, I've made the optimal design decision, and now have a game that I can be proud of.

The Lesson


In game design, I think it's often easy to become lost in the details - to see games as a collection of individual features and visual and audio assets. My approach for the first three years of Monsterpunk's development has been to improve it by improving the details. Would it be more fun if I made the textboxes look nicer and drew character portraits? What if I composed distinct music for each area? What if I provided better feedback through the UI? How about if I added more playable characters? Expanded the game world?

Yeah, sure, let's spend a few years adding 25 playable characters instead of addressing your game's real problems.

I spent a long time making changes to the game that, undoubtedly, were improvements. Yet the game itself still wasn't that much more enjoyable than it had been before making those changes. It was frustrating.

Even for those of us working outside of the industry, who make more minimalist work, the underlying assumption that "more polish + more features + better graphics = better game" is so prevalent that we have a tendency to focus on improving the individual components of a game at the expense of examining the larger picture. Or, at least, I have that tendency.

The thing about this approach is that it isn't a time-efficient way to solve design problems. Even though Monsterpunk's primary design problem (the awkward pacing) was a singular problem, because it impacted every sub-system of the game, and impacted them throughout the entire game, I originally thought that the solution was to improve each of the game's individual sub-systems. I spent years doing this with only modest success.

After taking a hiatus from the game, I re-examined the problem and came to the profound realization that the scope of the problem didn't change the fact that it was a singular problem and therefore demanded a singular solution.

Game development culture fetishizes time commitment to projects. For professional industry devs, working excessive overtime hours during periods of crunch is normalized, but even outside the industry, there's a broad expectation that successful game development requires great personal sacrifice. "If you aren't spending at least 30 hours a week on your game, you aren't going to cut it." "Don't sleep during game jams!" "Daisuke Amaya spent five years of his life handcrafting Cave Story, what the hell are you doing with your time? Spending time with friends? You obviously aren't dedicated enough." With this prevalent attitude, my default assumption was that, if I simply spent more time on the game, it would improve, regardless of how I spent the time.

To a certain extent, those advocates of self-destructive workaholism do have a point. Like anything worth doing, making games take effort! But there is little advocacy for, or celebration of, efficient game design. The key to successful indie game development, especially for those of us working day jobs, is to find the most efficient path to achieve a desired audience response. Perhaps if efficiency and elegance were more appreciated within our subculture, I'd have approached Monsterpunk with a different mindset and have solved its pacing problems sooner.

Thanks for reading, here's a GIF of a bird in a yellow television pooping on plastic bricks.

Friday, January 19, 2018

Patching of Games and the Implications

A friend brought it to my attention that Monster Truck Power Fantasy, among other Game Maker: Studio games I've made, would display a black screen on his computer running Windows 10. This appears to be a rare bug, but it's one I've since fixed. Monster Truck Power Fantasy, Gewgawlicious, Bloodjak, and Digital Toilet World should now run on Windows 10 with no problem.

The Morphine Western Revenge already had the fix applied, most people shouldn't download and play Darcy's Yurt Adventure, and Empty Chambers and How to Fly were made in Game Maker 8, so I ain't touching those anymore. Everything else was made in Unity or Twine. 

I know I'm late to the conversation about the permanence of software as a medium, but I'm becoming increasingly aware of just how fragile it is. Text can always be transcribed and preserved in a dozen different ways. Music and film can always be digitized to a playable format indefinitely. I'm starting to come to the realization that my games may no longer be playable on Windows, maybe not even ten or twenty years from now, and there isn't much I can do about it.

This particular black screen bug, from what I've read, was caused by the Windows 10 Creators Update, and it affects fullscreen Game Maker: Studio games indiscriminately. There's a simple fix that can be performed from within the program. So far, so good. It took an evening for me to go through nearly every game to perform the fix and re-upload it, but it's worth it to make sure that my games can run, let alone run well.

The scary thing, though, is that Game Maker: Studio is no longer supported by the developer, as it has been replaced by Game Maker: Studio 2. GM:S, in its final version, was capable of circumventing the bug. I certainly can't count on that being the case in the future, or on Game Maker: Studio properly running in the future.

So, it's possible to port all of my games into the new program. From what I hear, this requires the games to be reprogrammed, to an extent. I've made six Game Maker: Studio games so far, and it would take some serious time and effort to port them in Game Maker Studio 2 to make sure everything continues to work on current software and hardware. Not to mention, every time I have to make a change to fix a bug across all of my games caused by, for example, a Windows update, I have to fix and re-upload all of my games.

I make about two or three games every year. Let's say Game Maker Studio 3 comes out in five years. By the, I would hopefully have at least 16 games that I would need to port into that program... the workload required to keep my work current will snowball over the decades.

Of course, who knows how long Game Maker will exist as a program in any iteration? Nothing lasts forever. Maybe the last version is released, say, fifteen, twenty years from now, the company goes bankrupt, and I lose the ability to make any changes to my games' source code?

Of course, you can run any outdated Windows program in compatibility mode, and it should run correctly. But whether it does or not depends entirely upon the competence of Microsoft engineers. The ability for anyone to play my games over the course of my lifetime is largely in their hands. Not to mention, it won't occur to the typical player to run a game in compatibility mode, or to run it through an emulator.

This is probably going to be a widespread problem as operating systems undergo countless iterations over the coming decades (get hyped for Windows 40), and I may be pleasantly surprised by the solutions the IT community develops, but in the meantime, it is unnerving.

Wednesday, January 17, 2018

Monster Truck Power Fantasy v1.1

I updated "Monster Truck Power Fantasy" to version 1.1. It is now downloadable from Gamejolt and Itch.

I fixed some bugs, adjusted the spawning patterns and scoring to be fairer to the player, and made some slight graphical and technical improvements.

Here's the complete change list. Cheers!

-Tire damage dealt is now based on the percentage of tire integrity remaining.
-The minimum tire integrity is now 1.
-Tires deflate and wheels start sparking at a tire integrity of 34.
-The tire integrity bar now flashes red when tires deflate.
-New building textures added
-Score at end is now outlined in black.
-Rooftop fences no longer spawn in proximity of tire spikes.
-The spawn rate of sharp objects increases during last 30 seconds.
-The truck now shakes when hitting things.

Bug Fixes:
-Removed developer feature where truck height could be adjusted with the arrow keys (oops)
-The speed of game is now unaffected by frame rate.
-The truck now continues traveling in the correct direction after game ends.
-The game no longer immediately ends if you begin a run within a second of opening the game.

Tuesday, January 9, 2018

Monster Truck Power Fantasy

Here's a new game for ya kiddos: "Monster Truck Power Fantasy." I made it for the 2017 Sekret Santa game jam at Glorious Trainwrecks. My gift recipient asked for a game with a giant monster truck that destroys an entire city, among other things.

So, I made a game about a monster truck. I could describe it further by genre, but why should I? It's a video game about a goddamn monster truck.

I've always been enamored with the idea of music games in the style of James Earl Cox's You Don't Know the Half of It: Fins of the Father. So, I decided to write a song for the game with conventional structure and lyrics, as opposed to an instrumental loop. Imagine Jon Spencer, Sleater-Kinney, Shakey Graves, and the frontman from Arcade Fire getting together and making a baby. A song baby. This is that song.

I was given a month to work on the game, but due to the work on "The Giant Robot Blues," hospitalization, and holiday cheer, I've only had a week to make the game. Three of those days were dedicated to the music. This didn't leave much time for game design.

I'm pretty happy with the results, given the short development period, but a post-jam version with bug fixes is in the works.

You can download the game for Windows from Glorious Trainwrecks for the time being. Release on other platforms is impending. Thanks for playing!

Wednesday, December 27, 2017

The Giant Robot Blues

I am releasing a piece of interactive fiction. It is called "The Giant Robot Blues." You can play it here.

It's a comedic sci-fi tale about a test pilot trapped inside of a giant robot suit that is about to explode. It is also about other things: 70's rock and roll, mass media, secrets, hallucinations, mistakes, laughter, futility, and regret. 

Twine's inception, and the interactive fiction renaissance that followed, have dismantled a lot of my preconceptions about interactive art and how interactive systems can be compelling outside of overcoming challenges, completing objectives, or winning "games." One of the few elements that IF - a medium of text and hyperlinks - shares with conventional videogames is choice. By removing the mechanic of player choice from the tropes of games, and evoking the tropes of literature, I think that IF causes developers and players to re-imagine what kind of experiences digital interactive art can provide.

I've also long admired interactive fictions' accessibility. Contemporary IF can be played on nearly any device with internet access, by nearly anyone who can read, regardless of previous experience with games. This is my first mobile game! The more I make games, the more I am interested in their development into a broadly accessible and artistically diverse medium. So, naturally, I've long been interested in finding inspiration to write a piece of IF with Twine myself. While I previously made a tiny game in an hour with a professor, it was time for me to undergo a serious project. 

The chance came during Artscape last when, when Steven Thomas and I decided to create games for the winners of a high score contest we held during the festival. The winner of the Bloodjak high score contest asked for a text-based comedy about a person trapped inside of a mech, among other criteria.  I was pretty excited about the prompt.

I wanted to be able to evoke the tension that comes with the play of a conventional game, but I didn't want to bring along the skill ceiling that typically accompanies it. I don't want to spoil the experience, but I think was able to achieve this with the systems I put in place.

Despite being a game made for another person, "The Giant Robot Blues" eventually grew into one of the most personal games I've ever made. Inside jokes, previously unrealized project ideas, and experiences and places from Baltimore city all find their way into this little story. I hope you enjoy it!

Wednesday, September 6, 2017

Bloodjak Design Interview

I can't believe I forgot to post this, but last month, Greg Livingston interviewed me about Bloodjak! I talk a bit about procedural difficulty, the game's unusual scoring mechanic, and emotive game design. The discussion gets pretty good, especially after the five minute mark.

It includes game footage from both me and Greg - if you ever wanted to watch me reach 10,000 points and die, here ya go.

It's always wonderful to be given an opportunity to talk about your work. Greg records a ton of great interviews with Baltimore devs and posts many videos on design theory - you can watch them all on his Youtube channel!

Wednesday, August 2, 2017

Artscape's Over; Games Got Patched

screenshot of the finished Underground Arcade launcher program for festival exhibitions
Thank you all so much for stopping by our humble little table at Artscape! It meant a lot to both me and Stephen to see yinz playing our stuff and duking it out for high scores! We're definitely looking forward to showcasing our work at more festivals in the future. If you're looking for more of Stephen's work, you can find it here.

As promised, the winners of the Bloodjak high score competition will have a game made by me - I already have one winner's wishlist and am starting to pump that game out. If, by any chance, you participated in the competition and did not get an email from me, please let me know.

As I prepared the games for festival exhibition, I noticed that all of my games were running slowly on my laptop hardware. I won't go into the technical explanation (sleep margin! *shakes fist*), but Gewgawlicious, The Morphine Western Revenge, Bloodjak, and Digital Toilet World have all been updated and should be running at peak performance on all hardware now.

Furthermore, after the first day of festival, it became immediately clear that Gewgawlicious, the least playtested of my games, was way too long. I've since shortened the game's length by 45 seconds. I also fixed a minor bug in Digital Toilet World in which the android sprites would blur.

After I finish making the prize game (stay tuned!), I should be able to seriously redirect attention to Monsterpunk.