Post Mortem

Reflections on what went wrong during a development.

This past weekend I participated in the 30th Ludum Dare 48-hour competition and created Fusebox, an energy management simulation game. What follows is a summary of my experiences creating it, and what I learned from doing so. I had a lot stacked against me, and while I missed some milestones that would have taken the game from mediocre to great, I think that I did really well considering the situation. Before we can assess that though, we have to start from the beginning.

Sure-footed as a Mountain Goat

One week before the Ludum Dare competition started, I was at the local rock gym with a friend of mine. They had more than just rock walls there, and in my first (and most likely last) attempt at this whole slack-lining thing, I fell and landed sideways on my foot. It instantly swelled up to the size of a potato, and I haven’t been able to walk properly since. I have made a pretty decent recovery so far, but one thing I can’t do is sit up. If my foot isn’t elevated above my head, it swells back up like a balloon and becomes incredibly painful. Since working on a computer with any amount of comfort necessitates putting your feet beneath the desk, I wasn’t sure how it would turn out.

This is what you get for hanging out with extroverted adrenaline junkies.

This is what you get for hanging out with extroverted adrenaline junkies.

Over the course of the weekend, my foot turned out to be both more and less of a problem than I expected. By lowering my chair, throwing a pillow on my desk, and leaning back, I could actually sit somewhat comfortably for more than an hour at my desk. It required me to be a bit twisted, and it probably wasn’t good for my back, but I was actually able to sit at the computer. Had this not been possible, I had a backup plan of writing a game in javascript from my laptop, since it can’t run Unity. In retrospect, I probably should have gone that route, but I really wanted to try this out with Unity, so I suffered through.

The downside to this was that I couldn’t get into a position that was ideal for either my foot or for writing code. I was at least slightly uncomfortable the entire time, and several times throughout the weekend I had to stop and move to the couch to give my foot a proper rest. This had two side effects. The first was that I lost a lot of development time to laying on the couch with my foot on the back. The second was that in order to try and take advantage of this time I brought my notepad and did as much design and planning as I could while I was away from the computer. This is probably the main reason the game is so complicated and over-engineered.

This is the first time I've taken hand-written notes in years. I had to use one of those weird scratchy tube things to scrape my thoughts in stone.

This is the first time I’ve taken hand-written notes in years. I had to use one of those weird scratchy tube things to scrape my thoughts in stone.

What is it Even Uniting?

One of the main reasons I do these competitions is to force myself to try something new. I’ve used new engines, tools, or frameworks every time, and I’ve never made a game in a genre that I’ve done before. It’s a great way to learn a lot in a very short amount of time, and when you’ve been programming for a length of time measured in decades, it’s not a stretch to try and figure something out in that time frame. Since my current game project is in Unity, and I’ve been struggling with it since day, I decided that I would force myself to figure out and use Unity for this competition. In retrospect, I’m glad that I did, but it definitely slowed me down quite a bit.

I also chose to do a very UI-intensive project this time around, for a couple of a reasons. I felt that my foot might get in the way, and I wanted something I could work on from the couch if the need arose. I also know that I hate writing interface code, mostly due to the fact that I’m not very good at designing interfaces, and I find the whole thing very tedious. I may have been setting myself up for failure here, but the goal was never to win the competition. In all of the work I’ve done on Project Dunwich, I have not even touched the interface yet. At one point I actually had to look up how to make a button. I was starting from scratch here.

So... Much... UI Code...

So… Much… UI Code…

The Thought

Despite using tools and techniques I was unfamiliar with, and dealing with Quato growing on my foot, I felt pretty good going into the competition. I had read through the list of themes, and I focused my thoughts on the highest rated candidates from the first four days of voting. This is by no means a fool-proof method of predicting the winner, and I wasn’t writing any code or committing anything to paper, just idly thinking about the design possibilities. I ran through some ideas while I went about my day, and initially I wanted to make something with more action, since my last two attempts sort of fell flat in that regard. Most of the ideas I thought of with any amount of action seemed either too obvious, or not connected enough to the theme, and UI was another focus area, so I settled for a management sim game.

Once the theme was actually announced, I was a bit relieved that the top theme won out, since it meant I already at least knew what genre of game I would make for it. The idea was simple, connect worlds together through some interface, but give those worlds multiple, intricate layers of connection. I like to make my games hit the theme in multiple ways, and that satisfied that requirement. Connecting worlds to an energy source was the obvious take on the theme, but having them be linked to each other as well added a nice extra layer of depth to the interpretation. I’m not sure any ever notices these little touches, but it makes me feel better about my interpretations.

I'm really happy with how the planet rendering turned out. It's a shame I never got a chance to make that interface actually useful though.

I’m really happy with how the planet rendering turned out. It’s a shame I never got a chance to make that interface actually useful though.

The Look

I immediately started with graphics, since I didn’t think there would be very many, and I wanted to get it out of the way. I drew up a mock interface, some icons for the planet stats, and some graphics for the planets themselves, and actually had something passable by the end of the first night. I have used Inkscape quite a bit over the past few months, but I had never done clouds or noise in it, so that was a fun little challenge to overcome. In the end, I spent less than four hours total on graphics, and I’m glad I didn’t have to fight with them at all once I got into the interface code.

With graphics in hand, I set to create the game objects and renderers that would use them to actually put the images on screen. Unity actually made this really easy, though I have no idea if the setup I used is proper for an entity-component system. Since most of the game objects were just data containers, that didn’t take very long, and well before the half-way mark, all I had left was to write the code to process the interactions on the game objects, and then do a whole lot of UI work. After a brief stint on the couch to rest my foot, I started in on the UI.

It is a damn good thing I don't have to actually draw interfaces. I drew it and I can't even tell what's going on in some spots.

It is a damn good thing I don’t have to actually draw interfaces. I drew it and I can’t even tell what’s going on in some spots.

As I mentioned earlier, I had no idea how to approach the interface. I created things using GUIText and GUITextures, I switched to converting screen coordinates to world coordinates and driving the UI with game objects, and eventually discovered the OnGUI method and settled on using that. Throughout the course of the day on Saturday I created as many interfaces as I could, to enable interaction with the game objects. I could just as easily have started by coding that all into the setup and working on the simulation, but that seemed like it would be harder to iterate on. Once I learned how to make the interfaces, it was a pretty smooth ride of create, test for usability, modify, repeat. I didn’t do things in a very efficient way, there’s a lot of copy/pasted code for UI stuff, but I just kind of zoned out and started writing.

The Logic

By the end of Saturday, I had about half of the interface done, and none of the game logic. That seemed like a bad situation to be in, so I set out to right that first thing on Sunday. Since I had spent a fair amount of couch time writing out notes on how I wanted it to work, that actually went pretty fast. The logic is pretty complicated, there are a lot of moving parts that determine how the hardware will react, and how the planets will respond to their situations. The biggest problem with all of that is that I couldn’t get the interfaces done in time to actually explain all of that to the player.

My half-baked attempt at a tutorial. The best part is that I didn't even get to implement some of the stuff I explained in here. Super useful.

My half-baked attempt at a tutorial. The best part is that I didn’t even get to implement some of the stuff I explained in here. Super useful.

The final interfaces were the ones that told you what was going to happen when you advanced the day, and the one that you manage your circuit board. You know, where you actually play the game. I knew what needed to be done, but by Sunday my foot was in open revolt against me. I spent a lot of that final day on the couch resting, and with nothing to plan, I just sat there mentally writing interface code to draw out how I wanted it to look. The funny thing about mentally writing out code, is that it’s a completely useless activity. When I felt good enough to try and implement it, everything fell apart on me. I had planned on whipping up those last two screens and then playtesting the game for bugs and balance. What ended up happening was a mad dash to get the interfaces working that ended about 15 minutes before the deadline.

At Least I Finished… Sort Of

I decided that I was done, and 15 minutes wasn’t enough time to get any of the last things I needed from where they were to where they needed to be to even be passable. I set to build my project and upload, and then Unity decided to remind me why I hate it so much. Apparently the method I was using to color the planets with HSV colors was only available when you ran the game through the editor. It wouldn’t even compile. Fortunately, HSV to RGB implementations are a easy to code, so I started throwing one together. In the past I’ve worked on them with hue being an angle from 0 to 360. Unity’s method had it as a float from 0 to 1. No sweat I thought, I’ll just multiply it by 255. If that doesn’t make sense to you, it’s because it shouldn’t. All of the planets turned green because I mixed up angles with rgb values, but I didn’t have time to figure out why. Up it went, and just like that it was all over.

I’m glad that I made the choices I did. I learned more about unity and its UI features in this past weekend than I have in the past four months. Sure, I could have scrapped the planet interface and focused more on good UI, and I probably would have been better off spending time on tutorials rather than tweaking button positions. Given the constraints I was working under, I’m really happy with how things turned out. I do have some ideas for how to improve next time though.

  • Simple design with good balance – I had so much time away from the computer that my end product was as overly complicated mess, and there’s really no way for the average player to figure out what’s going on. Having a more simple design with a better balance would have been a better approach. Instead of having four types of compatibility and a two-hundred line calculation for fuse load, cut it down to two stats and spend more time on making sure the numbers work out over the course of the game.
  • Interaction before eye candy – My planets look way better than they need to for a game that is mainly driven by button clicks. If I had put that off until the end, I would have been able to see that before wasting time on them, and I might have had time to implement things like a proper tutorial or a win condition.
  • Playtest as early as possible – I put the core logic off for so long, that by the time I had it finished, I was already in crunch mode. This left me no time to make sure the numbers worked out, or that the game was even fun. With a game like this there’s really no excuse, I could have had unit tests written to test out the formulas and algorithms through all 100 days by Saturday morning if I had prioritized it. Good balance is going to be my main goal for next time.

That about covers it. I had a good time, and in the end I have another game to throw on the website and say “look what I can do in a weekend.” No matter how bad I do, or how stressful it is, that sense of accomplishment will always be worth it.

For those that don’t know, Ludum Dare 29 went down this past weekend. Ludum Dare is two events. One is a competition in which solo entrants make a game from scratch in 48 hours, the other is mostly the same, with relaxed rules on time, team size, and preexisting graphics. I threw my hat into the ring for the second time as a solo entrant in the 48-hour competition, and here is a breakdown of how it all went developing my entry Darkness Shines Through. I realize this is a bit late, but it’s been a hectic week for me, and I didn’t have the time or the drive to do this until today. Ludum Dare takes a lot out of me, and trying to rate a large number of games to get widespread exposure is almost more work than making the game in the first place. Almost.

Man against machine

If you’ve followed this blog at all, you know I’ve been making games for a long, long time, as a hobby. I was content to put my prototypes out to my friends and family and leave it at that. A while back that all changed, and I decided to try and go public with my work. After making a moderately popular Minecraft mod that took almost two years to write, I decided to go much smaller scale to save my sanity and have a better chance at finishing something cohesive. I tried to make an RPG, but I bit off a bit more than I could chew at the time, and when Ludum Dare 27 came around, I decided I would give it a go. I’ve always thought it was a fun idea, and that seemed as good a time as any to give it a try. It went pretty well, I turned that game into my first commercial product and earned my first dollars through making games. The feeling was incredible, though the project was a bit underwhelming as it didn’t exactly target the broadest of audiences. I finished up the final touches on the last patch for that game a mere week before this round started; the timing couldn’t have been better.

About a week before the contest started, I decided I was going to try and use Unity this time around. Despite the few hiccups I ran into, I largely enjoyed my experience with LibGDX, but I would like to branch out into the console market, and Unity provides me an easy way to do that while still making small PC games in the interim. I only had a few days to try and learn how to use Unity, and that simply wasn’t enough time. I’m a programmer, I write code, it’s what I like to do, it’s how my brain works. I was not able to easily adapt to the much-more-visual style of development that Unity presents, so at the last minute I scrapped the idea and went back to LibGDX.

LibGDX is like my fried chicken. It's not what I wanted to be eating, but it's so tasty. Photo by beketchai via Flickr

LibGDX is like my fried chicken. It’s not what I wanted to be eating, but it’s so tasty. Photo by beketchai via Flickr

I also thought this would be the perfect time to give this whole game development streaming thing a go. I’ve seen it around quite a bit, and while it really didn’t sound like a good time to me, I’ve been working on breaking out of my comfort zone to get my name out there. After a few snags with that, I finally got things up and running. Sort of. For whatever reason, Twitch would not update my status from offline, no matter how online I got. Others could view my stream, it was up and running, but I was listed as offline which meant nobody could find me; I didn’t show up in the Ludum Dare list of streams. In getting set up I had to switch my account from being a Justin.tv account to a Twitch.tv account, so I assumed it was because of that, and declared myself ready.

Man against theme

As soon as I knew I would have the time to enter, I started looking at the theme voting. There were some great themes, some that were mediocre, and some that I could do naught but roll my eyes at. As the list narrowed down to the final twenty, my brain went into overdrive. Every theme I read, my mind would flood with ideas of how I could possibly interpret that theme in a way that wouldn’t be overdone, and wouldn’t be out of the reach of my capability. I jotted down the best ideas that came to mind; nothing more than an elevator pitch and maybe a title, but it helped me not go crazy in the days leading up to the event. In the end I think I wrote down about 15 different ideas, each able to be tweaked to fit one of a couple of themes depending on what the actual theme was. I even tried to give myself a leg up by looking at the voting stats for the first four rounds to get a best guess at what it would be. Don’t do this, kids, it doesn’t work and it’s not a good use of time. When the theme was announced, I looked at what I had for that theme and realized I hated it.

I took parts from what I had written down; it was a platformer, the surface I was delving beneath was the facade of a small town of cult members, and there would be no combat. Outside of that it was back to the drawing board. In the first hour after the theme was announced, I started up my Twitch stream and started brainstorming. I decided to go with stealth as the conflict mechanic to replace combat, and to go with a horror-game feel. Making a stealth game in 48 hours that feels satisfying is no easy feat, so I decided to downplay that aspect in favor of a metroidvania-style of exploration. The stealth would still be there, but instead of being an epic struggle like Mark of the Ninja, it would be something more along the lines of blasting away Skree bats in Super Metroid. Something to get in the way and maybe slow you down a bit, but not really the focus. I came up with a list of must-have features, should-have features, and nice extras to add if I had time to spare. I felt good about it.

Stealth was to be my broken escalator. Sorry for the convenience. Photo by Kevin Simpson via Flickr.

Stealth was to be my broken escalator. Sorry for the convenience. Photo by Kevin Simpson via Flickr.

Man against time

By the end of the first night I had a simple platformer up and running. No graphics, no sound, just boxes jumping around and going through doors. The last time I did this, I had a horrible method for getting level content into the game, it took forever, and I nearly didn’t finish as a result, so one of the first things I set up was a streamlined process for getting levels from Tiled into my game. That turned out to be a crucial feature later on, so I’m glad I nailed that down early. My other biggest shortcomings last time were a lack of good audio, and the fact that the game was insanely hard. Audio was easy, I just had to prioritize it higher, and to address the second issue I pulled a page from the Bioshock playbook and made death a non-issue. I simply teleported the player back to the start of the map if they got caught. No loss of upgrades or progress, just a small inconvenience, and one that was easily avoided by entering a door. Going into day two I had a plan and felt on track.

I had convinced a friend of mine, the one with whom I am currently building a ping pong table, to try his hand at the solo competition for the first time. On Saturday he came over and set his laptop up across from me, with the idea that we could bounce ideas off of each other, and when the time came we would have easy and quick access to a playtester. This also gave us the opportunity to try and finish painting our table. None of those things ended up happening, but it was nice to not be locked in solitude for the entire event. I am seriously considering trying to find a local gathering for the next one, the extra human interaction was a bit distracting at times, but it helped stave off panic in a big way. What didn’t help was the fact that trying to stream was causing performance issues and eventually crashed my computer. Being behind didn’t help either.

By the end of day two, the panic had set in. I felt like I had over scoped, I felt like there was no way I could finish, and my mind was going at full speed when I tried to go to sleep the first time. I had fully animated, randomly assembled characters, tiled graphics loading from the map, and all of the music complete, but the gameplay was still missing a fair bit of what I had originally listed in the mandatory category, and I hadn’t even started on the level design. I tried to think back to where I was the last time, but my memory was hazy, I was tired, and I felt mentally drained. After kicking around in bed for about thirty minutes with no sleep in sight, against my better judgement I went back to my office and sat down for some more programming. I managed to get a buggy version of one of the planned platforming moves up and running in about twenty minutes, and while it wasn’t a huge milestone, it set my mind at ease that all of my architecture up to this point had put me in a good place. It seemed like a lot, but it would go quickly.

My mind was calm. Well, as calm as it could be, given the circumstances. Photo by Robert Grant, via Flickr.

My mind was calm. Well, as calm as it could be, given the circumstances. Photo by Robert Grant, via Flickr.

Man against self

On the final day, I was all drive. I became hyper focused and started chewing through features like a programming wizard. Within the first few hours I had all of the movement upgrades I had on my mandatory list implemented with only a few bugs that I waved away as being a casualty of speed. Stealth was working, the enemies would spot and react to the player. I wanted the whole town to react to the player being spotted, like invasion of the body snatchers, they would point and scream, and some flying cultist would come in and knock you out. Instead I went with a simple screen fade and called it a day. With about four hours left, I had all of my must-haves but two put in, and after deciding that I had time for neither of them, looked at the list of cool extras. I really wanted to add windows to the buildings, have them react to the sound of the player and open with a short delay. They would spot you just like the cultists, and the result would be the same, it just added an extra dimension to the game. I started drawing, got the graphics for them ready, got the code for how they would react written up, and with about three hours left, realized I didn’t have time to tweak the level editor and loading code to put them into the game.

I got pretty upset with myself for wasting that time. It was time I should have been using to finish the level map. Then it hit me. I hadn’t even started the level map. I panicked hard. I wanted backtracking and exploration, how could I design all of that in just a couple of hours? Fortunately, the pipeline I had set up for myself at the start saved me. The process was so streamlined I didn’t even have to close the game to load in the new map. With the editor on one screen and the game running on another, I was throwing down tiles like a fiend. After the first hour I was probably a quarter done with what I had initially envisioned. Instead of trying to finish that goal, I started throwing upgrades into existing places on the map. I added a few ledges to make the tops of building accessible with the right upgrades and stashed things all over. It changed the feel from what I wanted, no more sprawling exploration, instead a densely packed town with a collectible around every corner. The town was done, all I had left was to design the final area of the map, the church, and slap it into the game. Then I looked at the clock.

I had minutes left. Less than ten of them. I had lost track of time completely, but at least the town was done enough to play. After taking a deep breath, I made a giant empty room and put it into the game. I coded up the triggers for that map, which didn’t end up working anyway, threw in the entrance and exit, and then checked the time again. Five minutes. In a frenzy I played through the game one last time to make sure it could be beaten. With just two minutes to spare I saw the ending screen, threw my hands up and called it done.

Close enough. Photo by Mr.TinDC via Flickr.

Close enough. Photo by Mr.TinDC via Flickr.

Man against society

After I finished, worked through a stupid compatibility issue with the web version and got both versions uploaded, I took a break. I watched a movie with my oh-so-patient wife who was crucial to me not breaking down and quitting, ate some food, and just let the experience wash over me. I had done it again. Sure I didn’t get everything I wanted, or even felt I needed, in the game, but it was a product you could play from start to finish. I felt accomplished. After talking with my wife about it, she reminded me that it was just as last-minute and hectic the previous time, so at least I didn’t get worse. The game was done, but now the real challenge began. Trying to get people to care about my game.

Ludum Dare is nice in that you can steer a lot of people to your game just by voting on the entries of others. So I did that. I did that a lot. To date I have rated almost a hundred and fifty entries, which has consumed almost all of my spare time for the past week. The feedback this time around is much more positive than last time. The only glaring issues seem to be the occasional glitch in collision that results from how I handled the crouching, and the lack of a coherent introductory period in the game. Nobody seems to think it’s too hard or not fun, so I’m feeling pretty good this time around. In particular, the audio seems to be getting high praises, and since that was my worst score last time, I can’t wait to see how it turns out this time.

There are a lot of good entries this time around. Some make me feel inadequate and awful, some show a lot of promise but have a few design flaws, and some make me feel like other people don’t take this event quite as seriously as I do. It’s hard to be fair and impartial when judging, and often times the description can alter that in drastic ways. Some people didn’t get started right away, so I can understand why their game feel incomplete even for a dare entry. Should that mean they get a better score for a less complete game? I’m awful at dealing with people, so rating entries is a taxing process for me. I try to leave constructive feedback on every entry I rate, and while it makes me feel more like I’m part of the community, I think my blunt nature has left a sour taste in more than a few mouths. I try to state both the positive and the negative, but when there’s not a lot of positive, it can be hard to seem sincere with coming off as being negative.

I'm about 99% confident he's talking to me. Photo by Surian Soosay via Flickr.

I’m about 99% confident he’s talking to me. Photo by Surian Soosay via Flickr.

Initially I was going to list my favorite entries I had played so far, but since this article is already way longer than I wanted it to be, it will have to wait for another day.

Marketing. That terrible word that strikes fear into the hearts of indie devs everywhere. No matter what you do or how hard you work, those terrible gods of marketing can decide that your game is doomed to wither away in the dark corners of the internet forever. Your genius cast aside because you weren’t cool enough on twitter, or you didn’t sell out to the man. All joking aside, getting your game out there is paramount to success, and there are a lot of ways to do that with no monetary cost. That being said, for someone as painfully introverted as I am, a trait I suspect is somewhat commonplace among indie devs, interacting with the community can be harder than actually developing a game.

I started off with good intentions. I made posts on reddit, facebook, twitter and my wordpress blog. Granted, I had no followers on twitter, and my blog had clocked exactly two readers, but I was working on that. I thought that maybe people would stumble on the links from the youtube video I posted, or from my post on the minecraft forums where the mod was officially released. With this storm of social media interaction, I was sure the hits would start rolling in. They actually did, though not to the degree I was expecting. Within a day there were several comments, my website stats showed dozens of downloads, and there were several comments on the forum. I had done it, I successfully engaged in social media on the internet. I was a winner.

As it turns out, one blast from a shotgun doesn’t win the war, or even a battle. I was diligent in responding to the comments on the forum, but I didn’t do a good job of promoting my other avenues of advertising, so they withered, and I forgot about them. I figured the youtube reviewers that were active on the forum would stumble on my mod and start doing reviews, and I just had to sit back and brace myself for the deluge of players that was sure to arrive. Obviously it never did, I didn’t do anything after the first day to actively promote it to anyone besides the people who had already seen it. I had never even heard of a press kit, and I assumed the people who did reviews games were constantly scouring the forums to look for new material.

The world of gaming press was completely foreign to me. I mean, of course I had read magazines, and the big name websites, but they covered the big names in gaming, so their rules must have been different. I was just some indie dev (barely), that was something I surely could never hope to get into, so I just didn’t even bother. Now, I know what you must be thinking at this point. “Wow, you are an idiot, you were doomed from the start, no wonder I’ve never even heard of you.” I did make a lot of mistakes, but I’d like to think I’ve learned from them, and I have that much better of a chance at success next time. This was really the first time I had made a game for an audience that wasn’t just myself. I am always really interested in what I’m doing, and since I had only ever made games for myself before it was a forgone conclusion to me that my audience would be just as interested when it expanded.

Ok, after reading what I just wrote about myself I sound amazingly self-centered. I really don’t try to be, but I was wholly ignorant of how the world worked in this regard. I am glad I went through all of this though, and especially glad I did it in a low-pressure environment, because I learned a ton. I will not be discouraged by all of these terrible failures though. I will take these lessons, learn from them, and do better on the next go around. These articles are the first step toward reaching out and making ties in this community, and hopefully my mistakes and these reflections thereon will help some other developer in a similar situation from repeating them.

Barriers to entry are bad. I learned this lesson in a few ways with this project. Obviously when you say it that way, anyone would agree that preventing people from playing your game is a bad thing, but it’s not always clear that’s what you are doing when you are developing something. In hindsight there was a lot I could have done better, and this a good way for me to really process it all and hopefully help other developers avoid these mistakes in the future.

The game that I released was a bit rough. I had exactly one tester, myself, for the entire year and a half dev cycle. I tried to rope my friends in, but that didn’t really work out. They just wanted to play, not test, and they didn’t know how to give good feedback. One of the biggest things I will be looking for when my next project has any sort of playable prototype is good testers. After the initial release, the slew of minor issues that my written tests and personal play-testing didn’t catch was staggering. The first few days was a whirlwind of quick patches and hot fixes. Things like localization names not matching so the description of an item was item.description instead the intended text, or typos leading to one of the skills being drastically overpowered to the point where level 4 characters could one-shot level 24 mobs. All of these things could have been caught by good testing. Instead, my initial release was a mess, and the people who saw it were turned off. Feedback came in saying the game had a long way to go, and that maybe they might check back in later. That’s disheartening, and it needlessly turns away a portion of the few people who actually installed the mod.

After that things calmed down for a while. The first intended update, to add multiplayer support, rolled out much more smoothly from the technical side, and that update brought in a fair amount of new interest. With that though, came a lot of confusion. Minecraft, on the whole, is not very friendly to start of, and I didn’t think I needed to be any different. Comments started popping up about the mod lacking content that baffled me. There was tons of new stuff to do, how could someone play for an hour and not notice anything different? The answer was simple: I didn’t introduce the content to the players. This is not to say that they needed their hands held, but some sort of tip of where to start looking or what button to press first to get access to the new content menus. I didn’t have any of this, and I thought that in the hands of people who played a game with no instructions it would be fine. What I didn’t have, though, was a well fleshed out wiki detailing all of my content and how to get started. I had nothing. As a result I know I lost more than a few players, and again a simple tutorial, or even a pop-up message, would have solved all of that.

On top of that, there were fragments of a story in the mod, one that I had intended to develop fully by the fourth update, that were completely lost on people. I later came up with several ideas for how to fix this, but by the time I got any of them implemented it was too late, and they didn’t help nearly as much as I thought they would. It’s hard to find the line between subtle and impossible to find when you have been immersed in something for over a year. If you roll your eyes at how obvious the story is after a year, it’s probably just subtle enough. Good testing would have caught this as well, which is another reason to get 3rd party testing done early and often.

So a rough release and no tutorial is a bad combination to have. I did have plans to add an in-game encyclopedia in one of the future updates, but that isn’t something that should have been pushed back. It’s a lot better for players to know what is going on with the 80% of the game you gave them, than to lose players who couldn’t find any of the 100% of the game.

Making it easy to get into the game, and making the game easy for the player to understand. Two sides of the same coin, really; it’s all about getting people playing the game. Next time I’ll go over how I failed to do the one thing that could have overcome both of those issues: marketing.

This is the first in a three-part series on what went wrong with my first attempt at releasing a “game” to the public. In this part I will go over one of the three major factors that I felt contributed to the underwhelming response to my efforts: I did not make efforts to make the mod easy to get up and running.

One of the biggest lessons that I learned from this project was that no matter how good your game is, if people can’t get into it with little effort, it won’t matter. The response I got from the people that actually played the game was almost unanimously positive. Several people told me that the mod became the game to them, and they couldn’t go back to normal Minecraft afterwards. With positive initial feedback like this, I was sure this was going to be a smashing success. Then the negative feedback started rolling in. Nothing about the game itself, but waves of questions about compatibility and installation. I thought (erroneously) that the modding community would have no problems installing a stand-alone mod, but I wasn’t involved enough with the community to know how wrong that was (which will be the topic of the third part in this series, so more on that later).

Many of the people playing with mods were using one of two popular modding engines. These engines forced some compatibility between mods, and limited the mods to the places they allowed to maintain it. Essentially, they were unofficial modding APIs made by the community, and I decided not to play ball. I went beyond the scope they provided in a number of ways, and I didn’t want to sacrifice my vision for the game for the sake of compatibility. By itself, this may not have been a big issue, but there were other issues with compatibility that really prevented the mod from catching on.

The deluge of questions and criticisms related to the community APIs was a bit of a blow to the ego, but not entirely unexpected. I was hoping that the video preview and the screenshots would get people to decide it was worth it to at least try it, and unfortunately for many people that was not the case. I thought that if they would just try it they would be hooked, but so many people turned away before they even tried it. Over a year of hard work on my part being offhandedly dismissed due to what I perceived as such a minor issue was hard, but once the reviews started rolling in, things had to improve. But while the reviewers and community voices were at least willing to install it, they had issues of their own.

One of the big features of the popular mod APIs was that it allowed the youtube reviewers to pull the mods apart from the inside and really dig into them. Without that, many of them attempted to do a review and then stopped because they didn’t have the tools they needed to do it. I tried to patch that functionality in to get them rolling, but I couldn’t compete with people dedicated to making it easy for them, and I was set at odds with the people I was relying on to spread the word and get people to overcome their trepidations about installing it.

I was a bit upset about the way this all unfolded. I thought my game was so good that its quality would make people ignore these issues and I was dead wrong. I set such a high bar for both players and reviewers to get into it that many people wrote it off before giving it a chance. Many of these issues are unique to modding, and my future projects won’t have the exact same issues, but the underlying current will always be there. Making it easy to get up and running is now just as high on my priority list as making the game fun to play. I have seen this paralleled in the game industry at large with DRM issues and launch-day servers problems, I should have known better. I had said to myself “but that won’t matter, my game is good enough to get past that.” I’ve learned that anytime I hear myself say that phrase though, that it’s time to rethink things.

Next up I’m going to go over the importance of having a solid player introduction to your game.