Thursday, December 27, 2018
Danger Zone Friends Trailer
Danger Zone Friends is going to be out soon! What does that mean? I don't know!
In any case, here's the game's trailer! You may seen a bunch of screenshots by now, but I am fairly proud of the animation work, and especially proud of the music composition and sound design, so I'm very excited to finally show just a little bit of that off!
As for the game itself, it just needs a tad more tweaking. I've spent the past couple of months refining the game's balance, tutorialization, and user experience, and I'm completely done with that!
Finally, a quick note while I'm here: I've boasted in-person and online that a playthrough of the game takes about 3-7 hours. To improve the game's pacing, I recently decided to reduce the enemy encounter rate, which brings typical playtime closer to 2-4 hours. It was for the best to trim that excess fat and better focus the core experience. My apologies to anyone expecting an epic, but the game is better this way, and it is still freakishly huge for a solo effort. I am continuously excited to share this project with the world; thanks for watching!
Thursday, November 1, 2018
Danger Zone Friends & Other News
Announcing: Danger Zone Friends!
Spoiler alert - it is. |
This is, undoubtedly, my greatest game to date, featuring some of the best encounter design, art, storytelling, comedy, and music I've ever produced. 3-6 hours of playtime, 20 minutes of original music, over 25 enemy types, so on and so forth. It's been an undertaking.
This game was originally made for my girlfriend, who asked for a "cute game" for her birthday with animal characters. She plays a fair amount of Persona and Pokemon, so I thought she would appreciate a *cough* short JRPG. As a supposedly casual project, it seemed like a good excuse to dust off the copy of RPG Maker VX Ace I got in a humble bundle a while back, and just have fun making something without having to code original mechanics from scratch. Many of my favorite RPGs of all time - Off, Embric of Wulfhammer's Castle, and Space Funeral - were vanilla RPG Maker games created without a lick of original code. It felt like a rite of passage to produce my own RPG within the (very limiting) constraints of the tool. A lot of folks question the legitimacy of RPG Maker as a development suite, and while I know it was the right tool for the job, I still feel self-conscious about using it. At the end of the day, though, you can't argue with the results.
Despite my aspirations for this to be a tiny, casual, and sloppy game, it quickly turned into a serious endeavor. It became clear, after I had drawn, written, and programmed the initial cutscene that I was onto something special. I started development in June, missed my girlfriend's July birthday deadline, and continued to work for the following three months, pushing myself to push myself as an artist, composer, and writer.
As this game was made for my girlfriend, it includes a number of elements - inside jokes and scenarios - that will only truly be understood by the two of us, making this the most personal, expressive, heartfelt game I've made, strangely enough. However, the game should be just as enjoyable for the rest of you. Remove the insider knowledge, and what remains is an unusual story filled with non-sequitur humor.
But if you didn't know that about Astrodon Johnstoni, that's okay. |
Despite having the same core battle system as nearly every other RPG Maker game, I attempt to make combat in Danger Zone Friends deeper than in other games in its genre. |
Anyway, the most important thing is, I love Danger Zone Friends, and I hope you will too!
Updates to Monster Truck Power Fantasy and Bloodjak!
In other news, both Monster Truck Power Fantasy and Bloodjak have gotten patched! There's minor bug fixes with both, but the largest changes are that Monster Truck Power Fantasy now has a subtitle option, and Bloodjak now runs at a constant speed, regardless of its framerate. These were mostly made to address technical issues when showcasing the games live, but for those of you who are hard of hearing, hopefully the subtitles allow for you to better enjoy Power Fantasy.
Baltimore Game Collective: Now Featuring John D. Moore!
Tomorrow night, Stephen and I from Baltimore Game Collective will be showcasing our collection of work at Colorspace Labs' First Friday Indie Arcade in Philadelphia! What's new this time around is that we'll also be showcasing some games by our newest member, John D. Moore. John is a prolific developer whose diverse creative output spans over two decades. We'll be featuring three games of his this time around: Monster Hug, Dr. Creepinscare's Pumpkin Patch Match, and Ungrateful Birds. Happy to have you on board, John!
That's all for now. Please stay tuned for the release of Danger Zone Friends later this month.
Monday, July 23, 2018
Festival Debrief
Photo Cred: Christian Lumsden |
I want to give a shout out to our amazing players who stopped by! I'm often astounded by the tenacity of those who compete in our high score competition, but I've never before seen a feud between two players develop over the course of a long weekend. Thanks to Jordyn and my friend Dom for providing an intense Monster Truck Power Fantasy rivalry, and to Jordyn's stepbrother Mike for causing the greatest high score competition upset in Underground Arcade history, making a flawless run just three minutes before close, shutting out his rivals. I yelled a little bit.
446 buildings destroyed with perfect tires. Who does that? |
The complete list of top scorers by 7:00 on Sunday is as follows:
- Bloodjak: Jordan: 3926
- Mutant Highway: Caleb: 1483
- Monster Truck Power Fantasy: Mike: 44,600
- Fungilluminati: William: 13,230
- Diablow: Calvin: 15,505
Congratulations!
Some of you reading this may be looking for my colleague Stephen's work: it can be found at let-off.com. All of my games can be found by clicking the "games" tab at the top of the page (or, don't even scroll up, let me make it easy for you). Some of you may want to download a certain song about a Monster Truck; you can get that off of my soundcloud.
Stephen is continuing to work hard on Diablow. Meanwhile, I'll be releasing a secret mini-RPG in the coming month before resuming work on my running project, Monsterpunk.
We're looking forward to seeing y'all again! Much love.
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.
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.
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.
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.
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 a jerk (I am so, so sorry). I was irritated 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 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 care 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.
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.
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.
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.
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.
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.
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.
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?" 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.
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:
Been working on a game on-and-off since 2014, opened and played it after a year hiatus with fresh eyes, it's two hours long, now I realize only about 15 minutes of it are good.— Alex Higgins (@alchiggins) January 23, 2018
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 a jerk (I am so, so sorry). I was irritated 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 care 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 freakin' 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?" 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.
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.
Labels:
bloodjak,
digital toilet world,
gewgawlicious,
monster truck power fantasy,
morphineWestern,
my games,
ramblings
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!
v1.1
Features:
-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.
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!
v1.1
Features:
-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!
Subscribe to:
Posts (Atom)