Ash: A Retrospective

The first and to-date most successful video game project I've been associated with is Ash, a traditional RPG developed and published by SRRN Games in 2010 for iOS (later ported to Android in 2012). In this post, I'm going to revisit the game bit-by-bit, detailing what I like and dislike about the original iOS implementation of the game.

Development Overview


When our team first started working on Ash in June 2010, we were initially given what was deemed an early production version of the game. The implementation of the title had originally been outsourced to an external studio, but what that studio was producing was not what the designers at SRRN had intended. We were given the designers' goals and objectives, as well as an aggressive three-month window within which to complete the game. Personally, I was never really sure if the game could be complete in that timeframe, but with most of us still being students at UVa, I was frankly in happy-to-be-there mode, still unsure as to what we could do or what we were capable of achieving. It's worth noting also that, prior to Ash, my only experience with traditional RPGs was limited to Pokémon Blue and Legend of Legaia, though I did also have experience with table-top turn-based collectible card games such as Magic: The Gathering and WWF Raw Deal. Basically, I was in foreign territory.

Beginning on June 1, 2010, we started formal work on the game, working within the confines of a functional but drab hotel conference room to which we were given access for the summer. The first month was the hardest for me, personally; despite previous coding experience elsewhere, primarily on school assignments in native C++ and independent game development projects in C# leveraging XNA, I initially struggled to learn Objective-C and write quality production code on-the-fly. It took me a while to get under my feet on the project and make meaningful contributions, and I remember throwing entire sections of my code away because they didn't meet my standards, let alone what SRRN required. Speaking at the team level, it took about the same length of time before we had anything resembling an actual game, and though it was superior to what we were given at the project outset, it still wasn't playing out as we would have liked.

By the end of August, we finally had enough of the engine implemented to structurally complete the first two towns of the game - Nikel and Rattferd - and obvious headway had been made on many locations deeper into the game as well. In addition, the battle system mechanics were in place, most of the tilemap code and user interface was functional in its intended state, and in short it was finally looking like we had a game, and one worth playing at that. Unfortunately, the expected timeline for the project had lapsed, and the team of four software engineers - myself among them - was on the verge of disbanding for many reasons. SRRN took on an outside project was taken to keep the company operational, which required one team member. A second member of our team returned to school to finish his degree, as previously planned, and a third took a full-time offer of employment at an established studio, something SRRN, still very much in start-up mode, could not offer at the time. What resulted was a situation where for essentially the two remaining full-time members of the project were myself and my boss.

In the face of such adversity, for whatever reason, we thrived. Over the course of September, every memory leak in the code was squashed - understand that this was before XCode had implemented automatic reference counting; all memory management was done painfully by hand - and every map and cutscene was inserted into the game in at least an initial form, many receiving fine-tuning only possible once implemented. The game was in its first "finished" state on October 6 at 5 AM; I distinctly remember writing and committing the additional code and content needed to roll the credits. The final month was spent doing any and every sort of polish imaginable, such as further cutscene revision, balance playtesting, adding tutorial overlays, the addition of the vast majority of game's checking content, and the implementation of a couple minor sidequests.

Ash was released on November 9, 2010. We were thoroughly pleased with the response, with fans quite enjoying the game but vehemently wishing for a virtual control scheme. That, along with many bug fixes, was implemented quickly during the opening stages of the game's post-release support phase. The final update of the original version of the game as originally intended was released in March of 2011, adding proper screen rotation support to the game. We'd revisit Ash again in October to commence a wholesale art update and subsequent Android port.


The Story - as I said at the top of this post, I had little exposure to RPGs coming into the project, and many games I had played up through the development of Ash were not story-driven games. That qualification stated, the excellent narrative is the primary reason that this game succeeded. It hooked the player within the first 15 minutes and there was always something interesting going on to drive the player forward. The interplay between the two protagonists - Nicholas and Damien - is quite engaging and the player really comes to empathize with the plight of the two characters; moreso Nicholas than Damien, the game is Nicholas' story, but Damien has a major say in how things play out. The game finally builds up tension masterfully up to the climatic final battle, which leads to a masterful and unexpected conclusion which I absolutely do not want to spoil here for anyone who hasn't had the chance to play the game to this point.

User Interface - Everything about the user interface is designed with the touch screen platform that is the iPod in mind, and though there are some missteps I think it largely succeeds. The most commonly-used mechanics are simple to execute: to move, tap the screen; to attack an enemy, tap the enemy; to use an item, drag-and-drop it onto the character. The lack of virtual control pad was a complaint we received (loudly) and subsequently addressed with a title update. I certainly subscribe to the idea that more options are is than fewer options, but even without the on-screen D-Pad that I think the controls as originally designed are consistent and well implemented. There were also some minor responsiveness issues on older iPhones in the merchant interface if the party inventory was particularly crowded, but by and large the UI I felt was a strong point of the game.

Simple Combat - I haven't played many JRPGs in my time - a fact that my boss finds absolutely hilarious for a number of reasons - but my understanding is that their battle mechanics tend to be quite complex. The battling is Ash definitely has some depth, but it's by no means overwhelming. There are a mere six character attributes from which  all of the combat is driven, along with some special attacks with buffs and debuffs whose affects are obvious. Equipment is straightforward as well; there are weapons, shields, and chest plates, each of which affect the player in a consistent manner even within variance of individual item classifications. Consumable items were also straightforward; HP restores, MP restores, and character revives were the only such items available. Though minimal in scope, the content was necessarily streamlined, and this made the game easier to balance and, particularly important for a mobile game, easier to understand and play quickly. The simplicity of the combat also thematically fits the game; unlike many RPGs, the concept of "magic" isn't introduced until the later stages in the game. The simpler and more direct combat is by and large appropriate for a context where the player cannot employ magic-based attacks, in my opinion.

Save Anywhere and Everywhere - Of the notable features in the game, this one is the unsung hero, in my opinion. Any time the player does anything at all, the game saves into a dedicated auto-save slot, quickly and unnoticeably  Open a chest? Auto-save. Enter a new map? Auto-save. Finish a battle? Auto-save. Start a cut-scene which leads into a scripted battle? Auto-save at the position just before the cutscene trigger. This made the game incredibly pick-up-and-play for an RPG, which was of huge benefit for a mobile title. This was among the first features we decided to reprise in Ash II: Shadows

Environment Design - The actual layout of the maps is a bit hit-and-miss - the Mountain Pass comes to mind - but that's not what I'm referring to here. Rather, I'm referring to how fleshed out the environments are. Nearly everything in a town is interactive - mostly just to the end of some flavor text, but there are some surprises. That there is even just flavor text just about everywhere the player looks, however, greatly fleshes out the the environment and helps the player more deeply engage with the world of Aghaus.


RPG Maker Art - Though not a problem now as SRRN eventually grew to the point where it could staff full-time artists, the original version of Ash shipped with 95% of the art being licensed from RPGMaker VX. This led to a great deal of confusion about how the game was made during the game's initial reception. Many thought that we had somehow ported the RPGMaker software to the iPhone, which is not at all what we did; nearly all code in Ash is proprietary, with some low-level code being drawn from some open-source XCode tutorials which we leveraged to get the ball rolling. On account of that confusion, and also the art itself, the game was dismissed by some as "just an RPGMaker game" when in-fact it was so much more than that. It was one of the most frustrating points about the post-release support of the product, but fortunately one SRRN realistically won't have to face ever again.

Simple Combat - I indeed listed the simple combat as a positive for the game, but I do think it cuts both ways. Compared to other RPGs, combat in Ash was pretty straightforward. This probably disappointed some players expecting a deeper and more involved battle mechanic. The balance of the game was also a tad specific; it was relatively easy to enter a wrong area and quickly get overrun by high-level enemies without much warning, and it was similarly easy to grind battles and build up characters that could overwhelm the opposition. Further, there's no capacity in the game to adjust the challenge level of particular enemies if the player is over- or under-leveled. There's a challenge to face if one plays the game in a rather specific manner, but deviating from that path will disrupt that fine equilibrium.

Lack of Map / Log - Outside of the lack of a virtual control pad which we quickly added into the game post-release, this was the most vocal complaint. There is nothing in the game which keeps tabs of the player's previous exploits, as to remind the player what he had done previously if he had put the game down for a while and forgotten what he had done previously. More importantly, there is no map in the game whatsoever. The most we were able to do to address this in the short-term was to place a complete game map for download on the company website; a tacky solution, but at least we were able to offer one. Entering Ash II: Shadows, figuring out a way to solve both of these issues with an in-game feature was something we knew we had to tackle, and arguably our greatest design challenge during the development of that game; that's a story for another time, however.

Tools and Content Pipeline - To put it simply, the only tools we really had at our disposal during the entirety of Ash's production were an open-source tile map editor and a OSX Property List editor. We didn't have an established content pipeline by which pieces of content would be inserted into the game. We also had no tools for aiding in the creation of said content. In particular, this was quite a bear for cutscene implementation, as every cutscene was implemented by hand-writing a custom OSX Property List file, inserting that file into the game, and compiling the app. If any changes were needed, the app had to be recompiled. This process was not efficient or enjoyable whatsoever. Unfortunately, we'd revisit this problem in later projects, making our tasks for actually implementing the game part of the game needlessly much harder than they should have been.

Lasting Impression

SRRN Games earned a great deal of praise for the final shipped product that was Ash. Though not a runaway mobile game success story to the likes of something like Angry Birds, Ash definitely put SRRN on the map in the video game industry. For the company's skill level and capabilities at the time, along with the aggressive timetable of the project, the final product was likely the best effort we could have possibly made at the time, give or take a few minor details. It was an obvious springboard for us with which to jump headway into the development of Ash II, which would prove to be a far more challenging project. I'm personally quite proud of what our team at SRRN accomplished with Ash and I'm glad to have played an active role in its production.

codingCM HooeashComment