For our third week of lectures here at Bolton, we have had Nick Davis, CEO and head producer of Lucid Games; the same company Mark Craig hailed from, to run us through the business side of game creation; explanation the role of the producer, how to get a game signed up with a publisher, the development phases (as relate to business) and a comparison between working in small and large studios.

As a producer, your role is essentially somewhere between management and buffering, though things vary between studios and blur when the company is small. In Davis’ case, his job runs the whole gamut from team management and scheduling – setting up deadlines and keeping everyone aware of them – hiring and publisher and external relations; external meaning things like licensing, marketing, outsourcing and press. They essentially serve as a ‘shell’ around the company, ensuring the developers can do their work with as little interference as possible. That said, he did stress the importance of having a strong awareness of deadlines and pressures; keeping at least part of your mind on the bigger picture. This is particularly true in small-team studios, where the company’s position is a lot more precarious and dependant on striking its payment deadlines. The role can vary from company to company, though it’s generally a good idea for everyone to at least be aware of everyone else’s field.

Getting Games Signed

On getting a game signed with a publisher for funding with a new IP, he identified the following strategies. In all cases, the objective is to ensure the producers can understand your goal and what you plan to build.

Paper Pitch
Quite literally a pitch document. The wordier it is the worse its reception; the example he showed us was a powerpoint presentation with plenty of images and concepts. This is cheap for the developers, but risky to the producers, as there is no real indication of the final product; it’s just words on a page. No proof; essentially just promises on a scrap of paper.

Video / Ripomatic
Stepping up from a paper pitch, we have the Video/Ripomatic. These involve stitching together a video from footage of existing films, games, whathaveyou with the intent of getting across the feel and style of the game; good for providing an indication of art styles, environments and such, but awkward on displaying actual gameplay without saying the words ‘Like This But-‘. Still, it serves as being more visual than the paper pitch for a similar time/cost investment on the part of the developer. Probably combined they could make a decent pitch… but there’s still a high risk to the publisher.

Prototype
Probably the best option; a small prototype of core gameplay tossed together using freeware or existing technology (ie Unity,, Torque2D, UDK or any in-house engines the studio may have kicking around). This gives the producers a handle on the gameplay of the game and the core question of whether or not it shows promise and is worth investing in. Odds are you’re not going to have much in the visuals department here, so combining it with a paper pitch seems a wise idea. This is the highest so far in development costs and time as it requires actual coding and creation work ahead of a signing (with still no garauntee of sucess) whilst showing the lowest risk to the producer, as it proves you’ve gotten somewhere already.

Previsualisation
Finally, we have the previs; quite literally faking ingame footage that looks representative of the final product. It is not cheap, and it is still not guaranteed not to fall flat on its face, but is the most likely to impress the publishers for being representative of the final product. But the downside is the cost; this is the sort of thing only available to a larger studio.

The whole point is the visuals; a picture speaks a thousand words and all that jazz. Words on a page can be misinterpreted and vague; something with a lot of visual imagery can get a clearer idea across much faster and much more successfully.

Alternatively, a more established studio may find itself approached by a publisher as opposed to the other way around; they come to you asking you to create a game in x genre or to reboot x franchise. This generally only occurs with studios that have proven their expertise in certain genres, and you are still expected to draw up a pitch; the advantage is the pre-established focus and budget estimate.

The Contract

Once a game is signed off, contract negotiations can begin; always the most fun part of any business enterprise. This generally consists of the developer and publisher having teams of lawyers toss hefty 50-page documents of legalese at each other until someone calls a truce; usual sticking points being royalties, termination clauses, ancillaries, non-compete clauses and IP retention. As a developer, the further along you are in your development process, the stronger your position. It’s always a balance of risk and reward on both sides, with these points being the areas where the interests of the developer and the interests of the publisher most collide:

With royalties, obviously the developers want their share, but the publishers also need their return on their investment. With termination clauses, both need an escape if the other side isn’t holding up, but at the same time wants to ensure their hard work / money isn’t going to be unexpectedly ditched. With ancillaries… well, no-one really gets ancillaries. Non-compete clauses essentially tie the developer to prevent them making similar games for different competing companies (for example, you may be contracted to build a racing game with the NCC of not building another one for x number of years). The developer will want this as vague as possible and the publisher as explicit as possible; the publisher doesn’t want to be paying a studio that’s also making competing products and the developer doesn’t want to be tied down from accepting later contracts once they complete this one. It’s a balance.

IP Retention gets it’s own little subtopic; in an ideal world you would hold the rights to your intellectual property, and since it is generally you pitching your idea to the publisher, it seems obvious that it is your idea and you should keep it. On the other hand, if you sign with a producer, they are essentially agreeing to pay you to make your game, and this (in large studio projects) is not exactly cheap; they deserve some credit and IP control themselves. The more you ask for and the earlier you ask it, the more you should expect to lose your IP. And at the end of the day, if you don’t get the money to make your game, your idea is still worthless anyway. Generally, IP retention tends to amount in the developers getting first dibs on sequels, which generally makes sense, or else the publisher agrees to a multi-game (essentially a ‘franchise’) contract, with the IP being held by them for that period until the contract is complete. It’s a fuzzy one.

Budgets

For an average console game, you can generally expect your split to fall along the lines of 60/40 Development/Marketing. This can vary of course; it’s just a rough average. This money gets spent internally; staff wages and overheads and externally; Outsourcing (typically 10-20%), Licensing, Legal, QA and Localisation.

When it comes to development costs, a large studio can generally expect staff of around 200; this was Bizarre Creations at its peak, with 100 staff per title. Davis introduced to us the concept of the ‘Man Month Rate’; essentially how much each staff member costs per month to employ, which goes beyond just wages. You have the equipment and software licenses they need, the premises they need to work in, the insurance and the utilities. As a general  rule, he says to expect £5000-8000 per person per month. For a year, that’s £60,000-£96,000. For a 100 man team on a two year dev cycle, you’re looking at a cost of 6-10 million a year to fund a studio. Hence the need for publishers.

Outsourcing can help alleviate this to a degree; by outsourcing certain tasks (primarily 3D modelling grunt-work, motion capture, QA testing, music and voice acting) you remove the cost of having the facilities and staff set up ‘bespoke’ in studio complete with their equipment and premises. Obviously major tasks – design and programming – should never be outsourced, but designers and coders can generally be expected to be on-staff the full run through of the development process anyway. Speaking of…

The Development Process

(Davis had a very fancy chart for this that I have no means of recreating in wordpress, so imagine some fancy powerpointing here)

There are four main phases Davis identifies: Prototype, Pre-Production, Production and Mastering. To break them down on a dev cycle of 24 months, max 75 staff:

Prototype
Working with a core team of programmers, designers and artists, build a functional proof-of-concept to show the idea is workable. This may be the point of pitching to the publisher, in any case the purpose is to have a very rough form of the game playable with the core mechanics complete. From here, the initial specifications of the project can be drawn out; scope, budget, team size and timeframe.

Pre-Production
Here, the idea is to push for a ‘First Playable’ form of the game; complete, but unpolished and lacking a majorityof art assets. This is the sign-off phase before production starts; if the Pre-Prod still isn’t worth playing, go back to Prototype and hack at it until it works. This is where the team sizes and costs start to grow, so its best to do the majority of the comparatively cheap design work here; once an idea is proven, then it can go into production. In our example, the Pre-Production stage would last around 8 months of the total 24, with a staff of 10 or so building to 25 and ramping up to 75 for production.

Production
The longest, largest and most expensive stage. This is where the grunt work of getting the game together comes in; it is pure content creation. If pre-production is the skeleton of the game, production is the meat. Outsourcing starts coming in here. For our example, production should be expected to last 12 months, running the maximum 75 staff with a wind-down towards 40 towards the end.

Mastering
Essentially the polishing stage; this balancing, alpha and beta testing, polishing and to a degree clean up from the rollercoaster of production. QA is heaviest during this stage. Here, the game is finalised prior to release; in our example, 4 months running a staff of 40 to get it shipped.

Measuring Progress

Both the developers and publishers need and want a clear idea of the progress of the project, and to that end they introduce Milestones and Greenlights; Milestones are essentially a monthly or bimonthly deadline, saying ‘at this point in time we will have x feature implemented’. These are typically linked to payments, making them of crucial importance to smaller studios. Once again, developers will want these as loose and possible and the publishers as tight. Greenlights are run less often, and involve a full executive review from Business, Marketing, PR and so forth. These are the points where the game can get canned. Typically they come up at major milestones within a project; First Playable, Mid Production, Alpha and Beta. Fun for the whole family.

On Large and Small Studios

Davis’ experience on this topic stems from his work in Bizarre Creations under Activision, then his leading of Lucid Games when Bizarre was closed down. At Bizarre, as noted earlier, a staff of around 200 building high-end console games – primarily racing, whilst at Lucid, it was initially a core of 8 founding members that has expanded to a team of 28 + 10 contractors on 3 titles.

In common, the process and disciplines remain, but Lucid naturally has its scope reduced to meet its budget; this combined with the smaller size gives it much more flexibility but also makes it far more reliant on milestone payments, as it doesn’t have a lot of capital to keep it afloat in the event of a missed deadline. Smaller studios are in this sense naturally more precarious. Identifying the key features of large and small studios, Davis identified:

Large
Gets the big projects and latest tech, and is generally filled with experts with a higher(?) sense of security, but at the risk of pigeonholing and a shrinking of the wider picture. Large-scale games can also be quite the dominating slog when you have development cycles measured in years.

Small
Smaller scale and budget, but wider fields of knowledge; team members need to be versatile, as there are generally more tasks than there are people to complete them. This gives you a more rounded experience, but with less depth; there’s a lack of specialisation. As noted several times, they are also far more precarious, but with a faster project turnaround; games generally taking anywhere from 3 months to less than a year. It varies, naturally.

On Where To Start

As usual, the crux of Davis’ advice was research; knowing what you’re getting into and knowing to get into it at. Being willing to accept compromises early on whilst building up your experience is important, and having something you’ve made to show or better yet sell will get you further. Tailoring your CVs to each target will go a long way, and understand the place you’re applying to.

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.

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

Frameworks
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

Testing

• 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.

Submission

• 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.

As part of the Business and Computer Games Module here at Bolton, we’re getting guest industry lectures popping by once a week to talk to us about various topics. For the first such talk, we’ve had David Bramhall and Will Maiden from Sony, both Bolton graduates, in Production and Design roles respectively. They came here to discuss their roles and their general path of advancement, give a general overview of the game development process start-to-finish and give advice on entering into the industry. I’ve thrown in a few tid-bits from my own knowledge, mostly on the Art path side of things.

With the Production path, recruits generally start off as runners supporting the rest of the team; doing odd jobs here and there and getting to know people. From there, people move up to take on a team / management role for a small group working on a small task, ie one level or something similar. Their purpose is to keep everything on track; solve team-wide problems and assist communication. From there it pretty much stays the same but with an ever growing scope; from a small subsystem all the way up to the entire game itself, managing budget and deadlines and generally trying to inject a sense of reality into all us crazy arty types. Poor bastards. Production generally only has a few roles; makes sense considering they’re basically internal team leaders, so there’d only be as many as there are teams. On the Motorstorm team for example, there were around 7 (I assume this does not include runners).

On the Design side, it seems to largely be a mish-mash of everything; a designer needs to know at minimum the bare bones of every field, so that they can understand how they can be meshed together to create games both in a timely manner and in a way achievable at runtime on current consumer hardware. Whilst they are ‘idea guys’, this is something of a misnomer; a Designer’s role is not to come up with ideas, it is to come up with ideas and completely run with them; taking critique, making changes and fully working out every system and mechanic, trying to take into account the feedback from all the different groups along with production and management. It’s a little like the difference between having the idea for a novel and actually sitting down and writing it. Their role is not just to come up with ideas; it is also to figure out how to make these ideas work. At production time, it will also be their responsibility to keep them running, amend and make changes to things depending on how the project is going and partially to implement them too.

The Design path is less like a path and more like an upside-down tree; there’s lots of sub-branches at the bottom that slowly whittle down to less specialised posts further up the ladder. Frankly calling it a ‘path’ in the first place feels like a bit of a misnomer; it’s a very broad field:

• You have Level Design, which involves designing environments from on-paper prototypes up to the Greybox / Whitebox / Devbox / Blocking ‘Playable but Ugly’ stage (I’ve seen over a thousand different terms for this; Devbox is my personal preference thanks to the Source engine) and keeping it playable as the artists try to chisel it into something pretty. Involves sketching down ideas, some basic modelling / map-editing knowledge, a lot of scripting to get the gameplay up and running and then the ability to play the same level over and over again to ensure it hasn’t been broken without turning Johnny into a dull boy. Understanding the hows and whys of level design is important; ensuring the level has proper flow, balance and pacing and feels seamless enough to the player to allow immersion with the right amount of subconscious guidance to let the player deduct what to do next without feeling they are being told.
• Mechanics Design, which starts out involving a lot of Excel and prototyping ideas in things like Unity or GameMaker. The basic idea is to design a game mechanic, prove it can work, convince everyone else to include it in the rest of the game and then ‘champion it’; pushing to ensure it is implemented. The Prototyping stage may or may not involve working with a coder or artist. Involves more presentation skills than you’d think, as you have to convince everyone else that running with it is worth their time and money. You also have to understand that your ideas, even if they’re good, may still have to be sacrificed on the altars of time and money; it’s like being in the military – the best ideas are expendable.
• Scripters, which essentially boils down to level interactivity and AI. What exactly that involves is something that would vary greatly with the genre and engine; in the case of Motorstorm (a racing game), this involves setting up AI paths and responses, along with any level interactivity (ie the collapsing buildings in Apocalypse), triggers, pickups and so on. Timing and a sense of responsiveness are key here; it’s both making the game world responsive and making that responsiveness clear to the player (ie there is a clear line of cause and effect as opposed to things apparently happening randomly). For UDK / Source and so on, this would involve Kismet and Hammer I/O. This and Mechanics are I think the sort of field I’ll be aiming for.
• Audio, Interface, Combat and so on designers, which Maiden didn’t go into a lot; basically there a lot of often genre/game specific sub-roles that might well get their own unique design team, ie the car handling mechanics for a racing game, the shooting mechanics of an FPS and so on. Interface… well, is pretty much what it sounds like; game menus and UI design; it’s all about looking pretty whilst being readable and not getting in the user’s way. The art of subtlety in a lot of ways.
• Finally, you have Leads, which act similar to Producers in the sense they are an overhead role; in this case to ensure the game design is coherent as well as bouncing back and forth with the producers; personally it sounds less like design and more like herding a thousand highly intelligent cats going in a thousand different directions. Many, many meetings involved the higher up you go.

Finally, designers need to understand games. This means understanding the underlying theory, keeping up to date with the industry and both playing and breaking down existing games to identify what worked, what didn’t, and what could be improved on and how.

For the Q/A and Testing path, the de-facto ‘entry point’ to the Industry, you have a mix; you have in-house testers that work with the developers, test things (shockingly) and give one-to-one immediate feedback and larger Q/A teams that can be testing multiple games at once in their own studio; these tend to test daily builds and the like and so are a common source of micro-deadlines to get a build out to the testing staff in time. Key skills involve communication and writing to make your feedback readable, logic and problem solving to make your feedback useful and a sense of pro-activity to get yourself out there and ensure your feedback means anything at all.

The Coding path largely involves logic and problem solving, along with good mathematical knowledge, technical ability and awareness of the latest coding standards, techniques and practises. A wide knowledge of coding languages is also a plus, but primarily you’ll be working in C++. Can be programming systems, engines, tools, the works. Only the best tend to get hired, so this is probably a difficult direct-to-entry job; most likely people come in as scripters above.

The Art path, in a similar manner to Design, has a lot of junior roles mixed with leads and a few random technical offshoots. To summarise:

(Modelling)

• A junior artist will generally start off on prop modelling; making random in-game assets of low-to-minimal gameplay importance; things like trees and streetpoles. This is also the area most likely to be out-sourced. There will also be several leads involved here as they still need to fit into the environments.
• Character modellers, who probably need no explanation.
• Vehicle modellers which, amazingly enough, involves modelling vehicles. Equally obvious, this also only applies to games that actually feature vehicles (here’s an interesting question though; if the game features but does not rely on vehicles – ie they’re just props – do they still get dedicated modellers?)
• Environment modellers, who work with the level designers to turn Devbox levels into something pretty without breaking them in the process. May – depending on the setting – involve a lot of buildings. Knowing architecture is a plus. Most likely section to employ modular set techniques.
• As a subset of the above, there are also now emerging dedicated lighting artists, who both light up levels and ensure any dynamic lights aren’t going to murder people’s computers.
• Effects artists, who handle… well, effects. This is everything from particle systems to shaders. Snow, rain, explosions, lensflares; all of this is handled by them.
• Interface team who make the menus pretty; also likely to handle most of the marketing art.
• Leads, who keep tabs on everyone else, sign off on assets and generally direct and ensure a cohesive art style.

(Concepts are pretty much as above, only replace ‘modelling’ with ‘painting’. Both modellers and concept artists need strong 2D and 3D skills, though obviously the balance shifts on either side)

(Animation)

• Again, you have low-level prop animation; ie doors opening, pistons pumping and so on for junior animators to break their teeth on (this may, depending on the engine, be done in the level editor ie UDK Matinee or Unity’s in-house animation system).
• Character animation, which may or may not involve rigging, working with real-life actors and mocap data. Currently a blurring field with Dynamics below considering the improvements being made in IK and dynamic animation. Can be further split into gameplay and cutscene animations. Liaison with the audio and voice-acting staff for lip-synching, timing and sound.
• Dynamics, which crosses over a lot into scripting; this involves setting up dynamic animation ie cloth simulation and physics. Requires, obviously, a good understanding of physics. May also be involved in vehicles depending on how they’re implemented (ie setting up suspension and so on). This is more about setting up simulations and watching them fly than actually keyframing anything, but will still need to interface with that as well (ie a character going from a ragdoll to a stand-up pose, death animations that don’t involve poignantly gasping their last breath and then ragdolling into the stratosphere…). Generally, physics can be very unpredictable and it’s a balancing act regarding system resources, both of which will have to be accounted for.

Finally, they also discussed the Development Cycle when creating a game; running us through the various stages an AAA game goes through with the expected team size at each point:

(1-5 people) PROJECT PITCH
Involves a presentation to the directors for funding and approval – it’s mostly a high level pitch document with early estimations of time and cost. Team here will primarily be designers with some concept artists on hand to provide some early concepts. Once approved, we move on:

(2-20) MECHANICS PROTOTYPE
Playable But Ugly; early mechanics are in and one or two levels in Devbox stage, with all other assets reused from elsewhere. It’s ugly, but playable; a proof of concept. Again, if approved, we continue:

(10-30) PRE-PRODUCTION
Now that the idea is proven, work begins on actually preparing to make it. This involves setting out the project’s scope (budget, time), proving any required technology, creating the necessary tools, fleshing out the mechanics and systems and finalising the planning. This is the final approval stage before production begins in earnest.

(15-250) PRODUCTION
The get-down-and-dirty stage of actually making everything. A highly iterative stage; progress built upon progress, allowing the leads to keep track of where things are and adjust things to fit the constraints. Easily the largest phase, taking up 50-60% of a project’s lifespan. Here, the team’s size is largely fixed; it’s full-on game production time. Q/A can start to be brought in here as more and more systems are built for testing.

ALPHA
Defined as a function 50% milestone. Half the art assets are in and the game is feature-complete will all levels in a playable if not pleasant state. It is essentially the full game in it’s early stage; Q/A can now begin in earnest.

BETA
The game is almost complete; there are just a few bits and pieces that still cleaning up. This is essentially the bug-fixing stage; all the way to Alpha is about getting everything together – the Beta is where you iron out all the kinks. Q/A are mostly bug-hunting here.

GOLD MASTER
Game is complete; time to fine-tune everything. Involves working heavily with Q/A to ensure everything ‘feels’ right when playing. It’s a bit like making a car; by this point you know the car works, now you’re just tweaking it to ensure it works as best possible.

RETAIL
The game is in the stores. Now to wait for the reviews to come in and get ready to patch any bugs. The team can start to dissolve now to work on other projects, with a skeleton staff on reserve should anything go wrong here.

POST-RETAIL
This mostly involves DLC. Teams will be much smaller as they are more focused on expanding the game rather than building a new one from scratch. This stage basically lasts until it ceases being economically justifiable.

The concluding statements where with regard to the benefits of working with Sony; free games, discounts on hardware, profits and bonuses, company trips and so on. They stressed the flexible and relaxed/creative atmosphere, but also the importance of getting down and dirty come crunch time; there’s a real sense of team pride.

They also walked us through various ways to apply; the best being directly to the company itself; whilst Agencies may have more contacts, you are less likely to be hired simply because the company will have to pay the Agency, and there’s no one-to-one interface with said company. Being specific with your CV and what you wanted to do was flagged up as key; including not automatically going for Q/A because it’s the ‘default’ point of entry and also because if you’re vague on your CV, the company will be vague on whether or not you’re viable for a position. Knowing the company and it’s history is also highly important. Finally, online portfolios – though necessary – can branch out a bit more; ie displaying all your skills rather than just focusing on one of them (ie you target the CV, not the portfolio).

Standing out, having a clear idea of what you want to do and what that role involves and understanding the dev process of games are all paramount. Mod or indie experience is a great bonus; they prove you have some experience in getting games finished and out the door. Getting that first role is the main difficulty; once you’re in it gets easier.

I found their presentation very informative; they’re both clearly intelligent, creative people who know what they’re doing and love how they do it, and hearing from them has certainly inspired me and helped me narrow my focus. For now, I think I’ll be aiming for systems/mechanics development, which means a lot of prototyping in Unity (hence it getting its own section). I’ll still try to keep up my art side, and I’m looking into various Game Jams around the ‘net (mostly on SA), though obviously at the moment my dissertation work is paramount.