Official Sick Interactive Website Blog with Images: Here

Company: Sick Interactive

Founder, Lead Developer, Designer, Project Manager, Art Director: Casey Sick

Lead Artist: Jean Baptiste-Maligne

Game Engine: Unity3D (C# Scripting)

IDE: Visual Studio

Version Control: Git

Work Environment: Spare Bedroom, Computer, Whiteboard, Top-Ramen, and Not-Much Sleep

Start Date: May 15th, 2015

End Date: September 15th, 2015

Total: 4 months Development : Published in 5 months

Company Description:

Sick Interactive is an independent mobile game company based in San Diego, California, that develops, designs, and publishes mobile entertainment software. Sick Interactive was founded in May of 2015 and developed to give users an interactive and SICK mobile gaming experience, while at the same time, donating a percentage of company revenue directly to sick children in need.

Project Description:

This is Sick Interactive's first released mobile title. Cave Dash is a 2 dimensional, infinite side scrolling adventure built for iOS.  Silex, a Bestia creature, climbs his way through a lush and magical filled multi-directional cave system, collecting coins and avoiding pits on his way. Avoid these pits by tilting your phone horizontally back and forth, as the Mallum creatures will drill out of the moving pits and drain all your powers! Hover over the Magical June bug to fill up the Bug Juice Bar to generate points and listen to awesome tunes! The player can retrieve Magical Enchantment Scrolls. But, beware, they can be risky after +5. The higher you enchant, the faster your Bug Juice Bar will generate. The player can retrieve bug coins throughout the game in order to unlock Safe Enchant features, which gives the player free Safe Enchantments. Each player comes with custom sound effects and animations.

What Went Right

Cave Dash utilizes Apple’s new top notch graphics API called Metal. “Metal provides the lowest-overhead access to the GPU, enabling you to maximize the graphics and compute potential of your apps on iOS and OS X. With a streamlined API, precompiled shaders, and support for efficient multi-threading, Metal can take your game or app to the next level of performance and capability.” The real challenge here was creating real-time and dynamic 2D lights on transparent sprites. I could have just faked all the lighting, but the main goal for this project was to create a dynamically lit 2d game. Metal wasn’t even discovered until halfway through the project, so I suppose this was a bit of luck, since dynamically lit 2d transparent sprites are nearly not possible with lower level API’s such as OpenGL ES 2.0 or 3.0. The entire problem here was getting the dynamic lights on these lower level API’s and it really came down to the shaders being the bottleneck. It was too much for the GPU to handle draw calls with transparent sprites, which lowered FPS, causing an unplayable game.

Thankfully for the Metal API, Cave Dash now runs at optimal level. I’ve played so many games on mobile that either have low FPS, or that periodically cause huge lag spikes. When you are so immersed into the gameplay, the last thing you want is a slow game that breaks you out of your immersion sequence, which eventually makes you frustrated and wanting to re-download the game, or even worse delete the game off your phone.

The big challenge to get this low FPS in Cave Dash was the size of the textures not being POT (power of two). It was too late in the game to change all sprites in the game to POT images, which would have sped up things, reducing the image quality slightly, but allowing for more efficient sprite dicing etc, and higher FPS. So, this is where the optimization in my code had to be on key. Since this is a side scroller, the scrolling of these huge background images was the core FPS killer.

I had to develop a custom algorithm that sorts the background sections based on their type and only update them when needed. It wouldn’t have been possible without utilizing OOP and design, procedural methods, inheritance, object pooling, and polymorphism.

Each of these background sections objects contained child sprites that make up that entire section’s environment. In a typical background scroller, you allow 3 or 4 images to cycle after each other. In this case, 3-4 images cycle after each other, but “In every single direction”: Horizontally, Vertically, and Diagonally. So, this is where the complexity came into play. Each of these sections were constantly leaving their organized object pools and then cycling back into object pools where they belong, which also sorts them back for further section extraction, depending on direction. There were also moving child objects within these sections, so this just added to the importance of optimization. If it weren’t for the use of good programming techniques, using a custom algorithm, and object pooling, this wouldn’t have been possible to get such a high FPS. With weeks of testing and perfecting, the hard work paid off and there hasn’t been any noticeable fps spikes or crashes to date.

I used iOS Native for IAP’s, game center, reward based video advertising, screenshot sharing, and cloud capabilities. This actually worked out very well and I am very pleased with the model I set up, but there were a few exceptions and these are listed under what went wrong. I also used a Bezier curve editor for the custom particle system. One of the most difficult aspects of this was updating the curve’s points to meet my expectation, which involved a lot of math. It had to be updated during runtime without causing any major FPS drops. I also used the 2D Toolkit, which sped up things drastically. With this project, it was all about speed and efficiency. That worked out very well with the tools chosen.

To be completely honest, finding the right talent was very difficult with the amount of funds allocated to the project. I used Elance to contract an artist and there were 85 applicants around the world and I had most of them go through a pretty intense interview process. At first, I was only going to take locals in San Diego, CA, but soon realized how difficult this was, then branched out to other countries and was very careful about this because all work had to be communicated over messaging and Skype.

The interview process was made up of 3 tests, and sometimes 4, depending on their skills and past work history. The first test was having them sketch something from project specifications. The main reason for this is to save both sides money and time. If an artist is pretty accurate with your specifications on the first iteration, the project will get done 2x as fast. The reason for this was because I was in charge of the entire design, art direction, all programming, and running the business. The second test was a more formal concept with some color, theme, and sometimes would be a continuation from the first sketch, to see how well they could continue an asset. After those 2 tests passed, I then moved on to a third test, which was animation. The artist also needed to know 2d sprite animations and have past work to show for it. They then showed me a basic explosion animation based on another specification. After they passed those 3 tests, I’d then ask them a multitude of questions, to make sure they understood the technical side of things. Out of 85 applicants and a few weeks of testing them all, it was narrowed down just a few. The bread winner had talent in all aspects I was looking for and nailed all the tests, and questions. This is the best thing I could have ever done for this project was to hire someone who knew what they were doing in the tasks I needed them to complete. It was a good decision taking a few weeks out of the project allocated time, which I believe was still a very short time. Next time, it will be a month, at least. In the meantime, I was developing all the dummy placement holders and the core functionality of the game. The process was a success overall.

I had a slight idea this would take up some time during development, but had no idea how to turn a vision into an entire functional game. It was my first time designing and developing an entire mobile game, and it was the artist’s first time creating all assets and animations for an entire mobile game. The artist and I worked very well together, compared to many stories I’ve heard in the past with this battle of programmer vs. artist. As the days went on, we both became more efficient in listening and directing. We often sent each other advice on how to accomplish certain goals in the project, and this also sped up the development time. The methods we used were very efficient for being our first mobile game. I had written up a 30-40 page game design document prior to hire, so he quickly read through this and answered any questions he had. I then created an entire Assets list for him. This took longer than expected because I wasn’t completely sure what the final product would look like or what game mechanics and animations would need to be changed. What we did was save the animations for the very end. This allowed for game mechanic and gameplay changes without having to worry about re-doing any of the animation assets during development.

Each phase of art was finished weekly. This is typically how it worked. First I’d have him finish the sketches, let’s say for backgrounds, in one day.  Then I would have him start on concept. I would then give feedback, finish up sketches, and start on sprite development. This process was repeated obsessively until we finished.

We decided to use Trello for the art project management and github for my technical side of things and it all ended up working very well. Because of these efficient choices in tools, we barely had to Skype. We just created cards on Trello for Characters, Backgrounds, Animations, and so on. I would write specifications on those cards, then he would complete the work in the time given on the card. The images were then put on the card, feedback, card updates, and so on. After about a month of development we sped some things up when I created a document with everything for the rest of the project, including time needed to complete, and all that needed to be finished in time. This worked out pretty well.

      4. Sound

I found all the sound for Cave Dash for free or for very cheap through AudioJungle. I was pleased to find the right audio to fit into the theme of Cave Dash. All the sound was no more than $40.00.

      5. Published

I’ve developed and published 3 different websites professionally, prior to this game, but this is the first game I’ve ever developed and published a native game app. As a current student at San Diego Mesa College, I was frustrated with just doing schoolwork and was aware that I had much more potential. I took a few semesters off of college and went full throttle. What went right about this was that I didn’t fail. I published the App on the App Store, whether it gets millions of downloads or not. This was the goal I set out to do, and it was accomplished. On top of that, I started up my own business, which I didn’t initially plan on doing for this specific project, but it kind of fell into place. The game was published on October 31, 2015.

What Went Wrong

This was a big one for me. I wanted to at least get it on every single iPhone device. The game is currently released on iPhone 5S, 6, 6S, 6+, 6S+, and you can also download the iPhone version on most higher-end iPads. The devices were limited because of the dynamic lighting and usage of the Metal Graphics API. I started testing the game on an iPhone 4, which was great, but then later down the road, I solely was using an iPhone 6. I soon figured out that Metal only runs on A7 processors and above. Whoops. This was probably the most disturbing thing about the whole project. I really wanted to get it released on at least every version of iPhone. The artist would have had to redo all the art assets and I would have to implement the fake lighting, which would have taken a bit of time. I couldn’t afford it at the time and really would have rather gotten the high quality graphics, even if it was only on the higher-end devices. Another issue is that I was in rapid development mode and had so much going on all at once. I was the art director, project manager, lead developer, business owner, and marketer. All with never having done this before and learning it all within just a few months, it was a huge accomplishment. So, yes, this is something that went wrong, but then again, I did get the App out there. Next time, always test with lower iPhone versions or mobile versions in general with the lowest hardware capabilities. I would have hired others do help out, but just couldn’t afford it with the current budget.

This was definitely the most frustrating aspect of this project. The last week of development, there were some bugs in iOS Native that were produced because iOS 9 just came out. So, I had to update iOS Native. Doing so, I lost references to EVERY SINGLE sprite in the entire game. I basically had to rebuild the game for a few days straight. Since this was just prior to release, I literally wanted to die. Since I was using Git, it was my only hope. I tried doing a git reset to revert to the last commit prior to this incident, but no luck. For some reason, git decided to not save all of the object image references. It was odd because this was the only moment git was acting up and not doing what it was designed to do. I truly believe this may have been something to do with iOS Native causing this issue, or Unity itself. The only thing I could really do was just re-reference everything. Frustrating, but the only solution for this would be to either not download assets from the asset store, or, find out why git didn’t save those references. It’s setup to save the image references, but it was definitely an odd anomaly. It wasted at least a few days of development and my wrist almost fell off from clicking so much to get everything back to normal.

I wanted this to be a game that had 20+ characters available for purchase or available as rewards. I didn’t have enough funds to cover even 3 characters, so I had to settle with just one IAP character. Knowing that I only could afford one character in my “Cave Store” in Cave Dash, I had to come up with something unique. I thought about YOLO “You only live once”, then decided that the new character was going to be a Yolo Cave Gnome, that wears a diaper, and climbs the caves with his plungers. It had never been done before and I wasn’t sure if Apple would accept it, but they eventually did. I wanted to add something on the brighter and lighter side in the game. I wanted to show people that I’m up for suggestions and that this is an indie game with personality. Next time, I will allocate enough time to create more than 1 character, especially if this is one of the core revenue models to support the company.

Conclusion

All in all, the project went pretty good. The game didn’t produce the revenue I expected, but it did get completed and published, which was the initial goal. I also did get to experience the IndieCade festival and got the privilege to do some promoting with some of the Cave Dash / Sick Interactive tee shirts that were created. Cave Dash is also officially submitted to the IGF/GDC Game Competition.