For every Snapchat or PokemonGO!, there are thousands of mobile applications that fail or get outright ignored. What this means for developers is a more-than-good chance their software goes unnoticed for any number of reasons. It could be for bugs, a bad user interface (UI) or redundant ideas, as well as more trivial things such as a bad name. No matter how innovative or original, the recipe for a best-selling app almost always includes persistence, and perhaps some luck too.
Someone who is all too familiar with this reality is Taro Omiya, an indie software developer and owner of Omiya Games of Troy, N.Y. After struggling in the mobile development arena, Omiya has found his niche with game development. I recently had the chance to sit down with Taro at the Tech Valley Game Space in Troy, N.Y., where he enlightened me about his game, Not a Clone, and the road that took him into game development.
DF: Can you describe your game for me?
Not a Clone is a parody and satirical game about the mobile game market, criticizing their reliance on the store’s top charts and causing the rise of clones—games that steal the functionality of one game and put a different skin on it.
You play the game by going through 5-second-long minigames, one after another. The goal is to figure out how to play each minigame without failing and losing battery before the time runs out. Many of the minigames are parodies to other actual games sold in the mobile market. The satire kicks in when accessing the in-game store to unlock more minigames, where even more game parodies—often the same ones you’ve just played with different graphics—are sold.
DF: How did you come up with the idea?
From a game jam called #OneGameAMonth, a year-long event where you try to make a game every month. One month’s optional theme, which I used to base this game around, was a fair (like a festival).
I use what I call “the brain-dump” method to brainstorm a game idea: I write a bunch of one sentence-long game descriptions for an hour, then at the end of the session, select the idea I like the most. Since a county fair has a lot of short games, I wrote a quick description about a game where you play many short minigames. This idea turned out to be my favorite.
I had just come out of mobile game development, and was frustrated with the difficulty in getting attention and figuring out what people liked. I wanted to let out my frustration and show how tough it is to enter this market. Those emotions became the game’s primary design theme.
My game shares some similarities to the Nintendo game series WarioWare and the popular mobile game Dumb Ways to Die. The goal of all of these games is to figure out how to play each minigame in 5 seconds or less. I decided to take this formula and make it more serious than both games’ cartoony aesthetics.
DF: How did you come up with your team?
Initially, I started by building the original #OneGameAMonth prototype by myself using free art, sound, and music assets online. When I decided to expand this prototype to a mobile release, though, I asked for people's help on the fly. At its peak, our team size was seven: Astra was our main artist who created the majority of the game’s graphics. Jason was our backup artist, although since he makes games too, this project became a simple pass-time for him. Chase was our sound designer, Spencer was our music composer and Robert was our writer. Finally, our second programmer, Dylan, took care of code I didn’t have the time to add, such as translations and analytics.
I confess for a small company such as ours, this team size was probably too large. For those looking into starting a game development team, I would recommend two or three at most.
DF: When did you realize Not a Clone could be successful?
We posted the prototype from the #OneGameaMonth event on a website named Game Jolt, where it became surprisingly popular. There were a lot of LetsPlay videos enjoying the game on Youtube, so we decided to expand on it.
DF: What challenges did you face while making your game?
I found it quite intimidating to program most of the minigames solo. Every time I made a new minigame, it felt like I was making a new app. For example, I usually program my applications without spending much time planning on an architecture. Instead, I prioritize on creating a functional prototype first. Once a prototype is finished, I review each script, looking for commonalities between them and moving any shared lines into their own file. This way, both the current code and any other future programs can reuse those common lines, reducing the workload. This eventually becomes the game’s architecture. With this game, some minigames happen to have a lot of overlapping functionalities, such as ones that have a character moving left to right at a constant speed and dodging obstacles.
Other minigames have no overlaps whatsoever, which significantly increased the amount of work I had to do. To contrast the previous example, some minigames use swipe gestures as their primary way of controls, which will require a completely different set of code. Because of the large variety of minigames we were implementing, I sometimes hit a difficult minigame to program due to it not sharing any functionalities from previously minigames. In the end, the only code that every minigame shared are the triggers for when it starts and ends. Everything else felt like it was made from scratch.
Adding features that affect the whole game tended to be easier, but not always. Making a minigame list was very easy since it didn't impact any minigame individually, although it did require new art and sound assets. Other stuff, like making the volume control was difficult because it required us to update all the minigames individually. A minigame may have multiple sound effects, each set at their own independent volumes (e.g. a soft jump sound vs. a loud crash). The game engine we were using, Unity, required us to go through each minigame and bind all of their sound effect instances to the Unity Audio Mixer file. Obviously with the large number of minigames to update, this became a very tedious and time consuming task. The difficulty of adding a new feature really depends on how many things in the game it affects.
The most difficult part was trying to provide clues to the user to figure out how to play each minigame. Unlike most games that provide a tutorial that lets you learn how to play the game at your own pace, our game is on a 5 second timer. It was an intimidating task to hint to the player how to play a minigame in that time frame, while also giving them the satisfaction that they figured it out by themselves. Multiply that task by 30-plus minigames, and you can see why this became very difficult.
Initially, we made all the minigames available at the start due to feedback from the #OneGameAMonth prototype. It turns out, most people who were playing the game for the first time didn't actually like that. After struggling with these playtesters for so long I experimented by taking out minigames I noticed our audience were struggling with. It was a big breakthrough: this smaller build was much better received than any of the previous iterations we’d created. To keep both the first-timers and the more experienced players happy, we created a shop that acted as the game’s skill gate: the player’s score will be converted to in-game virtual currency, which lets them unlock more minigames. Since the shop affected all the minigames, we almost had to rewrite the whole game.
DF: What advice do you have for people looking to develop mobile games?
My advice is to start small, make a lot of games, and always learn from what you do. Remember to have other people play and comment on your game. Kids and playtesters that do not have a personal connection with you usually provide the most honest feedback. Don’t push back on any criticism you receive—something I confess I struggled with when I first started making games—and always thank your players. Regardless of whether you want to be a self-starting entrepreneur or hired by the industry, I highly recommend making your own games and expanding your portfolio.
DF: What’s the difference between mobile games and games for consoles and computers?
If you are starting small you are not going to make a triple-A game (those made for console and PC markets). They have very large teams, spend 4 or 5 years on each project, hire professional actors, and have the clout to go through all the legalities and guidelines. It just isn't possible for a small group without money to replicate that experience.
If making money is the reason you want to make games, I’m sorry, you are in the wrong industry. For one, hits are few and far between. A huge amount of luck is necessary for your game to become a viral hit, let alone a traditional one. And that’s before we take into consideration how difficult making games can be. A common misconception is that game development involves “just playing games.” In reality, it requires combining a wide range of skills, including programming, art, music, sound design, usability, project management, marketing, and more. Games are not easy money.
If you really love or are interested in making games, fortunately, there’s some good news. The video game market is open to small teams and their nostalgic or artistic endeavors. Viral games made by one-to-three person teams do exist, often going by the indie label. I highly recommend checking out these smaller games first to get a better idea of where to start on your journey.
As with all things, game development requires practice. Again, start small, and make lots of games. If you don’t know where to start, try remaking some of your favorite old school or mobile games, such as platformers. Making one and comparing it to the original product forces one to appreciate the details that goes into making games.
DF: What software do you recommend to aspiring game developers?
A lot of people recommend learning programming first, but I disagree. There are many game engines—applications that allow you to design a game and generate an executable as a result—that are both free and don’t require coding. Some examples are Construct 2 and GameMaker. For old school turn-based Japanese role-playing game (JRPG) lovers, RPG Maker has a free trial that lets you make some sophisticated RPGs very quickly. For 3D games, Unreal Engine 4 is a really good option so long as you have a powerful computer. It’s also a tool commonly used in the industry, so that’s a huge plus.
I personally recommend Construct 2 because their tutorials are easy to follow, and we were able to teach middle school students to make a game with it in a week.
DF: What software do you use and why?
I personally use Unity, which is another free game engine used in the industry. There are paid plugins available for this tool that make it possible to make games without coding. I am a pretty advanced programmer, though, so I didn’t need one for Not a Clone.
Incidentally, for the previous game engines I suggested earlier, Unreal 4 provides C++ as a programming option if you prefer to code, and GameMaker uses its own scripting language, GML. While I don’t think coding is necessary to learn to make games, it does widen your options if you have some knowledge about it.
With additional reporting by Kevin J. Harrigan