The #OneGameAMonth 2013 Post-Mortem

[Cross-posted from Omiya Games blog]

Having established the company at 2013, #OneGameAMonth proved to be a perfect opportunity to get a head-start on creating a library of games to work for in 2014. Brace yourself, because we'll be looking through several games at once in this long 2013 post-mortem.

According to my profile's list, I've successfully created 11 games out of the 12 months, which is rather impressive if I do say so myself. The games were:

If you looked at the above list and said, "that's a lot of Touch Yogas," well you'd be right. Ports were allowed in #OneGameAMonth, and I decided to take full advantage of it. If anything, however, the fact that I resorted to taking shortcuts shows that I underestimated my ability to manage time this year, which will be something that'll haunt me throughout this post-mortem.

SWARM!

SWARM! was a major project e4 Software and I started two years ago. The game was first available on late December last year on the Android, and was approved in early January this year for the iPad. The game was a ball-roller on the tablet where tilting the tablet would cause the character to roll into that direction, while tapping the screen would make the character jump. The key feature of the game were its large number of enemies. Since all the characters were pacifists, the player had to lure the enemies into environmental hazards to kill them.

Since the game is made by e4 Software, I won't go into deeper details about development. I will say that project was one of the largest I've worked on since being indie. The game unfortunately had lukewarm sales, which had a very negative impact on my ability to make games throughout the year.

Take-away: Beautiful graphics (great work, Chris Totten!) and solid, innovative controls does not make a game a success. The game had an intentionally passive gameplay, but this turned out to be the largest criticism on our game. Also, not being able to sell a game really hurts emotionally, hindering my development capabilities throughout the entire year.

The Heart of Darkness

The Heart of Darkness was made in 48-hours for Global Game Jam 2013. We initially started with five members in our team, but one of the members had to stay home sick (the one who came up with the idea, no less), leaving only four of us to rummage together whatever design notes we had left. The theme was based on a sound of a heartbeat, and we decided to go with a 2D platformer where the game is so dark, none of the platforms are visible. Instead, the player must rely on the commands given by a robot telling you when to jump.

When starting on developing this game, most members of the team had little experience working on a game, let alone a game jam. Since I was the most experienced with game jams, I took the role of putting together what tools were necessary to make the game (Unity and SVN), teaching how to use those tools, and help guide everyone on a more productive path. This "mentor" role tend to make me feel very useless, because it felt like I wasn't directly helping on making the game. Regardless, while the beginning was very bumpy with everyone trying to learn Unity and SVN as fast as possible, a lot of progress was made in the last two days. Special credit has to go to Alec Slayden for finding and putting together a ton of graphics into a beautiful, haunting space scenery.

Take-away: version controls are ridiculously important in team settings, but it's very difficult to teach how to use it. Taking a "mentor" role is a lot more difficult than expected. Unity post-processing effects and particles goes a long way in making a game very pretty.

Touch Yoga

On February, I registered my company, Omiya Games. It's first debut game, Touch Yoga, was made in about a month and a half. I was strongly inspired by Hundreds, and decided to develop a much more minimal version of it. Touch Yoga is basically finger Twister: the player must keep his/her fingers on all the circles on-screen for 4 seconds. Said circles usually moves in a predictable pattern, which means every stage has an optimal solution. The game requires a multi-touch device supporting 5 or more touches.

Developing my first game on my own was a pretty crazy experience, if anything. A lot of problems arises when you're doing something on your own compared to working on a team. For example, I'm a programmer by trade, which meant I immediately knew art and sound was going to be a major problem. Furthermore, since this game was developed for Omiya Games, I didn't use tools for SWARM! to keep my company legally clean. I had to program my own multi-touch buttons since Unity 3.5's built-in GUI performs terribly on mobile devices (no clue how 4.3's GUI performs). Lastly, I had to do some research on the maximum number of multi-touches that were allowed on each device, which proved to be a ordeal on its own.

For example, I decided to go with a max limit of 5 circles for each level since iPhone supports 5 touches. While porting to most tablets were easy, Android proved to be the hardest. Android devices provides a way to limit devices on the number of touches they support, but their thresholds are only 1-touch, 2-touch, and 3-touch or more. Thus, I had to spend an extra time implementing a starting menu that lets the player test whether their device can support 5 touches, and if not, to click a button to get a refund from the Google Play store.

This was also the first project where I started posting prototype pictures. My first prototype had a Windows 8 like aesthetic, with numbers indicating the order the circles needs to be touched.

Playing this iteration, I quickly discovered how unintuitive the numbers on the circles were. I quickly took them out, letting the player tap the circles in any order they prefer. I did eventually bring back the "tap circles in correct order" feature with a much more intuitive and visually pleasing effect: tapping certain circles would make more circles appear, branching out from the original one.

Rather late in development, a colleague from e4 Software mentioned that I should toss the Windows 8 aesthetic in favor of something more shiny. I grudgingly agreed (I actually like Windows 8's flat and simple aesthetic), and created a more sparkly graphics as the final product.

Since I produced the game on a rush, there was virtually no advertising done on the game. This, unfortunately, lead to abysmal sales for the game.

Take-away: marketing is much more important than I'd like to admit. I should have also spent a little more time in researching into how other games with similar gameplay, such as Fingle, did (I seriously did not know about that game until after I put Touch Yoga into the market). Making your own tools suck. They take a lot of time and effort, although fortunately for this game, it wasn't that bad. I learned far too late that bringing back the level select screen after clearing a level was incredibly confusing. Leading the player to the next level is much more intuitive. Touch Yoga also began my rather abstract art style, since I'm not exactly the most talented artist.

The Sentient Cube

If I had any doubts about working alone last month (remember, I worked in teams before then), The Sentient Cube cemented my confidence. Created for Ludum Dare 26, The Sentient Cube was a 48-hour solo project that can be described as Katamari Damacy with a finish line to cross over. Since the goal post was too large for the very small starting cube to see, the player had to increase it size to find the finish line. I frequently compared the game to Crazy Taxi because finding the finish line was part of the fun. This was made more obvious by a big arrow on the top of the screen that would always point to the direction of the goal post.

I've had a lot of fun making this game. Thanks to Phillip Ludington's wise advices, I was able to get plenty of food and sleep throughout the event. It also introduced me to live-streaming via Twitch.tv, where I had a lot of fun playing other competitors' games. The Sentient Cube itself was surprisingly easy to make in Unity. I was able to have a decent prototype by the first night, as seen in the screenshot below.

Much like The Heart of Darkness, I used a lot of post-processing effects to create a grainy cartoon visuals. I was actually inspired by a Japanese Pokemon fan-art that had outlined shadows. I think I did a pretty good job emulating the same effect with these filters.

The rest of the event was used for implementing a few special obstacles and power-ups (the rockets in particular comes to mind), putting together high scores, making unobtainable objects dark and obtainable objects brightly colored, and constructing levels. I've had very minor blunders in between development, but for the most part, it went very smoothly. Almost too smoothly.

Then I learned via Wikipedia that both Katamari Damacy and Crazy Taxi are patented.

That hit me hard. Even though I didn't receive any Cease and Desist orders, I wasn't going to take any legal risks: I immediately put the game down, leaving only a few gameplay trailers and several screenshots as a short memory of the game's existence. Added on top of the fact that I was still feeling terrible from SWARM!'s disappointing sales, that particular week was very depressing to me.

Take-away: I learned a lot about patents. While the damages were minimal, it was a brutal experience. Despite this, Ludum Dare helped confirm that, yes, I'm very capable of working alone.

ABCs Learn & Sing

ABCs Learn & Sing was a month-long project e4 Software and I made last year. As the name implies, it was a fun toy app to let smaller children learn the ABCs. It was actually very fascinating to make this project, as it surprised me how much kids like pushing buttons, so long as it provided some sort of feedback.

Since the game is made by e4 Software, I won't get into too much details about development. I do admit I had no hand in porting the Nook tablet game to the iOS devices, but I was heavily involved in the somewhat stressful month-long development. Another shout-out to Chris Totten who also made the graphics for this game last year, and has done a beautiful job at it.

Take-away: Smaller kids have a very different criteria for what games they find fun. It's actually very fascinating to make games for a different audience. This was probably the first confirmation for e4 Software that it was possible to make games in a very short time-frame.

String Theory

String Theory was a 2-month solo project that was (unusual for me) in first-person. The game involves using a fishing line with a magical lure that can stick to and create a string of larger and larger objects, similar to Katamari Damacy (minus the patent infringement). Said line of objects becomes useful for hitting targets and pushing aside barriers. I think this game had the best tutorial of all the games I've made, which made it very easy for new players to jump in.

When I was originally developing String Theory, I was thinking about a fishing game where you caught flying fishes. The fish you've caught would be usable as bait for catching even larger fishes. I abandoned this idea, though, when I was deeply unsatisfied with the string physics I was using. Plus, creating an AI for all the fishes seemed like a bit of a chore.

Instead, I borrowed a ton of code from The Sentient Cube and implemented it into String Theory. The game became about finding objects smaller than you (as indicated by their bright colors) and attaching them to your lure. Attached objects themselves become lures, making it easier to collect more objects just by using sweeping motions.

This time around, I opted for softer, more colorful toon graphics. Part of it was to make the game feel different from The Sentient Cube since comparisons to it were inevitable, but also because I was getting tired by the solid-colored graphics. I definitely like the brightly colored aesthetic this game had over the overbearing whiteness The Sentient Cube had, as well as the grim darkness Touch Yoga depicted.

On the other hand, String Theory was really, really hard to design. Since I provide no precise controls to change the movement of each collected object, the only features I could implement without frustrating the player were puzzles that can be beaten with brute force. It was really annoying dealing with this limitation, and it certainly didn't help that I was still healing from The Sentient Cube pain.

Take-away: if you're going to make a new game concept, make sure that it provides the player some sort of precision control that requires skill. A lack of this element will be greatly harmful to the game design overall. Always keep your old game's code. You never know when it comes in use! Experimenting is very important, but remember that it will take a lot of your time away from actual development, with a huge risk that it'll result in absolutely nothing.

Prototype: Munch

Prototype: Munch helped answer one of my biggest questions with games: what would second-person perspective feel like? I also took this opportunity to educate myself about Unity's free feature, path-finding. As the name implies, though, this project was unfinished due to my light-depression.

I spent about a month working on this prototype. Taking every free Unity assets in the Asset Store I can find, I think I did a great job putting together an aesthetically pleasing experiment about controlling a teddy bear through a maze. The catch, of course, is that the camera is an AI-controlled non-playable character that is slower than the teddy bear. I actually did have a parental horror game in mind when making this, but the final vision never came through, only leaving a dreadful, red-tinted graphics that has a jarringly optimistic music.

At least the prototype did have one very good intended effect: I learned a lot about Unity path-finding, and was able to implement it in Dead Man's Trail very quickly.

Take-away: depression is a serious productivity killer. Unity path-finding is surprisingly easy to implement. Second-person perspective gameplay is pretty awesome, I don't know why only a few games have it as their main form of gameplay.

Galactic NEON

Between Prototype: Munch and Galactic NEON, I had a lot of time to recover. For one, I started playing video games again, and actually cried tears of joy when playing Okami for the Wii. It was great to discover that yes, I still loved playing video games and my drive formaking them were justified. For another, e4 Software and I were trying to finish a game we started this year. The game missed its initial deadline, which left me with a nice long winter vacation from my day job (Boeing) and side jobs (e4 Software and Pie for Breakfast Studios). I took the opportunity to reunite with my family, rest for a few days, then get started in learning the new 2D engine in Unity.

Galactic NEON was always intended to be a hybrid of Asteroids and Geometry Wars. It's a neon-colored super-precise twin-stick shooter set in the infinite space. Much like any arcade game, the game becomes progressively harder as you kill more enemies. To spice up the action, there are many randomly generated power-ups, most of them changing the ship's weapon. The game was designed for the player to either constantly adopt to a new weapon, or to avoid all power-ups if the player obtained his/her favorite weapon.

The bulk of the game was made in a week and a half. The first time I started working on the game was during Thanksgiving, where I had a moving ship and 6 stationary asteroids to destroy.

I got back to the project again during the Winter break, and started working on making enemies appear off-screen to give the infinite space impression. My brother thankfully helped as a wonderful playtester who would identify different problems. With the first iteration, for example, my brother quickly found out that simply standing still and waiting for the enemies to get near the ship was the most optimal way to play the game. To fix this, I've added power-ups to encourage the player to move, as well as adding enemies that chases after the ship.

Most of my time was spent on implementing new weapons, enemies, and bombs. I also spent a fair bit of time polishing the difficulty curve. Implementing the new graphics as well as a combo scoring system came about towards the last 2 days of development. Initially, I had all the enemies color-coded, but realized very quickly how boring that looked. Instead, I randomly generate their color, and use the same technique to create the brightly colored background.

I had the game done 2 days before 2014, giving me a good amount of time to rest before MAGFest. During MAGFest, I took the opportunity to sign up to a 2-hour table slot near the indie booth, and managed to receive a lot of feedback on Galactic NEON and Touch Yoga. Both games had incredibly positive receptions, giving me the much needed morale boost.

Take-away: when feeling down, playing video games helps a lot. Unity 2D engine is pretty simple to use, though its easy to get confused with its layering scheme. Having a constant playtester is a godsend. It really helps the iterative development process crucial to making interactive software. Interactive backgrounds adds a lot to the game. Having a lot of variety in graphics is very important. MAGFest is pretty awesome. So is Okami and Xenoblade Chronicles.

The Leftovers

In between The Sentient Cube and String Theory, I've made 2 other prototypes. Prototype: Warhol was made in 2 weekends, and was intended to be FallDown! with ragdolls. While I learned a lot about Unity ragdolls, I couldn't continue making a game about essentially torturing a person. It simply wasn't my style, and I dropped the prototype entirely.

The other game was Prototype: Van Gogh (notice a pattern?). This one I created in one weekend based on a joke my friend made when he said I should make a mountain climbing simulator. I had a really hard time putting together any sort of objective to the mountain climbing, and decided to abandon it quickly.

Take-away: it's not my style to make games about torturing people. While I admit this probably won't prevent me from making violent video games, it does mean I have a limit in what I can tolerate.

Making a game based off of gameplay is good and all, but it's difficult to make it fun without an obvious objective.

In Summary

If releasing SWARM! was the climax to a story, the rest of 2013 was the falling action where I've hit into a lot of pressure and personal limitations. I heavily overestimated my stamina when I took on 3 part-time jobs on top of my current full-time job. This left me with very little time on my own, which caused both my mental and physical health to degrade significantly.

Fortunately, taking large breaks in between helped out greatly. I was able to discover several games that I absolutely loved, which motivated me to continue what I do. Furthermore, I've managed to create a wonderful game at the end of the year that has a very strong potential.

With this in mind, the goals for 2014 becomes very clear. For one, I have to find a happy medium between my own time and developing games. I also need to develop my skill at marketing since all of my games are still obscure. Finally, while I'm great at creating short games in rapid intervals, it has become clear to me that a longer, more polished games are necessary to have bigger impact on players. I plan on fleshing out several of my past projects both from Omiya Games and college so I can create a much more fulfilling experience.

I have high hopes that 2014 will be where the optimistic conclusions begins. Happy belated new year, everyone, and keep making those games!