I’ve been debating on when to write this Post Mortem. I wanted to gauge people’s reaction to this #OneGameAMonth project before writing this post, and for the most part, I’m glad it was positive. There are several parts, though, that I felt I did a terrible job at, leaving me with mixed feelings. Overall, I think I succeeded in making an entertaining game, but not one that delivers the proper message.

What is Not a Clone?

Not a Clone is a Wario Ware Inc. style game where you play a series of super-short mobile games. The story is as follows:

Upon receiving his new smartphone, poor Jimmy downloaded all of the top-selling games that now demands every second of his attention. Help Jimmy play through as many mobile games as possible before the battery runs out!

At the end of the game, the game tallies which games you’ve played were clones, and which weren’t.

What went right?

Focused idea

Not a Clone‘s core design was to water down mobile games to 5-second chunks, then serve them with progressively increasing difficulty.  It’s a super-simple concept, and one that I knew would work well. Because of how focused this concept is, I didn’t need to spend that much time experimenting and polishing the game, leading to quicker development.

Quick access to free assets

Not a Clone required creating a variety of minigame, all of them as different experiences.  While I’m adept at programming, I’m nowhere near as swift when it comes to art and sound, so I was glad that I had a few libraries I can immediately rely on to complete this game.  This includes graphics from Kenney, music from Kevin Macleod, particles from the Unity Asset Store, and BFXR for sound effects.  These assets helped me pull through the last week of development, where I had to put everything together.

Increased efforts in marketing

Seeing that Not a Clone is a series of minigames, finding the best screenshots for this game was shockingly easy.  Since each game looks visually different, I could post a new screenshot every day for two weeks and not make it look repetitive or annoying.  And that’s exactly what I did.

I’ve also started using Twitter more actively, first to connect with developers from Boston FIG, then later to use hashtag-seeking bots to spread the screenshots.  The latter strategy worked surprisingly well.  A lot of my posts were retweeted every day with this method.

Lastly, I took the time to set up a proper trailer for the game, even though it’s a super-short game.  While it’s too early to tell whether the trailers and the retweeting bots were effective strategies, I think it drastically helped from where I originally started.

Provided enough instructions to play each game

An unavoidable nightmare with games that you only have a short time to play is to actually teach the player how to play it within that time frame.  This was an early complaint with my, albeit minimal, playtesters.  After spending a few days working on that, and releasing the game, it seems this problem has mostly vanished.  I’ve only heard of one feedback that told me a minigame was confusing, and I consider that a huge accomplishment from where I began.

I learned something new!

I always try to learn a feature I haven’t touched before on Unity, and this game was no different.  This time around, I educated myself in how to use Unity’s new GUI system from the recent betas.  I can say I have a very good handle on them now.

What didn’t go so well

Poor presentation of the game

Let’s get the most important thing out-of-the-way.  Many people were discouraged by the game’s tagline, “a satire on the mobile game market.”  I’ll go over the reason I wrote that later (and that reason might surprise you), but for the purpose of marketing this game, this was a poor, poor idea.  When hearing that this game was supposed to be a satire, there were a few people who thought the game wasn’t supposed to be fun.  Heck, one of my friends who played the game posted on Facebook that he thought the game was very fun, and asked why it’s a satire from the first place.  The game was designed to be fun, and more importantly, addicting.  So it’s my own folly that I gave precisely the opposite impression for would-be players.

The people who played the game and got the message weren’t that better off.  Mainly because of this ending screenshot:

I won’t sugarcoat this: this screen is very condescending.  For the people who aren’t familiar with mobile games, they would have legitimate fun playing this game, only to be scolded by the game for not recognizing which games were clones.  For the people who are familiar with mobile games, this screen punishes them for not recognizing which games they played were actually original.  I fully admit that not only is this screen offensive to me as well, it’s not even the message I want to deliver.  Originally, I wanted to convey that the app market’s reliance on top charts and poor discovery leads to absurd number of clones due to uninformed customers.  Instead, I’ve created a game that says either the player is uninformed or misinformed, and that’s why the app market is the way it is (they had fun, after all).  I feel like I failed pretty badly in this regard.

Working with a controversial game is draining

To be completely honest, when I was developing this game, I was completely nervous about making it.  Almost the entire time, I was debating on whether the game looked different enough from the source material, or not enough.  This constant worrying left me with low confidence on the delivery of the game.  The reason I had the tagline, “a satire on the mobile game market” at the beginning of the game was because I was afraid someone might think this game was a predatory attempt at cloning mobile games, despite having a clearly sarcastic title.  It also lead to a ridiculous amount of time spent on the credits, just to make sure I had every necessary information in there.

Fortunately there wasn’t any immediate backlash with the game, and as mentioned earlier the reception was definitely positive.  Still, considering how badly pressured I felt making the game, I doubt I’ll be making a similar game again.

Minimal Playtesting

I had exactly two playtesting sessions: one with the Dirigiballers team when they were setting up the Tumbleweed Express booth at Boston FIG, and one with the Albany Unity 3D meetup.  I had many last-minute bugs and polishes at the end when building the game largely due to the lack of playtesting, and thus, the lack feedback and bug finding.  A lot of the problems during the last week of development could have been easily detected with outside help.

Working with beta software

While I learned a lot about the new GUI with Unity 4.6 beta, the software was also pretty buggy.  The minigame my friend commented earlier that lacked sufficient instructions was a result of Unity crashing when attempting to provide that very instructions.  Since I lost a lot of back then, I’ve decided to avoid providing the intended instructions with that game.

Poor scoping

Initially I scheduled myself to create 20 minigames with unique mechanics for each one.  In the end I created 26 minigames, with only 16 of them having actually unique mechanics.  I ultimately blame on bad estimation on this one, especially since I’m the kind that’s easily distracted with internet.

What will I do, moving forward

Developing this game was a significant departure from what I usually make, and while a lot of parts came together well, a lot of other parts clearly needed more work.  It’s clear to me that while I’ve polished my skills in making fun games, I’m still miles off from one that’s capable of conveying a message, let alone a story.  Moving forward, I see it necessary that I practice more with conveying narrative into a game.  Additionally, the incorrect message I gave with Not A Clone were mistakes that was easily predictable, both with playtesting and with a little reflection.  For next month’s game, I’ll be seeking for a method to have regular playtesting sessions.  Lastly, I’ll be work with more stable software, rather than betas so I don’t get hit with crashes again.