Saturday, December 17, 2016

The Morphine Western Revenge v1.0

The Morphine Western Revenge is done. You can play it on Gamejolt or Windows users should download the desktop build of the game for the best experience. For everyone else, you can play the game in your web browser. You will need a mouse to play it.

The game's soundtrack is available here, and the game's source material, The Hyperbolic Needle by Brian Cristi, can be read for free here.

Please report bugs and provide additional feedback! I want to make sure my games are enjoyable to as many people as possible, and to do that, I need your help! As it stands, I may need to make the game's easier difficulty settings a bit more forgiving - how I do that depends on audience response.

Thank you for playing! I hope you enjoy it. Tell your friends about it! Tell your parents about it! Tell your electors about it!

Now that all of those formalities are out of the way, here's how I feel about all of this.


Gosh, Feelings

First of all, I am damn proud of this project. It's the most substantial game I've released, ever. Typical playthroughs will last anywhere between thirty minutes and two hours. The game represents my best work in terms of mechanics, design, engineering, style, and musical composition. My adaption of the original story is probably the game's weakest point, but the gunplay is more than good enough to carry the experience.

However, if you've talked to me about games, or have been reading the blog for a while, then you know I have a complicated relationship with shooters. Shooter games are a foundational part of who I am as a player and maker of games. I grew up on the internet driving Scorpion tanks across the icy fields of Sidewinder and blasting away with my scattergun in the Gravel Pit. As a teenager, video games were shooter games. I played the occasional RPG, and as I got older, I started becoming interested in experimental and narratively-driven work, but I've been playing, thinking about, and designing shooters for longer than I've done anything else in games. It's my primary design inclination. More than half of the games I've finished over the past seven years are shooter games.

Making art-games, not-games, alt-games, walking-simulators, narratively-driven games, or whatever you want to call them is not hard to do, but making good ones in a short period of time is.When I originally volunteered to make The Morphine Western Revenge, I was expected to complete the game in a month. So, I chose to work in the genre I was most comfortable with - the shooter. Had I known it would have taken me 10 months to complete the project, I probably would not have made an action game.

I fundamentally believe that video games are capable of exploring the vast breadth of human experience beyond strife and competition, and that the traditional core genres - shooter, strategy, RPG - are not going to be the future of the medium. While Revenge is very much a traditional action games, perhaps even to a fault, it does, at least, tell the story of a marginalized person and how she copes with loss and oppression. The game is also stylish and weird. "Well, uh, that was very indie," one of my playtesters told me when he had finished. The game walks a fine line between being a conventional shooter, and being this weird piece of wonderfully trashy software, but it still leans closer to convention than I would like.

I'm not sure of what interest these thoughts are to the typical reader, but this game has more or less consumed me for most of the past year. It's caused me to constantly reflect on who I want to be as a creative person, what sort of work I want to create. In the current political climate, these questions become of greater relevance.

Overall, my pride about this project overcomes my ambivalence. No matter how complicated my feelings about the project are, this is undoubtedly my greatest achievement as a game designer.

Technical Lessons

While I've ported old games of mine into HTML5, this was the first major project where I've developed desktop and web versions of a game simultaneously (I previously did the same with a short game joke game I made for my sister, but that project was not technically demanding). The Windows version of the game is superior than the web version for countless reasons, so when it can time to test the game, I almost exclusively tested the desktop version. I did this because I was lazy.

Game Maker: Studio, the program I used to develop Revenge, bugs the hell out whenever you try to export a game into HTML5. As in, sometimes I would compile the game and it would look like this:

This is supposed to be a cave. Instead it is A MONSTER.

Squashing the unique bugs that expressed themselves in the game's web build was enough of a challenge. But the web version also experienced performance issues that I didn't discover until late in development. A level that ran smoothly on the desktop (with, say, 70 bad guys in it) just had too much stuff in it to run smoothly online (the level would now slow down if you had more than 40 bad guys in it).

Usually, when I encounter performance issues in games, my inclination is simply to put less stuff in it, rather than engineer things more intelligently. But since I already designed the game around having lots of stuff in it, I needed to actually confront the issue.

I'm not going to bore you with the details, but by the end of development, I managed to optimize the game in ways I thought were impossible. One raycasting script that drew a straight line between the player and the closest object in front of them (which can sometimes be expensive to do every frame with any precision!) became 32 times more efficient. The number of enemies a level could support at a time doubled. Dust and rain effects automatically downgraded in quality as framerate dropped. I was able to deliver my vision on a technical level with little sacrifice, and it feels good.

Design Lessons (why the game works)

What surprised me most as I watched folks playtest the game was the sheer number of valid and creative solutions they found to solve the problems I presented them with. In the canyon level, the player comes across a group of a dozen riflemen. "I can't outgun them," the player character says. "I'll have to be clever."

Most of my playtesters solved the problem as intended. Except for one. "Nah, I'm going to outgun them."

He died a half dozen times, and it took him twenty minutes, but god damn, did he keep his word.

I was worried that the game, overall, was going to be a homogeneous experience. Limited to human opponents, 19th century weaponry, and natural environments, creating a diverse variety of game elements was a challenge. All of the baddies in the game use variations of the exact same AI, all of the weapons are slow firing, and I couldn't use moving platforms, locked doors, or other interactive elements in the level design. In retrospect, these limitations allowed me to hyper-focus on creating very specific and deliberate differences between each enemy and weapon, not only to create chemistry among all of them, but also varied and emergent gameplay.

For example, there are essentially 4 classes of enemies: revolver guys, shotgun guys, rifle guys, and big guys. Revolver guys are the game's fodder - not too dangerous at close range, less dangerous at long range, and easy to kill. Shogun guys are highly dangerous at close range, but nearly harmless at long range. Rifle guys are fairly dangerous at all ranges. Shotgun, rifle guys, and revolver guys are all similarly fragile. Big guys, on the other hand, can absorb inhuman amounts of damage from the player.

With this palette of enemies to choose from, you can create a surprising variety of enemy encounters. Shotgun guys can be safely fought at a distance in the open without cover... unless there's a rifle guy sniping at you from the corner. You can pick off a group of enemies one at a time with your rifle... unless there's a big guy leading the charge, protecting the men behind him with his bulging muscles. So on and so forth.

Furthermore, the overall design of the game itself lends itself to emergent gameplay. If you're stealthy, you can avoid the gaze of enemies and take them out from behind, undetected. If you fail, you can then pop in and out of cover, taking them out one at a time. If you fail again, you can run and hide, heal yourself, and run back into the fray. Or, you can run and hide, have your enemies lose sight of you, and then try to use stealth again.

Essentially, no matter what choices the player makes, no matter what mistakes they make, they always have an alternate method of solving a problem available to them. Not only that, but the player is unable to immediately repeat their previous strategy, forcing them to adopt varied techniques. Here's a visualization of how the game works:

At the beginning of an encounter with bad guys, the player can choose to 1) sneak or stealthily dispatch them, 2) use brute force, or 3) run away from them. If any of these strategies fail, they cycle to the next strategy. Repeat until the encounter is won or avoided. This is why the game works. This, I suspect, is what makes it fun.
From an aesthetic design perspective, I wanted to make the game's world feel as tangible as possible, especially since the game's levels are otherwise as static and dead as they are. To do this, I tried to animate and add sound to every physical interaction in the game I could think of. No matter what the player is doing, the world is responding. Dust clouds form as the players boots rapidly thud against the ground. Shotgun shells fly out of your weapon and litter the ground. So on and so forth. I tried to make it so that something interesting is always happening on screen and in the player's ears, and to a large extent, I think I did well.

If I have any regrets about the design of the game, it's that it expects the player to learn too much too quickly. While I was very conscious of the game's tutorialization (40% of the game is tutorial levels, whether the player is aware of it or not), I guide the player through the tutorial a bit too quickly. I explain a mechanic once, have them execute it, and then move on to the next one. I probably could have spent a little more time having players learn each individual rule of the game.

That said, I think I did some good damn work this year. As excited as I've been to release this piece of software for it's own sake, I'm even more excited to move on and do something radically different - games that are more peaceful, more experimental, and that tell stories I can be proud of. And, on a similar note, Monsterpunk development will resume soon.

Thanks for playing, thanks for reading, happy holidays.

No comments:

Post a Comment