Introduction

Hello there. I am the developer of a game called Outrealm, which released on Steam recently. If you want to check out the game, you can do so here. Welcome to Part 2 of this game Post-Mortem (Part 1 can be found here). This part focuses more on the actual game and the problems and solutions I discovered while developing. Truth be told, at no stage did I ever feel that I had an unsolvable problem or an impossible to implement feature. I did however, have to change some of my developer paradigms as the project ballooned in size.

The Original Concept

Outrealm looked very different when I first started in late March 2017. At the time, I had just played through Breath of the Wild, a fantastic game at the forefront of game design in many ways. I’ve been a fan of the Zelda series for many years, having played and completed every 2D title in the series save for the original. Although my favourite is A Link to the Past, the standout 2D entry in my opinion is Minish Cap, which builds on many of ALTTP’s designs and employs some new original concepts.

My last game was very hit and miss, with some good and bad. It was nowhere near commercially viable, and I failed at executing nearly every good idea I had. So this time, I wanted to do a simple concept and really hit it out of the park. Something I was familiar with. No crazy mechanics or gimmicks, just a solid experience. Something I could show to people. And naturally, I drifted towards Zelda. I had a ton of awesome mechanics in my head, and really wanted to bring them to a game just like the 2D Zeldas. I originally wanted the game to be multiplayer, but decided against it in favour of using Game Maker: Studio. However, I did envision my project would make it to the Nintendo Switch.

I essentially wanted to bring a 2D Zelda to the PC, complete with dungeons, items and the same sense of linearity. The player would be exploring a remote region, dubbed the “Outerlands”. The inhabitants of the world regard it as similar to Runescape’s Wilderness: a long-forgotten world where few travel and fewer return. I drew a map and planned out four areas: A corrupted mushroom forest, a picturesque archipelago of islands, a lonely desert ravaged by sandstorms and a desolate temple with portals to the otherworld. I kept many of these ideas when I later revamped the game.

Combat would be very similar to the GBC Zelda games. I coded sword swings that replicated the GBC Zeldas. Progression would be typical metroidvania, lock and key. I had a Wisp that lit dark places, a Hammer that could smash stones and a Hookshot. I also intended the player to gain access to new sword techniques, some that still remain in Outrealm today. Items were interesting: the player would get random sword drops from enemies. They could hold four weapons, each had durability and a number of uses which was visible. You could also see the weapon’s stats and abilities from the menu. The idea was that you’d churn through many different weapons during play, but perhaps save stronger weapons for a difficult fight. I wanted to improve on Breath of the Wild’s item system and I feel that in some ways, my system was designed better.

Production started. I developed the starting area, and mushroom forest. The first dungeon was dubbed “Corrupted Shrine” and featured crimson-colored, infected monsters, some puzzles, and a few other mechanics that revolved around light. It had four floors, and was your typical, linear Zelda dungeon. Everything was going well, until…

Changing the Concept

I put the project on hold. A close friend of mine who happens to be an artist, wanted to make a game with me. So we switched to that. The new project was in Unreal, and I wanted to learn it. So we did that for a while. Eventually, we switched concepts again: but that also fell through. In early August I felt the need to work on Outerlands again, and loaded up the project. It just felt... off. I could see then that the project was doomed to fail. Scope was way too big. So I thought about how I could condense the experience down in order to get a more manageable scope.

And then it hit me, I could make a Roguelike game. Not a true Roguelike, but something like Risk of Rain. However, I wanted to preserve the combat which already felt good. So I endeavoured to make a top-down version of Risk of Rain. I used Risk of Rain’s scope as a general indicator for my scope, but factoring in that I was only half of their dev team. About six levels, seven playable characters and fifty items. That was my original scope for what would become Outrealm.

I scrapped nearly everything I had, save for some art and design ideas. Concepted a few new worlds: The Realm of Endless rain was inspired by the beginning sequence of ALTTP, as well as Routes 119/120 from Pokemon Ruby/Sapphire. The Poison Wastes were inspired by a few things, such as Runescape’s equivalent, and Mordor from Lord of the Rings. The previous weapon enchantments combined with some of the upgrades, became the start of my fifty items (a number I eventually increased to eighty). I had no idea what to do about the story, but didn’t worry too much. This is when work started on the Outrealm that exists today.

Project Structure and Systems

Outrealm’s overall size and structure are a step up from any project I had previously worked on. This meant that during development, I had to adopt new paradigms. You see, like many developers before me, I got my start in Game Maker from a series of tutorials (Thank you Shaun Spalding!). My previous projects were at their core a few tutorials mashed together, which I would customise, add a few of my own implementations and tada! However, this time I really had to think about project structure.

When you’re dealing with hundreds of different objects/classes, sprites, particles, menus you need to have systems of organisation. You’ll start to forget where you implemented certain features. It will start feeling like you’re reading through code that someone else wrote! It’s one thing to actually be able to code all the features, but managing things is an entirely different beast. Things like just commenting code go a long way to preserving sanity.

Naming conventions are also important. Everything in your project should have a prefix or suffix that denotes what it is. For instance, I use short prefixes. Obj_ is an object. Spr_ is a sprite. Sfx_ is a sound effect. Scr_ is a script/function. This makes it easier to identify and navigate through the elements of your game, identify what they are. Once you’ve been doing this long enough, you’ll start being able to correctly guess. What did I name that blue slime enemy? Obj_blueslime, of course!

Next, I had to start thinking in terms of systems. I had a guy slashing in less than an hour, but that doesn’t matter: what I really needed was a combat system. Outrealm has a Combat system, an Inventory System, a Layering System, an Audio system… even a Pause system! The majority of Outrealm is divided into these systems. This makes it mentally much easier to keep a grasp on the project. Let’s say I’m trying to fix an audio bug. Instead of using an unwieldly search system or having to remember where I wrote the functionality, I can dive straight into my audio system. Which is neatly commented, so it only takes me around 30 seconds to find the faulty line.

Designing the worlds

When I set about designing Outrealm’s worlds, I really didn’t have anything specific in mind. However, I wanted to create a few environments atypical of other games. The Mushroom Temple was inspired by Final Fantasy Crystal Chronicles, and I loved the concept from the beginning. I got the “Corrupted” idea from the Metroid series, another one of my favourites. It's my favourite realm to this day!

The Poison Wastes were another idea of mine. I wanted to take the player to a place thoroughly inhospitable, a place that felt really alien. I got the base idea from Runescape, but wanted the place to feel more alien. So I took inspiration from Dragon Ball Z, specifically the planet Namek, and gave the place some much-needed plant life.

The other areas were more or less straightforward. Ice Area, Desert Area, Forest Area. The final realm was also more or less generic. Art is not my forte, but I do feel that the environmental art is probably the best art in Outrealm. The major difference between this and my previous project’s art, was my use of colour. Seriously! Colour is everything in pixel art! For the most part, I made good use of colour within Outrealm.

Designing the characters

I wanted seven characters, each with their own unique playstyle, abilities, look. Now I’m not an artist by any stretch, but your boy here knows a trick or two about character design. Like I mentioned before, it’s all about colour. The best designs all use 2-3 primary colours, no more, no less. I could name any character in Overwatch and you can already see the colours. So I set about giving each character their own little palette. The characters themselves are tiny, thanks to me being gross at doing anything bigger. I tried to accentuate their designs a bit and hopefully, the difference in colour would help them to pop out a bit on the levels.

The first character I designed was the Bladesman. I thought him to be somewhat like Aragorn from Lord of the Rings, a loner who travels the wilds of the world. That’s why I made him green and brown. I wanted him to play just like Link from the 2D Zelda games. I gave him a simple, well-rounded kit and moved on.

After making the Lancer and the Berserker, I noticed that all three were quite similar. This is because they used the same basic attack pattern. But that attack pattern was also quite fun, and my modifications just didn’t feel quite as fun. Instead, I tried to work around the problem by making them rely on their other abilities. Take the Lancer for instance. I took inspiration from Overwatch’s Genji, and added a reset mechanic to his dash. Then I looked to Super Smash Bros. Melee’s Marth, and granted him a “Tipper” mechanic. I also changed Crescent Moon to have a different hitbox to Whirlwind.

The Smasher was based on the Ball ‘n’ Chain trooper seen near the start of ALTTP. I always liked his design, and felt he could make a really fun character. I loaded him with powerful attacks, and when it came to sound, gave him powerful impacts. Another of my favourites is the Boreal Hunter. Her playstyle is inspired from the Sniper class from Maplestory. She freezes foes, and then eliminates them with a hammer. Getting that combo is really satisfying! The last character I designed was the Aureola. I was tired of doing humanoid characters, and wanted to do something a little different (It was also a lot easier to design the character’s look...). Although I was lazy in the beginning, I am proud of how that character turned out. The huge beam attack was inspired by One Piece’s Franky, and I wanted it to feel like a deft, agile fighter.

Designing the enemies

This was the part I dreaded the most, and feared from the moment I had resolved to make this game. I really hate drawing enemies, and I am not good at it. If I could outsource one thing from this project (aside from marketing) it would be this. I took inspiration from Zelda games, and made some basic RPG enemies. Slimes, Giant worms, Flying eyeballs, Animated rocks. Mushrooms, Bats. I also recoloured quite a few enemies. I really do wish I had spent more time in this area in hindsight, as I think the game would be genuinely improved with more interesting enemy designs. I do feel that I dropped the ball a bit with bosses, too. It was hard to design mechanics around all seven characters, and they were the hardest things to draw in the whole game, being so big.

Even now, I feel that the enemies are a bit of a weak spot for Outrealm. There aren’t too many variations, AI is very basic, and for the most part, they just zombie towards the player character. Part of this is because Outrealm is about mowing through truckloads of them, so I didn’t feel like I could make them too advanced. However looking back on things, surely I could’ve done something to spice them up a bit.

The Urgency Problem

Early in development, combat was fun but lacked any sense of urgency. There was little motivation for the player to try and keep moving forward within the game. I made several attempts at fixing this design problem.

Attempt one, introduce a currency into the game. Silver pieces were dropped from enemies and could be used to open treasure chests in order to receive items. Therefore, players would have to fight many enemies quickly in order to loot more items. This was by far the most flawed solution, and didn’t really fix anything. Players could take their time and farm up if needed. It also meant that player’s progression through levels was awkward, with a lot of backtracking needed.

What I needed, was a way to put a timer on the game. My next idea involved having your health slowly drain downward. Health was restored by defeating enemies. Additionally, opening chests would now cost a percentage of health. I was very satisfied with this solution at first, as it meant that players would have to keep fighting. It also added an opportunity cost to opening chests. I ran with this for a month or two before scrapping it. In practice this system had flaws. First of all, it punished map exploration heavily. Secondly, despite the health cost it was nearly always better to open chests. Next, the fact that chests were random robbed most of the meaning out of the decision. Players would have to loot every chest to have a chance, and would be at the complete mercy of the RNG. And finally, depending on what items you did get, much of the game’s urgency could be mitigated. This was not the best solution.

So I decided to take a leaf out of Risk of Rain’s book, and have enemies become stronger as time goes on. To complement this, I increased the amount of item chests in the game, and spread them around the map more. This means you’ll have to be mindful of how much time is spent looting, as you’ll have a timer keeping your honest. I added different colour health bars to the enemies to represent their stronger versions, and a timer to show just how long it would take for them to be buffed. Urgency was solved!

The Item Problem

Solving the above problem revealed another, however. There are many different types of items in Outrealm, each with different types of effects. Many are designed to synergise well with certain characters or other items. However because the chests were random, there was no real strategic element to item builds. It was just “pray you get good stuff”. And since players had no control over it, they also had no reason to care. Most people who played did not read the items descriptions or pay attention to what they picked up.

I had to find a way to give players some strategic control, and a reason to care about what they were getting. In the end I found an elegant solution: Simply letting them choose between two items every time they open a chest. This gives them a degree of limited control, enough that they feel invested in the decision, but still mostly at the mercy of RNG. Also, by presenting the details for both items before the choice is made, players would actually stop and read the descriptions. While the choice is being made, the enemy buff timer stops. This means they don’t feel rushed and can enjoy agonising over the decision if they desire.

The Sprite Tearing Problem

About four months into development, I decided to do some testing on a few different PC’s. I was not expecting much, as Outrealm is pretty low-spec. However, on every computer with an nVidia GPU, I experienced very noticeable sprite tearing. And I had no idea how to fix it. Quite a bit of time was spent on this issue, and no to avail. Many people had also encountered the same problem while using Gamemaker. Sprite rounding on sheets was the issue, as the camera was moving in sub-pixel increments. When the camera moves in subpixel increments, the game can become confused about rendering certain pixels, and so it will appear as a tear.

The solution though, was stranger than I could’ve imagined. I was messing around with the resolution and first noticed that more tearing occured on aberrant resolutions. I thought to myself, perhaps there is a certain resolution which could prevent the issue. I did not find any such setting, but I did notice that after switching FROM 1440x900, the next resolution, provided it was a divisor of 8, would not have the tearing. 1920x1080 could have the tearing, for instance. If I switched to 1440x900 and back to 1920x1080, then the tearing would be gone. I have no idea why this works, but it turned out to be very consistent. On rare occasions, the tearing can appear in some specific spots, but that’s about it.

Getting the right feedback

Another problem I experienced was getting the right sort of feedback when executing playtests of my game. I got many different kinds of people to play, and noticed that each would err towards a type of feedback. What I found was that most people are not good at giving feedback. Almost nobody will decline to give it, but you have to be mindful of who says what. You can’t treat all feedback the same, as all feedback is NOT the same. For instance if you give your game to a Game Designer and they comment on a gameplay mechanic, you should probably note that down. But take what they say about Art with a grain of salt unless you know they’re proficient in it.

“Unskilled” testers, or testers who aren’t a part of the game industry must have their feedback held in a completely different light. You should definitely listen to what they have to say about ease-of-use and general impression. The good feedback that they do give, will happen without them realising it. My item problem was revealed through testing, but nobody said or gave any direct feedback on the issue. I had to pay attention and pick up things on my own.

“The game is fun”.

“the graphics are good.”

“I like the music on this level.”

“How do I beat the level?”.

Only the last statement has real value in it: They are telling you that your game’s objective is difficult to understand, which can probably be rectified with a better tutorial. “Your game would be better with more X (content)” was probably the most worthless and common feedback I heard. X could be enemies, levels, bosses, characters, anything. It’s a worthless statement because it could be applied to nearly any game on the planet.

Cross-referencing feedback is very important. If multiple people are saying the same thing, it’s probably worthy of being looked at. I had multiple instances where an unskilled tester would be very adamant about a particular piece of feedback. However in all of those cases, that tester was the only person to mention it. If only one unskilled tester mentions something, chances are it can be thrown out.

It’s an unfortunate reality that you also can’t take on board everything that everyone says. I’d highly recommend avoiding testers who wouldn't normally play the sort of game you’re developing. They’ll be more clued in about the genre and have the right sort of expectations for your game. If your game is missing something that many games in the genre have, they will know about it.

Story and Narrative

Remember earlier on when I said that I left story for later? This ended up screwing me over in a big way, as I found myself nearing the end of development with absolutely no idea what I would do in terms of story. I had already designed all of the enemies, characters and worlds. Instead of designing these elements around the story, I was forced to come up with a story that made sense of what I had already created. Outrealm's story is weak because of this, and it's one of the weakest areas of the game.

It's much easier to do things the other way around. The real mistake I made though, was procrastination. The reason I put of developing Outrealm's story was because it was hard, and doing other stuff was easier. I put it off to the point where it became an unreconcilable monster. This also hurt me when I approached publishers with the game. Many commented asking "What's so special about Outrealm?". I couldn't answer them, and I would've loved to have said something story-related. It's a genuine missed opportunity that I couldn't see until it was too late.

In order to make sense of what I had already created, I had the story be about travelling through the mind of some great beast. It's cheap, nasty and I'm genuinely ashamed of it. I tried to make up for this in the Item and Monster logs. I set out to give each item an interesting backstory and do feel that I achieved a relative level of success there.

The Finale

Late December, I was finishing up the OST and felt ready to release soon. I wasn't really all that happy with it, as I had just gone through the act of putting in the meager story elements mentioned above. However I attended a new years party with Outrealm's trailer on my phone. When I showed people, they fell in love with it. "It looks so fun!" "When is it coming out!"

Of course, all I could see was the game's flaws (cleverly hidden in the trailer, of course). But it felt good to have people appreciate what I had created. So I gave myself one more month. And that month turned out to be one of the most productive in my life. I fixed up countless small, nagging things that had always annoyed me. At the end of the month, my attitude had completely reversed. I finally felt a measure of pride for what I had created. This is covered in more detail in the previous installment.

So February 6th came and went, and Outrealm released. There is a great feeling of relief in finally finishing a project, nay, a product. It's extremely scary putting yourself out there, especially when you are asking for money. My advice? Get it over with ASAP. Put a low-scope, polished project out for a few bucks and experience the rollercoaster ride of emotions for yourself.

If you've read this far (it's even longer than Part 1!) then, thank you! I will certainly be doing Post-Mortems here from now into the future. However, I'll probably focus more on the content in Part 1 in future. Hopefully, I'll see you on the next project!