The Reticle can be dragged across the screen to aim at advancing enemies.

The Walking Area is for Leo to traverse in order to evade enemies and improve his aim.

The Fire button is the trigger. Tap to fire. Hold for Automatic Rifle.

The Overdrive button will bring up a panel of teammates to summon for help.

The Weapon Upgrade button allows you to gain advance weapons based on the amount of chupacabras killed.

Coding from scratch: Having worked previously with Cocos2D, Kelvin suggested we work with the engine as he thought it would help us develop faster. However, this engineering mentality consumed much of our time. Programmer’s pride of building things from scratch prevented us from delivering a product within a reasonable timeframe.

Finding a dedicated artist: Five different artists shuffled through development since its start on Window Phone. They would work for a month or so before disappearing, literally. In their defense, it’s hard to be motivated to work and deliver when there’s no contract or income guaranteed for the project. Recognizing this problem, we moved ahead by developing the full game with placeholders. It took a couple of iterations to get our Lead Artist on the team, but Jorge felt the responsibility to deliver as much as the rest of us. In the end, this issue resulted in us waiting for art assets to be completed in order to integrate them for release.

We started without the full story: Development began with an idea and some mechanics but the story was generic and filled with plot holes during much of the production process. Worried about breaking the player experience, we revisited the story until we found cohesion. Those revisits took up long weeks of development because most of the story elements were directly linked with some confusing game mechanics.

Extending the deadline: Working on an indie project without an enforced due date requires serious discipline. We had our milestones very clear when it came to completion, but the milestones weren’t directly linked with specific due dates. Therefore, every time we finished a sprint cycle and couldn’t complete a user story, we used the subsequent week to finish it. We realized this either pushed us to work longer or cut features. More often than not, features were cut.

Not having “pay attention to detail” as part of the work schedule: We spent a lot of time working on those tiny details that would provide players a better experience. However, those details were the 20% of the work that took 80% of the time. This occurred in part to our varied focus on different tasks and willful ignorance of those tiny glitches or misplaced assets. These came back to bite us in the end thanks to the amount of work and polish they required.

CocosBuilder Issues: CocosBuilder is an open source tool we used to develop our game’s different scenes such as dialogues, cutscenes, overdrives, and more. Sadly, we had an ongoing issue whenever we published. All the project files would be deleted and since those files were in a shared Dropbox folder we literally lost them a number of times. In theory, we had to work with the source code, hack our own version of CocosBuilder, and proceed to run it with Xcode so this problem would stop. Every time we lost the files we had to revert them individually in Dropbox or email Dropbox Support so they could revert the batch, a process that took around 2-5 business days.

Obligatory iPhone 5 Support: When we started our development, the iPhone 5 was not released yet, so we were developing without taking widescreen support into consideration. Our extended deadline made us go through the different generations and thanks to the frequent Terms of Agreement Apple provides, the fineprint obligated us to include support for the iPhone 5. We noticed this when we were just about to submit our game to the App Store. As a result, we had to reformat the entire game to support the iPhone 5. Assets and code had to be restructured in order to fit the requirements. This was done in a long crunching week that had us find and fix a lot of bugs, stretching our development time until we finally released.

Poor Marketing Strategies: Having a team full of technical people has its flaws. Being indie makes you work in areas of your game you never thought you'd deal with but doesn't necessarily mean that you'll be good at them. Marketing is one of our biggest flaws because of our lack of expertise. We had poor marketing strategies, sharing on Facebook is not enough.

Switching from Windows Phone to iPhone: We had the option to continue our Alpha project, but we had to face some facts: XNA is kind of dead. We were using Cocos2D XNA, which was a product that never fully released. Cocos2D iPhone was fully functional at the moment and the market share was pointing towards iOS, so we went for it.

Organized Work Environment: We were using Scrum as our development framework, which consisted of weekly Sprints that would end with the delivery of a build to test by the end of each week. We started by doing weekly meetings on which we would lay out all the tasks we would be working on during the week. Halfway through the project we shifted on doing Daily Scrum Meetings, which helped us increase productivity by around 500%. All the meetings were held by phone, Skype, or in the worst of cases if we needed to do screen sharing, G+ or TeamViewer.

Documentation, Documentation, Documentation: We were very thorough with documenting everything so we wouldn’t have to redesign by lack of documented concept. Therefore, every time we had to redesign or revisit some concepts, it was because of playtesting results or flaws. Most of the documentation was completely visual or at least provided visual references, like mechanics functionality using PowerPoint, cutscene concepts using Penultimate for the iPad, or concepts simply on good old pen and paper.

Team Dynamics: The team was encouraged to be open with their problems all the time. We all understood that the faster we put our issues out in the open, the easier it was to deal with them. We were lucky the team knew how to handle remote work and respect each other's roles. Everyone could contribute in discussions but the Lead had the final voice. This ensured less time spent in arguments and more time developing. If for some reason the Lead wasn’t available for a discussion and the issue had an alternate solution that didn’t need the specific Lead, we would adopt it. Lastly, the team felt the commitment to deliver the product and every member found ways to motivate themselves, and each other, towards reaching our goal.

Research and Adapted Design: Heavy research fueled the dramatic changes between the Windows Phone and iPhone versions. I played a lot of games, good and bad, in order to reach the final design. I think I found a decent flow in Barricade: Midnight Terror where the Survival section keeps the player tense and then releases said tension in the Resource Gathering mode while keeping the player active.

Incorporation of 3^rd party tools: Using tools such as CocosBuilder, TexturePacker, and PhysicsEditor helped us eliminate months of work and automate our processes for faster development cycles. Although we practically built the game completely from scratch, I acknowledge that without these tools we would still be in development.

Paying attention to detail: I previously mentioned the negative aspect of not including this as part of the work schedule, but that doesn’t mean we didn’t pay attention. When we finished Beta and started to polish for release, we got to relieve the itches of noticing low-quality aspects within the game. This demonstrated the team’s level of professionalism as we wouldn’t accept any mediocre work from ourselves or each other.