Uni Guest Lectures 01

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:


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


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

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:

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.

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.

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.

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.

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.

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.

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.


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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s