This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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:
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".
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.
There is nothing wrong with showing off your project, if you've done something good and attractive, you might find someone who is interested.
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.
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.
We are currently re-designing the In-Game store, mainly improving its usability, and simplifying the addition of new items.
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.
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.
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.
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:
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.
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.
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.
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?
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.
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.
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.
Also.- Make sure you check out this sites, they have lots of great information: