Continuing after my

The basics

If you are like me you will probably think that the Playbook has something to do with the tech that used to run Blackberry’s phones. This misconception was so strong in me that I didn’t even consider a port to it. The truth is however, that the Playbook is based on the new platform that Blackberry is creating based on the Native Development Kit (NDK) is a complete solution for developing on the platform. Not like Android for example, where the NDK is just a crude exposure of the native Android’s build system, supports minimal functionality and requires Java calls for most stuff. On Playbook you can write a full native app and never look at Java again. The NDK will provide C level APIs for all that you are going to need. From screen handling and input, to in-app purchases.

The Blackberry provided development environment is QNX Momentics, which is based on Eclipse, but also you can easily do everything with command line tools if you prefer. I chose to go with Momentics even though I find Eclipse slow and sluggish, because it is very nicely setup for native C/C++ development (with debuggers, profilers, etc) and I wanted to see how far it will get me until I started missing the command line. Surprisingly, it did all the way. Had no problem with it, which is a first for me and Eclipse.

You also get an emulator for trying out your, code which is based on VMWare. This didn’t strike me a good thing because you have to buy VMWare to run it. Sure there is the VMWare Player version that is free, but you can use that only on Windows and Linux. The Mac users, like me, will have to use the 30-day trial of VMWare Fusion, or buy it.

Next I will go through the major porting areas to keep this consistent with my corresponding article for Android.

Input

Handling input on Blackberry QNX is very straightforward, and in correspondence with the way iOS does it, so you shouldn’t encounter any problem. Like every other event on the system, touch events are represented by the bps_event_t structure that you pull with bps_get_event(). The event belongs to the “screen domain” and you query its data using the screen_get_event_property_*() set of functions.

int touch_state;
 
  int id;
 
  int position[2];
 
  screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_TYPE, &touch_state);
 
  screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_TOUCH_ID, &id);
 
  screen_get_event_property_iv(screen_event, SCREEN_PROPERTY_SOURCE_POSITION, position);

The above snippet is all you need to get the basic touch info. The touch_state can be one of SCREEN_EVENT_MTOUCH_TOUCH, SCREEN_EVENT_MTOUCH_MOVE and SCREEN_EVENT_MTOUCH_RELEASE. Which you can map to the touches began, moved, ended events of iOS. There is no canceled event here like iOS. Also since you poll for the event you get it on the thread you like and you will not have any issues like I had on Android.

There are no hardware buttons to handle.

Sound

Like on iOS, OpenAL is also supported on Playbook. If you have sound coded in OpenAL (which you probably do) you will have nothing to do here. Even ALUT is included in with the platform in case you rely on it.

Graphics

As you might expect the Playbook supports OpenGL ES with no problems. Both 1.1 and 2.0 versions are supported. There is a sample OpenGL application included with the NDK that handles all the details of setting up your screen, and because of the simple, yet effective, way the API is designed, it is self explanatory of what needs to be done.

The device sports a 1024×600 pixels screen resolution, which is almost 16:9 and hence much narrower than what the iPhone and of course the iPad have. Depending on your game, you will have to either rearrange the UI to fit the resolution or add black bars. For Pop Corny I support aspects from 1,33 to 1,50 with the UI adjusting automatically for this. So for the Playbook it adds some bars to bring the 1,7 aspect down to 1,50.

The number of pixels per screen are equivalent to that of iPhone 4 and iPad 2 so if you have artwork for these it will be ok for the Playbook without changes. If your game uses iPad 3 resolution artwork you will probably have to scale down, or you will be wasting space.

Assets

Loading assets is also as simple as it should be. No poking in zip files, disabling compression on specific extensions or using unnecessarily over-engineered asset managers (Android I am looking at you). Applications are distributed as .bar files that are just zip files in essence. During the installation the .bar file contents are extracted and the application can access the file system in any POSIX compliant way you know and love.

If you want to load files that were shipped with the application’s .bar file (textures, sounds, etc) you will find them in:

 ./app/native/

If you want to create files and save data for your application you do it in:

./data/

As simple as it should be.

Leaderboards / Achievements

OpenFeint (now Gree) is not available and Game Center of course is not too as it’s an Apple only network. Blackberry offers it own network called “Scoreloop” that supports leaderboards, achievements and chalenges.

Closing words

For me this was the easiest platform I ever ported to. After a long time, I really enjoyed working on a platform with “sane” software design decisions. Hat off to the engineers at Blackberry that pushed for a POSIX compliant platform that supports all the open frameworks we as game developers came to love. For most platforms you must bundle all the libraries you use with your executable. On Playbook libpng, libjpeg, freetype, and more are all included in the system and you can link to that. No compiling hassles and making your executable fat with static linking of libraries that are already there anyway.

Support from third parties is still not that good as on other platforms. For example for analytics on iOS I use the awesome service of flurry.com, but they don’t have native support for Playbook yet. They support Blackberry through Java that might work with Playbook but I didn’t want to mess with Java at all this time.

You will not require a fee to publish your game on App World after you have ported it, like there is on iOS and Android. As long as you have a game ported you can register, get your signing keys and put it out there. However there is a review process similar to that of Apple.

Closing, I must admit that the overall feeling was that of things working effortlessly. The whole porting effort took 2-3 days, with one of the days working with a fever! I would suggest that all indie developers take a look at this platform. Also given the fact that the iOS and Android app stores are so saturated with apps, this might be a good opportunity to get more exposure for your game. At the time of writing this its been 4 days since Pop Corny got released on App World and it is still visible on the “New Arrivals” section. If you are indie, you know that this exposure is gold for you. And this just gave me the idea for my next post about my experiences in AppStore, Google Play, Amazon Store and AppWorld! Until then, happy porting!!!

[This was also posted on Thoughts Serializer]

…almost…there…

I swear I can see the finish line up ahead.  If you squint, you can just make it out.  It’s there, I assure you.  As we approach the launch of our second mobile title, Vex Blocks, I can’t help but get excited at the prospect of putting our finished product in front of people.  Now I know…I know – there’s still a never-ending amount of work to be done from testing to marketing, to more testing, continued marketing, then the tweaking followed by testing, then some testing…but my point is we’re nearing that final stage before our launch.  There’s light at the end of the tunnel and I swear the faintest scent of cinnamon buns.  The burndown chart and the task list is at the point where you can at least realistically imagine the launch day, even if it’s still a few weeks away, instead of just dreaming about it happening at some point in the future like flying cars or super-intelligent, faithful monkey servants.  It feels good, like an imaged back rub from said imaginary monkey servants.

Our first title, Itzy3d was and still is well received by gamers even if it didn’t exactly race up the charts.  However, our inexperience developing games led to a bit of a rollercoaster ride creating the title.  Initial performance hurdles, an over complicated control scheme and simply learning the pitfalls of Unity3d/IOS/Android development made the experience of working on Itzy3d a rocky one.  Still, despite it’s shortcomings I can to this day sit back, fire it up and lose myself in the game and take pride in our first outing as an indie game developer.

Vex Blocks’ development wasn’t nearly as up and down and even though I still thoroughly enjoyed working on Itzy3d I find I’ve had much more fun working on our upcoming action/puzzler.  If I’m going to lock myself in my office and gamble mine and my family’s future working on videogames full time, at least I know I’m doing it with a smile on my face.  The anxiety filled nights haven’t entirely gone away, but I’m far more confident in what we can accomplish this time out, and there’s a few reasons for that.

The first is a matter of scope.  When we started Itzy3d we had no idea how long tasks would take us to complete and as such, creating Itzy the spider’s world became a much more ambitious project than we had anticipated.  When planning Vex Blocks we were able to estimate what we could accomplish in our given time frame with far more accuracy than we had with Itzy3d.  We started with a simpler concept so the development schedule didn’t become like Crawmerax the Invincible….lobster-like, purple, one-eyed and nearly impossible to beat at our current skill level.  Feeling that our goals were attainable within our time frame from the start did wonders for the ole confidence level.

The second major boost to all around enjoyment levels on Vex was having the artwork more or less completed when we started.  Vex Blocks was a concept I dreamt up a couple of years ago and it was initially given to a group of students consisting of three artists and two programmers from the Northern Alberta Institute of Technology to build a prototype for us while providing them with a final project for graduation.  Having a willing group of artists working under my instruction provided us the opportunity to start with a completed list of art assets when the prototype was eventually turned back over to our team.  In contrast, Itzy’s artwork hit a wall when our main artist found himself unable to contribute the time necessary to create the assets required for 3 of our 11 huge levels.  It also left us with zero assets for our menus and ultimate left us with menus that looked like they had been designed by programmers.  Starting the project with almost every art asset we could conceive was a huge load off my mind as I knew my Maya and Photoshop skills would not be tested as rigorously as I scrambled to fill in the blanks with my limited artistic ability.

And the biggest difference this time out was experience with Unity3d.  We know what works, what doesn’t, where our graphical ceiling is for mobile, how to implement sounds more efficiently, how to create an asset pool, the GUI bottlenecks, the performance tweaks, the ongoing mobile testing during development to make sure our mobile performance is where it should be and isn’t biting us in the ass, lighting, texturing, shaders…you name it.  Having the ability to predict where we may run into problems and addressing those issues before they became serious instead of charging full ahead into the unknown is a much more relaxed way to develop a game in my opinion.  Who knew?

So this time out it’s all about making the game fun, challenging and having a blast doing it.  As our cycle on this game nears it’s end I can’t wait to see how the game will do in testing and it’s eventual launch.  The thought of others enjoying our work as much as we enjoy building and playing ourselves is all the reward we need.  Well…and monetary compensation.  All the reward we need is seeing others enjoying our work and money.  That sounds about right.

Last week, we wrote a well-received post on how to maximize your launch for iOS or Android, but it also prompted a lot of questions: What if your goal wasn’t a huge launch, but to test the concept? What if you’re trying to capture a hardcore niche? What do I do if I’m making a game for the browser? We wanted to address those questions with a similar, but tangential guide for developers launching or testing a new game.

Finding your first 1000 players

For many games, finding that elusive first 1000 users can be the most challenging part of game development. The key is to approach marketing your game like marketing any other technology product. As Eric Ries has stated in his book The Lean Startup, no matter how much your product (ie game) is lacking, early adopters will still love it and play it.

Who are your early adopters?

You might not know this yet, so ask yourself this: why did I make this game? Let’s say you made an asynchronous turn-based strategy game. Chances are, you made it because you love turn-based strategy, or you wished that there was a modern update of Advanced Wars, or what have you. Your early adopters are people that absolutely love turn-based strategy games. Who are they? Well, you’re one of them. You need to dig into your mental pocketbook and figure out what your target early adopter looks like. This can be as concrete as gender and age percentages backed up by statistical analysis, or it can be a hunch based on your experiences playing these games yourself. As long as you’re willing to keep an open mind and try again if your assumptions turn out incorrect, then you should forge ahead.

Where do I find my early adopters?

To find your first group of early adopters, seek out communities of players that are dedicated to the type of game that you’re testing. As per our example, let’s say you’re looking for strategy gamers. You could look at Strategy game company that is similar to yours (note: they may not take to this too kindly, so tread carefully). Be sure to create social accounts for your game on Facebook and Twitter, and to use this accounts daily to interact with your first players.

If you’re looking for more focused design and development feedback, you can also seek out communities that support indie game development, likeTIGSource. In my experience, a simple forum post by an indie developer asking for participants is usually well received, and these guys love playing games as much as you do. You can also link to your game in your forum signature, so that any other posts you make on these forums also serve as mini-advertisements for your game.

Your goal here is to find people that share your love for the game you’ve created before they even play it. They too love asynchronous strategy games, or wish there was a modern update to Advanced Wars. The goal here is to find kindred spirits that will be naturally interested in your game. The advantage of using this tactic to get your initial group of players is that you are building a relationship with them. This also means they will be more likely to forgive your game’s rough edges and give you valuable feedback.

Building a community around your game

After the first two steps, hopefully you’ve found some early adopters and have done your best to cultivate personal relationships with many of them. The next step is to build a community around your game. Why? Communities are sticky, and will keep players coming back. They also serve as validation for new players that this game is fun, has other players and has a group of people to talk to about the game. As early adopters of game types are often in hardcore niches, this validation is critical for people looking at a game.

As a case study, let’s look at two browser-based strategy games: the beautiful, award-winning talk on game monetization that many people continued playing Mafia Wars long after they were bored of the game because they felt loyal to their Mob. You want to engender this kind of community among your players as well.

Scaling the early adopter community

Once you’ve started to build your community and see some traction, it’s time to starting thinking about how to scale that community. Beyond the community outreach and social media that you should already be doing, it might be time to start thinking about paid advertising and press.

Since you’re reading this guide, we’re going to assume that spending thousands of dollars on user acquisition is not an option. That’s OK, because there are a number of ways to do hyper-targeted advertising that will give you the most bang for your buck:

• Facebook: You can use Facebook’s laser-targeting to target users by country, age and what games they Like or play on Facebook. Done correctly, this can be one of your most cost-effective channels in the short term, but be wary of tapping out a very narrow audience quickly.
• Google Adwords: While not able to segment by habits, Google Adwords can target users by interest, which is just as useful. There’s a lot to be read on keyword research, but I think it can be summed up with the question “If I was a player, what would I type into Google when I was looking for exactly this game?” Then advertise on those keywords.
• Banner ads: When you were searching for early adopter communities, you may have noticed some of them running ads. Now it’s time for you to do the same. Banner ads are expensive yet effective, so make sure you pick which sites to advertise on carefully. It’s also worth spending some time making or commissioning a solid graphic for this purpose. Lastly, make sure you test different messaging or even different graphics to learn about what sticks with players.

At this point, you should hopefully be able to get press in your niche to review your game, giving you valuable exposure that can lead to social media buzz and new players. When approaching press about your game, make sure to do your homework. Look for press outlets that cover indie games in your specific niche (as with paid advertising, the goal is hyper-targeted promotion). In your email to the outlet, you want to do the following to maximize your chances of a story:

• Connect with them: show the reviewer that you read and enjoyed their coverage of similar games
• Get their attention: tell them what is unique about your game
• Meet in-person: if you are co-located and can meet with them to give them a demo in-person this will help ensure coverage.
• Make the sale: explain why your game is a great fit for their audience
• Close the deal: give them a promo code to access your game early and ask them if they would be interested in reviewing your game
• Negotiate embargoes: so that their reviews post when your game is live. This will help drive traffic.

Wrap up

No matter what type of game you’re making or what platform you’re launching on, finding your first 1000 players is not as hard as it seems. It just takes an understanding of the early adopter for your game, marketing your game to those players, and building a community around that initial traction. Our hope is that this will serve as a successful guide for those endeavors. Don’t forget to report back here with your experiences or share existing ones below! Oh and if you liked our guide, you should sign up for our educational newsletter.

Warren Spector recently gave an interview to Eurogamer that’s circulating pretty widely now about the need for better AI in games. Specifically what he’d like to see is people like John Carmack and Tim Sweeney stop focusing on graphics and start working on creating believable characters and immersive worlds.

Of course, I’ve got some issues with this. These guys are graphics programmers, they aren’t AI experts. Thinking that a graphics guy can just up sticks and refocus on AI is effectively part of the cultural issue AI has – it isn’t considered a serious discipline, it isn’t “hard”, it isn’t something people are experts in already, so let’s call in some graphics programmers to solve the issue! Of course, this is completely untrue and shows a bit of contempt for the AI that does exist and the experts who are working on it right now. We don’t need John Carmack to solve AI for us, we need people to listen to the Carmack-esque characters who already exist in AI and who are ignored because “players don’t want good AI”.

However, this minor piece of bitterness aside, what Warren is talking about makes a lot of sense, and it’s something I’ve been saying a lot over the past couple of months as part of a lecture tour that’s taken me to South America, Europe and across the USA. One of the key themes I’ve been talking about is AI outreach and advocacy – helping to explain what AI is and how we can use it to make better games. So, because Warren has set the stage so well by bringing it up, here is the article version of that presentation!

Why So Scared?

AI is seen as a really scary topic by a lot of people. I think a big part of it is that we’ve been culturally conditioned to see intelligent machines as an inherently bad thing. We’ve had decades of books and movies dedicated to the enslavement of humanity, if not an outright apocalypse, all because of robots and AI systems getting a little too smart for our own good. It makes people kind of wary. But it doesn’t have to be that way! All AI really boils down to is the applied science of decisions. There are whole branches of maths dedicated to analysis of decisions, Decision Theory being an obvious one, but also Game Theory and even Economics. These all allow us to theorise about how we should react in a given situation, and after we do all the algorithmic analysis, we end up with a neat result on a whiteboard and we walk away – problem solved. AI is about putting that solution into practice, whether it be in some simulated environment or with a robot.

Why is AI scary? Well, this guy has been our spokesman for nearly 20 years…

But the big question is, where do we see these kinds of decisions? Typically when gamers talk about AI in the context of games you might hear that “The AI did such-and-such”, and what they really mean is the enemy in the game. There are an awful lot of decisions happening there, it takes a surprising amount of sophistication to create characters that can believably run into the player’s field of view and convincingly fall over when killed. And whilst this is what a lot of Game AI focuses on as a discipline – what you might call opponent AI – there’s a lot more possible. People often say that players don’t want better AI in games, this is what they’re talking about. And to an extent they’re right, because what they mean is that players don’t want opponents that can out-think them. Part of my advocacy has been to address this specifically, especially in the academic community where “better” typically means stronger and more capable. If that was truly the goal of Game AI, as Blizzard’s Schwab pointed out at GDC ‘11, we could just make NPCs that were faster, stronger and had more powerful attacks. Making a game more challenging in and of itself isn’t hard. Academics – especially AI academics – like to talk in terms of optimal solutions, so one of the breakthroughs I’ve had is to explain Game AI as AI that tries to optimise “fun”. Some people get it, others then want to pontificate about an algorithmic definition of fun, but that doesn’t alter that as a core concept, this is what we are trying to achieve by using AI in games. What I want to do though is explain to people how we can use AI to do this. I’m not going to deal in technical details, because what I want to do is explain this in a way that designers and producers can follow, and implementations already exist out there.

The Best Game Ever Made

I want to start out by asserting that Dungeons and Dragons could quite easily be described as the best game ever made. It, and the table-top genre as a whole, has endured in a way no video game has to date, and its supporters aren’t growing tired of it, it’s just a bit of a pain to organise compared to firing up World of Warcraft. The great thing about D&D is that it’s not a game itself, it’s a rules framework in which games can be created and players aren’t restricted in what they can do. Of course that means that players will try to do weird and wonderful things, things that could never be predicted beforehand and that’s where D&D can come into its own. The thing that makes this possible is the human Dungeon Master who controls the game. The Dungeon Master is part of the game, and part of the gamer group. Before the game starts they create the world and build up an idea of what the plot of the game will be. It’s important to note that since the players drive a lot of the game, the DM can’t plan out the entire storyline in advance, because as any good strategist knows, “No battle plan survives first contact with the enemy”, and players need to be able to shape the story that is unfolding in their own way. Invariably however, this unfolding process will lead to a combat encounter, which requires a map to be created and populated with creatures for the players to battle. There may be plot devices as part of the encounter or specific elements that foreshadow something to come later which combine to create a subtly cohesive experience for the player. Once the encounter is created and the players are engaged in it, the DM will take responsibility for controlling whatever creatures have been placed into the map. This is a fairly interesting part of the role, because the DM has to balance the need to take believable actions that would make sense for those creatures against the need to make an exciting – and not too challenging – experience for the players. If the players will die from one more hit from a goblin archer, it doesn’t make sense for the archer to turn and fire into the wall. This isn’t a believable action though, and players in general won’t like that there is only an illusion of risk. Schwab described this as “Losing with style”, and it’s a key aspect to this kind of player experience management – we don’t want to be blatantly throwing the game in favour of the player, but at the same time, we don’t want to be insensitive to the fact that they are playing a game and don’t want to be frustrated or have the game end prematurely. One of the most important ways to manage this is to have a good understanding of who you are running the game for, knowing what types of player are in the party and how they will react in certain situations. This allows the DM to have a much better handle on how to stage manage the game to get the desired outcome, as well as tailoring the content to suit particular player types – if you know that players in your group tend to favour finding diplomatic solutions rather than confrontation, you can ensure that the options for this kind of play are available. Equally, if you have a player who is liable to charge at every band of enemies presented, you might like to prepare “surprises” for that player to exploit that they’re going to do something foolhardy.

The Dungeon Master is, in my opinion, a significant part of what makes D&D and games like it so successful. They have a longevity completely unmatched by any other games from their era, and continue to enjoy popularity and a zealous fan-base. To my mind, they represent the “Gold Standard” of what we should be trying to emulate when we make games today – not necessarily in terms of setting and tone, but certainly the design philosophy of empowering players to make choices and have real, tangible impact on the worlds we are playing in.

Of course, the obvious way to do this would be to ship a DM with every game, but I’ve been assured that cramming guys into retail boxes specifically to look over the player’s shoulder and tweak the game in real time would be considered a human rights violation. …Hippies. So instead, what we typically do is pre-bake a lot of the DM’s job during development. We fix the whole plot of the game upfront and reduce it to a sequence of combat encounters stitched together with cutscenes. We play those encounters out in a set of fixed levels, crafted by a designer once and then never changed, no matter how many times a player works through them. And then, we spend the vast majority of our time focusing on controlling the minions within the encounters – to such an extent that this almost becomes the totality of the wider perception of what Game AI is.

Of course, it is so much more than that so I want to close out by discussing briefly how AI can be used to start to replicate the DM’s role, and hopefully create powerful, engaging experiences as a result.

AI For Storytelling

This one is a bit over my head, but we can use AI to dynamically tell interesting stories, to take into account the player’s actions and adapt the story to take this into consideration. We’ve started to see this becoming increasingly mainstream lately, with Bioware being one of the big pioneers of some of the lowest-hanging fruit here with branching narrative. This is more of a 70’s era expert system than what we think of as true AI, but consider a game such as Mass Effect, where your choices at one part of the game are going to influence what happens and what choices are offered later. At a basic level you might think of this as a choose your own adventure book, but even that rapidly becomes pretty complex. Now add the nuances that Mass Effect and the like introduce into dialogue, recurring characters and so on, and the combinatorial explosion on the potential state graph is pretty intense. We can go a stage further though, because not only can we represent an enumeration of potential states using AI techniques to effectively manage this, but we can start to introduce actions within the world that are the AI system steering the player towards certain states in this notional graph. If we specifically want the player to arrive at a particular point of the story, we can push them back in that direction and begin to constrain their choices. If done carefully, we can give the illusion of complete choice, whilst still stage managing the experience. We can also build in concepts from literature to this, and manage the dramatic pacing of the story by modifying how components are shown to the player.

Choosing your own path through an entire trilogy proved to be so engaging to players, that they nearly revolted when this choice was removed.

There’s a strong, and growing, Interactive Fiction movement that has some great resources on this subject. A great place to start if you are able is Marc Cavazza who has a lot of publications centred on the theme.

AI For Encounter Design

Procedural Content Generation is one of the latest crazes sweeping through the game development community. At its most basic, it says that creating content, whether that be quests or a varied array of weapons or even levels for the game, is a time consuming process. For a certain amount of overhead, we can instead create an AI process that will make that content for us, and make as much of it as we need. Skyrim demonstrated this effectively with the Radiant quest system, which enabled the developers to create a seemingly limitless range of side-missions without ever having to write one of them by hand. The system could pick, in a mix-and-match style, a location for the quest, a task, a target and then assign it to the player. Tiny Wings is another great example, where every day the levels the player experiences change – without a way of generating these levels algorithmically, it wouldn’t be feasible to do this since it would be so time consuming.

No discussion of PCG is complete without a Tiny Wings reference!

At its heart, procedural content is about creating things dynamically, and may seem to be random, but rarely is. Randomness in general is a bad idea when you are talking about replacing a talented content creator such as a level designer – there’s a reason these folks get paid to make content, and it’s not because they can be replaced by glorified dice. With that said, it’s often possible to capture something of their insight and build that into the generation system, to create the kinds of content that they would. Using Tiny Wings again, each level has a different parametric description, so the overall feel of the level is kept the same and the difficulty progression varies in the same way each time, despite the specific details changing day-to-day.

Procedural generation is something that’s really close to my heart right now as myself and Heather Decker-Davis have been relying on it heavily for a casual title we’ve been working on, and in turn it has shaped a lot of our workflow and tools. You can hear more about our experiences and some tips we shared for working with procedural methods in gave a great overview of their approach last year.

AI For Character Control

As I said earlier, this is traditionally an area that gets an awful lot of attention, so I’m going to gloss over it a little bit, except to say that there are a broad range of techniques that you can use to create characters, such as Behaviour Trees, Goal-Oriented Action Planners, Hierarchical Task Networks and even Finite State Machines. Ultimately though, you need to understand what you are trying to achieve – is it to provide the player with a challenging opponent, or an engaging companion? The AI techniques required to die convincingly are separate from those required to create a believable set of responses to the weird and wonderful things that the player might decide to do. If you intend to make opponents, you need to consider if they work in squads, and whether a squad is a loose collection of affiliated enemies, or a well-trained group following specific orders, perhaps from an officer within the group. The Halo franchise demonstrated that small squads with officers could implement a morale system effectively and have squad cohesion disintegrate with the death of the officer.

These design choices are going to have a direct impact on what AI techniques are going to be most appropriate to create the desired feel to the characters in our game worlds, and it can be some of the most immersion breaking moments for players when the characters don’t act the way they expect; they are willing to believe that an alien swarm has taken over New York and the government has ordered the military to kill everyone involved, but they aren’t willing to believe that it’s possible to kill one of a pair of soldiers without having the other react in some way to his companion’s death.

There are lots of resources for reading more about this kind of AI, from AIGameDev.com through to a large portion of the AI Summit held at GDC, available through the Vault. The AI Game Programming Wisdom series of textbooks is also a good source of material, and when it comes to understanding the rationale behind the decisions characters might make in specific circumstances I also highly recommend “Predictably Irrational” by Dan Ariely, which is a book about so called “Behavioural Economics”, or where decisions meet psychology head on.

AI For Player Modelling

Player modeling in games is a relatively new approach that has yet to see wide adoption, but which has the potential to be a bit of a game changer, especially when combined with some of the other techniques already discussed. At its most basic, player modelling is something we’re already pretty familiar with whenever we play a game with humans; we try at some level to get a sense for who they are and how they play. This is most often seen in games like Poker where the stereotypical classifications of players, such as “Tight” and “Loose” have become part of our vernacular. In these competitive games, we use this kind of classification to predict an opponent’s behaviour and exploit this, but again this isn’t really the aim of Game AI – sure it’s great when an enemy opponent adapts to your tactics and challenges you to try harder, but we can use this technique for so much more than this.

Silent Hill: Shattered Memories is a great example of player modeling in action. In the opening scene of the game, you find yourself in a doctor’s office undergoing a battery of psychological tests. Unknown to the player however, the scene is set up in such a way that although the character is being given these tests, really the player’s responses to them is what matters. In truth, the testing is being done on the player, and it’s actually a standard psychological profile being built up. Based on this, the player is put into a category, and throughout the game, different content is shown to them dependent on their category. It doesn’t change the overall story of the game, but it does change the tone and feel of the experience.

This is the same scene, as experienced by two different types of player

But what happens when you don’t have the luxury of running a complete personality test on the player as the game begins? Let’s face it, games would rapidly begin to feel pretty dull if they all had to find a justification for doing this! It turns out that just as in Poker we can start to classify players as we observe their playstyle, we can do the same thing with other games. In 2009, Drachen et al at ITU Copenhagen were able to analyse data from playthroughs of the AAA title Tomb Raider: Underworld. What they found was that by applying some machine learning approaches, they could extract a number of stereotypes of players that people would broadly fall into, namely “Veterans”, “Solvers”, “Pacifists” and “Runners”. This was based entirely on ingame analytics, the kind of data we all have access to already.

Using AI systems then, we can learn a lot more about our players and how they interact with the game. But we can also feed that back into our content generation or narrative systems to start customising the experience directly to specific groups of individuals. This is something we’re seeing explored in the academic world through such things as the Mario Level Generation competition that has been running for the last couple of years. It’s something that we’re starting to see come to “real” games a bit, and in particular it’s something that myself and Heather have been working to put into our indie title. For us, it’s pretty much a no-brainer. Our game is based around a simple maze system, and this is broadly what our PCG system creates. If we can detect players who are interested in exploring the maze and ensuring they have collected everything before progressing, then we can adapt our content to prefer to give them more sprawling mazes with a wider range of things to collect. Equally, if we find players are more liable to dart straight to the maze exit and take more risks with the hazards in the maze, then we adapt to suit those tastes too and provide a more action-oriented experience. As with the human DM, understanding the players tastes and desires means that we can cater more directly to specific individuals and get better engagement with them. That means they have a better experience, more fun and means we’re making better games!

The End

I really hope that this post has helped you to understand a little bit more what AI can do for your games – in a very real way, Warren Spector is bang on the money, AI has the potential to be the next big thing in game development but we need to get more designers who aren’t intimidated by it! If you want to learn more, there are some great resources online that can help you get started, and of course every year the AI Game Programmers Guild hosts the AI Summit at GDC which is a great source of more inspiration. And who knows, maybe you’ll run into Warren there!

This little rant was mostly to have something to point people towards who don’t appreciate what it takes to make a game. For the people who are happy to whinge about the way a box falls off a shelf rather than just smile and enjoy the game.

Making games is hard.

Now, that in itself is a statement that many people would casually read and then scoff at, but it’s very true and very serious. Making video games is one of the more difficult things that you can do as a profession. Especially as an indie developer, because you don’t always have the people to have your back when you need it.

Even now, still reading this, many people will still be under the impression that it is easy to make games, and the sad fact is that their minds won’t be changed. But – in the off chance you keep reading – maybe I can help you understand just what we have to go through.

A game developer must be able to write software. That – in itself – is a feat. I often say that there are people who can program and then there are programmers. Anyone, given the right resources, can learn to write software. They can then go on to get a job writing software and make good money and reap the fruits of their hard work… But that doesn’t make them a programmer. True programmers write software because they can’t help it. It’s in their blood. They see things and wonder about the algorithms that make them work. They don’t stop at wondering how something works, but feel a compulsive need to know why it works, too. They will often dream in code, or search for that elusive “perfect combination” of sleep deprivation and caffeine that allows them to find their “coding zen” where they do their best work. When they’re coding, they are 150% there, in the moment, focused. When they’re not coding, they’re planning out what they’re going to write when they get back to their IDE. It’s this sort of unnatural focus and necessity of expression that makes someone a programmer. They are a programmer because they have to be.

Just being a programmer is one thing, but being a games programmer is another thing entirely. Games programming is arguably one of the hardest forms of programming. It can be made considerably easier by the use of proprietary engines and pre-made modules which can be used so much as to reduce game programming to basic scripting. But for those of us who write our own engines, our own modules, it gets phenominally difficult, and it’s mainly due to the fact that we have to become detailed experts in a variety of fields.

We must be physicists. Every little bit of movement you see in the game has been hand-crafted. When a box is knocked from a shelf and falls to the floor, most people take it for granted. In fact, many people will complain if it’s not there. But someone has had to learn and follow precisely how nature affects objects with gravity and collision and friction to perfectly simulate that box falling off of the shelf. So much study, practice, research and code must go into doing something so very simple that it staggers the mind.

We must be psychologists. When the bad guy sees you, throws a grenade and ducks behind cover to lay down fire, that hasn’t happened by magic. A game developer has studied anthropology and psychology to make the characters in the game behave in that specific way. And as games get more advanced, so does the AI. Even simple AI methods like the Dijkstra algorithm can become very complex to write out and be handled efficiently, let alone larger, more advanced and complex algorithms.

We must be artists. A game world must be visually appealing. It must conform to the desires of our senses, but this – once again – doesn’t happen by magic. People have worked long and hard to smooth down all of the sharp edges of the world that you’re running through, making sure that every object, every leaf, every light, every particle system is placed with utter perfection to bring the game world to life.

We must be lighting engineers. Do you see the way the light is shining on that pipe? That small effect is the result of long hours of study and coding to generate rays to simulate photons of light whizzing through the map and hitting surfaces, referencing their normals, comparing them to the viewing angle and illuminating the texture map accordingly, applying bloom if too bright, increasing contrast if too dark. Just trying to begin thinking of the process that is behind this happening at 60fps is utterly bewildering, but game developers do this in their sleep.

We must be pyrotechnicians. We must understand fire, explosions, destruction of objects, projection arcs and the light and heat associated with it. We must make it feel dangerous. Read that sentence again. We must make it feel dangerous. A thing that is not real, can – in no way – harm you. Not even a little. But it must scare you. It must make you reel in shock and make you feel like you are there. That you could get burned, or hurt. We must, as game developers, and purely through fancy code, make the virtual real or you won’t play.

We must be tacticians. It isn’t good enough for the enemies in the game to be able to move through the maps, or even “think” dynamically with relation to the players actions. They must employ tactics against you that will be effective or the game will be too easy. A good game developer must be able to think like a well-honed military unit – something that often takes years of training in harsh conditions – or people will be able to outsmart the game and will find it too easy.

We must be designers. The game must feel immersive. It must draw you in and make you forget the outside world. It’s the key to success in a game. But to do this the game developer needs to understand layouts, composition, landscaping, interior design, use of colour, light, shadow. They need to study things like the golden ratio and apply it with precision or people won’t become immersed in the game.

We must be directors. The game, after all, is almost like a cinematic experience. We must feel the adventure. The people must say the right things, the events must play out in the right way. This is made even more difficult in games with procedural content as the developer has no reference to make the game play out well. Therefore they have to make the game know how to play itself out well. They have to teach the game how to be fun and then trust it to do its thing. Think about that for a second.

Lastly, game developers have to be emotionally strong. It is an incredibly personal thing for a person or team of people to invest so much of their time, money, energy and love into a project for a year to five years, lovingly honing it into their idea of a masterpiece. For them to finally build up the courage to display it publicly and let the world in to see this personal world that they’ve created – to see their vulnerabilities, hopes and fears made manifest takes real courage. What takes even more courage is to read and cope with the armies of inconsiderate punks on the internet who hide themselves behind a veil of anonymity as they methodically try to destroy this much-loved thing that someone has put so much of themselves into. But you build up a tolerance. You become immune to it after a while. The noise that those people make will never be louder than the call to play this wonderful thing that they’ve made. Neil Gaiman said it quite well – if you do work that you’re proud of and the money doesn’t come, at least you still have the work. A game developer must work to cope with having their soul destroyed a little bit more each time someone says something ignorant and hurtful about this thing that they’ve created, but they get built right back up again by the praise that they receive. People enter their little worlds and are truly amazed, and there is no greater feeling than that.

But one thing that always hurts is when someone says “Oh, you make games? Isn’t that really easy?”

No. It’s not easy. John Carmack, one of the greatest game developers of all time took a break from making games to do rocket science. Actual rocket science. For a break.

So basically this little rant was mostly to have something to point people towards who don’t appreciate what it takes to make a game. For the people who are happy to whinge about the way a box falls off a shelf rather than just smile and enjoy the game.

For those who want further insight into just what it takes to be a game developer, I highly, highly reccommend watching this movie.

I’m aware that this is an opinion piece and that you may not agree with me, but frankly I don’t care. The dedication, skill and emotional investment that game development requires needs to be better recognised.

Launch is one of the most important moments in your game’s life. A good launch can lead to a strong initial audience that you can leverage for ranks and, in the best case scenario, organic traffic from reaching a Top 25 list. A bad launch leaves you with only the grim prospect that you will need to sink more money into your game in the form of user acquisition spend to see the same results. For small studios and indies without tens of thousands to spend on user acquisition, launch can literally make or break your game.

So how do you craft a successful launch?

Good launches don’t happen by accident. They are the result of rigorous planning, equal parts marketing, PR, and engineering. Bugs and other issues will kill an otherwise good launch, but so will not understanding your market. iOS and Android are very different in how they handle discovery. And that’s the goal of launch: getting your game into a position where it can be discovered by millions. We’ve gathered tips and tricks regarding launch on each platform from many sources, including knowledge from members of the Stanford GSB: Video Games mailing list, to help you make your next launch a success.

The Goal is Discoverability. How you get there is different.

To start planning your game’s launch, you need a lay of the land. iOS and Android are very different when it comes to discoverability.

Discoverability on iOS

For iOS, there are two main ways to get the kind of discovery that drives significant downloads.

The main driver of discovery on iOS is the Top 25 List. Your goal is to get on these lists: they are extremely powerful drivers of organic traffic, even if you only nab a top spot on a subcategory like Games > Strategy. Only download numbers seem to contribute to ranking in this list. Colloquial wisdom states that being in the Top 10 will net you about 50% of the downloads you need to maintain your position on the list, and being in the Top 25 will net you about 30%. While these are rough numbers, they show that simply being on a Top list alone is not enough.

However, an elusive but more valuable way to get discovered on iOS is to get a coveted Feature spot from Apple. You might say that it isn’t realistic to make this a goal, but the potential payoff makes building this goal into your launch worthwhile. While getting Featured is entirely determined by the whims of Apple’s staff, the following is certain:

• Making a beautiful game is required.
• Having your game be free to download significantly improves your chances.
• Don’t forget, Apple doesn’t make these picks for charity: their goal is to make money. If they think your game will monetize well, that will improve your chances.
• Lastly, integrating Apple APIs such as Game Center give you a slight edge as well.

Discoverability on Android

Android discoverability is quite different, and reflects Google’s history as a search company. Like Apple, Google Play drives a lot of organic acquisition through Top 25 lists and Featured placement, and these are a key goal of Launch. However, unlike Apple, a combination of variables determine ranking in the Google Play marketplace:

• App store optimization (ASO, not unlike SEO)
• Daily active user count (DAUs)
• Click-to-install rate
• Uninstall rate

This reflects the second major driver of organic discoverability on Android: search. Your goal is to either establish a strong brand name that you can own (ie “Angry Birds”), or optimize your app’s launch around commonly used search terms in the genre (ie “physics puzzle game”). Let’s jump into the specific launch tactics you should use for each marketplace.

Launching on iOS

You can’t control Featured placement, but you can control one thing: your placement in the Top 25 lists. The only thing that matters for this is downloads, either organic or paid. You want the biggest spike of downloads possible and that’s usually within the first week if not the first few days of launch. Here’s a number of tactics that you can use to maximize your big launch bump.

Press

By doing some prep work ahead of time, you can get press to review your game, giving you valuable exposure that can lead to social media buzz and significant downloads. To get press to review your game, you should contact them at least two weeks before launch. When approaching press about your game, make sure to do your homework. In your email to the outlet, you want to do the following to maximize your chances of a story:

• Connect with them: Show the reviewer that you read and enjoyed their coverage of similar games.
• Get their attention: Tell them what is unique about your game.
• Meet in-person: If you are in the same city, meet with them in-person to give them a demo.
• Make the sale: Explain why your game is a great fit for their audience.
• Close the deal: Give them a promo code to access your game early and ask them if they would be interested in reviewing your game.
• Negotiate embargoes: So that their reviews post when your game is live. This will help drive traffic.
• Don’t be ashamed to pay: Due to the high number of games being submitted, a number of high quality review sites have started asking for payment to put your game at the “top of the heap”. If you can afford it, do it.

Outreach

Next, you need to start building buzz about your game in the weeks leading up to launch. Be sure to give your Twitter followers and Facebook fans a heads-up that a new game is coming soon (if you don’t have social profiles for your company, now would be a good time to start them). Start sending out teaser screenshots and maybe even a Youtube trailer: this bite-sized content is easy for your fans to share and serves as a great elevator pitch for your game.

Once launch day hits, everyone in your small social corner of the world needs to know about it. Post it on your Twitter feed multiple times over the course of the day. Post it on your Facebook Page and pay to Promote the story to all of your followers. Engage in conversations with your fans about the game, and keep them abreast of any bugs or problems. Be sure to thank any fan that says they downloaded the game or reviewed it. Lastly, reach out to applicable friends and family and ask them to rate and review the game with 5 stars. This will take the whole day, but the result is a big boost to your social media buzz, your downloads, and hopefully a good bunch of 5 star ratings. This is crucial for a successful launch.

Paid acquisition

If you’re looking for a little extra boost and have money to spend, consider buying traffic within the first week of your launch, or even for launch day itself. This needs to be set up in advance and typically will cost between $0.50 and $1.50 per install, but this boost can give you the extra edge you need to break the Top 25 list. Deciding which paid advertising to buy is such a big question that we’d need a whole nother blog post to explain it fully, but here’s the cliff notes:

• Free-app-a-day websites and apps will generate a lot of exposure for you for one day for a lump sum fee. Good for use on launch day.
• Large ad campaigns from mobile ad providers will sell you as many downloads as you can buy, but they will be relatively expensive and require a minimum budget. If you’re going to go with these guys, go big and do it within the first week of launch.
• Self-serve banner advertising will often give you the most bang for your buck, but only after a couple optimization cycles. Best for maintaining position in the charts.

Launching on Android

Let’s be honest, the “Launching for iOS” section above could cover launching on Android just as well. There’s a lot between the two platforms that are similar when it comes to launch, but remember that we do have slightly different ways of achieving our goals on Android. On iOS, the goal is to get as many downloads as possible and push, push, push. With Android, you’re actually better off getting fewer, higher quality downloads that won’t uninstall (while still aiming to get as many of those as possible). Let’s examine some of the key differences from the above strategy.

Press

This is largely the same as before, but in addition to generic “games and apps” press, you want to go after the Android blog network. Android users pay significantly more attention to their cadre of bloggers than iOS users, and significant traction in these circles can pay off handsomely. To get their attention, you can use the same press tactics as mentioned above, but I would recommend being even less sales-y. These guys are often more indie than corporate, and so treat them like a fellow Android fan rather than a business person.

Outreach

Like the close-knit Android blog community, Android has strong communities online in forums and Google Groups. Be sure to build a relationship with these communities before your game launches: solicit their feedback and ideas as you build your game. When your game is ready to launch, sharing it with these communities in addition to the outreached mentioned above will give you a big boost of support.

Paid Advertising

Unlike iOS, doing a big paid advertising push to accompany your launch can backfire on Android. The goal with Android is to find high-quality users that will be less likely to uninstall your game, so your best bet with paid advertising is to start the campaigns small and optimize them before scaling them. Instead of trying to generate a big bump at launch, you should use paid advertising to maintain or increase your ranking over the long term. A long-term campaign with large ad providers or self-serve ad services are the two avenues that are most aligned with this goal.

Conclusion

Whether you’re launching on iOS, Android, Facebook or web, thinking about launch ahead of time will give you a key advantage over competitors, and hopefully this guide has helped you do just that. If you liked our guide, you should sign up for our educational newsletter.

If you have an inline profiling system, with some slight modifications, you can view that data in the Chrome web browser rather than writing a visualization tool yourself.

Having a nice graphical representation of profiling data is crucial to finding critical hotspots in a realtime application. Creating a viewer application for that custom data is a massive time sink, so before you start writing ones, know your options.

Getting started with profiling your game

Ahh performance —  that three syllable word that accounts for the headache-causing and most often avoided part of the game development cycle. Once in a development blue moon your manager will ramble into your office in a deep sweat, shouting about performance and expect you to do something about it.

search the Internet to find ways to uncover the hotspots in your code. You’ll also learn some important information to consider when deciding what kind of profiling to use in order to discover where your code is spending its time.

current program counter against a known set of debugging symbol data.

Each type of profiling has its pros and cons. External profiling does a great job at keeping your existing codebase clean, but suffers from a lack of resolution and overwhelming data density. Most external profilers will generate sample data by polling the target application at regular intervals (usually capped at 1ms), so the granularity of your sampling is limited by that constraint. If you make a call to 30 separate functions during that millisecond sampling interval, that information won’t be displayed in the resulting data (rather you may see a single function taking 1ms of time). In addition, external profilers are non-discriminatory, meaning they sample your data and give information for whatever functions are being called, on whatever threads, regardless of what you’re looking for. The excess data can make it difficult to navigate the profiling timeline to see what’s really going on.

There are several benefits and drawbacks to consider when using inline profiling.  Inline profiling offers you the opportunity to choose the resolution you need because you can use high frequency timers right in your code.  It also provides additional flexibility and granularity since you can get insert timings at a per-function and per scope level.  However, it does so with the sacrifice of littering your codebase with functions to evaluate timings. This code change is so invasive that many developers have to create separate builds and testing configurations during production to properly exclude the profiling functions at runtime.  

data. They often expend man-years of effort sunk into drawing boxes on a screen and adding proper UI information to navigate massive datasets.

Using chrome://tracing to peek under the hood

pretty awesome web browser.

chrome://tracing. What’s great about this tool is that it allows you to capture profiling data about what Chrome is doing under the hood, so you can properly adjust your javascript execution, or optimize your asset loading. Chrome://tracing offers an intimate view of the browser’s performance, recording all of Chrome’s activities across every thread, tab, and process.

Do you know what’s going on under the hood of your web browser? chrome://tracing does.

console.timeEnd(“eventname”) events, allowing you to directly profile your custom Javascript code alongside the rest of what Chrome is executing.

Viewing external profile data files

FREE.

The chrome://tracing tab acts as a visualizer for inline profiling data. You can scan, scrub, select, and more with this tool, allowing you to analyze your game profile data directly.

Understanding the chrome://tracing JSON data

non-optimized JSON file containing a sequence of event blocks. Each block includes the following name/value pairs:

• ‘cat’ – the category for this event. Useful when doing larger grouping (eg “UnitUpdates”)
• ‘name’ – the name of this event (eg ‘PathingUpdate’)
• ‘pid’ – the processor ID that spawned this event
• ‘tid’ – the thread ID that spawned this event
• ‘ts’ – the processor time stamp at the time this event was created
• ‘ph’ – the phase or type of this event
• ‘args’ – any programmatic metadata that’s attached to this event

For an example, a JSON file with a single begin/end sample is listed below. Note that an event include descriptions of its category as well as its name. Some events occur in pairs, which are marked by complementary phases (B/E or S/F – read more about that below).

[

{

“cat”: “MY_SUBSYSTEM”,  //catagory

“pid”: 4260,  //process ID

“tid”: 4776, //thread ID

“ts”: 2168627922668, //time-stamp of this event

“ph”: “B”, // Begin sample

“name”: “doSomethingCostly”, //name of this event

“args”: { //arguments associated with this event.

       }

},

]

Some sample data from the profiler’s format. You can see there’s a named category, as well as a name of the scoped event we’re tracking. Some  events come in pairs of phases (see below).

Understanding the phase (‘ph’) tag

Sample Begin/End events ( ph = B / E )

The most common event types are sample begin and sample end, denoted by setting the phase tag to “B” and “E” respectively. These events define the start and end points of a sampling time interval.

Instant events ( ph = I )

Instant events, denoted with an “I” phase tag, are great for tossing extra information into the stream to mark actions or events in your game, such as LevelLoadComplete, or  SuperHugeMonsterStartedAttack.

Instant markers in the timeline appear as small triangles. The visual difference is crucial when scrubbing over large portions of data.

Async Start/Finish events ( ph = S/F )

Async events can occur across multiple threads/processes. They are useful for tracing operations like texture loads that can start activity on other threads. The start of an async event is denoted by setting the phase tag to “S” (for start) and the end by setting the tag to “F” (for finish).

Event metadata (args)

Along with instances, chrome://tracing supports per-sample metadata (called args in the format), which can be filled in with name/value pairs of arbitrary data. This appends information to a specific event. Anyone who’s scrubbed through inline profiling data will tell you that these types of markers are invaluable when you get barraged by a flood of samples with the same call stack and need a way to determine the data associated with each instance.

Every Event and Instance can have annotated data associated with it, which is very helpful in tracking down unique data relating to a sample.

Adding capture-specific metadata

Another nice feature of the JSON format for capture analysis is the ability to append specific capture-specific metadata to the trace that may be helpful in analysis of the bigger picture. For instance storing what developer did the capture, what OS they are running, hardware specs, etc.

As mentioned, chrome:tracing will gladly accept the following syntax:

[

   {       “cat”: “MY_SUBSYSTEM”, …..   },

   {     “cat”: “MY_SUBSYSTEM”,…       },

]

And in order to add meta data, you can modify the format thusly:

{

  traceEvents: [ /*the previous format data goes here*/ ],

  someData: “this is some capture specific data”,

  someMoreData: “generated by tPhips@blah.com”

}

When you utilize the 2nd form of the JSON format, upon file-load, a button in the UI will popup labeled ‘METADATA’ that shows all the non-trace event data in a stringified form.

Generating a chrome://tracing compliant JSON file

chrome://tracing and hitting the Record tab, running, then hitting the Stop tracing button. This action will record the inline profiling events generated by all the open tabs and processes running in Chrome. You can then save the data to disk and examine its format.

github.

Moving chrome://tracing forward

The tracing page inside of Chrome offers a powerful timeline viewing tool, and like any tool, it is constantly being improved.  Here’s what you need to know about working with chrome://tracing in the future.

1. Like most Google products, the Javascript front-end code for rendering the timeline is open sourced, which is highly valuable for those of you looking to embed the process in your own applications, build-bot, or compliance testing web pages.
2. Make sure you can find and report bugs with the tracing tool inside of chrome.
3. In Case the JSON format doesn’t suit your fancy, the chome://tracing authors accept contributions on what types of timeline file/data formats to support.
4. The Systrace feature recently added to the Android SDK lets developers use the same profiling UI to analyze the performance of their native applications.

Looking for more information? Check out the how to use chrome://tracing guide and get started using this powerful tool to display profiling data from your game.

Andy Samberg, hair performance capture session.

The competition for jobs in the gaming industry is getting increasingly fierce (many companies receiving 100′s of applicants for a single position), yet many applicants consistently make the same mistakes which hurt their chances of landing the gig. I’m going to cover some of the more common mistakes I come across, as well as provide some insight into what I (and most others) look for when reviewing an applicant.

There’s no shortage of cover letter, resume, and interview “help” articles and services out there, but anything that really covers it from start to finish with information that is specific to games (and more specifically, game animation) is scarce. Much of the advice offered for cover letters and CV’s is geared towards a corporate position and the demo reel direction is often targeted at a job in film or TV, which could put animators at a disadvantage.

I’ll run through this in chronological order from a hiring perspective: cover letter, resume, demo reel, interview. So, let’s get started!

COVER LETTER…

…must be willing to work overtime for little to no money.

I’ll be honest, up until recently I didn’t write cover letters. They were never requested and rarely read. They seem to be coming back into fashion lately, though, and as part of a well presented application, deserve some attention.

I’m going to say this a few times throughout this article, as it’s one of my biggest pet peeves and a mistake I see in at least 80% of the applications that come across my desk. NAMING CONVENTIONS! We make software for a living and as such, are detail oriented and slaves to organization. Especially naming conventions! Don’t name your cover letter “cover letter.docx” or “COMANY NAME – cover.pdf”. In the folder full of potential applicants sorted alphabetically, those will get lost in the shuffle. I have to open and re-read it to find out who it belongs to (and probably rename it as well, so I don’t have to do this again in the future). Don’t make people do extra work to hire you.

Here are the three rules you should follow:

– Your name is part of it (preferably first, as this will group all of your documents together when sorted)

– The document’s name/type is called out (resume, cover letter, references, etc.)

– NO SPACES! Use underscores, dashes, or capitals to separate words visually. If I send a link to your resume via email, the link will be broken by your space.

A couple of examples of what that should look like:

DaveSmith_CoverLetter.pdf

John-Doe_Cover-Letter.docx

There are a couple of exceptions. First, if a company has specifically requested on their site that you name it a certain way, do that instead. Second, if your cover letter is submitted in the form of an email or web-based form. In those cases, make sure to get your full name in the subject field (and possibly the position you’re after too) to make it easier to find on their end.

So, what should be in the cover letter? I’m sorry to say there is no right answer here as it’s a subjective topic. Generally speaking, it should be short, flattering (to the company or project), confident (without being cocky), and highlight what you bring to the company/project. Make sure your contact info is on there and easy to read/find. If possible, maintain some kind of design continuity with your resume and other submissions (contact info in the same place, same font and layout, etc.). If the job posting described some specific skills and requirements (they usually do), pick a couple of key ones and illustrate how you meet those criteria.

What I’m looking for here is a sense of your personality and your motivation for wanting to work at the company in this role. I have never heard of someone getting turned down for a job based on what they said in their cover letter, so I wouldn’t sweat this one too much. Just make sure it represents you authentically, has been spell checked and proof read by at least a couple of people, is named correctly, and isn’t more than a page in length.

RESUME…

Applying for a Digital Makeup Artist position? Andy Serkis, performance capture for Rise of the Planet of the Apes.

First off, name that resume properly! Follow the three naming rules above and just change the words “cover letter” to “resume” and you’re all set.

A recent study suggests that recruiters spend an average of six seconds reviewing a resume before putting it on the “keep” pile or the “trash” pile. I tend to spend a bit more time than this, but I can also assume that the applicant has made it past the HR filter and is worth considering in more detail. I imagine that six seconds isn’t too far off for some of the more actively hiring companies. Regardless, this means you need to use your time wisely.

I love facts and data, and the study suggests that 80% of that six seconds is spent looking at these six things:

– Name

– Current Title/Company

– Previous Title/Company

– Previous Position Start and End Dates

– Current Position Start and End Dates

– Education

So make those things easy to find and read!

Besides the six above, the main thing I want to know is: What do you think were the biggest accomplishments in your previous job(s) and what did you do to add value to the team/project/company.

In the spirit of keeping your resume easy to digest, do whatever you can to keep it to one page. Six seconds is not enough time to read two or more pages and 90% of employers will probably never read those extra pages anyways (they might even leave them on the printer!). Keep it short, keep me interested, and leave me wanting to find out more.

A great tip I received from fellow #AltDevBlogADay author Alex Darby is to have a few people skim through your cover letter and resume quickly and summarize it back to you. This will give you a good idea of the type of impression you are making and what your strong and weak presentation points are.

Beyond that, try to avoid using photos or getting too fancy with the design. You will use up your valuable eyeball time on that stuff (Here is a great collection of minimal designs that read well and look nice. Deviant Art has tons so check there too!

DEMO REEL…

NOT Andy Serkis’ performance capture.

Once again, name that bad boy properly! Don’t slouch on what is the most important asset when looking for work and often the only thing being passed around the studio for consideration.

ALSO, make sure you have your name and contact info (email is good enough) at both ends of your reel. Make it easy to find and see.

It goes without saying that content is king here. Always choose quality over quantity. I try to make it a point to watch all the reels that cross my desk in their entirety, but sometimes they are just too much. I don’t need to see every little thing you have ever animated; only the things you are most proud of. I’d rather you leave me wanting to see more, than the feeling of seeing too much. This is a tricky balance so my best advice would be to seek out feedback on it as often and as many times as possible (something you should be doing with every piece of animation anyways).

Years ago, I had edited together what I thought was a totally sweet montage of awesome animation and quirky and humorous clips from my favorite 80′s movies. I thought that no company could resist its charm and I would be beating away offers with a stick. After showing it to some people whose feedback I respected (they all hated it) I re-edited it to something more agreeable and the world was a safer place. If you have a limited arsenal of people to get feedback from, reach out to leads and senior animators in the industry. You should be able to turn up a few dozen in no time on LinkedIn and I’m sure many would be happy (flattered, even) to throw a little critique your way. Bonus points for making a new contact in a very network-centric industry!

Now, that stuff has all been said before many times. What I want to cover is some stuff I don’t hear being told to animators enough. The kind of stuff I am looking for when watching a demo reel.

First, and I’m just going to come right out and say it, it’s ok to have mocap on your demo reel. BUT, I want to see what you did TO that mocap if you want to impress me. Take a basic walk loop and adjust it a few different ways to make it have a limp, look more masculine, more feminine, have some emotion…the possibilities are endless. Maybe grab a big action shot and make it more exaggerated with stronger posing. Show me the before and after. There is no avoiding the fact that we use mocap as one of our main tools to create game content, show me you are comfortable using it and bending it to your will. I need people who are comfortable with and good at using mocap. This is a great example of a demo reel using mocap, explaining what is and isn’t capture.

Now, that said, do NOT try to use mocap and claim it as keyframed animation. I, and many others, have been using mocap for a long time and can tell the difference 99% of the time. I have had people actually claim in an interview that certain scenes were keyframed when the movement was clearly full of mocap artifacts and impossibly detailed movement compared to the rest of their work. You just end up looking silly and I would be far more impressed if you told me about how you used this tool to achieve your shot and the challenges you faced doing so.

Adding music is another subjective topic. Personally, I have had some really great conversations in interviews about someone’s choice in music. It tells me a lot about your personality and, ultimately, that’s what the interview is really for anyways. One of my current animators had fantastic animation and effects on his reel, but I just HAD to have him in for an interview so I could ask him what the hell he was thinking putting explicitly hard-core gangster rap on it. It was a funny interview and he has turned out to be one of my favorite people I have ever worked with.

Some people suggest having nothing on there, thinking that it detracts from the animation. I say go for it. Just make sure the soundtrack dips sufficiently when the dialogue is happening. Don’t worry; I won’t turn you away because you put Lady Gaga on there.

A note on rigs: I, like everyone else, have become really tired of seeing the same few characters in every demo reel (I’m looking at you two, Bishop and Norman). I also understand how limited the selection is out there and how much time it takes to make and rig your own character. Hell, I’m in the same boat as you guys. I have asked every character artist I have ever worked with if they had a character I could animate with and have always come up empty handed. You should be spending your time getting better at your craft. It takes several lifetimes to master animation; I don’t expect you to be a master character artist and rigger on top. So, I’m not going to write you off because you’re using a standard school rig (and anyone out there who does needs to get their priorities straight), but it is always refreshing to see something new in a reel, even if the character is a little rough. Like my old animation director was fond of saying, “A good animator should be able to do good animation on anything”.

Besides solid character movement, what I am also looking for is a good understanding of staging, composition, timing (from an editing standpoint), and at least a basic understanding of how to use a camera. These are all key skills in games and will become even more relevant as we continue to push the medium. Storytelling and communication are the main pillars of gameplay and cinematics and these are some of the tools to achieve them. 

For film, you are highly specialized as an animator. You’re there to follow very specific direction to execute someone else’s vision. Camerawork, lighting, and editing are usually someone else’s job. In games, animators tend to wear several hats and work a little less specifically directed. Often an animator is responsible for an entire section of the game, from inception to implementation. The way the engines and tool sets are being engineered, animators are fast becoming “movement designers” and not simply content creators. Showing you are a well-rounded artist will help you immensely.

At the end of the day, great animation is great animation. BUT, a well-polished, lit, and properly edited demo reel with good animation will always win over a default-rendered, grey, static demo reel with good animation.

Here’s the thing, when I look at the whole package (cover letter, resume, demo reel), I take time out to consider the presentation and level of finish of the whole thing. I expect animators to be empowered and to take ownership over their respective areas. How you have represented yourself is indicative of how you will deliver an assignment on the project. The level of care you have taken to present yourself is equal to or greater than the level of care you will take when executing a task. This may or may not be 100% fact, but it is what you are communicating to me in your application. If it’s sloppy and unorganized, I can only assume you conduct your work the same way as well. Consider this when submitting your application to a company.

For inspiration, check out THIS channel on Vimeo.

THE INTERVIEW…

Image from the movie “Taken”. It’s about a father trying to find his son who is trying to save mankind from extermination…or something.

Understand going into the interview that the process itself is fundamentally flawed. Most of the people conducting the interviews have not been trained to do so and it’s a poor way to gauge your ability to do the job. Still, It’s part of the process (you have to meet the team sometime), so you might as well be as prepared as possible going in.

There are two main types of people you’re going to run into in these interviews and both are trying to figure out the answer to two basic questions: Out of all the people applying, are you the best qualified to do the job, and are you the best fit with the current company and team culture. It’s a balance of the two factors and the person with the highest score in each column gets the job. Personally, I would rate the importance 60% ability and 40% personality. Every company places different values on this though, and that’s where preparation comes in. A company like Valve probably places much higher value on personality over immediately applicable skills than a company like EA, for instance. It does have some wiggle room. A team will usually make allowances for some personality issues with a person who is exceptionally skilled and someone who is really easy to work with and takes direction well can be lacking a little in the skills department (I have found it’s more often the former, so don’t assume your witty personality will get them to overlook the fact that you can’t animate).

Who are these two types?

First, there’s the hyper-aggressive interviewer who, subconsciously or not, is trying to get you to fail at the interview. They try to overpower you with ridiculously overwritten questions and problems, trying to trip you up and find your weak points. My best advice on dealing with this type is to remain as positive as possible. I spent several years doing customer service work before games and you learn quickly that you have to fight fire with water, not more fire. Preparation and a proactive attitude are of high value in this industry and ultimately what this person is after anyways. I’m not saying to turn every possible question into rainbows and kittens; you need to remain truthful and honest in your answers. Just remain upbeat and try to find the positive takeaway from each blemish they bring up. The only lessons we learn are through mistakes, right?

The other kind of interviewer is also, thankfully, the majority of people you will encounter. These are people who are clearly not trained in it, don’t have a lot of pre-written questions or standard “where do you see yourself in five years” or “what’s your biggest flaw” type questions. What they’re after is to gauge how you will fit with the rest of the team. You won’t get to this point if your reel didn’t demonstrate your potential to do the job anyways, so that’s the only missing piece of information. You are likely going to spend more time with these people than your friends and family, so it only makes sense that their primary concern is if you will all get along.

Again, the best thing you can do is be as ready as possible for whatever you encounter. How do we prepare? As I mentioned earlier, I am an info junky. I like to go in with as much information as possible. When I have an interview with a company, I will spend at least one evening (often many evenings) finding out everything I can about the company, their employees, their products, and their culture and values.

If you aren’t familiar with the games the company makes and don’t have time to play them (I have a family, I totally understand this), YouTube is your friend. You can watch a full play through of almost any game out there and become well-versed in all of a company’s products in relatively little time.

Start with the company’s website. Check out their “About” page, media pages, and the staff page if they have one. Look for interviews available online. Even press they did for game releases or E3 can give you a useful look at the type of people who work there and what their values are.

If you can, find out who you will be interviewing with and get a little info on them as well. I’m not saying you should e-stalk someone to the point of knowing their kid’s name and wife’s social security number (and please, if you do happen to find out some personal stuff, don’t bring it up. It’s just creepy), but a little background information can be really useful. I have, on several occasions, filled dead spots in interviews by striking up conversations about common backgrounds, mutual acquaintances and so on. Don’t think for a second that they aren’t doing it to you.

That leads me to a small side note. It should be common sense, but be careful about what you put out into the internet. A company will research you before deciding to talk to you. Google yourself and look at the findings objectively. Would you want to hire yourself? In my opinion, you don’t have to be a saint online. Having an opinion and a personality are requirements in my book, so use your own best judgement on what crosses the “bad taste” line.

Speaking of personality, I know several incredible animators who are slow to get excited and to someone just meeting them, come across as uninterested. They have been passed over for jobs and companies have missed out on potentially amazing co-workers. It’s not that you shouldn’t be yourself in the interview, but be aware of how your personality might come across to complete strangers. Even saying something like “Listen, I’m a super mellow guy and I usually come across as disinterested to people who don’t know me well. I am very interested in this position and I wanted to make sure you didn’t get the wrong message.”

When I interview someone, I’m really looking for a few key things that are important to me as a lead. How much direction did you receive to create the work on your reel (how much of that work is your own and how much required some heavy hand holding), how do you take criticism and feedback (I might even give you some in the interview to see how you respond), and are we going to get along when we’re working 60+ hours a week together. If you’ve got a good personality, a bit of talent, and a proactive attitude, I would be more than happy to work with you.

Lastly, don’t come to the interview empty handed. Bring a few extra copies of your cover letter and resume (in case someone hasn’t seen them yet or forgot to print them out). Also, bring a thumb drive with a copy of your reel on it. As I said at the start, don’t make people do extra work to hire you. Bonus extras to bring: artwork, storyboards (I LOVE animators who can storyboard well), work in progress, reference videos of yourself or others you used for the shots on your reel (again, I love this stuff), or anything else you’ve done. Everyone loves to work with and be around people who are passionate about something. Bring that to the interview.

SUMMARY…

Be prepared, be organized, be polished, and be yourself. I hope we get a chance to work together someday. Good luck!

Guess what! You’ve just inherited a stinking, steaming pile of messy old code. Congratulations! It’s all yours.

Bad code can code can come from all kinds of places. Middleware, the internet, perhaps even your own company.

You know that nice guy in the corner that nobody had time to check up on? Guess what he was doing all that time. Churning out bad code.

Or remember that module someone wrote years ago, just before she left the company. That module that twenty different people have then added hacks, patches and bug fixes to, without really understanding what they were doing. Yup, that one.

Or what about that open source thing you downloaded that you knew was horrible, but it solved a very specific and quite hairy problem that would have taken you ages to do by yourself.

Bad code doesn’t have to be a problem, as long as it’s not misbehaving, and nobody pokes their bloody nose in it. Unfortunately, that state of ignorant bliss rarely lasts. A bug will be discovered. A feature requested. A new platform released. Now you have to dig into that horrible mess and try to clean it up. This article offers some humble advice for that unfortunate situation.

0. Is it worth doing?

The first thing you need to ask yourself is whether the code is worth cleaning. I’m of the opinion that when it comes to code cleaning you should either karate do “yes”, or karate do “no”. Either you assume full responsibility for the code and rework it until you end up with something that you are actually happy to maintain and proud to have in your codebase.

Or you decide that even though the code looks horrible, it isn’t cost-effective to take time out of your busy schedule to fix it. So instead you just do the smallest change possible that solves your current problem.

In other words, you either regard the code as yours or theirs.

There are merits to both alternatives. Good programmers get an itch when they see bad code. They bring out their torches and pitchforks and chant: “Unclean! Unclean!” And that is a good instinct.

But cleaning code is also a lot of work. It is easy to underestimate the time it takes. It can be nearly as time consuming as rewriting the whole thing from scratch. And it doesn’t bring any short term benefits. Two weeks cleaning code won’t add any new features to the game, but it might give you some new bugs.

On the other hand, the long term effects of never cleaning your code can be devastating. Entropy is the code-killer.

So, never an easy choice. Some things to consider are:

• How many changes do you expect to make to the code?

  Is it just this one small bug that you need to fix, or is this code that you expect to return to many times to tweak and tune and add new features. If it’s just this one bug, then perhaps it is best to let sleeping dogs lie. However, if this is a module that you will need to mess around with a lot, then spending some time to clean it up now, will save a lot of headache later.

• Will you need/want to import upstream changes?

  Is this an open source project that is under active development? If so, and you want to pull the changes made upstream you can’t make any big changes to the code or you will be in merge hell every time you pull. So just be a nice team player, accept its idiosyncrasies and send patches with your bug fixes to the maintainer.

• How much work is it?

  How many lines of code can you realistically clean in a day? An order of magnitude estimate says more than 100 and less than 10 000, so let’s say 1 000. So if the module has 30 000 lines, you might be looking at a month of work. Can you spend that? Is it worth it?

• Is it a part of your core functionality?

  If what the module does is something peripheral, like say font rendering or image loading, you might not care that it is messy. You might swap out the whole thing for something else in the future, who knows. But you should own the code that relates to your core competence.

• How bad is it?

  If the code is just slightly bad, then perhaps you can live with it. If it is mind-numbingly, frustratingly incomprehensibly bad, then perhaps something needs to be done.

1. Get a test case

Seriously cleaning a piece of code means messing around with it a lot. You will break things.

If you have a decent test case with good coverage you will immediately know what has broken and you can usually quite quickly figure out what stupid mistake you just made. The time and anxiety this saves over the course of the cleaning process is just ridiculous. Get a test case. It’s the first thing you should do.

Unit tests are best, but all code is not amenable to to unit testing. (Test fanatics, send your hate mail now!) If unit tests are too cumbersome, use an integration test instead. For example, fire up a game level and run the character through a specific set of actions related to the code you are cleaning.

Since such tests ate more time consuming, it might not make sense to run it after every change you make, which would be ideal. But as you put every single change you make into source control, it’s not so bad. Run the test every once in a while (e.g., every five changes). When it discovers a problem you can do a binary search of those last few commits to find out which one caused the problem.

If you discover an issue that wasn’t detected by your test, make sure that you add that to the test, so that you capture it in the future.

2. Use source control

Do people still have to be told to use source control? I sure hope not.

For cleaning work it is absolutely crucial. You will be making lots and lots of small changes to the code. If something breaks you want to be able to look back in the revision history and find out where it broke.

Also, if you are anything like me, you will sometimes start down a refactoring path (like removing a stupid class) and realize after a while that it wasn’t such a good idea, or, that it was a good idea, but that everything would be a lot simpler if you did something else first. So you want to be able to quickly revert everything you just did and begin anew.

Your company should have a source control system in-place that allows you to do these changes in a separate branch and commit as much as you like without disturbing anybody else.

But even if it doesn’t, you should still use source control. In that case, download mercurial (or git), create a new repository and put the code that you checked out of your company’s stupid system there. Do your changes in that repository, committing as you go. When you are done you can merge everything back into the stupid system.

Cloning the repository into a sensible source control system only takes a few minutes. It is absolutely worth it. If you don’t know mercurial, spend an hour to learn it. You will be happy you did. Or if you prefer, spend 30 hours to learn git instead. (I kid! Not really. Nerd fight now!)

3. Make one (small) change at a time

There are two ways of improving bad code: revolution and reform. The revolution method is to burn everything with fire and rewrite it from scratch. The reform method is to refactor the code with one small change at a time without ever breaking it.

This article is about the reform method. I’m not saying that revolutions never are necessary. Sometimes things are so bad that they just need to go. But people who get frustrated with the slow pace of reform and advocate revolution often fail to realize the full complexity of the problem and thus don’t give the existing system enough credit for the things it does.

Joel Spolsky has written a classic article about this without falling into the trap of making strained political metaphors.

The best way of reforming code is to make one minimal change at a time, test it and commit it. When the change is small it is easier to understand its consequences and make sure that it doesn’t affect the existing functionality. If something goes wrong, you only have a small amount of code that you need to check. If you start doing a change and realize that it is bad, you won’t loose much work by reverting to the last commit. If you notice after a while that something has gone subtly wrong, a binary search in the revision history will let you find the small change that introduced the problem.

A common mistake is to do more than one thing at the same time. For example, while getting rid of an unnecessary level of inheritance you might notice that the API methods are not as orthogonal as you would like them to be and start to rearrange them. Don’t! Get rid of the inheritance first, commit that and then fix the API.

Smart programmers organize the way they work so that they don’t have to be that smart.

Try to find a path that takes you from what the code is now to what you want it to be in a sequence of small steps. For example, in one step you might rename the methods to give them more sane names. In the next, you might change some member variables to function parameters. Then you reorder some algorithms so that they are clearer. And so on.

If you start doing a change and realize that it was a bigger change than you originally thought, don’t be afraid to revert and find a way of doing the same thing in smaller, simpler steps.

4. Don’t clean and fix at the same time

This is a corollary to (3), but important enough to get its own point.

It is a common problem. You start to look at a module because you want to add some new functionality. Then you notice that the code is really badly organized, so you start reorganizing it at the same time as you are adding the new functionality.

The problem with this is that cleaning and fixing has diametrically opposite goals. When you clean, you want to make the code look better without changing its functionality. When you fix, you want to change its functionality to something better. If you clean and fix at the same time it becomes very hard to make sure that your cleaning didn’t indadvertedly change something.

Do the cleaning first. Then, when you have a nice clean base to work with, add the new functionality.

5. Remove any functionality that you are not using

The time it takes to clean is proportional to the amount of code, its complexity and its messiness.

If there is any functionality in the code that you are currently not using and don’t plan to be using in the foreseeable future — get rid of it. That will both reduce the amount of code you will have to go through and its complexity (by getting rid of unnecessary concepts and dependencies). You will be able to clean faster and the end result will be simpler.

Don’t save code because “who knows, you might need it some day”. Code is costly — it needs to be ported, bug checked, read and understood. The less code you have, the better. In the unlikely event that you do need the old code, you can always find it in the source repository.

6. Delete most of the comments

Bad code rarely has good comments. Instead, they are often:

// Pointless:
 
   
 
  	// Set x to 3
 
  	x = 3;
 
   
 
  // Incomprehensible:
 
   
 
  	// Fix for CB (aug)
 
  	pos += vector3(0, -0.007, 0);
 
   
 
  // Sowing fear and doubt:
 
   
 
  	// Really we shouldn't be doing this
 
  	t = get_latest_time();
 
   
 
  // Downright lying:
 
   
 
  	// p cannot be NULL here
 
  	p->set_speed(0.7);

Read through the code. If a comment doesn’t make sense to you and doesn’t further your understanding of the code — get rid of it. Otherwise you will just waste mental energy on trying to understand that comment on each future reading of the code.

The same goes for dead code that has been commented or #ifdef’ed out. Get rid of it. It’s there in the source repository if you need it.

Even when comments are correct and useful, remember that you will be doing a lot of refactoring of the code. The comments may no longer be correct when you are done. And there is no unit test in world that can tell you if you have “broken the comments”.

Good code needs few comments because the code itself is clearly written and easy to understand. Variables with good names do not need comments explaining their purpose. Functions with clear inputs and outputs and no special cases or gotchas require little explanation. Simple, well written algorithms can be understood without comments. Asserts document expectations and preconditions.

In many cases the best thing to do is just to get rid of all old comments, focus on making the code clear and readable, and then add back whatever comments are needed — now reflecting the new API and your own understanding of the code.

7. Get rid of shared mutable state

Shared mutable state is the single biggest problem when it comes to understanding code, because it allows for spooky “action at a distance”, where one piece of code changes how a completely different piece of code behaves. People often say that multithreading is difficult. But really, it is the fact that the threads share mutable state that is the problem. If you get rid of that, multithreading is not so complex.

Since your goal is to write high-performant software, you won’t be able to get rid of all mutable state, but your code can still benefit enormously from reducing it as much as possible. Strive for programs that are “almost functional” and make sure you know exactly what state you are mutating where and why.

Shared mutable state can come from several different places:

• Global variables. The classic example. By now everybody surely knows that global variables are bad. But note (and this is a distinction that people sometimes fail to make), that it is only shared mutable state that is problematic. Global constants are not bad. Pi is not bad. Sprintf is not bad.

• Objects — big bags of fun. Objects are a way for a large number of functions (the methods) to implicitly share a big bag of mutable state (the members). If a lazy programmer needs to pass some information around between methods, she can just make a new member that they can read and write as they please. It’s almost like a global variable. How fun! The more members and the more methods an object has, the bigger this problem is.

• Megafunctions. You have heard about them. These mythic creatures that dwell in the deepest recesses of the darkest codebases. Broken programmers talk about them in dusky bars, their sanity shattered by their encounters: “I just kept scrolling and scrolling. I couldn’t believe my eyes. It was 12 000 lines long.”

  When functions are big enough, their local variables are almost as bad as global variables. It becomes impossible to tell what effect a change to a local variable might have 2 000 lines further down in the code.

• Reference and pointer parameters. Reference and pointer parameters that are passed without const can be used to subtly share mutable state between the caller, the callee and anyone else who might be passed the same pointer.

Here are some practical ideas for getting rid of shared mutable state:

• Split big functions into smaller ones.

• Split big objects into smaller ones by grouping members that belong together.

• Make members private.

• Change methods to be const and return the result instead of mutating state.

• Change methods to be static and take their arguments as parameters instead of reading them from shared state.

• Get rid of objects entirely and implement the functionality as pure functions without side effects.

• Make local variables const.

• Change pointer and reference arguments to const.

8. Get rid of unnecessary complexity

Unnecessary complexity is often a result of over-engineering — where the support structures (for serialization, reference counting, virtualized interfaces, abstract factories, visitors, etc) dwarf the code that performs the actual functionality.

Sometimes over-engineering occurs because software projects start out with a lot more ambitious goals than what actually gets implemented. More often, I think, it reflects the ambitions/esthetics of a programmer who has read books on design patterns and the waterfall model and believes that over-engineering makes a product “solid” and “high-quality”.

Often, the heavy, rigid, overly complex model that results is unable to adapt to feature requests that were not anticipated by the designer. Those features are then implemented as hacks, bolt-ons and backdoors on top of the ivory tower resulting in a schizophrenic mix of absolute order and utter chaos.

The cure against over-engineering is YAGNI — you are not gonna need it! Only build the things that you know you need. Add more complicated stuff when you need it, not before.

Some practical ideas for cleaning out of unnecessary complexity:

• Remove the functionality you are not using (as suggested above).

• Simplify necessary concepts, and get rid of unneeded ones.

• Remove unnecessary abstractions, replace with concrete implementations.

• Remove unnecessary virtualization and simplify object hierarchies.

• If only one setting is ever used, get rid of the possibility of running the module in other configurations.

9. That is all

Now go clean your room!

This has also been posted to The Bitsquid blog.

Making money on Android can be hard. Many developers devote countless hours to building, testing, and marketing their apps only to fall short of that income-independent holy grail. We went through over 50 Android game & app postmortems and developer income reports to put together a list of common best practices and tactics that worked.

In-App Purchases versus Advertising

We are big proponents of freemium game design on our blog, so imagine our surprise when we found out how the majority of independent Android game developers make their living: ads!

As it turns out, implementing a fully baked freemium game design is rather difficult. You can’t simply tack on freemium monetization after the fact: you need to build the game for freemium monetization from the ground up, complete with appropriate gating and enticing in-app purchases. When faced with this daunting design challenge, most developers opt for in-game advertising instead. Even when they did implement in-app purchases, it typically accounted for less than 5% of their revenue.

But Betable, you say, won’t users hate having ads in their game? Yes, they will. However, what’s surprising is how few of them are willing to pay to get rid of them: we found that less than 1% of revenue typically comes from Paid, ad-free versions of Free apps. This may also be a function of the frequency of advertising in apps on the Android platform, but it’s still a very low number. This tells us that while users dislike ads, they dislike paying for apps more.

Use multiple ad providers

One of the key tips we found for maximizing ad revenue is to use a mix of small and large ad providers. Small ad providers have low fill rates, but pay you well for the ads that you show. Large ad providers can always fill your inventory, but typically have a significantly lower eCPM. A common strategy is to work with one or two small ad providers to fill as many spots as possible, and then let the large provider fill the remaining inventory. This is also very important because revenue from each provider can fluctuate wildly month-over-month, so diversifying your ad providers gives you some insulation against those changes.

For fun, we wanted to post the average eCPM and inventory fill rate from each popular Android ad provider below. These numbers should not be taken as gospel, but hopefully help:

• AdMob – $1.00 eCPM, almost unlimited inventory
• InMobi – $1.00 eCPM, large inventory (especially international)
• Millennial Media – $1.25 eCPM, large inventory (mostly US)
• Madvertise – $6.00 eCPM, small inventory
• Leadbolt – $3.5 eCPM, moderate inventory
• revmob – $6.50 eCPM, small inventory, interstitial ads only
• Mobfox – $6.00 eCPM, very small inventory

Utilize App Store Optimization

While we’ve written a MobileDevHQ.

Optimize your ad placement

Optimizing your ad placement is tricky business. You’ve got to eat, so you need to make money, but you’d also like do so in a way that doesn’t totally ruin the user experience. Taking equal inspiration from Johannes Borchardt, we’ll show you some potential optimizations and then you can decide which approach is right for you.

Option 1) Optimize for Visibility

With this method, you place your ad where users are most likely to see it, but not in the line-of-fire of gameplay. The goal here is to maximize the likelihood that a user sees the ad, is interested in it, and then clicks on the ad. This generates the highest quality clicks.

Option 2) Optimize for Clicks

With this method, you place the advertisement where users are most likely to click, whether it’s by accident or because the ads are in an area of the screen that is a focal point during gameplay. The goal here is to maximize the likelihood that a user clicks on an ad, period. This generates the most clicks but can lead to disgruntled users. Also, if done too intrusively, it can upset your advertisers.

Option 3) Optimize for Gameplay

With this method, you place the ads in non-gameplay screens such as the menu, the inventory screen, and others. The goal here is to leave gameplay intact to preserve the user experience. This method generates the least clicks, but is least likely to prompt complaints from your users.

When optimizing for gameplay, many developers opt for interstitial ads. These ads have the benefit of fitting well in between gameplay chunks, such as between turns in an asynchronous game or between levels in a puzzle game. These ads often pay well compared to banner ads and don’t intrude on your game’s immersion like banner ads.

Build multiple apps in different categories

This might be the most obvious tip here, but a developer with a diversified portfolio of multiple apps always outperforms the developer with one project. Other than the truism that you shouldn’t place all of your revenue eggs in one basket, there are a number of advantages to this approach. By building different games and apps for different audiences, you’re increasing your overall target audience. You’re also attacking different niches, which might be less competitive than your current target niche of app or game type. It’s very common for one game or app in your stable to generate the lion’s share of your revenue and impressions. You won’t know which app this is until you create it, but having a workhorse app can power your entire ecosystem with cross promotion.

Cross promote your other apps with House Ads

Admob and other services on Android give you the ability to cross-promote your apps using your own ad space. This is huge for growing your ecosystem, as you get to double-dip in revenue and impressions from your users. Furthermore, you can maximize the engagement of your existing audience by matching them with the right app. And perhaps most importantly, this gives you a ton of free marketing firepower for promoting your next project and extending your ecosystem further.

Conclusion: Build an ecosystem

To tie together the tips mentioned above, developers need to think of their entire user base as one ecosystem. Like Reddit or ICanHazCheezburger, mobile apps that cover diverse interests can build on each other around a central brand. Even though they cast wide nets, these sites are good examples because they can still narrow down their target audience to only a few key demographics. To figure this out for yourself, think about why your users use your apps or how they get value out of them. Do your users enjoy your dead-simple budgeting app? They might appreciate a dead-simple to-do list. Think about what type of person is using your most popular apps to identify opportunities for new apps. Maybe that user who loves your dead-simple budgeting app would play a stat-driven baseball sim? You won’t know until you try, but by thinking of your user base across all apps as a single ecosystem, you can identify which audience you have struck a chord with and continue to grow. And as your ecosystem grows, the downloads, impressions and revenue will follow.