header
Currently Browsing: Design

Postmortem: Quick Shooter

Postmortem: Quick Shooter

Quick Shooter is our first release at Spotkin, and it’s now available on both iOS and Android. Now that it’s out in the wild, I want to take a look at what went wrong, and what went right.

First, I’ll touch on what went right. I’m proud of the quality that went into the game. It has great menus, characters, music, art, etc. It is a great experience tailored to the phone. It can be played with one hand, and a complete playthrough of the game only takes a few minutes (perfect for waiting in line, at a restaurant, on the bus). Also, we get lots of praise from the players that really like the game (We have 4.5 stars on iOS and 4 stars on Android).

However, things did go wrong with the game:

  • The game is too hard to get into. For how simple it seems (hold, draw, shoot!), the game is too hard for the average player to pick up and play. If I hand the game to someone who has never seen it before, it takes too much back and forth, and too much explaining to get them going.
  • Playing for a high score isn’t obvious enough. The main idea behind the game was to play it over and over again to get a high score and beat your friends. The problem is, lots of players don’t get this (or even have the desire to do so). As a player is learning to play the game, they will usually lose before they make it to the end. Once they get better and finally make it to the end, they feel like they have “beat” the game and don’t want to play anymore(even though they finally completed a full, real round).
  • It doesn’t have a good elevator pitch. If someone asks me what the game is, I don’t have an exciting answer for them: “It’s a Western, reaction-based shooting game with a fun swipe and touch shooting mechanic.” The explanation is usually followed by a blank stare and a, “Ohh….That sounds fun…” After letting them play the game for a while they usually get it and have lots of fun, but it doesn’t sound fun at first.

Some of the problems could actually be fixed, worked around, and solved, but the main problem is that it’s just not worth it. Quick Shooter was supposed to be a “quick and dirty” mobile prototype just to get our feet wet in the mobile market. The more we worked on it, the more attached and excited we got, which made us spend too much time. We now have our first mobile release, and we learned some lessons along the way. There are a lot more games out there to be made though, so it’s best that we just lick our wounds and move on to our other projects.

Speaking of lessons, what did we learn from this game?

  • Dont fall in love. This is a little strange, because obviously you need to be in love with your game and believe that it’s better than everything out there. However, you can’t be so in love that you don’t see the bigger picture. Like I said earlier, Quick Shooter was supposed to just be a quick and easy mobile prototype, but it ballooned into something we believed could be much more. We added in IAP, worked the main game mode around, and just kept putting more and more time into the game. If we had stayed more focused on our original goal, I believe we would have ended up with a much better product.
  • Test with users early. We didn’t do usability testing with even friends and family early enough. I didn’t really want to show it off at such an unfinished state, believing that it would be too hard to understand until more UI, tutorials, etc. were implemented. If we had tested before all of that extra stuff was put in, we would have noticed a lot of glaring problems that we had to work on after a lot of the main systems were already in place.
  • Don’t ignore Android. I’ll explain this in more detail later, but don’t ignore Android when it comes to mobile games. We didn’t necessarily avoid Android (It worked on Android devices through most of the development), but we definitely had iOS on a much higher pedestal. We listened to all the words from developers that Android doesn’t monetize, their player base isn’t as good, etc. We made a few decisions that were definitely iOS biased, but we won’t be doing that anymore in the future.
These are just my global thoughts on the game. I have plans for more posts about different parts of the game and the process, so stay tuned!

 

Should Developers Play Games?

Should Developers Play Games?

A recent article on Gamasutra inspired me to throw my two cents into the discussion. The article asked the question, “Should developers be obsessive gamers — or remain outside of the influence of other titles?” This question brings up two extremes, but I believe that the answer is a happy medium between the two. Game devs, regardless of what their job is, should all be involved with games somewhat. This doesn’t mean that they need to be playing all games all the time, but they should always be at least reading about current games or watching them on youtube.

Some people say it’s better to “design in a void” and not get influenced by other titles, but I have just never felt that way. I feel like all of the games I have played/read about/watched over my whole life have given me a vast library of design knowledge to pull from. I have countless examples in my mind of fun and bad gaming experiences. Would I call myself an “obsessive gamer?” Definitely not anymore. There is no way I could find as much time to dedicate to playing games compared to when I was in middle school (and I don’t really have the desire to play that much anymore). However, I am still always out at least looking at all sorts games. If I’m not checking out a new iPad game, I may be watching a video of some other game, always on the pulse of what’s going on in the industry.