tiogus, Author at Helldorado Team

Game Engines – To build, or not to build: The Eternal Conundrum (Part 4)

Design and Development of Condor Wars

It was June 2012. It had been almost 1 year since I traveled to Bogota to work on The Descent for 3 long weeks as I mentioned already in Part 3. During that time we completely forgot about game development for a while and parted ways momentarily. Elias continued work on his baby YouOrderIt, which he was developing exclusively for his restaurant and I continued my graduate studies. In Summer 2012 I started a 12-week internship close to Detroit, Michigan and found myself with a lot of free time on my hands. I was also in a contemplative mood and somewhat depressed during the first couple of weeks of the internship. This was prompted by many factors – the work was not hands-on and I feared losing my technical coding skills. I had this paranoia that if I stopped coding in cold turkey fashion (my new career path demanded a different set of skills – mostly technical but strategic) I would be bound to forget coding and the dread of this idea made me feel worthless. I had been coding for almost 11 years so programming was an essential part of who I was. For this very reason I always kept a side project under my belt at all times in addition to my full-time professional responsibilities.

The situation in Summer 2012 accelerated my desire to get back into coding mainly to feel better about myself:

I was afraid that after taking a 1 year break my coding skills had decreased (a fallacy since Bill Gates in 1995 claimed he could write “slicker” code than John Carmack during a Windows 95 event even though he hadn’t obviously coded for many years)
I was living in the middle of nowhere and the setting was depressive, further exacerbating my depressive mood
I was running out of Breaking Bad episodes to watch, needed something to do ASAP

The situation above made me open Android Studio immediately. I had never played around with Android and OpenGL so I decided to develop a small proof of concept to test ideas and scrape off some of the coding rust I had hypothetically developed over the past year. Also, I didn’t want to deal with the Android Canvas library ever again so OpenGL seemed like the only alternative available. Ten years before during undergrad I had dirtied my hands with OpenGL for 3D programming so I didn’t expect a steep learning curve.

I toyed around with the concept of a spaceship flying through the vacuum of space, moving with the use of thrusters and attempting to avoid planets and asteroids. After a couple of days I had the proof of concept in pretty good shape and had tested out OpenGL graphics rendering, physics, game controls and some game mechanics ideas. It felt like I had gotten back in coding form so I archived the proof of concept and began brainstorming other ideas that had the potential of maturing into an actual game.

After a call with Elias we decided we wanted to release something very small – even smaller than The Descent. The Descent’s development was problematic due to the limitations we faced with the Android Canvas library and because of our lack of focus and direction. We also faced some challenges in our art department which added more obstacles into the mix. After learning from previous mistakes we didn’t want to play around with new ideas but rather with something simple that felt familiar. We also wanted to avoid having to depend on an artist or graphic designer to deliver game assets. We only had a 10-week timeframe and we wanted to control all aspects of development – adding a 3rd party artist/designer in a constrained timeline felt like adding a potential dependency for release. My internship ended by the end of August 2012 and we were targeting to release before I went back to graduate school.

We decided to resurrect a game that Elias had developed in assembly language many years previously called Condor Wars. We already had the game assets – there were only 2 types of sprites: the player’s spaceship and the enemy alien. The latter came in 2 flavors: green and red. The game is reminiscent of Galaga and Galaxian and the mechanics simple – you control a spaceship at the bottom of the screen that can only move left and right. Enemy aliens spawn from the top of the screen and zigzag downwards towards the player. They spawn randomly at certain intervals and the game objective is to dispose of them with the laser. The player can shoot the laser by tapping the screen. The simplicity of this gameplay made the technical requirements trivial:

Draw a player’s spaceship sprite and the spaceship laser
Draw a black background with randomly generated stars that move downwards to give the illusion the player is traveling through space
Draw enemy alien sprites
Manage an array of enemy objects that spawn randomly from the top of the screen (NPC object management).
Draw enemy alien explosion animation
Draw the player’s spaceship explosion animation
Draw raster fonts that display the player’s score
Handle collision detection between the player’s laser and enemy bounding boxes and also between the player’s bounding box and enemy bounding boxes (simple rectangle to rectangle collision detection).
Play sound effects (no music)

The limited technical requirements above didn’t warrant the use of an SDK such as Corona or Cocos2D so using OpenGL seemed like a decent option. There were only 5 types of objects displayed on the screen at any point in time: 1) the player’s spaceship, 2) the player’s laser, 3) the enemy aliens, 4) raster fonts and 5) the black background with stars. Managing the rendering order for these 5 objects was already predefined so a complex Scene Graph implementation was not required. For example we knew the rendering order would be the following:

Background and fake star field
Player’s spaceship and player’s spaceship explosion effects
Enemy aliens and enemy alien explosion effects
Player’s spaceship laser
Raster fonts

In the draw() method we just made sure to render the game scene in the above order. Some complexities were involved with the loading, managing and rendering of OpenGL Textures for all of these 5 objects. However we developed boilerplate OpenGL texture loading and management code and carried on without deliberating if using an 2D Graphics SDK made better sense.

So after 10 weeks of development we were close to release. My internship ended in late August 2012 and I went back to school. Two weeks later we finished development and released Condor Wars to Google Play. After almost 8 years Condor Wars became Helldorado Team’s first game officially released to an app store. Everything we had done before amounted to technical demos, prototypes and proof of concepts. We downloaded v1.0 of the game from Google Play and the game crashed horribly due to a last minute production release bug. A fix was made and we released v1.1. So we downloaded the patched version and played the game again. But after playing the first couple of levels we realized something: The game was terrible. After 2 or 3 levels we found ourselves bored and you were lucky if you didn’t find yourself yawning beyond level 4. If you had to find 1 word to describe the game it would be sleep-inducing. A friend of ours claimed to have reached level 255 (the last level of the game and a nod to the 8-bit era) but I’m prepared not to believe such tales.

We realized we had found ourselves releasing yet another prototype masquerading as a game – but that had been our intention all along. We had committed to develop and release a technical demo to Google Play in order to experience the Android app release cycle, and we learned valuable lessons from that process. Before development both our mission and goal had been clearly defined and we followed through till the end. In some ways Condor Wars was a pilot test, and the foundational code that was developed for it served as springboard for the development of Condor Wars Redux, where we made some of our biggest mistakes in our game development experience. For Condor Wars we picked the right library (OpenGL) for the technical requirements which had been correctly identified before development, so the mistakes we made with The Descent were not repeated.

When tempted to release something (either a prototype, a demo or some semblance of a game) early due to external or egotistical pressures some conflicted developers advice to consider the words an ancient and wise monarch (who was also an accomplished coder) once said:

“Cherish an unpolished gem in your local machine. Abhor a turd in the App Store.”

– Alexander the Great of Macedon

With Condor Wars we learned that as a developer you are constantly faced with the following predicament: release your technical demo too early thinking that it can pass off as a game, or hold off the release of your pet project until it achieves a certain level of “perfection” or it fulfills your unrealistic ambitions. Most of us are tempted to lean towards the latter, and this is exactly what happened with The Descent (amongst other issues). Despite what Alexander the Great once said, it is better to release a piece of excrement to customers and gain valuable feedback than to let your closely guarded, ambitious project that hasn’t seen the light of day fall into oblivion due to your own high standards.

The disappointing story of Condor Wars Redux, as it was codenamed, will be the subject of our next article.

Game Engines – To build, or not to build: The Eternal Conundrum (Part 2)

Go to Part 1

As game developers, our main goal is to make games, and fun games. And by fun we mean games we want to play and games that will be dowloaded and played by others consistently. For the purposes of this article we are not going to dwell on all aspects of game development – from coding to play-testing all the way to marketing. We will only focus on development aspects because these are the areas we as game developers can control and cannot be affected my external factors or luck. After all whether your game gets 1000+ downloads on its release date is due to many factors. These factors will generate their own set of headaches so it would be best not to focus on them at this time.

However, you can control gameplay mechanics – if you want the game character to move left or right depending on the intensity of the swipe of the screen (for a mobile game) you just open Xcode (or Android Studio or any other IDE) and code the damn thing. Whether you succeed in this attempt might also depend on the number of brain cells you have but we assume your brain is perfectly equipped with these otherwise you wouldn’t be reading this article.

The game development landscape has changed quite a bit. We now have countless of avenues that can be used to release our games for instance Steam, Google Play, and App Store to name a few. Literally thousands of games are released every day and there is no such exclusivity and scarcity of games like there was in the past. In the early-to-mid 90s if you wanted a free PC game you had to scavenge your way through shareware sites and you were lucky if any of the titles available tickled your fancy. We now have an irresponsible overload of games and the result of this folly is that Google Play and App Store have become graveyards for the majority of games that are released every day. There are just too many games out there. Sometimes I ponder why we haven’t faced a mobile game industry crash like we did with video games back in 1983 (thanks Atari!).

Even if you (as an independent developer) think your game is solid and “fun”, there is no guarantee that your precious little addictive game will not be at the bottom of the App Store rankings and fall into oblivion together with thousands of other orphaned titles. The basic lesson is that game development is hard not because coding is hard but because game development is an intractable medium with success factors that cannot be easily controlled. And we have to learn to live with it. For many aspiring developers months of sweat and blood during development hells amount to nothing. Titles are released by countless of established companies or independent teams with the uncertainty of Julius Caesar crossing the Rubicon. You push the Archive button in Xcode with high hopes to release your title to the App Store and literally alea iacta est, the die is cast – leaving almost everything to chance and leaving your hundreds of hours of development at the mercy of App Store ranking algorithms.

My wish is not to alarm readers – I am just basing the above observations on previous experience. In a nutshell the main lesson is that game development as a whole is hard albeit fun and rewarding and we should be prepared to navigate the harshness of the terrain ahead throughout our game development journey. This demands a different kind of mentality. Understanding the uncertainties ahead we have to cherrypick our battles wisely and know what to focus on when we sit down and open Xcode to start developing.

As a game developer it is very easy and quite tempting to get bogged down on unnecessary details such as the technical intricacies of developing a new “font rendering library” or a “special effects/particle rendering system” for our little game even if it sounds fun to write and perhaps because I could potentially learn something useful from writing it. We sometimes face Developer’s FOMO (Fear of Missing Out). If we don’t know something inside out, or if we don’t develop it ourselves we don’t feel in control. Using someone else’s library or SDK equates to surrendering control to a 3rd party who is a subject matter expert in a specific area, and this thought hurts our ego. We are even prepared to think: “That random guy in Ukraine created this beautiful PNG compression library for hardware accelerated games which I probably need for my game. He built this library with his bare hands, so I can too! I will probably learn something cool and useful along the way!”. These internal monologues pigeonhole us into unrealistic and inefficient paths – further detracting us from our goal to focus on more value-add game development activities for example pure gameplay mechanics.

We even make ourselves believe that some 3rd party developer’s highly acclaimed font rendering library could become obsolete or deprecated in the future and create a potential external dependency. An asteroid could also fall on the 3rd party developer’s head and kill him and that would be a frustrating inconvenience – who will support that library in the future? Better to write it ourselves right? We dread having to deal with these external dependencies and factors so we have the temptation to avoid them at all costs. The worst thought of all is thinking we need to write something ourselves because we could potentially modularize it, package it and use it in the future for another game. Maybe even sell it! The possibilities are boundless! Chances are your nice little font rendering library works fine for a subset of use cases isolated to your game and cannot be used a second time because your next game might have different font rendering requirements. Chances are that perhaps you are never going to build a second game because you wasted all of your energies writing foundational engine code, recreating graphics, physics and all other core libraries yourself and no longer have the stamina to focus on gameplay code for your hypothetical second game.

Our optimism and wishful thinking clouds our judgement and we easily lose interest or get burnt out along the way. We end up with games made up of 70% foundational engine code and 30% half-baked game play mechanics because we didn’t have the discipline to focus on gameplay code – we have no gas left in the tank because we focused all our energies on library and game engine development and nothing else. We end up with half-finished prototypes or nifty technical demos that only we can admire in silence as we secretly pat ourselves in the back on a job well done. We are delusional to a certain degree. We admire the intricacies and the complex moving puzzles of our custom-made particle rendering system even though users are not playing (or reviewing) our games over and over again due our special effects library’s ability to render 50K particles in a single frame with ease. It’s how gameplay mechanics interact with other technical subsystems to provide players with an overarching experience that is fun, challenging, rewarding, immersive and stimulating. As game developers this should be our sole focus.

At Helldorado Team we’ve fallen prey to all of the above fallacies during the past several years and we would like to share our experiences answering the to build or not to build question in our past game projects whenever we’ve faced a decision to build core engine code. Stay tuned for more.

Go to Part 3

Game Engines – To build, or not to build: The Eternal Conundrum (Part 1)

A young, aspiring game developer is one of the most admirable human specimens you will ever encounter. Eager, hopeful of the future and with a insaciable hunger for knowledge, he strives to learn by experience anything he can lay his hands on. In this respect a young game developer is like a sponge and no dissimilar to a 2 year old toddler. Knowledge is a precious jewel to be acquired and guarded at all costs. During the early phases of learning a game developer has no focus since everything could be potentially useful – algorithms, design patterns, optimization, data structures, game engine fundamentals, graphics programming, rudimentary AI concepts, Newtonian Physics, etc. The list goes on an on, but during those stages everything is interesting and non-trivial – as each of these topics has the potential of building on the foundation necessary to become a well-rounded game developer.

Many of us recall those early phases – deep-diving on graphics programming concepts, contemplating on the differences between 2D and 3D graphics programming, understanding (or more accurately attempting to understand in vain) Binary Space Partition (BSP), texture mapping, software rendering, shadowing, the different kind of shading (flat vs Gouraud vs Phong vs whatever else became industry-standard these days). Those are just a subset of topics, but we all recall the countless prototypes we put our hearts and souls in – written in old Microsoft DirectDraw interfaces or OpenGL. Little algorithms that we feel so proud of, that satisfied intellectual and problem-solving longings but more than that strengthened our foundations in game development. These little programs served their purpose at the time – we needed to understand these concepts well and we felt a fascination in understanding the complex, interwoven puzzles that make up what we see on the screen – from the pixel drawn on the screen to the shadow cast by a game character in a simulated ground.

Our first prototype of a pixelated blur resembling a spaceship blasting away more pixelated bullets was one of the most gratifying moments of our professional or amateur careers. We understood why those pixels move and how the algorithms we wrote organize the bullets to be shot. The academic and intellectual goal reached, we moved on to more ambitious prototypes in the search of testing newer and more complex ideas. At the time, the more we read and the more the dug inside the game engine trenches the more intriguing the whole experience became. Today we learn how a pixel is drawn on screen, tomorrow we could learn how to perform full object culling with algorithms written with our bare hands. The possibilities seemed limitless.

The desire and the hunger for dwelling to such granular levels in our conquest of every game programming is also rooted by the stories we read as well – real or romanticized. We read how highly motivated duos, trios, quartets or even lone wolves lock themselves up in a basement or a lake house and by the sheer momentum of ambition pull off a feat unmatched by today’s standards. These are the Carmacks, Romeros, Sweeneys and the Ken Silvermans that we both admire and to some degree despise. Admire because of their monumental accomplishments that we so highly covet. But we also hate them because they accomplished so much with so little at their disposal at the time. In turn today we have so many resources at our disposal that this comparison seems both unfair and shameful. John Carmack and Tim Sweeney both developed game engines from scratch on their own. Carmack single-handedly developed software and hardware-rendered graphic engines for multiple blockbuster titles with the rapidity of an industrial assembly line. Sweeney performed a similar feat. Ken Silverman is honored now with a more memorable task given a shorter timeframe – this one man army surpassed the technical accomplishments of id Tech 1 (Doom Engine) and produced the Build Engine now used by several games that are household names in the PC gaming community. He was 17 at the time. We need not pay homage to Romero here. This self-proclaimed “Project Specialist” did everything that was necessary to ship a game out the door – game design, game programming, graphics programming, tools programming, level design and even PR to name a few.

I believe that the stories we read in books such as Masters of Doom both inspire and set the wrong expectations for aspiring game developers in 2016. Inspiration is most welcome, but truly speaking the dangers of setting wrong expectations (or standards) as game developers far outweigh the benefits of short-term inspiration. After reading such books we want to be heroes like the ancient legends of the 80s and 90s and feel the need to become jack of all trades like them. We want to be able to write gameplay code, draw digital art ourselves as well and similarly be able to re-create Carmack’s Reverse Shadow Volume Algorithm by memory. This is what developers did back then so why should we be deprived of similar honors?

Our egos are already hurt because we are now one Google keyword away from finding that solution in StackOverflow that has eluded us for days on end. However we now live in a highly-specialized environment. We are no longer in the nostalgic era of the 90s. Highly dedicated garage duos are now seldom producing and releasing blockbuster titles in Steam, Google Play or the iOS App Store. In the same vein there are no such things as prodigious hermits living in grandma’s basements developing every single granular component of a game (graphics, physics, AI, network, etc.) themselves. This myth is both dangerous and irresponsible to believe. The current environment is forcing us to become more specialized in the skill sets we can offer to the game industry.

To be a game developer 25-30 years ago meant many things. Nowadays it has a very different meaning.

In this series of articles I will be discussing one of the conundrums that has been a heavy burden for Helldorado Team (for many years actually) regarding Game Engine Development: to build or not to build your own game engine. I will discuss the wonders, perils and what to take into consideration when attempting to tackle this dilemma. Stay tuned!

Go to Part 2

The Descent v1.2 and Free Version Released!

We just released an update to The Descent (v1.2) but we realized that a small but pestering bug was introduced related to achievements (boo!). Somehow, even though the game only has achievements you can unlock once, Game Center will keep showing the “you’ve unlocked achievement..” after unlocking the same achievement over and over again. Somehow we believe Game Center doesn’t really know you’ve unlocked the achievement so it keeps unlocking it all the time after you earn it. We are looking into the issue ASAP and will let you know (via a blog post or a push notification directly to The Descent app) when we find a solution.

Luckily, we also released a free version of The Descent that is now available for download:

The Descent Free!

This version doesn’t exhibit the weird achievement bug mentioned above and it also shares the leaderboard of the paid version of The Descent. Switch now to the free version so you don’t get blasted by repeated Game Center “new achievement unlocked” notifications!

The Descent v1.1 Released!

After a couple of hiccups during the v1.1 app update review process, The Descent v1.1 is finally released – available exclusively on the App Store. We added music on the title screen and new sound effects on the game over and new record screens. Some bug fixes have also been included in this update.

We’re working on the v1.2 update which will include more bug fixes and some new UI elements. We will also be including push notifications to help us keep players informed when new game updates are available.

At the same time of the v1.2 update we will be releasing the free version of the app for players who want to try the game before purchasing it. The v1.2 update and the free version of The Descent are scheduled for release sometime this week (depending on how the update review takes). Stay tuned!

The Descent Released!

We are happy to announce the official release of The Descent for iOS. Last week we officially submitted the app for review but now its finally available on the App Store

You can also check The Descent’s official website for more information:

The Descent official website

Stay updated! We are currently hard at work in my grandma’s basement getting ready for the 1.1 release which will introduce new sounds effects, translations to other languages, bug fixes and other cool stuff! Tell your friends!

The Making of The Descent

5 Years of Hubris

The Descent was originally conceived in early 2010. Back then we had been experimenting a for years with many types of game engines and technologies. However our interest in gaming back then was purely academic. We knew that we wanted to experiment with games and that making games was far more interesting than building payroll applications or enterprise software. Between our college years and 2008 we had played around with Java, programming with DirectX (using DirectDraw), and even experimented with established game engines such as Valve’s Source Engine. We never really developed games to full completion, just tech demos or small games or graphics applications showcasing features. We lost interest easily in the apps we were building back then. We just liked trying some cool ideas and then moving on to the next thing. In 2008 I ported a mini game from Nintendo’s Wario Ware Inc (for the Gameboy) called DONG DONG to the Microsoft XNA platform. In my opinion that could be considered our first released game (or port). We posted the game installation file in some website and forgot about it. Shortly after that experience I opened a boxing blog called Boxing Highlights (now defunct) which I ran for 2 years. After closing down the blog in early 2010 (I lost interest in boxing), we decided to venture into working with games in smartphones.

Back then we didn’t know Objective-C. I don’t remember if we owned Mac computers (which are required for iOS development), but we made the decision to try Android game development because I already had some experience in Java so Android seemed like a sensible choice. We wanted to create a small game that we ourselves wanted to play so we decided to build a game inspired by Paper Plane (a mini-game from Wario Ware Inc.), one of the very few casual games that had stolen so many hours from our lives.

I began the core of the development during Fall of 2010 without many graphics assets until we on-boarded a freelance graphic designed into the team. There weren’t many Android game frameworks at the time so we decided to build the game using Android’s built-in canvas functionality. This proved to be a major mistake. We developed an MVP with core gameplay functionality but didn’t have a clear vision or an end in sight. We also started experiencing technical constraints with Canvas that we tried to ignore at the time (most of these were out of memory exceptions). By early 2011 we decided to release the game before summer of 2011 because I was going back to school for a Masters degree in August 2011. That was our initial target but we were still working without a clear plan, without a committed designer (a freelancer whose name will remain undisclosed but who will be referred to as Claudia Pulcher in this article) and experiencing technical flaws in our game implementation. Our technical flaws were deeply rooted in the graphics library selection. We didn’t have experience in developing real-time games for Android and we ended up picking Canvas as our de facto graphics library for development. We paid a dear price for this as we started experiencing many performance issues closer to our “imaginary release date”. We considered moving to native OpenGL (we were still thinking of doing everything ourselves instead of using a relatively established graphics framework) for graphics rendering but never did it due to the effort involved. Before going back to school I decided to fly to Bogotá (where Elioncho was residing at the time) to undertake a 3 week development crunch which we thought would complete the game. It never happened.

During those 3 weeks we started adding more features and developing a lot of new functionality ourselves (scope creep galore). We wanted to have leaderboards and achievements but we ended up developing that functionality ourselves. There was no Google Play Game Services at the time. Those features ate up around 2 weeks of our development time. But we still didn’t have the rest of the game developed (all the levels, all the small easter eggs we wanted to include in the game, and also the addition of sound effects and original music tracks). We also faced many challenges with Claudia at the time. Frustrated with all of these challenges we parted ways with Claudia and after the 3 weeks of development we still had an unfinished game under our belts and no designer.

After that we basically placed The Descent in the back-burner between the rest of 2011 and early Spring of 2014. During this 3 year hiatus Elioncho and I went our separate ways to focus on other projects (In 2011 Elioncho started developing YouOrderIt and I spent 2 years pursing a Masters degree from Carnegie Mellon University). Also, in the middle of 2012, even though we still had The Descent in our minds we developed Condor Wars for Android, a recreation of a game Elioncho had developed in Assembly language during college. There were many psychological implications behind the development of Condor Wars. During Summer of 2012 I was doing an internship close to Detroit, Michigan but was desperately seeking a side project to work on during my spare time. One day we brought up the idea of porting Condor Wars to Android “just for the heck of it” but in reality I believe we did it for the following reasons 1) to regain confidence in development after falling short with The Descent and 2) to use the port of Condor Wars to Android as a “guinea pig” to learn about the pros and cons of developing and releasing a game to Google Play. We released the game in September 2012 but shortly after removed it from Google Play. Condor Wars is now vaporware.

In 2014 something compelled us to bring back The Descent from the dead so we decided to continue where we had left off. However we decided to focus on the iOS platform. In April 2014 we on-boarded a new designer – Quintus Sertorius (his real name will remain undisclosed) to start working on the graphics for the game. We decided to develop the design elements for the game (sprites, backgrounds, etc.) from scratch. With a new designer under our wing I worked on a rough prototype for The Descent iOS using the Cocos2D framework during Spring of 2014 and handed off my work to Elioncho during before Summer of 2014.

By June 2014 Elioncho decided to continue the game by building on top of the rough prototype but switched from Cocos2D to SpriteKit since the latter is an official Apple framework that looked promising (it also shared many structural similarities with Cocos2D, which we realized lacked sufficient documentation). However we were focusing mostly on getting the graphics right this time so between April and July 2014 we worked closely with Sertorius while doing minimal development work on the new prototype. By the end of July 2014 Helldorado Team went on a 4 month hiatus again and The Descent went into hibernation mode due to personal reasons and other side projects.

In October 2014 development work on The Descent resumed but at a plodding pace as we continued to work on the graphics and tried to finalize the official assets for the game. We went back and forth too much with Sertorius regarding the finalized graphics deliverables so we decided in February 2015 to part ways with yet the 2nd The Descent designer. We were again in the same situation – we had a working prototype and no designer.

Between February 2015 and May 2015 we were swamped with other projects as well – we had to develop additional functionality for YouOrderIt which we wanted to include in our product roadmap and some prospective clients were pressuring us to deliver. But even though actual development of The Descent had stalled for a couple of months, we decided that 2015 was the year for release. We set a target for June 2015 to deliver the game or “die trying”.

We started juggling work on many fronts – YouOrderIt (web and mobile) and The Descent. Early during 2015 Elioncho did some freelance work for Carlos Forero of Milmentes and made an arrangement that would allow Forero to work with Helldorado Team as the official designer for the game. In April 2015 we on-boarded The Descent’s final designer and by end of May he had produced all the graphics that ended up carrying the real feeling of the game we had always wanted to play. The bulk of The Descent’s development work (now with SpriteKit and the integrated graphics assets) was developed between February 2015 and June 2015.

In June 22, 2015, after almost 5 years of a development schedule that we described as “half a decade of sweat and blood”, during the middle of day, Elioncho made the last code change of the The Descent, ran some unit tests to validate functionality and clicked the “Publish” button within the deployment wizard of Xcode. For 5 years we had felt like Atlas holding the Earth under his shoulders. Having been burdened by past frustrations and by 5 years of trials and tribulations, we mentally let out a long, deep sigh as a smile formed in our faces.

New Website and New Game Release

New year, new beginnings (año nuevo, cero clientes). We are pleased to announce our new website and finally the release of The Descent – a game we’ve been wanting to release since 2010. We had been thinking of changing platforms for our website (for quite a while) and finally made the decision to migrate from a custom-made website (hosted in Heroku) to WordPress. We decided that we want to change the mentality of “doing everything ourselves” and instead adopt best of the breed platforms and leverage their strengths. In this way we can make updates to our website constantly instead of waiting for website updates and release cycles.

We are very happy with the release of The Descent after the challenges (development and emotional) we’ve faced for the past 5 years. The story of the development of The Descent is very bittersweet and I am planning to share with you the full story in a different (and quite lengthy, but sleep-inducing for some of you) post. Welcome to our site and stay put!

Android deployment: Best advice you can get

I am posting this to save you the headache. For all of you who are right now diligently coding your way through the final weeks of deployment, make sure you take into account what I am about to tell you. Probably you already know this, and I’m not really sure if Google detailed this information in the Android Developers website (I didn’t really see it in their deployment checklist), but here we go.

Most of us (Helldorado Team included) have not written code from scratch, but rather, have based our codebase on an existing template taken from the internet, etc. This is true when you want to get a code skeleton for a specific purpose, for instance, an OpenGL rendering framework or something similar. With this in mind, sometimes we have the bad habit of not changing the package name of the application we based our code on, and this in turn comes to haunt us during the actual deployment process.

Therefore, make sure the package name of your android application DOES NOT contain the following strings: “google” or “android“. If the package name of your application contains any of the previous strings, Google Play will not let you deploy your application. We ran into this issue with Condor Wars (the app’s package name was com.android.CondorWars), and when we tried to deploy the app at 4am in the morning, we realized, tired and frustrated, that we had to make a quick code change before deployment.

Quick code changes before production deployment, even if their effect seems to be benign at best, are the worst things you can do in the final minutes before actual deployment. We renamed the package name to com.helldoradoteam.CondorWars and resumed the deployment process. Google Play accepted our deployment package as we celebrated the release of our first game.

Later on we realized we hadn’t changed all references to our old package name in the code, which caused the game to crash in various places. We released a patch to version 1.1 in order to fix the package name issue.

The lessons learned here is to have the correct package name of your application from the very early stages of the SDLC cycle. Fix things now to avoid headaches from last minute changes later.

Deployment aftermath: Android development reminiscences

Naturally, I would just go on and say nice things about android development. True is, the Helldorado Team development team confesses that due to deployment issues we have faced in the past week, we will rethink our original strategy of picking Android as our development platform of choice.

We made it abundantly clear in the past that we had chosen Android because we were familiar with Java and because I was going to buy an Android phone (Samsung Galaxy S). That was back in Fall 2010, Android’s popularity was rising and its outlook was somewhat promising. But now its Fall 2012, there’s countless Android devices, API Levels, etc and honestly it is getting really hard to support every single permutation of Android phone and API Level. Props to Chris Pruett for what he was able to achieve with Replica Island. He is kind of an unsung hero in the Android development community, but honestly Helldorado Team is not hear to play the same role. We are not here to prove anything to anyone. We are not here to prove that we can write code that can run smoothly and without crashes on every available device, we are here just to create fun, playable games. We don’t need this headache. We realized that the reduced development time that came from our previous familiarity with Java is being offset by increased maintenance efforts post-deployment. We are currently a team of two. Elioncho is running a restaurant full-time, and I am currently pursuing an MBA. We are both extremely busy and we want to use our valuable time creating quality games, not debugging the reason why the Option screen crashes when you press back button on the Xperia phone while this works perfectly fine on a countless array of other devices.

We are now venturing into iPhone development, it will take at least a pair of months to get up to speed, but depending on how the development and deployment of Condor Wars for iPhone goes, we will make appropriate decisions regarding our platform or choice. If everything goes smoothly, Android will cease to be our platform of choice and will just be a pile of dust left behind (Sorry Pebo).