Get the latest Education e-news
 
  • Ship It Fast: Why We Developed A Tiny Game In 2 Months

    [01.31.19]
    - Jair McBain

  • Throw unique mechanics out the window

    Unique and exciting mechanics usually mean more upfront design, time required to implement, iteration cycles and testing time. We went with an automatic wobble on the dolls which required us to only need to check for a single tap input to trigger the doll launch. Our thought process here was with less time designing an overly complex system up front, the more time we'd have to implement and experiment with it.

    Pick a simple art style and stick to it

    Despite wanting to initially go down the path of a painterly traditional folk-art vibe for Oshka, I realised if we wanted to get it out the door in 2 months I'd need to simplify the style and make it as easy as I could to generate new art assets. This didn't mean I had to skip the folk aesthetic entirely, but it did change how I approached things. To keep our art scope down we:

    • Created a single doll template in Photoshop and started with that for every doll

    • Set up a doll prefab with a generic open/ close and launch animation in engine (meaning we could replace the doll sprites easily and use the same animations on each doll)

    • Limited doll facial expressions to an idle, happy and angry animation (only adding unique expressions to dolls that required them)

    • Didn't create any fancy transitions or animations if they didn't drastically improve the experience

    • Used an out of the box free font that suited the aesthetic and reused the same UI assets as much as possible

    • Picked a relatively limited palette and tried to keep art detail as low as made sense

    Crush your insecurities and perfectionist tendencies

    Admittedly I struggled harder with this than Adrian did - he had spent the previous year doing a game a day/ week/ month regularly and had beaten his perfectionism down better than I had. In most cases we had to be comfortable making do with the first or second version of whatever it was we were doing, be that doll art, environment art, system implementation, etc... every time we found ourselves wanting to revise something we had to ask "is this worth it?", "does leaving it as is impact our core goals?" and "will the benefit of this revision be measurable to us after launch?"

    Cut content to MVP only

    Initially we had planned for 15 unlockable doll skins at launch. Every few days we would revise this number based on how quickly I was getting through creating them, how much play time it was looking like it would take to unlock them and how much time it would take to implement them as in-app-purchases/ coin unlockable shop items. We also heavily cut down on how many environment Easter eggs we had planned for launch. Sure they might have been a nice polish addition, but most of our players wouldn't ever see them.

    Build a working system ASAP over an overly polished one

    When Adrian was putting together the main stacking mechanic, he quickly built a system that validated our idea of how it would work. This system met our needs at that moment which as far as we were concerned would serve us until the end of the project.  With more time and planning the code could have been cleaner, but what was most important here was that it simply worked.

    Go against what you believe is the best design implementation for one that works just fine

    Of all of the compromises we made, this one was the hardest. We were pretty certain that this game needed a near miss mechanic and we tried to implement this a few different ways. Binary systems can be boring and frustrating. It is a well-known fact that success and failure is more meaningful when there's a chance of an outcome that isn't quite either - like small wins during major jackpots to encourage you to gamble again the next time. We got stuck on the best way to add a near miss mechanic for two weeks mid development and it became apparent that the systems we were trying would take too long to implement. Despite it being a more interesting design, we bit the bullet and cut our near miss system in favour of the simplicity of what we already had. We felt the near miss mechanic wasn't ultimately going to impact our core goals of assessing market viability given our means for this project.

Comments

comments powered by Disqus