Sunday, 2 March 2014

Open Thread Summary: What Went Wrong?

I have to admit, I was a bit worried about the Open Thread experiment, but I think it went quite well with (currently) 31 comments. Thanks to everyone who contributed

Here is a summary of many of the pitfalls and problems authors have encountered. I tried to cover as many of the ideas as possible and some of the categories are almost duplicates of others, but I’d rather go for broadness then precision here.

Hopefully this list can help both new and established authors when they set out to start games. If there is anything anyone would like to add, please feel free to comment and I will update the post with suggestions.

Biting Off More Than You Can Chew/Work Load: I suspect the vast majority of problems have at least some root in the work load that AIF requires. I wish it wasn’t so, but designing an AIF is hard, designing one with complex elements is even harder, doing this and trying to create multiple branches is incredibly difficult.

The Biting Off More Than You Can Chew problem though frequently occurs to new authors (I’d say this is a general fact about humans even if we aren’t just talking about AIF). We have great ideas and we want to cram everything into a game. Trying to do all of that, while learning how to do it, sets up a nearly impossible task and can lead to frustration and the whole project getting tossed.

How to try to avoid?: Understand what you are getting to and focus your design. That is hard to do, but will increase the chances of getting a game finished and likely make it better in the long run. You don’t have to do everything at once, you can always design a second game later (and 2nd, 3rd, etc.)

Loss of Interest: With work comes boredom. You’ve designed the game, have the outline of the plotline, and are really excited, but as you sit down and write you realize ‘I’m bored’. On top of that, there is a nagging idea in the back of your head for a game that would be even more awesome.

How to try to avoid?: Sadly, there isn’t much that can be done. In general, doing things that keep you from getting frustrated (keep it simple) will ease the difficulty of the actually writing of the game and thus prevent you from starting to look to the next great idea.

Out of Control Plot: “Boy meets girl, boy tries to seduce girl, boy tries to become international jewel thief to impress girl, boy ends up falling into a vat of chemicals and becoming superhero, boy gets pie thrown in face because game is also comedy, boy seduces different girl who hadn’t even existed at beginning of game, and then boy finally gets girl, who may or may not be an alien”.

Similar to the complexities of game design, the plot can spin out of control. Given that AIF creates the ability to give the player options, the directions the plot can go are able to expand infinitely. Except sometime the plot can expand to so many different places that the original purpose is completely lost.

How to try to avoid?: Ask yourself, what is the story I want to tell here, and what is unnecessary? There is nothing wrong with side storylines or options, but if you are spending too much of your time on things not related to the main purpose of the game it can spin out of control.

Trying to Make Everyone Happy: Another form of trying to get too much material in is trying to please everyone in a single game. We each have our own tastes about what we would like to see in a game and it needs to be recognized early on that you can’t appeal to everyone. That’s fine, even if some people say ‘I think your game would be better if you do X’ you can evaluate their opinion and reply ‘I understand what you are saying, but I disagree’.

How to try to avoid?: Your product will be criticized. That’s good. Some of the good criticism might be bad, incompatible, or illogical. That’s fine too. It’s good that you want the audience to enjoy the game, but keep your focus upon the people who do it enjoy it, try and implement the improvements suggestions that don’t conflict with your overall design, and respectfully disagree with the others.

Second Guessing: This can fall under trying to make everyone happy, but a problem can just be concern/fear about how a game will be received. I’ll admit to trepidation when I released a mini-comp entry that was extremely rushed. A lot of time gets put into a game and it never feels good when people don’t like the product and, it can feel by extension, your hard work. Unfortunately, people can become so worried about reception that they never finish/release their game.

How to try to avoid?: Like I mentioned above, your product will be criticized. So has every game out there. It’s just a fact of life. Some of the criticism might be wrong, some of it might even come off as harsh, but you’ll likely also get much that is extremely helpful.

Another solution is beta testing/getting help. If you are worried about the overall reaction, find people to test the game and/or go over it before release. This way you can get an understanding of problems/strengths and either fix them or be prepared for comments when it does get released.

Bad: Sadly, after a lot of work, you might realize the game just isn’t good. Now, first be sure you aren’t falling under the second guessing or trying to make everyone happy, and feel free to get some outside commentary, before tossing everything. But it is a sad possibility that the work just doesn’t make for a satisfying game and is thus not worth anymore of your time.

How to try to avoid?: There is nothing wrong with this as long as you learn from your mistakes. You messed up, so what, so has everyone. Learn and apply the lessons to your next project.

Not A Game: Writing an AIF and writing a story are usually two different things (though there are some good AIFs out there that are extremely linear). You can design a plot line but realize that there is no variability and/or challenge for the player. In short, there is no reason that the game doesn’t just read as a narrative because the characters inputs are pointless.

How to try to avoid?:  I don’t think this is by default a problem. There is no requirement that an AIF have branching paths or puzzles to overcome. But, if you want to be sure that you get the Interactive into AIF, I’d recommend a focus on game elements before plot. If your plot keeps dominating the game, focus upon what the player is trying to accomplish and how they could fail.

I Can’t Get X to Work: Whether it be game design or plot, one major flaw can unravel an otherwise promising work. Maybe you had a great beginning and ending, but the middle is just a mess, or maybe there is a great storyline, but the combat system that progresses the game just isn’t working.

How to try to avoid?: Design before jumping into the writing process. Make sure you have taken the time to get an idea of what you want the whole story to be and understand that the things you want your engine to do you know how to do.

As a quick side note; I should add that some people write without a clear cut plan believing it allows for ideas to develop. I’m not saying that is in anyway wrong, just outlining a potential problem.

Forgetfulness: This was brought up by fensome7 and something that has happened to me which I had, ironically, forgotten about. Designing an AIF can be a long process (especially with interruptions) and it is possible to open a project and your own work to no longer make any sense. This happened to me with my Buffy game, something that I wanted to release a bug free and updated version of, but I put it off for so long that when I opened it nothing made sense anymore.

How to try to avoid?:  Take notes and make outlines. That doesn’t guarantee that your notes will make sense to you later, but it will help a lot.


  1. As someone who just released their first game, I can say this is a really good overview of the potential pitfalls and possible ways to avoid them. I'd like to elaborate on a few things I experienced:

    Getting Bored: I actually started a few games over a long period of time before I got working on Study Date. The thing that I think made the biggest difference is that with Study Date I actually sat down and outlined the whole game from start to finish before I ever wrote one line of code. Always before I would get a basic idea for the game in my head and then just start writing, thinking it would come together on its own, but every time I would barely get started on it before I realized I didn't know where it was going and would get bored with it and stop. Outlining the whole thing first is the main reason I was able to finish Study Date.

    Beta Testing: Do this! No matter how thoroughly you test your game yourself there are going to be bugs that you don't find because you know what you want the player to do and you just don't think of the things the player will actually do. Study Date's release was a mess of me updating it when I thought the bug reports had slowed down, and then receiving new reports 5 minutes after uploading the "fixed" version. The worst part of it is that I know there are people who played through the first version, or the second or third, and missed content because of problems that I hadn't fixed yet, but who don't know I released follow-up versions or who had already played it enough that they didn't care to replay it again. A closed beta with a handful of testers will allow you to go through that iterating process in a much more controlled setting, so when you finally release publicly you only have to do one release, not 6.

    Just my $0.02.

  2. I agree with all you said as well as Karrek's additional info. I do realize of course some people can do pretty good (or even better) without such a planned outline, and that is OK too.

    If you aren't planning everything down, one thing to at least consider is the main gameplay mechanics. For example, if you are going to have a story about two people who are friends then end up in a relationship, how will this happen? Is it a game that goes by days, and each day their relation can increase? If so, how are days processed - turn based, something you can do for each section of the day, or just until the player types sleep? What about conversations? Can he increase their relationship by asking certain things? And then what conversation system will you use?

    You can end up with a really great idea but no way of implementing it, or at least not how you thought of previously.I guess that goes with 'I can't get X to Work', but it is something you might not even be thinking about initially. If it ends up being a pretty big part of the game and you just get stuck, not knowing how to do it or you simply can't implement it well or at all with your selected program, it can quickly stop a game in its tracks.

  3. One thing to note: if you think your game is bad and you bring in a second opinion to evaluate it, it's unlikely they'll say it's bad. Likely you'll get some supportive encouragement, so if you're genuinely trying to determine whether a game is just not good enough for release, that's a hard call to make but you're probably the best judge.