Uni Guest Lectures 02

For our second week of guest lectures, we’ve had Mark Craig, the Programming Director of Lucid Games developing games on iOS / Android, previously lead Game Programmer of Bizarre Creations working on console game before the studio was closed by Activision. He came in to discuss getting a job as a programmer as well as mobile/app based development.

App Development
Speaking as a person who has neither a phone nor tablet, this topic is a little beyond me so I can’t offer much opinion beyond the most basic of observations. One of the major considerations when it comes to developing games for the tablet/phone market is that there are a lot of tablets and phones out there. Whilst this makes for a larger market, it also makes for a highly varied one (particularly in Android’s case), with the three major divides identified by Craig as follows:

iOS (Apple)

  • Very powerful devices; iPad 2 in particular is the current reigning king (even over the iPad 3, amusingly enough).
  • A good API, which is always a plus, particularly if you’re just getting started.
  • Runs on Objective C; can also work C++ code. I only have experience with C# and only a trickle of C++; Objective C is supposedly an extension of the latter using messages, instantiation and dynamic typing, making it ‘looser’ than its more static cousins.
  • Finally, the dev environment is good, but unstable; so in other words, the old adage of saving often is still very much in play.
  • The (free) simulator for testing an iOS app on a PC is good to get started with but will not give an accurate indication of performance; it’s no emulator.
  • Learning the profiling tools is vital.
  • Plenty of good tutorials on working in its environment (Ray Wenderlich being his primary recommendation).

Android (Google, Open Handset Alliance)

  • Largest, but also most diverse, userbase; whilst iOS only runs on Apple hardware, Android can be deployed onto nigh-on everything… and is. Hence, the specs of your average /target customer can be hard to judge.
  • Dev environment is more generalised; designed more for apps than games.
  • People take their time to upgrade; over half are still running Android 2.3 ‘Gingerbread’.
  • Finally, due to it coming from Google and its open-source nature in general, Android users tend to expect software for free, making monetisation difficult.
  • Can be developed on OSX, Linux and Windows; in that order in terms of ease of use. He also recommended learning the command line interface to understand Android’s ins and outs.
  • Viable Android 4.0 dev devices can be bought for as little as £60 (specifically NATPC; basically everything that matters aside from the screen and the battery are of a good spec)
  • Java OS
  • For coding in C++, use the NDK and transfer information through the JNI. However painful that may be.
  • Google has a 50Mb restriction; if your game is larger than this, you’ll need to arrange some kind of downloader (ie the submission is an installer than downloads the full game from somewhere else)

BlackBerry (Research In Motion)

  • Smaller userbase compared to iOS/Android.
  • Development is straightforward.
  • Less competition due to a smaller app base; RIM is trying to encourage a wider spread by paying developers who meet certain technical targets.
  • Blackberry users in general are willing to pay more.
  • Generally, not a bad market to get a foothold into.

Team Sizes
Craig also delivered a small run-down of team sizes for developing small-scale games, ranging from lone coding warriors to teams of up to 15 people:

Small scale; typically single-screen games
1 – Generally a Coder/Artist, who builds the game prototype and then starts bringing assets in.
2 – Like the above, but split in two; one artist, one coder working in parallel. Typically one hires the other, or it’s a pre-arranged team.

Medium scale; games liable to involve multiple levels and so on
3-5 – Typical mix runs 1-2 coders, 1-2 artists, and the remaining position(s) filled by audio experts and designers. As an aside, this arrangement seems very reminiscent of a mod team; they tend to revolve around a few core members and other contributors who chip in when they can:
Nightmare House 2: a Design/Lead, an artist, a programmer, an audio expert and a scene choreographer (not counting voice actors)
Jailbreak: Source: 3 Designer/Artists, a programmer and a ‘Bugfinder General’ / Beta testing lead, plus a rotating bundle of testers / contributors

Large scale; the sort of thing that could appear on a console, for example
5-15 – Mix of all types, and likely to have a lead to keep things on hand.

Payment Models
A quick run-through of the payment models available:

Paid App
The traditional method; pay an upfront charge and recieve the whole game. The tricky part on the app market is that consumers generally don’t expect prices to be that high.

Paid with in-App purchases
The general answer to the above; both the price and game are ‘sliced’ apart and made available in smaller, individually purchased chunks. This keeps the immediate price down, but can feel ‘cheap’ if mishandled. Best not to think of it as DLC, I’d hazard.

Free App with in-App purchases
There are actually multiple approaches to this. There’s the most well-known methods akin to Zygna and free-to-play MMORPGs where ingame items or abilities are purchased through an ingame store, or there’s the method that runs similar to the above, only without the ‘Paid’ part (meaning the first level is essentially a free demo)

Free App, Ad supported
The game is free, but contains adverts; its these adverts that gain the developers revenue. Typically, a Paid ad-free edition is also released in tandem. Most common on the Android market.

Particularly when working as a small team, it’s vitally important that you don’t try to do everything yourself!

2D – Cocos 2D / Cocos 2DX, Torque 2D
3D – Unity, UDK, Torque 3D

Open Source Libraries
Physics: Box2D, Bullet Physics
Scripting: Lua, Python
Rendering: Oolong engine, Irrlicht, Ogre3D

Testing and Submission – iOS


  • Dev builds only run on valid provisioning profiles; Apple’s anti-piracy at work.
  • Builds can be sent to testers as .ipa files.
  • Testflight can deploy directly to devices.
  • Analytics (ie Flurry) can log errors and user behaviour.


  • Takes longer than you’d think to put together a submission package together; due mostly to icons. You need a ridiculous number of icons.
  • App must be set up with iTunesConnect; this also allows price tweaking and other tools.
  • 5-10 day delay between submission and release, due mostly to the review queue. Actual app review is very short and not in-depth, and should not be relied on for bug catching.

Getting a job as a Programmer

Most companies advertise their roles; the general rule of thumb is to pick the role you’re most interested in, research it thoroughly and tune your CV accordingly. The CV lists your skills, the cover letter shows your enthusiasm and the Portfolio essentially acts as proof.

Demos are the single best way to get hired, simply as they act as the highest form of proof (short of actually having a published game). They serve as a real and interactive demonstration of ability and again, are the closest thing to actual functional game short of an actual functional game.

When giving examples, he gave a general divide of Gameplay and Graphics; a Gameplay demo – built in Unity / UDK etc – would be all about… well, the gameplay. Getting it as tight as possible, with art a secondary consideration. With Graphics, it’s the inverse; the point is simply to display; effects, lighting renderers, if it works, show it! Someone raised a question on AI demos, to which the focus would be simply to display the decision making as clearly as possible.

He also ran us through some Interview and Pre-Interview tests; programming and abstract logic problems as well as tests of technical knowledge. The general thread seems to be in these cases to spot the obvious answer and improve on it; not to just ‘complete the task’ but to ‘complete the task in the best possible way’, with bonus points if you can find some way to improve on it further beyond the questioner’s expectations; the example being fixing a bugged Pacman game… and implementing audio at the same time. As some general tips, he also stressed the importance of research; research the company, research the games, have ready a list of questions and generally just be ready to talk with confidence to the person on the other side. Considering everyone in the games industry is enthusiastic about games (else we wouldn’t be here), it’s always best to remember you and your interview will have at least that in common.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s