Sponsored By

Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.

Draw: The Showdown. How we built the west.

So we came out of a tertiaty course with some friends, wanting to make games, and as Raptus Games, we made Draw: the Showdown for the iOS. How did that go? What could have prepared us better for the challenge? What have we learned?

Bernardo Del Castillo, Blogger

January 31, 2012

25 Min Read

I don't think I ever had the idea of working for a big company, I think I am not attracted to the very cliché idea of being another cog in the clock, so Even when I was working comfortably as a motion graphics designer in Chile, I decided I would throw all the safeties away and go study Videogame Programming at AIE Melbourne, in Australia.

(Why Australia? well it has the best beaches and drive-through bottle shops in the world).

So some years passed, I returned to my old programming habits, and after the ups and downs of AIE, we decided with a few highly motivated friends from the course, that we would become Indie, and we would make games. Game companies were all at the paranoid state of the established economic crisis, and we didn’t really want to work for generic brown shooter ver. 17.
So iOS seemed like the best place to start. everyone was talking about how this was an exciting new market with gazillions of new found gamers, and how some quality vision could potentially shine, and make everyone's dreams come true. Raptus Games was born!

We would make a game in Unity, since we had some decent notions of the engine, it was cross platform, it had a big community, good support and an impressive showcase. So plans were that in some 3 or 4 months we would have an awesome product that would blow people's brains out and drop everyone's knickers.

Westerns! Cowboys! A cool graphic style! We brainstormed. Duels, Encounters, Special events! It was all exciting and new. And we thought we could handle it, since we had learned from projects at school that we should keep the scale under control.

We would make the game in our own time, develop alongside everything else, and hopefully get some funding when we had some nice flashy pictures to show off. Once that was done, we would just do it full time.

Anyway, that was all a year ago, and just last October (2011), we released our game to the app store, I don’t know if you’ve heard of Draw: The Showdown, I hope you have. Anyhow, A few months have gone by, and we have learned much of the app store, about the whole game production process, and about games themselves:

Pre-Production

What Happened?

Design concept

As you might already imagine, we fell into many rookie mistakes when defining the range of our game. Initially we set out to do a series of minigames with a hub. This on itself becomes a problem, considering the size of our team, and taking into account that each sub-game would require special programming, art and UI.
A few months in, we realized that with our production team (4 people), we would never accomplish a polished product with all of the planned components. We were gradually forced to re-evaluate, but we lost quite a bit of time on that. 

Prototyping is pure win

On the other hand, we did a fair share of prototypes, and this process allowed us to realize what was unnecessary, enabling us to clean out a lot of the game's more superfluous aspects. We finally decided that the game would be a procedurally generated (endless) on-rails shooter, and the mechanics would mainly be Shooting, Timing, and character customizing. 
Your character would be the newly appointed Sheriff of Coyote, and although your demise was absolutely certain, the challenge would be to last as long as possible, and get rid of as many outlaws as you could.

We learned: Narrow down what your game MUST do well and focus on that. At least in the beginning, strip all the unnecessary components to find what at the core makes your game fun. Hone the experience so that all its components are related to this purpose. Anything additional is gravy and it should be added thoughtfully, considering the impact in the production.

Art and Style

When we just started, our goal was to emulate what Team fortress had done, and make a highly stylized, yet vivid shooter. This view shifted as well just observing that much of the graphic detail might not be adequate for the iOS devices dimensions, we adopted a cell shaded style, more akin to a "comic book".

Character_Concepts.png

DrawCharacterConcepts



I think this rescued a lot of the vibrant colors and expression, and this was a positive change at the time of defining our image. It definitely sets a tone and differentiates Draw from other games, but it honestly was a rather intuitive decision, and may or may not have benefited the game in the mass appeal sense (and let's face it, you want that for the app store).

We learned: Aesthetics can often be an afterthought, or sometimes it can be the whole driving force of a game, but in any case, it can really hamper a game when the components are not coherent to the feel of the game. It sounds obvious, but If your game has an aesthetic base, make sure that the gameplay translates that. And in the same way, if you decide later in the process what you want the aesthetics (which is not ideal) to be, make sure it collaborates with the gameplay.

Want to help me out?
With our initial steps we were rather oblivious of external finantial options, that we later conidered. We presented our game to FilmVictoria, which offers some great funding for independent developers, but we were not fully prepared, and we got turned down. Had we prepared earlier we probably could have gotten the investment, and we most definately could have found external assistance in the funding of our development.

We learned:
There is nothing wrong with showing off your project, if you've done something good and attractive, you might find someone who is interested.


Production

What Happened?

What are you Programming? 

Yes, I think programming is fun, but it isn't for everyone. I'm not a great programmer, I'm a bit messy, I'm quite aware of that, but one thing I am extremely good at, is writing code that makes sense. I can show my teenager sister some of my code... and just by reading it, the comments and the naming conventions; she can understand what it's doing.  I am very proud of that: I can normally give my code to any other programmer and they can modify what they want with relative ease. This isn't always the case, and that is extremely bad when you are working with someone but you can’t understand anything they have done. It is as if I started talking in strict Ye Old English, maybe technically impressive, but it it destroys the communication. 

We learned: Keep this in mind for everything, especially when you are working with people. Chances are you are going to have to go back and revise a component, and when you have a hard time deciphering your own code, your peers will probably end up just rewriting all the work you have done.

Can we add this? 

This is linked to the concept step of pre-production and planning. It often happened in draw, that we were halfway through some production component, and we started pondering the old question: wouldn't it be cool if we added X? 
This is a very dangerous situation. On one hand, it is perfectly valid to experience the game and realize things that you hadn't thought of before, and that can improve the game. But on the other hand, you must know when these additions go out of scope.

On my coding side, draw has many systems that we ended up not using at all, even if they probably added some interesting aspects. In the art side, I know many textures and animations were left un-used, even if they revealed cool things about the characters and the environment.  It's impossible to completely avoid this, because shit happens and fun is often unpredictable. But today, I would know better than to devote myself to components that would most likely be too hard to implement in the game. This also leads us to:

Designing makes the game

This is mostly linked to the concept step of pre-production and planning. It often happened in Draw that we were halfway through some production, and we would start pondering the old question: wouldn't it be cool if we added X? 
This is a very dangerous situation. On one hand, it is perfectly valid to actually experience the game and realize things that you hadn't thought of before; it is only natural to attempt to improve the game. But on the other hand, you must know when these additions go out of scope.
It’s important to balance finishing and polishing basic pieces of the product with the always growing pile of new ideas, or you might end up stuck in an endless loop.

On my coding side, draw has many systems that we ended up not using at all, even if they probably added some interesting aspects to the gameplay. Why? Because mistakenly, we didn't have enough time or people dedicated exclusively to designing the game and the levels. 
In the art side as well, I know many textures and animations were left un-used, even if they revealed cool things about the characters and the environment. Simply because their inclusion was too complex for the time scope we were contemplating. It's impossible to completely avoid this, because shit happens and fun is often unpredictable. But today, I would know better than to devote myself to components that would most likely be too hard to implement in the game.

We learned: 
Even when you have the technical muscle to pull of complex and unique pieces for your game, you have to consider the expense of the actual implementation. Level design and player interaction are far more important than most new teams realize, and it is a very subtle art. Even if you have a cool feature or art piece that you love, you have to consider if it's implementation in the game will be viable and if it will actually add to the player's appreciation of the game.

Hey guys, I made a wheel!

One of the defining traits of higher primates such as humans is that we have begun using tools to aid us, tools are not thought for the product in itself but as a method to improve our productive output. Now our world is full of standards, and it is in our best interest to use them when they can assist in our productive process. It is also obvious that our productivity will be greatly improved if we generate reusable modules for ourselves. It is not necessary to reinvent the wheel with each small component, when here are plenty of perfectly functional wheels lying around.

It may require a great deal of planning, but creating a basic menu structure that can be used all around the game, or a general adjustable enemy AI, or an expandable store, will save us a great deal of time in the long run. This is also increasingly important with games nowadays, since most generally contemplate the option of being updated quite regularly, so chances are very few things are unique unchangeable pieces. 

This is not to say that you should always avoid set pieces that work only with given components, but you should try to generalize as much as you can in case you want to use a similar piece later in the game, or even in another game. In every aspect of game production (and general production really) even when you are rushing, it is better to consider if this component can be tackled as a module or tool to aid you in the process later on.

store.png

InGameStore


We are currently re-designing the In-Game store, mainly improving its usability, and simplifying the addition of new items.

We learned:
Several components in Draw started out with the intention of being modules we could use in current and future games. Some remained that way, and some succumbed to the pressure of deadlines. Many of these unique pieces have reared their ugly heads now, when we are trying to update, and have required almost complete reconstructions.
Sometimes it’s better to delay and develop thoughtfully rather than rush and pay the bill later.

Yeah, we'll get the UI sorted out later

Before Draw, I had little to none experience in the iOS platform, or the AppStore's horde of applications. But that is no excuse. We largely ignored the Interface design and the flow between the different areas of the game. Simply because we considered that we would take care of it later. 
The huge problem with this is that in general iOS games have an extremely polished interface; Menus are well thought off, simple and streamlined. This responds to the fact that most iPhone players are not strictly hardcore players, and they need very functional, intuitive and simple interactions with the device. 
Today UI and interaction design are a MUST, not an afterthought. 

We learned:
The game itself is one thing, it’s obviously vital that it works well. But don’t overlook the non-game areas of the game. Draw was nicely connected graphically, but we never realized some usability problems that were only pointed out by users. Test, try out, give to your uncle who hates videogames and your little sister, if they can't reach your game-store, chances are few people will get there when the game goes live. Sometimes a small comment can deeply affect some decisions you took for granted.

I'm sure that people will get it 

It's not that players are stupid and must be told how to do everything, but when developing a game for months, it is easy as a developer to assume the player will know how to play your game. Of course they will know to swipe up and down in the main menu, of course they will read the tutorial and know how to reload the gun. It's safer to assume they won't. 

We learned:
Same as above, it might be a hassle (meddling with the humans, pain!), but there is no other way to know all of this unless you test and observe and get people to tell you as candidly as possible what their experience is with the game. I seriously feel there is no other way to succeed in portraying the polished and intuitive feel some games accomplish.

We’re making games, a dream come true, it will keep the team together.

This is a lot more personal and it is something that is present throughout the production process, when you are indie, you hope that the team will stay together purely out of the will to make a game. This is partially true, you will find people that will devote their lives to it because they have dreamed of it their whole life, and seeing their character walk on the screen is payment enough. But that is not always the case, and life happens.

It is not simple to keep people invested when you are doing a labor of love.
We learned: This is hard to deal with and it will happen, I’m sure it even happens in bigger companies, with bigger projects. It’s hard to keep someone engaged and motivated when working in a project for such a long time. What can I say that is not terribly obvious? Try and make your peers participate,  take note on what they think about the game, channel their interests into doing what inspires them and what they feel is better for the game. And try to balance that personal input with a structured must do approach. If the game is theirs, they will fight for it.

Working from a distance

First of all, this is my own experience, Given that Raptus Games is Australian/Chilean, and that I am the Chilean part of it, halfway in the production cycle I had to relocate to my hometown, and it has been quite a challenge to keep things going working from a distance. I suppose this is pretty common today, communications being so immediate and all, but logistics when you are trying to make an international team come together efficiently can be problematic.

We learned: I believe we have greatly succeeded in continuing production even with the huge time and distance difference. I believe that apart from scheduling regular meetings, the clue is making yourself always active, showing the rest of the team improvements regularly and taking interest in what they are doing without necessarily pressuring about deadlines.

 

 
Release

I must say that at the time of publishing the game, after all the difficulties and horror stories I had heard from Apple and its selection process, everything was quite straightforward and functional. Just make sure that you have planned and set up all the documents you need. If you follow their instructions the process is not too complex.

(Although acquiring a developer ID when you are in Chile can be ridiculously complicated, steps include sending them a fax with your credit card details. I didn’t know that faxes still existed, but that is a story for another time).

The young pup is out there alone in the jungle

On the other side, once your App is approved, the process becomes quite murky. All the workings and decisions behind Apple’s featured choices are editorial. These choices don’t respond directly to any guideline, and can seem absolutely arbitrary.
However, you are more likely to be featured if:

  1. Your game is a beacon of cool Apple innovative technologies, IE Cloud saving, in-App purchases, GameCenter multiplayer, Achievements, Accelerometer, Swipe or Camera controls. Any sort of novelty factor will help.

  2. Your game looks and/or plays like a million bucks, normal maps, console quality models, some electro-pop duo made your soundtrack. The Game, Menus and Interactions should be carefully polished, bugs mostly taken care of and in general it has a qualitative advantage of some sort.

  3. You have a good core audience, an original take on the idea and your product is aware of that. IE: A good lock-picking game, or a fantastic gardening simulator, will probably be featured before another Angry Birds clone.

  4. Tough but true, if you already have 3 successful titles; you are more likely to get featured because you are a respected developer. Safe bets look nicer for the investor.

This sounds rather obvious to be honest, but sometimes it’s easy to forget that you are going up against some very experienced big companies doing small games, a lot of the time you won’t be able to compete if you don’t bring in you’re A game.

If a player finds something that conflicts with his gameplay, it is highly likely that he will not give the game another look. And your one chance to show your quality is gone. Half assed attempts are not really an option.

3.png

DrawTheShowdown1


We believe that we achieved some very attractive aesthetics that set us apart from other games.

Anyway, being featured can make or break your success. Quite obviously it gives you much more notoriety, reports show that an app that makes it to the startup screen, on has 15 times more downloads than apps that don’t. If it is compatible with your game, it’s always a good Idea to aim for the featured spot.

One thing we realized too late is that you must choose a good name for your game. You must attempt to make the title memorable, but also hopefully rather unique. The word “Draw” for example, is a commodity today, if you type it into iTunes, there are thousands of apps. We already had produced a lot of content with it and we decided to go with it, but it is decidedly a weak name.
Also, there is a problem with the subtitle that we used to differentiate our app, since although it works in English; it is not a simple word to remember in other languages, given that the pronunciation is not phonetically intuitive. This means that in many non-English speaking places even if people have seen or heard the name of the game, it might not stick with them.

 

How much is my precious’ worth?

It’s hard to put a price tag on games today. Considering that roughly only 20% of the people that own an iOS device ever purchase anything on the app store, it often seems that by charging anything at all you are missing out on the opportunity to get to a huge audience, and who knows, your in-app item could be their first purchase ever.

Imagine all 250 million users buying a dollar from you, haha now let’s get over the wishful thinking, although I’m sure it’s perfectly possible.

I believe that in reality, prices depend on your game model. If you have a technically impressive game, that you know will appeal to more hardcore players, and you have generated enough hype prior to launch, you can probably consider a relatively high launching price (7 to 15++ dollars). But remember you are against games like Infinity blade here.

On the other hand if you have an addictive casual game for the masses, and you want to live off micro-transactions it seems that the idea is to capture an audience as wide as possible, so free is a very viable option.

We were not sure what our actual situation, on one side Draw is a 3d on-rails shooter that even though is quite aesthetically attractive, it’s aspect isn’t as dazzling as some other titles. And on the other side, although the gameplay itself is not much more complex than Fruit Ninja, graphics do make it seem a bit more complicated. So we were stuck somewhere in the middle between casual and hardcore.

One thing we had clear is that we wanted to be as straight forward and honest about costs to players, rather than using conniving schemes to get them to buy, or giving them a broken game that forced them to purchase the full version in order to play, I believe this is a good practice still, and I think in the long run players will appreciate that. We eventually decided for an initial release prize of 1.99 dollars, as a trial prize, given that it was our first game and we could probably test the waters.

A day after its release you could find it as an un-signed installer for jail-broken devices. We took it as a good sign, the game was pirate worthy.

initial_reception.png

InitialUnitsSold


After our release which was quite positive, sales decreased rapidly, to around 10 or less a day, it was rather disappointing but it was also very informative. You should note that our initial release didn’t include Gamecenter, or micro-transactions (big mistake). We got some growth when we released our first update and isolated spikes when the game was reviewed or featured in different places.

We decided that we would give it a free period just to create some awareness. And the results for us were quite impressive. 

Free hugs

Draw: the Showdown went free for 3 days, still without any micro-transactions (another error), we got a small mention in IGN, and quite a few other sites took notice. The game got atound 77000 downloads, reaching rather unexpected and impressive numbers in rankings all around the world. Draw actually showed a lot of potential, potential that we saw, but that hadn’t been demonstrated yet. How could we harness this potential?

FreeRanks.png

TopRanks

 
Not too shabby

In those 3 days, Ad companies and various local publishers approached us, which was surprising since we were previously ignored. But this also made us realize that we actually had a decent game on our hands.  

One thing that hit us with the numbers was a tremendous upraise of user reviews and comments. Most of them were positive, many gave us pointers on what they wished to see on further updates, and some were uselessly negative.

Go easy on me

We struggled to find any use to a “Boring - What a junk!!” review, especially considering the free status of the game. We were also boggled by people who complained about the game not starting when their devices were not compatible. But all in all it was an excellent learning experience too.
We even had some players come forward, sending us quite insightful emails on what improvements they would like to see on the game. 

We learned: I consider that we have done quite well regarding our availability to comments, and our approachability, we have immediately fixed most of our players repeated requests, and I believe that this will pay off in the future. I wish personally that there would be a way to get information about your reviewers, so that you could address their issues since they often leave out many important details in their comments I wish apple would hear us out and implemented something like this. It’s hard enough for an average user to send you a quick message detailing their  problems with the game, let alone go through the rather unintuitive process of submitting crash logs.


What we know today

After the free period the game went back to a lower 0.99 dollar price, and we could temporarily observe a decent increase in sales, although it also dropped off quickly after the first week.

On our latest update, we included in-app purchases and various enhancements, achieving a very competitive level of polish. The experience with the engine and the market has given us the ability to see this now, and improve the general development efficiency (our current titles in development have a much more streamlined and directed focus as well).

The in-game store has brought considerable sales (around 30% of the total income since it was released), even with the limited amount of items available in it currently.

Appearing active and approachable in various social networking sites and being featured in specialized press has obviously been vitally important for sales as well.

currentSituation.png

InfinityAndBeyond


Watch out Angry birds!

The size of your game seems important when it comes down to the sales cycles. Bigger games, like Draw: the Showdown (over 20megs, which you can’t get on 3g networks) tend to sell better on the weekends, theoretically because people have more spare time at home to download. On the other hand smaller games have a less a variable download cycle, and appear to do even better on weekdays, because people download them as a spur the moment kind of thing when they are using their phones and devices for everyday tasks.

Next steps.

The next update for Draw will probably be the a big change, we are adding much of the content that players were asking for, and following a model that we have seen implemented previously by games like Temple Run or Jetpack Joyride. We expect that an overhauled store, new levels, characters and items will be a reward for our old players, and a hook for newcomers. We have seen that the potential is actually there. The Android platform, although interesting, presents many important challenges, and is now not a priority. However, the idea of porting Draw is still in the horizon.

Looking back on the experience, at Raptus, we believe that Draw at its core is a good, entertaining, casual and competitive game, and with the recent improvements, we know that it can perform quite well in the longer run, even if it did initially suffer from a lot of adolescent mistakes. We are very excited to continue producing high quality games for this and other platforms. You will hear from us!

We are also developing other games where we are applying much of the knowledge we’ve acquired, hopefully exploring the various innovative interactions that these devices enable.

I made this for you! 

I sincerely hope our experience does help out other developers in the process of understanding the market and the different components that go into creating a relatively simple game.

Cheers.
B out

Also.- Make sure you check out this sites, they have lots of great information:

http://thegamebakers.com/money-and-the-app-store-a-few-figures-that-might-help-an-indie-developer.html

http://www.inc.com/guides/making-money-iphone-apps.html

http://www.betabeat.com/2011/04/06/how-to-get-your-app-into-the-apple-app-store/

Read more about:

Featured Blogs
Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like