Barricade: Midnight Terror started off as “Barricade”, a small project for Microsoft’s three-month App Idol competition in Puerto Rico from April to June in 2012. While we were excited to place as runner-up in the event, we weren’t able to visualize the game’s future on the Windows Phone platform. We opted for a fresh start and took the plunge into the dark realms of iOS.
This game was the first intellectual property for our studio Kraniumtivity Games, LLC., and we started production for the title officially in October 2012. I was an online student at Full Sail University when we started, so I had little time to spare between my day job and classes. Our stellar programmer, Kelvin Bonilla, was also in a similar situation thanks to his full-time job at Hewlett-Packard (HP). Nevertheless, we knew that shipping this game would be essential if we were to call ourselves professional game developers.
We came across complications during development, like all developers do, but we also found ourselves handling some unexpected situations that greatly affected production. A handful of these involved:
Kelvin quitting his Software Engineering job at HP so he could better focus on following his passion as a game developer.
My job transfer and eventual leave to focus full-time on academics and my final project at Full Sail University.
Kelvin and I volunteering as Conference Associates (CAs) at the 2013 Game Developers Conference! It was an incredible experience and we met many industry professionals who gave us great feedback on our game, specially regarding some flaws that we fixed as soon as we got back home.
Our involvement in starting Puerto Rico’s first chapter of the International Game Developers Association (IGDA). Motivated by our CA experience and IGDA’s substantial role in GDC 2013, we founded the chapter so we could organize events for our local developer community.
The completion of my final project at Full Sail and subsequent graduation. This helped me fully devote myself to finishing Barricade: Midnight Terror in the subsequent month.
While that was an extensive tangent, it’s an important piece of backstory that led us to extend our development time.
Our small team wore many hats, you know, because indies. Most of us couldn’t work full-time on the project, but our core team managed the following roles:
Kelvin Bonilla - Project Manager & Lead Programmer
Jeb Alvarado - Lead Designer
Jorge Colón - Lead Artist
Stephen Alberts - Concept Artist & Designer
Daniel Sosa - Environmental Artist
Pablo Colón - Audio & Sounds
Christian Rodríguez - QA
Let’s not forget those who helped us lay the foundation for our game during its humble beginnings on the Windows Phone:
Emmanuel Barreto - Concept Artist
Jose Luis Torres - Artist
Anner Bonilla - Programmer
Barricade: Midnight Terror is an action/survival shooter that pits you against hordes of chupacabras in the dead of night. Players must survive six levels that include a mini-boss encounter and a final boss battle. Each level becomes progressively harder with each passing night as more and more chupacabras attempt to destroy your barricade. As the sun rises, chupacabras retreat and the game alternates to a second gameplay mode - resource gathering. During this period, players must effectively manage their time while searching the surrounding areas for supplies, repairing the barricade, and travelling to new locations. If the player does not accomplish their tasks before nightfall, they risk run-ins with the Chupacabras as they return to attack once more.
The game includes rich storylines and character development in the form of cutscenes and quirky dialogue. The narrative is also embedded with references to Puerto Rican culture.
The tale revolves around Leo Renan, the unlikely leader of an elite team of skilled soldiers sent on a mission to a distant Caribbean island. Their objective was to extract a captive scientist from an enemy base but unaware of his impending rescue, the scientist rigged a massive explosion that destroyed the lab that held him hostage. The ensuing damage allowed the escape of his biologically modified experiments - the chupacabras. Leo and his team are alone in facing the major threat posed by their escape and the ensuing “protective” measures by other nations to destroy the island within the next twenty days. It’s up to the team to find a way to defeat the chupacabras across the island. The challenges imposed throughout their journey will lead them to make decisions they might never consider in order to reach the Oleander Base; a safe haven that harbors their only opportunity for escape. Will they make it?
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.
There are two main modes of play, action-packed Survival runs and strategy-based Resource Gathering.
Defend the barricade: Protect your barricade from dusk until dawn. Waves of chupacabras will come to destroy the fortification and once that’s down, you’re next.
Move, Aim, & Shoot: Change Leo’s position and create waypoints by taping inside the barricade area. Aim by dragging your finger across the left area of the screen outside the barricade. Last but not least, tap-tap-tap the fire button!
Summon your allies: The Overdrive button brings up the team panel where you can choose a special ability from one of your squadmates. The fuller the Overdrive Bar is, the higher your rate for a successful attack.
Upgrade your weapons: The Weapon Upgrade button is ready for use whenever the Weapon Bar is full. Once the player activates it, Leo's pistol will upgrade to a rifle while activating a countdown. If the player manages to fill the Weapon Bar by killing enough enemies before the countdown expires, the rifle will upgrade to a rocket launcher. Otherwise, the rifle downgrades back to a pistol.
Find resources, the clock is ticking: Search different rooms and odd containers in order to find the supplies needed to travel to your next location. Once you locate something you need, tap to pick it up.
Break everything: Locked rooms bar your progression but you can break doors down by continuously tapping them until they break. Same rule applies with containers.
Find “The Shack”: A special room in each progression with a Barricade Repair Table and the Travel Backpack.
Repair the barricade: Whenever chupacabras bring your barricade down, you can fix it on the Barricade Repair Table found in The Shack. To fix it, just drag the correct pieces of the puzzle into the blueprint instructios.
Check the Minimap: Traveling through the different rooms might be a bit confusing at first, so whenever you feel lost tap the minimap and it will display your current location as well as the remaining days and your current supplies.
Escape!: Once you find the resources you need to travel, do so. Previously visited locations will appear blue and unreachable locations are marked red. Your next location will be displayed in full color. Travel onward as soon as possible as each passing day increases the difficulty of Survival and brings you closer to the nuclear missile attack.
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 3rd 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.
Although this project grew larger than expected, we were capable of delivering the final product. Developing games is no easy task and we managed to overcome almost all our challenges while working remotely with no pay and part-time jobs on the side. This game is the proof that we needed to realize our potential as a team. Coming from a small island with no industry makes it very hard to stay motivated, but knowing that we would be delivering one of the first games Puerto Rico has produced kept us going. There are teams inside and outside the island with better resources who still aren’t able to deliver due to many variables. It makes us proud to acknowledge that we did.
While I’m aware there are mistakes the team might experience again, we learned so much through this project. My team now has the experience and the knowledge to deal with similar issues the future may bring. We will have a better focus when we confront our next challenge: development speed.
In a world compelled by experiences, Barricade: Midnight Terror serves as our industry debut in creating philosophical escapades that question a player's reasoning and perspective. The game ultimately seeks to create an environment where morality is not only questioned, but turned upon its head. Check out the game on the iOS App Store here.