Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs or learn how to Submit Your Own Blog Post
I take a look at my first indie game and some of the mistakes I made along the way. In particular, I look at the difficulties behind making pay-to-play work in 2015's App Store.
Catalyst has been out for a month now, so the timing feels right for some reflection on how it's done and what went right and wrong.
Sales overall have been pretty slow across iOS and Android (a little better on iOS). Overall the game was received positively by those who downloaded it, but failed to make much of a splash on the app charts / social media / blogs I reached out to. Let's take a look at how I approached my first indie title.
Catalyst was done in five months, from prototype to the App Store / Play Store. I set out to do a game in six months or less in order to learn the ropes of cross-platform app development and all the art / sound / promotion work that goes into it. I was able to quickly prototype and iterate the game concept while getting quality feedback through TestFlight and Google Play's alpha program. Looking back at old screenshots, it's amazing to me how quickly the game morphed from one mechanic to another. Here's an abridged evolution of Catalyst:
A game where you flick gems and collide them for points (I used the gem artwork of an old game I worked on). Keep the grid clear of garbage blocks by colliding gems nearby. My initial inspiration for the game was the simple flick mechanic applied to a matching game, which is pretty much the only element that stayed from this part of development. The prototype I had here was pretty boring, though playable.
The largest overhaul to the system, and one where a lot of the final game elements came into place. I moved to a 4-by-4 grid to focus on elegant gameplay for phones - rapid sliding on a grid this large is easy even for fat fingers. The game here was sort of a mesh of Tetris and Rubiks cubes. The player is given patterns they must line up by sliding pieces around - having more patterns matched at once results in much higher scores. There were a lot of balance problems here - getting one match was trivial but getting more than one simultaneously was impossibly hard for most, which led to most players just going for one and clearing it. This led to a very boring game with a disjointed death mechanic (a red line fills up in the background which could be pushed by matching).
This iteration doesn't address the problems I just listed, but it was a nice moment of elegance when I realized i could overlay the patterns directly on the grid. The issue it raised, however, was the visual overload from so many different nearby lines that formed the pattern outlines. Which led me to my next breakthrough...
Molecules! By using a molecular visual pattern I greatly reduced how many lines were on screen while keeping the patterns super clear. This is a good example of basing a theme around a mechanic, instead of starting with theme. Another big change - molecules spawn at regular intervals instead of after a player matches one, hence the "next" box. When there's no place for a molecule to spawn, the game ends. However, it was unclear when exactly a molecule would spawn, which led to some frustrating loss. Leading to the next innovation...
A conveyor belt! Balls with numbers move down the belt at a set speed, and when they reach the end, a molecule spawns of that numbered size. When there was no space to spawn, they would start backing up the belt, and the game ended when the belt was full. This added a lot of visual complexity but made the mechanics a lot more clear. It also introduced the "fast forward" button for hardcore players.
A first attempt at puzzle mode. Originally there was an indicator showing the exact combinations needed to finish the puzzle, but it was quickly obvious how useless this UI element was.
And voila, final visual overhaul! I went with hexagons since they meshed well with the molecular theme while maintaining minimalism. I still tweaked some colors after this but was really happy with how the games visuals ended up. The final mechanic change was getting rid of the belt and just having the molecules spawn on the board directly. I briefly had a hexagon styled conveyor belt before the change (note the hexagons near the fast forward button).
In short, iterate fast and don't be afraid to throw out ideas that don't work!
Catalyst was always driven by minimalism, both graphically and design-wise. Minimalism helped with dev time tremendously; as a one man team, keeping the scope small was critical to finishing the game in my time frame. Minimal graphics and sticking to very simple shapes and icons meant I could the graphics myself while keeping the aesthetic pleasing and coherent. Keeping the game to two modes meant I could focus on making those two modes work really well; keeping to 70 puzzles meant I could work on well designed puzzles with very few repeated elements.
Another advantage - scaling to older devices. It was great to see that even devices as old as the iPhone 4 (nearly a four-and-a-half year old device - crazy, right?) could run the game at a smooth framerate. Having less graphical elements also meant scaling to various screen sizes (especially important on Android) was a lot easier. I've heard a lot of horror stories of how difficult maintaining your game on a thousand different resolution and operating system combinations could be, but keeping the feature set small and graphic elements to a minimum made it a breeze for Catalyst.
I can't speak highly enough of how well the sound design of the game turned out. I worked with David Krystal throughout the game's development to make sure the sounds meshed with the game's visuals and themes well. We made sure to keep a constant conversation going and experiment with many styles before narrowing down the exact sound we liked. Integrating sound and gameplay worked especially well with the theme for Endless Mode, which has carefully timed increases in intensity to match the escalating gameplay. If you haven't played the game, check out the result - it's a real treat towards the end. In the future I'll make sure to continue a close, friendly conversation with anyone who contracts with me.
The Marmalade SDK attracted me at first for a few reasons: the cost ($500 for iOS + Android vs $3000 for Unity), the Quick APIs (a Lua layer on top of Marmalade for fast 2D development) and fast, near-native code performance. To be fair, Marmalade delivered on those three points, but as Catalyst matured the flaws quickly started becoming obvious. One issue I had was with Quick itself - it runs on top of Marmalade's C++ layer and exposes only a tiny fraction of its APIs. If you want to access ANYTHING outside of those APIs, you have to write custom C++ wrappers to expose functions to Lua and then re-build the entire Marmalade Quick interpreter (and hope you don't break anything in the process). This would be okay if it were a rare exception, but some of the gaps I found were really surprising. iOS Game Center support? Google Play Games? Launching the device's web browser? All not there and require custom wrappers. I had to write enough of these to question why I was using Quick in the first place.
A bigger issue was speed. Ironically, Quick is actually quite slow when it comes to app loading performance. A simple "hello world" type app takes a staggering 7 seconds to load on a modern Android device, which is simply unacceptable. This is due to the Lua layer, which adds a ton of scripts that are forced to be compiled at runtime. Perhaps even worse is that you can't show any kind of "Loading" splash screen on Android; there are options for splash screens but they will disappear to full black when the core app starts to load, making them essentially pointless (they stick until the app loads on iOS at least). This is simply a deal breaker for using Marmalade Quick going forward.
Finally, there just isn't a lot of support for Quick out there. Documentation is sparse and sometimes unfinished. A lot of issues I ran into had empty support threads, and it's clear that Marmalade is focusing more on adding features to its core C++ set than getting Quick up to par. I'm in the early stages of learning Unity and the difference is night and day. I can't tell you how valuable it is to be able to google an engine question and just about always find an answer!
While I'm happy with how the core gameplay of Catalyst ended up, the approach was ultimately not enough to stand out. At the end of the day most classify it as "just another matching game"; the core mechanic didn't create enough of an identity on its own and the visuals or sound couldn't carry the game. An important piece of advice I keep in mind is that your game needs to "tell a story" and that story needs to be unique, relatable, and easily communicated both in text and pictures. Catalyst never had much of an angle beyond "minimalist puzzle game with no IAP or ads". When competing in as crowded of a market as the App Store, your game has to stand out and have a unique angle.
In a somewhat related note, I could have done a better job of giving updates throughout development. Catalyst was mostly done silently with just a few screenshots leaked out through #screenshotsaturday .Other things I should have done (expect to see a few of these for my next game):
A dev blog.
Having a press kit / mailing list early on.
Facebook fan page / Twitter account for game specifically.
A Toucharcade development thread.
Presence on other development forums (TIGSource / IndieDB )
More open communication in general!
This one is a bitter pill to swallow, but I believe that in general premium games on mobile are dead (Catalyst launched for $0.99 and is now $1.99). My theory is for a premium game to work, you need:
An incredibly fun and original mechanic that sells itself.
Incredible production values and aesthetics.
Be an established developer with a good track record and/or have a lot of press going for you.
Be really lucky, or at the right place at just the right time.
You almost definitely need two of these things, and most likely need three or all four, to even have a chance at a premium hit. Otherwise, you simply don't have the penetration - players won't have enough confidence to be willing to spend even a dollar to try out your game. Why pay for yours when there're a thousand free alternatives with 4.5 star ratings?
Gamers like to preach how IAP are the devil and that they will definitely support developers who go premium-only, but this turns out to be nothing more than a loud minority. The race to the bottom has reached the finish line, and premium lost. A huge focus going forward for me is to find a way to do F2P without ruining the player experience or filling the core game loop with greed. It can definitely be done! (just look at Crossy Road)
A lot of Catalyst's problems manifested before the game even began full production. I picked a genre that was already flooded in the App Store and did very little to stand out. I picked a monetization model that is almost impossible to pull off in 2015. I picked an engine that has little support and flexibility for the wrong reasons (cheaper cost, easier to learn).
The actual making of Catalyst went smoothly, but for my next game I intend on being more cautious before committing to a full development budget. Wooga makes 40 game prototypes each year and only 3 make it to a full launch. While I don't have that kind of manpower, the idea of quickly prototyping, testing it with a few players, and only going further if the idea clicks feels like the right direction. This post by Rami Ismail expands on the importance of making a lot of little games; you can often learn more through failure than through success. Even if Catalyst wasn't a chart topper, I leave it a better game designer, and hopefully my next major game will be proof of that!
Read more about:
Featured BlogsYou May Also Like
