The Game Team 4. Production and everything else.

Last entry in the list of game developer team positions.

This time we’ll cover production, QA, Audio, Localization and everything else.


1) Exec Producer

The Big Kahuna. This is the guy who is ultimately responsible for EVERYTHING on this project. Depending on the studio, he may have one project, or several he is responsible for. EA, for example, has one EP per project, whereas other publishers have one for several. This is where the buck stops, and this is the person who make the ultimate decisions on what the game is going to be, who it’s targeted at, what the platforms are going to be, budget and so on. He hires the Producers, leads and gets the ball rolling.
NOTE – while the EP defines what the game ‘is’, per-se, he is not the one carrying The Vision. That’s the lead designer. The EP says “This game is an fps, with a budget of $20m, and will take two years, with a team of 30. We will be targeting teenage boys, have semi-realistic graphics, no gore, be a sci-fi story, and have a space combat component. We will store back end player details in the cloud and we will have a small IOS app that precedes us.” Every decision that is made on the game going forward is measured against that criteria.

2) Producer

There are usually multiples of these guys on the project. He’s the guy who is keeper of the task list, the go to guy to provide whatever the leads deem are necessary to move the project forward. He knows how much is done, what is yet to be done and is often the final authority in terms of break deadlocks between the leads. What he is NOT is a designer, art director, programmer or anything else. The producer exists to ensure progress is made, and to cut that which is not working. He’s also a leader and needs to cajole, threaten, embarrass and compliment the team into great achievements.

3) Associate Producer

An AP is basically a producer-in-training. They are often the ones doing the tedious things, like updating exec spread sheets, checking in with developers to see how they are doing, taking notes in meetings, generating posters that indicate progress and so on. Think Intern, and you’ll be close.

4) Audio Lead

The Audio lead is responsible for all audio going into the game. Now, this doesn’t sound like much for your average game. A bit of music, some sound samples. Done. But we aren’t in 1995 any more, and that’s insufficient to the task. These days we have full on orchestrated music (Hans Zimmerman wrote some of the score for Call of Duty, for example), voice recording, foley effects (IE the sound effects of object use in game), and then straight forward effects. This is not an insignificant set of tasks, and it can be argued that audio in games has never had the attention to detail of priority that it should do.

5) QA Lead

QA. Quality Assurance. Testing. Man, this tends to get ignored as “The sweaty guys over there, in the basement”, but really is so massively important to building a big AAA game these days. While QA is often a different department, for the best results, they have to feel like they are part of the team. Invited to meetings, their opinion asked. The more integrated they feel, the more effort they’ll put into what they are doing.
QA has a huge job at the end of the project, dealing with iteratively playing your game to see what might have broken recently. Automatic testing of your game is a must, but automatic tests only tests that which you tell it to. Human testing tests So Much More.


6) Music lead

Fairly obvious. Often this guy is the main composer too. Bungie had one for the longest time, till there was quite a falling out and lawsuits occurred. However, most studios has someone that creates everything, from small rifs and stings, to someone who can compose something for a complete orchestra. There’s even a group of studios who use midi, and need compositions in that (so they can control tempo and pitch). There is an extra dimension when games require seamless audio track switching – so when the player goes from walking to combat, the music changes and gets up tempo and more pulse pounding. Creating music that can do that, easily, is a tough ask.

7) Sound effect lead

This is your more traditional audio designer on a video game. He that makes all the blips and bloops. However, these days he’s usually creating sound samples, rather than programming an on chip sound device, like in the days of the Commodore 64. There is more to the job though – creating echo effects, atmospheric effects, and effects that may be modified programmatically dynamically, like changing the pitch and timbre of foot steps or combat noises.

8) Writer

This one seems obvious, but it’s actually a much harder gig than you might think. In the same way that novelists aren’t always good screen writers, traditional fiction writers aren’t always good video game writers. A good video game story introduces the next bit of gameplay, in a way that isn’t forced, and makes it matter; it gives the player a compelling reason to play and to win. The problem is that all too often, the story is pulled in late to basically tie together whatever the developer has already completed. And you end up with a convoluted mess. Video game writing is also hard because narrative is the enemy of interaction. It’s a toughie, this job.

9) Voice over producer

This is an offshoot of the newer, large narrative based games. Even back on Soldier of Fortune, we had a separate producer who held the voice recording sessions with the talent, who knew how to direct them and get what we needed. This is a skill, and not one that people on a game development team normally have.

10) QA Tester

Well, this one is a very obvious one, enshrined in the movie “Grandma’s Boy”. This is actually critical for releasing a polished game, and the dev team core will love you for being good QA. It’s actually way harder than you think as a job – playing the same game, over and over, and figuring out ways to play it that aren’t the obvious ways, looking for bugs and crashes – it’s actually a skill. Most QA testers get VERY bored of the game they test, and never want to see it again once it’s released.

11) Localization Team

This one is somewhat self explanatory. There is usually someone on the team tasked with managing external localization companies. Sometimes they hire people in house to do conversions of text / speech, but mostly it’s handed to external companies that specialize in this. What’s interesting is that this is way more of an art than you think – text (particularly UI text) needs to be roughly the same length in characters, so it doesn’t disturb how the screen is formatted, and that’s often hard to do (particularly in German, for some reason).

12) Community manager

Another fairly obvious position. The community manager manages, guess what? The Community! She usually runs the forums, patrols to ensure nothing outrageous is being said, and is also often the front face of the team to the community, relaying messages, interviews and sometimes even asking what the community thinks. This job needs a thick skin, a delicate touch and a ton of patience.

13) Mainline Ops

This is an interesting position, and it’s got more to do with games that use a lot of servers. Bungie’s Destiny, for example, is server based and as such Bungie will have an online team, maintaining those servers, ensuring they aren’t going down, analyzing data throughput, watching the database servers that contain persistent data and so on. These positions are becoming more and more important as time goes on – having a great game you can’t play because the servers are down just sucks.

That’s about it for general purpose positions. Some places have other, more exotic positions – Valve had an economist, for example, analyzing steam purchasing trends. Linden Labs has a full time economy balancer. Every studio / publisher / developer / genre has their own specific positions they fill – it’s just not the norm across lots of developers.

If I’ve missed anything obvious, please don’t hesitate to drop me a line –

Posted in Game Development | Leave a comment

The Game Team 3. Design.

So Design. Yes… Design. Where most people who want to make video games want to end up. And nothing wrong with that!

So lets run down some of the positions, shall we?


1) Creative Director

This is the top guy for designing. He’s the one who says “Lets make a game about ZOMBIES!” and then comes up with all the justification as to why, and why making a 1st person zombie vs Kardashians game is The Bomb and why people will want to play it. This individual sets the company goals in terms of what kinds of games it’s makes, how they are going to look, what the target demographic is, and is, in general, the holder of the high level vision of what the game needs to be.

2) Lead Designer

The Lead Designer is the guy responsible for the one game he’s on. Every design decision on that project rests with him. He’s the guy the lead artist collaborates with in order to ensure they get the look he is looking for. This guy carries The Vision about the specifics of the game around with him, and is constantly reviewing everything implemented to be sure that it conforms to that vision. The lead Programmer and Lead Artist are his partners, and they are there to provide him with that which he feels he needs for the game (and sometimes they are there to say No to him, when his requests are outside of the realm of their ability to provide.)

3) Lead Level Designer

This is kind of a genre specific kind of designer – it’s for games that have world navigation in them. He’s building out the architecture for a level, with a view to what the game play is going to be in that level. So he’s both world building, placing models supplied by the 3d modeler, and also designing the flow of how the player/s may be navigating that level – what events might take place, where, and where the camera might be when that happens. He’s part scripter, part game designer and part architect. And it’s not just FPS or 3rd person games that have this position – RTS games have it, even Tower Defender games have it.
I include this as a separate position simply because with the proliferation of FPS teams, it’s a pretty common one to have.

4) Lead Combat designer / UI / Game Genre Specific area

There are usually always area’s of specificness for each genre type that may well require a specific lead. Games like Uncharted, for example, will have a combat designer, as do games like Call of Duty. Mobile card games have a UI flow designer. Games like Rez have a sound flow designer. The Sims have Object Designers, who decide what features an object in the game will have, and how they will satisfy the sims needs.
Every game has different requirements, and each game will need different leads covering those requirements.

5) Lead Story designer

Like Level designer, it’s worth calling this one out as a specific discipline. Narrative games are built around story (Uncharted, Halo etc) and as such, the story is tightly woven into what the game is. Some places tend to use story as just glue for the next shooty bit, but some integrate properly. MMO’s also have this issue – new quests and story driven aspects need to be woven in and as a result, someone needs to both be creative and come up with what the intention is of the story telling aspect and also ensure that everyone else understands that and follows it.
They will also be writing cinematic scripts, directing the voice talent and even potentially directing the motion capture actors.


6) System designer

A system designer is someone who takes a reasonably isolated system and basically, designs it. So, for example, a Quest system designer for an MMO will look at what is already out there, look at what the design doc says about Questing (which usually isn’t that much) and will then sketch out what Quests are, what they could be, the component parts of a quest, how they interact, how they are communicated to the player, how they played by the player, how they are considered complete, and what effect it has on the player once that is accomplished. They will sketch out ideas for tools to help design quests, and then write all this up, for use by coders and content creators later.
System designers may handle multiple systems in a given game.

7) UI designer

UI flow is a massive thing these days, what with so many games – mostly mobile – being UI only – card games and the like, and it’s very definitely a specific discipline. UI is more than just “What we put on the screen to show the player his score” these days. It involves the entire flow of screen to screen, what information is where, when it’s presented, how it’s presented, how it’s hidden and so on.
Companies like Apple exist purely on their UI display systems; IOS is superior to Android for exactly that reason.

8) AI designer

The AI designer is more than you might think. They design the behaviors of the game objects – which can be more than just “This npc goes here and does that”. It can involve creating day / night objects, objects to handle weather, objects to make the world turn, objects to handle gravity etc etc. The AI designer also deals with designing what the bad guys in the game can do, as well as the players abilities. I can jump – can the enemy? If they can, how high? Can they jump up on walls and ledges? How do they track you through the world? Can they see you? What about hear you? What do they do if they do?
AI designer has to cover a LOT of bases.

9) Environmental (level) designer

This was a big position at the FPS shops I worked at. Part architect, part game coder. Visual flow and game flow were paramount in the level designers position. Sometimes they’d be building cinematics, sometimes multi-player maps, sometimes boss fight spaces, sometimes run and gun situations. It was always different, and level designers are constantly trying to find new ways to have new experiences for the player.
The biggest problem with level design was (and is) building puzzles. Most of the time, when this happens, the player ends up playing the level designer, and what his solution to the puzzle he’s built is, rather than playing the Game.

The next post is the last part in this series. Production, Story, Audio, translation, QA and other misc jobs.

Posted in Game Development | Leave a comment

The Game Team 2. ART!

Art! Yes, ART! (little joke there for my old friend Les Ellis)

So, we’ve covered programming, in terms of team members. A second big entry in the team is Art. You’ll notice I left out world modeling / level design in this section. That’s because, to my mind, a lot of that is actually design. It’ll be covered in the next posting.

So lets run down some of the positions.

Lead / Management positions

1) Art Director

This is the top of the chain. He’s the one, like the lead programmer, who establishes the way that art is created at the studio. He decides if particular processes are going to be used, particular software, or outside groups (e.g., we are going to use company X, who specialize in face rigging, or group Y, to do our motion capture for us). He may also be the person who generates the style guide for a given project – what is the color palette, what kind of style is it going to be (comic book, anime, photo realistic, Lovecraftian etc).

The Art director tends to be involved with lots of projects at once.

2) Lead Artist

The Lead artist is on a specific project, and is the main person responsible for every pixel that appears on screen. He (usually) manages the artists, works out texture budgets, and assign tasks. He basically cajoles and judges the artist on their work, and is the final arbiter of what gets into the game art wise and what does not.

3) Lead Technical Artist

This can sometimes be a lead position, and sometimes not. Sometimes the lead artist is this. The Technical Artist is the one who works out _how_ things are going to be made. It’s apart from the tools creator; the tools programmer is the guy who goes to the technical artist and says “Ok, we need to have complete procedural animation going on. How are we going to do that? What does the rig on the models look like? What needs to happen here?”
He will work out potential new blend modes, talking with the shader engineer about visual effects, and generally work out the how what needs to be done from the art perspective.
Sometimes this role can ever be broken down further – lighting technical artist, animation technical artist, environmental technical artist, etc.

Team members

4) Concept Artist

A concept artist is critical at the start of a project – generating imagery (in conjunction with the art director and lead designer) that gives the style and design of characters and environments. She’s the one who helps develop the style, look and feel of what the game is going to be. She’s also the #1 thing that is pushed in pitches. Plus her stuff gets packaged up in nice coffee table books at the end of the project.

5) Texture Artist

Texture artists generate the actual visuals of what gets painted on the geometry. It’s even got to the point now where there is specialization within the texture artist genre – environmental artists, creature artists, people artists. It’s amazing how far this area has come.
They also do more than just textures  – there’s normal maps (IE making flat surfaces look bumpy when light falls on it), specular maps (making a surface look shiny), and many other aspects of added value (e.g. sub surface scattering heat maps) to a given texture to make it look “Last Of Us” good:)

6) 3D Modeler / Rigger

This person is the guy with all the Maya skills. And what’s interesting is that they don’t just build characters and enemies, but also objects and buildings for environments. They need to keep tabs on polygon counts and the like, and then they hand the models they make to the texture artist for texturing, and also to the rigger (in the case of animating models). The rigger may (or may not be) the initial modeller. The rigger creates a skeleton within the model, and attaches the individual polygons to that skeleton, and also creates handles for animators to move the model around. In the case of motion captured animations coming in, they also create a second skeleton in the model, that is mapped to the dimensions of the original actor (the actor may be 6 ft tall, but the model only 5 ft tall), with connections between the two skeletons that allow animations from a larger figure to be translates to a smaller or differently dimensioned model.

7) Animator

So this is a very “art like” job. Basically, it’s posing the model skeleton for key framing, and then creating animations from those frames. It can get more complicated than that – creating partial animations that get blended at run time with other animations already running (e.g. shooting a gun while running). This is a major artistic skill, and badly built animations are very very visible.

8) VFX Artist

This is another fun job – the creation of visual effects in a game. Particle effects, lens flares, animating backdrops, changing skyboxes, gun flares, the whole shebang. This is now a full time position at lots of the larger studios – BattleField, for example, has specialists in just gun effects, never mind the rest of the game.

9) Lighter

This is a relatively new position for video games. Movies have had it for years – a dedicated group of people who place lights and render the scene to ensure the lighting looks natural (or, in the worst case, dramatic!). I didn’t even realize that video games had this position until I was introduced to a bunch from Infinity Ward! So yeah, it exists.

10) Cinematics director

This guy! Now this guy has the fun part. He basically scripts out little cinematic events, using game assets. He decides where the camera is, where it moves to during a shot, what goes on in the shot and everything else. He’s literally a digital movie director. This has been a new thing recently, and it’s very visible with games like Last of Us, Uncharted and Halo, which are all narrative driven stories.

Next up: Design!

Posted in Game Development | Leave a comment

The Game Team. A primer in Who does What and Why.

So yeah. There are lots of fledgling indies out there – two or three man operations, and they don’t necessarily have a background in what a large team makeup is. Who can do what or not.

So I thought, what the heck, I’ll have a go at categorizing them. I intend to split this over several blog posts, one for each discipline.

So lets start with Engineering. You know. The code monkeys. The number pushers.

People like me:)

Engineering used to be just ‘programmers’ but now it’s got several area’s of specialization. It’s important to note that lots of teams combine these positions. There often isn’t a need for a specialized UI engineer, or a dedicated Networking Engineer – are one person may be tasked in lots of different area’s. The differentiation I’m using here would be evident on 30-40 programmer teams, like Bungie or Infinity Ward have. Not your average 30 people team that counts EVERYONE.

We’ll work from the top down, I think.


1) The CTO

This is where the buck stops. This is the guy who is ultimately responsible for all technical decisions made. If something cannot be done, or fails, he’s responsible. He ultimately ratifies all the decisions of those beneath him, and is the guy who says “Yes, we are going to spend $1.5m on an Unreal 4 license”. He does the strategic planning, looks around and says “everyone else is in the cloud, we should be do”. He holds the 5 year plan, and is aware of the industry and what is going in a general sense, and guides the technology plan for the studio at the top most levels.

2) The Technical Director (TD)

This guy has two different modes. The first is a back stop to the lead programmer. He’s not replacing the lead, he’s someone that is an independent verifier of the leads decisions. If the lead says “We need to spend X amount of time on Y system to do task X”, he’s the one who looks at the statements, verifies they are true and that the proposed solution will both fufil the requirements, and is actually do able. He will highlight area’s of risk – and in the worst case, rush in to help firefight if need be.
A TD will often have multiple teams he is working with, but traditionally, they do not report to him – he’s an independent entity.
The second mode is as traveling help for hire. He can and will be able to go anywhere in code and help build / fix / triage as is required. His technical knowledge in general is wide (and deep in some areas) but he’s not specifically tied to one project, working on many at once.

3) The Lead Programmer

The Lead programmer is the guy responsible for getting the game done. He’s the one who makes the plan about how the game will get done, who is going to do it, what the risks are, what outside software / libraries he may want to use to get the job done. He works out the tasks and either delegates himself, or he hands it off to a manager to do it (that’s how EA works). He is the touchstone that all other coders use, and he’s the one who has to know the entire codebase and what goes into it.
He decides coding standards, what the tool chain is going to be, and also manages any outside systems that are used (remote DBs etc).
A lead programmer should be on one project at a time.

4) Technology lead

It’s entirely possible that the engine your game uses is actually owned by another part of the company – a group who’s job it is to build and support shared technology. They don’t make the games, they make the technology that the games sit on. They take requests and tasks from the game teams, who require feature X so they can ship game Y, and implement them in a way that other teams may use that feature too.

Technology Coders

There are some specific area’s of technology worth pointing out.

5) Animation

Animation coding is one of those things that is almost solved – once you’ve got the system importing models and animations, and providing an API to blend them, you are done. Except you are not. Next comes the systems that decide _what_ animations you play, why, how long, and how to interrupt them if need be. Add to that the creation of tables to decide how which animations are available for selection, and you’ve got quite a task.
The best way this can be implemented is at a data driven layer – so it’s done by external tools and the code in the engine is entirely generic.

6) Rendering

This is a biggie, and there’s a lot of specialization in this area. There’s driver optimization, new features and then shader writing, which is an area of expertise all it’s own.
The bottom line is that adding new features, new ways of rendering and getting visual artifacts is one of the easiest to see upgrades a game can get.
It’s where all the glory code is:)

7) Networking

Networking is interesting, because networking needs to be thought of as part of the initial design of a codebase. You can’t just graft networking on after the fact; you have to be thinking client server architecture from day #1. Networking impacts so many different aspects of how your game engine works, it’s definitely a specialized area.

8) Audio

Audio tends to get relegate to also-ran status when making games, and that’s a shame since there is a ton yet to be done with this area. Correct audio bounce, correct obstruction, biaural processing, waveform distortion, environmental changing, musical beat matching for switching music tracks etc – there’s a lot yet to be solved with audio, but it gets short shifted because for lots of game devs, ‘good enough’ is good enough. The issue comes with gaming rigs with radically different audio properties, and the ability of the listener to even hear the small differences.
If you can get into it though, this will be an area of expansion over the next few years. I hope.

9) UI

UI (sometimes know as UX, although there is a difference. UI is what the text / menuing / information passing looks like on screen. UX is the flow from page to page – the decision of what info is present to you, and when that happens). This is increasingly becoming a large part of game design, given how complex games can be, and how small a screen you may be providing information on (e.g. Mobile).
Good UI / UX flow can often mean the difference between a good game and a great game.

10) Tools

Tools is often an entirely separate area of the team, complete with it’s own lead. Tools programmers are responsible for creating plugins to existing tools, creating a pipeline to get stuff from content creation tools, like Maya or Photoshop, and into the game in a game (and sometimes platform) specific format.
Tools are one of the biggest area’s of expansion in the last few years. Games often live and die on the quality of their content creation tools. Better tools = better looking and more content for games.
Tools engineers relate directly to content creation parts of the team, often working with them for requirements and what the content creators need tools to actually do for them.

Game Coders

10) Scripters / AI

Interestingly, this group can often be the hardest to hire. You need logical thinkers, who are also content creators. These people are crafting your game at the highest level – using a scripting language that (hopefully) doesn’t have to be compiled. They don’t need Visual Studio on their machine, just a text editor and understanding of how a high level language like C#, python or lua work. You need a programmer who is also a game designer.
For some reason a lot of the people hired for this position tend to be graduates; I’ve no idea why.

11) Pure Game Engineers

These are the guys who *just* make the game. They don’t build technology, they use it. They are like scripters, but in pure C/C++. They create game specific objects, cameras, input systems and create the actual game experience.
These guys have the most iterative job, in that usually their code will get re-written several times over the course of development, as they try things, they don’t work and a new approach is taken.
This is actually one of the most stressful jobs, because code is thrown away so much, and so much of the final product is dependent on their work. They are the equivalent of the Formula 1 driver – everyone else is building the car – these are the guys who actually drive it.


12) Development Support / IT

This is part of team that handles things like build machines – that fire a build of code every hour, or every time something is checked into Perforce. It also builds a test harness, so the game can be run through testing of features every night. Again, this is a heavy investment in time, but in terms of finding issues with features in the game, it’s a gold mine. Coming in in the morning and looking at a webpage of lists of features in the game that are broken, or the fact that the frame rate halved that day due to some check in, is massive.

13) On Team QA

One of the nice things that large teams have is a couple of on team technically competent QA guys. They sit in the corner, look at reported bugs and try running the game through the debugger, so when it crashes, they can come find you, and you can see the crash as it happened in the debugger, with stack trace and all.
To be clear, this is a massive luxury, but if your team can afford it, it can reduce your beta development time (the time at the end of the project, where you ONLY work on bugs, and not on features any more) by almost 50%, since you are fixing crash bugs as you go along.

14) Automatic Testing Engineer

This is something new – an engineer dedicated to writing a test harness, so the game can be automatically built and tested every night, using specific human written tests. This means it can look for reduction in frame rates, crashes, game functions that aren’t according what the design calls for, etc.
This can seriously impact a build’s stability and track when things go wrong, allowing the team to address it immediately.

So there you  go. There are more specialties – path finding, facial animation, visual effects coding, and so on, but those tend to be very specific for a specific game. A football game may have a dedicated person to create large crowds, for example, where as a fighting game would not.

So, next post – Art!

Posted in Game Development | Leave a comment

Running a Kickstarter

I was just wondering why I haven’t actually pulled my finger out and done one of these.

I think Kickstarter has gone through some radical and interesting changes, in terms of usage case and perception, over the past year or so. We are closing in on $4m for the new Oatmeal card game, we’ve had massive success stories, and some utterly dumbfounding failures too – like Uber’s Human Resources, for example. Amazing video, compelling premise and large indifference on the part of those who would fund it.

Those within the video game developers community are utterly bemused by this failure; if there was ever a sure thing, Human Resources was it.

From what I can gather, to have success you need to have one (or more) of the following things for success.

  • Compelling and well made video. Not just a bunch of people sitting around talking about what they want to make, but footage of what it’s going to be.
  • Have some nostalgia feature. It’s no secret that it’s Tim Schafear, trading off his Adventure Game roots that had success – Planetary Annihilation, trading off the Total Annihilation roots etc. Nostalgia is a big thing for the 30-40 somethings with disposable income willing to fund things on Kickstarter, it appears.
  • Have attachment of a ‘name’ – some celebrity (online or otherwise).
  • Have something so compelling that it can’t not be funded (Pebble, the new ice chest, that awesome new luggage).

If you don’t have one or more of those, then yeah, good luck. It’s an entire crap shoot.

Now, I’m also noticing thatquality of the video matters. For example, the Uber Human Resources video (found here ) cost almost $100k. Now, that’s a lot, and a lot more than most people can afford to put into what is an elaborate pitch. But even $20k is more than most people can afford.

But who am I kidding? I’m just afraid of failure:) Such a chicken shit:)



Posted in Game Development, Life Musings, Movies, Uncategorized | Leave a comment

The Internet and Social Justice

So yeah, been an interesting few days. Well, “interesting” is not really the word. “Bloody scary” is probably closer to the mark.

I refer, of course, to the whole Social Justice Warrior scene between Zoe Quinn and her ex boyfriend.

To recap, her ex – Eron Gjoni – put up a blog where he basically accused her of sleeping around, while making sure he knew of her feelings on infidelity. This then got picked up by 4Chan and Reddit, who made it out to be more than it was – a simple case of loose morality and bad judgement on her part – and made it into “Game dev sleeps with journo to get coverage”. Which it wasn’t and never was, as Eron himself pointed out.

But then, the avalanche of social warriors, who are fearless behind their anon email addresses, start harassing Zoe in unbelievable ways. Those women who come to her defense also get attacked – one even having to leave her home after the death threats.

Now, lots of people have had a lot to say about this – mostly picking sides. Some are all about the fact that Zoe invited this on herself, behaving as she did. Some are all about the over reaction of the internet based social warrior, who appears to be consist of mostly white guys who are deeply misogynistic and have anger issues.

I have my own thoughts, and I’m going to get them out here.

Firstly, this is not about “Slut Shaming” as some people describe it. Lets deal with this. Firstly, the word Slut is bullshit. It means nothing. It’s a derogatory term for a woman who sleeps around. The word for that for men is “Stud”. It’s a double standard that is horseshit. Women are looked down on because they sleep around, while men are venerated for it. It’s just so apparent crap, yet it perpetuates itself. The least said about this the better. We can all just agree it’s shit and move on. So lets remove the word Slut from this.

When Eron did was “Hypocrisy shaming”. Zoes behavior was, at best, hypocritical. Lets be clear on that too. She made great capital about fidelity, then didn’t live up to those statements. That’s at best hypocritical and at worst, extremely damaging to your significant other – to the point where the relationship fails, as is the case here.

Now I don’t really want to harp on about morality and/or sleeping around, suffice to say, whatever a relationship is between two people, it’s up to them and no one else. Common western civilization dictates that a relationship between two people that is romantic tends to be monogamous. That’s the default state, as agreed by pretty much everyone out there. It’s what we are brought up with and defined as. Now that doesn’t make it right at all – just what you would reasonably expect of a relationship. Now if two people don’t want to do that, then it’s entirely their decision to alter those parameters and make it whatever they want it to be. They get to define what their relationship actually is, no one else, and more power to them. If they want to open up their relationship, then that’s fine.

But it does take two to tango in that regard. One person cannot do that and expect the other to just go along. Both have to know and agree, or it doesn’t work, as it hasn’t here.

I totally get how Eron feels about this – it’s very apparent in his blog posts. He’s upset, bewildered and probably very angry, and making this behavior public is probably his only recourse here.

I would imagine that he feels he is just making her behavior public, holding it up to the light so others can make their own judgements. Of course it’s rendered in such a way as that he controls the interpretation, but still, I would imagine that’s his mindset.


The fact is, The internet has no middle ground. It just doesn’t. The reaction from anonymous commentators has to been to vilify Zoe, his Ex and to basically eviscerate anyone who disagrees with that analysis. Nasty emails, threats and so on.

What Zoe did was bad, but it in no way justified the backlash she is getting. It’s outrageous. It’s life threatening. It’ll destroy her in ways that she in no way deserves.

But there it is. The crux. The word “Deserve”.

What do we do here? As a society? Her behavior was crap, there’s no real getting around that. But proportionate to this response? Not even remotely. She’d have had to kill people to deserve this reaction. This is just angry boys, who have finally realized that life isn’t like an 80′s romantic comedy, and they aren’t going to get the prom queen to suddenly come to the realization that they are “the one” and are pissed off about it.

It’s made worse because it’s video game related, and by definition, lots of the audience is angry 12 year olds who have too much testosterone and have no outlets to let it out; we’ve done a great job as a civilization removing those, over the past few years, via concerned mothers. So your audience for this starts out being skewed, which just fuels the fire.

There are those who say “She doesn’t deserve to be even mentioned” – which is a valid view point; her behavior was to one person – her significant other – not the rest of us. Why should we be involved in this? It doesn’t effect us?

Others would say it does, because what she does in her personal life apparently spills out in to her professional one. Hypocrisy is hypocrisy, and as such, when it’s discovered, it should be brought out into public. Other wise the behavior goes on. This is the driving force for things like Watergate and Snowden.

The question is, what do we do when the behavior is bad, but the only punishment for it – the unleashing of the Social Justice Warriors is far worse than the crime?

That’s where we are right now. The internet, as it’s structured now, gives these cowards (and I use the word advisedly) a place to strike and hide. Society, as a whole, develops these kinds of people because parents are generally too busy to actually instil some social values in their kids (or, worse still, have a wry smile when it happens). This issue is not about to go away and regrettably, loose groupings of people who oppose it are far outnumbered by those perpetrating it. Or to put it another way, those who do it have already justified it in their minds. Missives like this are not going to change anyone’s core beliefs that it’s their right to vilify people.

So what is the solution? We shouldn’t be hiding this kind of behavior, but equally, the response is too outrageous to even contemplate?

My personal feeling is that what this particular situation has taught us is that we will HAVE to hide this kind of thing. Or at least, not make it public in the way it has been. The internet Beast is just a thing of evil, with a mind of it’s own, and it’s simply too aggressive and too random to be unleashed.

I don’t like it; I feel justice as much as the next person – but I don’t honestly see what alternatives there are.


Posted in Game Development commentators | Leave a comment

Vertex and Pixel Shader Primer

This is intended for those artists and students who have heard the terms Pixel and Vertex Shader, but aren’t really sure what they do or how they work.

Now this is very high level, and doesn’t get into the specifics too deeply, just because that’s an abyss that definitely looks into you as you look into it.

The idea is to just get the concepts across, rather than go too deep.

So lets get started.

A vertex shader and/or a pixel shader (sometimes called a fragment) shader is a very small, self contained program, that runs on the actual graphics card – using the graphics card GPU and not the main device CPU, that manipulates vertices and then, at a lower level, the actual pixel being rendered.

Complicated eh? Yeah, that doesn’t really explain it very well. So, assuming you have _some_ degree of understanding of how 3D models get transformed, what you are doing in the vertex shader is doing the 3D math that takes a normal 3D models vertices, and then applies all the complex 3D math of moving it in space, rotating  and doing other things, like animation, to each vertex of the model.

So, for example, if you have a 3d model of a cube, it has eight vertices, one for each corner.

On the Graphics card, it’s going to run the vertex shader 8 times – once for each vertex. You have to feed the vertex program stuff like the transformation matrix and the 3d->2d matrix, and then the vertex shader itself does the work for you – all on the graphics card and not taking up precious main CPU resources.

Once each vertex has been transformed into a screen coordinate set, the graphics card now knows exactly what pixels on screen are being drawn. It knows that it’s drawing a flat triangle between points x1,y1, and x2, y2 and then x3, y3. So from that it does what is called a raster scan – ie lines usually from left to right on screen, for each line the triangle covers for each pixel in that triangle.

And here’s where it gets clever – for each pixel it’s rendering, it calls the pixel shader. At the vertex level, you are doing 3D math on vertices that make up a model. At the pixel shader level you are doing color math on individual pixels.

So, the GPU does the vertex shaders first, to transform all the 3D vertices into final 2D screen positions – discarding polygons that are back facing once the 3D model has been transformed – then it does the pixel shaders – one for each pixel it’s rendering on this specific render call.

As an aside, shaders are generally written in straight C, and do have some helpful functions built in you can call – like dot product, cross product, sin, cos, arc etc and other helpful math features. But generally, you write the code to do the math yourself.

Generally you package up vertex and pixel shaders up together – in OpenGL for example, you feed OpenGL the ascii code for each shader type, let the OpenGL driver actually compile it to machine language the GPU will understand, then you tie the two together inside the OpenGL Drive, so when you say “Please render this object” and feed it the vertex array and Texture coordinates, the GPU knows “I should use this vertex shader and this pixel shader to attempt to draw this thing”.

So, basically, for each object you want to render – each combination of texture, vertices, stuff-you-want-to-do-to-move-the-object – you have to specify to OpenGL which vertex / pixel shader combination you want it use on the graphics card to actually render that set of data. You can have lots of these small programs loaded into the graphics card at once, at run time you are just picking which set you want to use for any given render call.

Now, there are some other interesting aspects. For example, you can actually pass in variables to these little graphics card programs – you can set up variable types in the programs themselves, and then, at render time, for each rendered model, send the programs different sets of variables. Kinda of like how you can use command line arguments to send to a command line program.

So, you could send in a different set of lights for each model being rendered; in fact, most systems already do this. Why? To explain that, we need to go into what pixel shaders can do in a little more detail.

A pixel shader defines the final color value of each pixel being rendered for the current model being displayed. So the pixel shader is called once for every pixel rendered in that model.

Now these things aren’t free. The GPU is now doing logic processing for every pixel rendered. The more logic you want to do – for example, the more lights you want to have falling on that pixel being rendered, – the more time each pixel takes to render. And the GPU only has so much time to go around. Oh, it has a hell of a lot of time; GPU’s are VERY quick – but the more pixels you want to render, and the higher the resolution you want to render it at, the more time it takes. You can only paint the screen so many times before you run out of GPU time because each pixel is taking a while to process.

It’s for this reason that lots of systems have different types of lights affecting different parts of the scene – you might have expensive pixel shaders for character models, and way less expensive ones for the environment. Even then, the characters – when being rendered – will often only take the 4 or 6 closets lights as program variables because a) doing more than 6 lights is too cost prohibitive in GPU time and b) because there’s a limit to how much data you can actually send a pixel shader from the main program per call.

Interestingly, the pixel shader is not responsible for certain hardware type operations – alpha blending, for example, is still handled at the purely hardware level. You do not, in a pixel shader, sample the screen and then mix that into the resulting pixel color value to make alpha blending work. It’s still purely hardware that does that.

The pixel shader can see textures though – the simplest pixel shader simply samples the texture passed in to the render call, at the appropriate spot for each pixel being rendered (fed into the pixel shader by the hardware in the graphics card)  inside the texture, and then presents that to the end of the shader, which is the value that is then passed to the hardware to be written to the screen.

Another interesting fact is that pixel shaders – by and large, and certainly in OpenGL – cannot see the screen. They can only write to the screen, not read them.

So how to do clever effects like screen ripples, or heat haze? Where you are not rendering actual data to the screen, just affecting what is already there?

Well, in OpenGL, the solution is to never actually render to the screen in the first place. You render to a texture instead, then that screen texture can be passed in as a parameter to a pixel shader, so it is effectively writing to itself. Then, as a very last step, the entire screen textureis actually rendered to the real screen, so you can see the results.

So to do a small ripple effect, you’d start off by asking openGL for a new texture, but in a special way, so OpenGL knows you aren’t going to be feeding it texture data – it just creates the space for that texture internally, but doesn’t try and copy a loaded texture into it. Every time you render something, you point OpenGL at this texture as the destination, rather than the screen, then render normally, as you would if you were rendering to the screen, then when you are done, you render another quad over where you want the ripple to happen, pass in the screen texture as the source, and have the actual pixel shader do some cleverness about where it’s reading from the original texture, thereby writing over itself with itself as the source.

There are many clever things you can do with shaders – mix multiple textures together, pass in lights so you can calculate how light or dark a particular pixel should be – even generate color values on the fly without using textures at all.

The math can often get quite intense – lots of stuff has to be worked out per pixel in the shader and quite often what you have to work from in the first place is not a lot, so everything has to be regenerated per pixel. But the results can often be very impressive – and at no cost to the main CPU which can then go off and do other, more important things, instead.

Hope this is helpful.

Posted in Uncategorized | Leave a comment

Indies != AAA developers.

So I just read this article about why developers go from AAA to Indie, but not the other way around.

You can read it here.

I think that as far as it goes, it’s on the money, but I don’t think it really covers some of the real reasons.

The reality is that publishers like Activision and EA are FAR more risk averse than their Hollywood counterparts. They are far more market research driven than Hollywood will ever be. Given that, they will never give the creative control necessary for someone like Cliff B. to persue exactly the game he wants to make.

Nor will a lot of the current Indie Auteurs out there – people like Phil Fish or Jonathan Blow – be given that opportunity due the incredibly bad professionalism they project. It’s an unspoken truism that the reality is that Ubisoft is never going to give Phil Fish a multi-million dollar budget and just say “run with it” because he’s inherently uncontrollable. More to the point, he’s a loose cannon and so are most of the indies out there.

Again, as something most people won’t or can’t say – the reason a lot of them are indies in the first place is not some love of the indie lifestyle – no one enjoys eating Ramen Noodles day in day out – but because quite a lot are inherently unemployable anywhere else. Most are unmanageable, have ego’s beyond belief and don’t really have the ability they imagine themselves to have. Of course most will deny that if asked – “Oh, I’m far happier being indie” but the reality is that, for a lot of them, they understand at a gut level they would never survive at the AAA level, nor be given the opportunity to do so. If you say you actively don’t want the opportunity, then you can’t be faulted for not being offered it.

Being Indie is a skill set that does not scale. The whole point of being indie is to remain small and not have fifty people reporting to you. It means you are where the rubber meets the road of development, not viewing it from an ivory tower.

Another axis to consider is attention span. Indies, by definition, don’t spend three years on a game, doing the same thing all the time. They generally have an “A.D.D.-by-video-game-standards” attitude, where they want to be finished with what they are doing in six months and then onto the next idea they already had. There’s a lot of Shiny Object syndrome in Indie Development, and I can’t for the life of me decide if that’s good or bad. It’s good because lots of new things are constantly being tried, which expands the possibility space for what an Indie Game can be, but it’s bad because no one appears to have the discipline to actually polish something to the point where it’s a completed and good looking game.

Now the article does make mention of a couple of things – financial reward and creative control but it makes no mention of risk. It’s worth mentioning that the financial reward aspect is important. When you have to sue Activision for the $35m bonus you were supposed to get – but didn’t -, is it any wonder that most would prefer to have their hands on the purse strings directly? The reality is that for anyone other than the chief designer or Exec producer, there’s little hope of ever taking home “Fuck You” money from a project you’ve built for one of the large publishers. Activision didn’t get the market cap they have now by giving all the money to the team making the games, and nor would they want to. Why give that money to individuals who then have nothing pushing them to continue making those games for you?

In terms of risk, the fact is that for the individual small indie, the amount of risk in failure is usually measured in the impact for four or five people. If you fail at that AAA level, it means the loss of millions of dollars and possibly / probably the loss of a LOT of people’s jobs. People you don’t even know. People who didn’t choose to follow you, but are there because that’s what the company told them to do. That’s a HUGE thing to put on the shoulders of someone who isn’t used to it.

At the Movie level, directors can do that because the fact is that everyone under them knows this is a short term gig and will be moving on regardless; a failure at that level means they were still paid for their time, which everyone understood going in. A failure at the AAA game development level means that people are out of a job, unpaid and looking for a new one, potentially having to move across the country to do it.

Then there’s the other aspect of risk – or more accurately, fear. Fear of failure and ridicule. You can be a very successful at the indie level and still have a lot of failures and still be able to go to GDC and hold your head up high and not have people snickering when you leave the room.

You fail at the AAA level and that’s all you have to look forward to. The more of a personality you are, the more that’s likely to happen. Just ask George Broussard or John Romero about how that feels. The fact is that lots of Indie developers wouldn’t have the skill set or the desire and would be far to scared to take on a AAA team. They don’t have the team management skills, nor the ability to either inspire or pass on their game vision to the entire team, and they aren’t used to the concept of even having to try.

Lastly, there are dependency problems that Indies have with AAA developers. With AAA development, there are a TON of failure points, and often, as a AAA developer (even at the Exec Prod level), there are outside influences that you simply cannot affect. Marketing, for example. They decide the campaign they want to do, and you just have to sit there and watch. A bad campaign can be disastrous for a game that one hundred people have sweated blood for two years, and there is nothing you can do about it. AAA development has a lot more moving parts than a small indie game, and for an indie – who is used to handling marketing (in as far as they talk to the editors of all the gaming websites directly), having to outsource that to a group you have zero control over is a shock.

For the record, I’ve done both, and it’s definitely a different skill set for indie from AAA development. As someone who wants to be more self sufficient, not less, then Indie is definitely more towards my sensibilities. But everyone is different. There are definitely some Indie developers I know who could handle AAA – Robomodo is a case in point. They’ve handled some very large Tony Hawk projects for Activision-  and they are ready for it in terms of executive and corporate culture.

But the majority of indies who could handle it will almost certainly never get the chance, because their mentality is not indie enough to actually have the kind of success you need at the indie level to get noticed and move up. Indie is all punk rock, ignoring axis because you don’t have the bandwidth (e.g. Pure single player because you don’t have the programming ability to handle multi-player etc) and AAA development is trying to do everything right because so many other parts are dependent on it all working as a whole.

The fact is, there is a reason why Indies aren’t moving to the major leagues, and it’s because the things that make them successful at the indie level would NOT translate to success at the AAA level. And I think most indies, consciously or unconsciously, recognize that.

Posted in Game Development, Game Development commentators | Leave a comment

Interviewing Programmers – what every engineer should know.

I’ve been in a fair few interviews in my time, that’s for sure. Some good, some bad, some horrific. Sometimes that horrific situation has been my fault, and sometimes it’s been the interviewing party.

Anyway, over the years, I’ve learned what I like and what I dislike in a technical interview, and I thought I’d share some these thoughts. As a jobbing engineer, I like to think I’m kind of everyman. I have some math – I understand trig and all the rest of it, but I don’t spend that much time thinking about Big O notation (for a good reason – I wait for the profiler to tell me I’m spending too much time in a function before I worry about it’s speed) or stuff like that.

This is a long post – a big wall of text -, but hopefully it’s worth it.

Obviously some of this stuff is wish list and in some situations isn’t possible – preparation, for example, can only happen if you are forewarned. But most people are, and still don’t do it and it just smacks of disrespect.

General Observations

1) Prepare. Don’t walk into an interview without having looked at the resume of the person, and at least looked at the websites of places he’s worked. If there are things to see – a blog, a set of lecture notes, whatever, then look at them. From the interviewee position, there is nothing worse than the guy you need to impress rolling into the interview and desperately looking at a resume that it’s obvious he’s never even seen before.

Far too many interviews are basically just the interviewer reading a resume and groping for questions to ask about each of the jobs you’ve had. It smacks of disrespect, and that’s a killer in terms of the person trying to get the job actually wanting it.

2) Have some questions prepared. And I don’t mean of the technical variety, I mean of “Who are you?” variety. You are likely to be working in close proximity to this person – and may even be working with them directly – and as such, you need to understand if this person is someone you can work with. Whether they are likely to arrive stoned, or drunk. Whether they have flash points regarding C++ Code notation layout. Whether they are going to drone on and one about the band Gwar etc.
Basically, everyone need to get a handle on cultural fit for the individual, way beyond the root question of “Can they do the job?”

Some companies break interviews down into separating out different parts – person A does technical acumen, person B does cultural fit. This is not a good approach. What it does is concentrate all of the potential elements that go towards a “yes” answer in one persons hands. If one person doesn’t like that the interviewee doesn’t know dot product, he’s now in a position to completely torpedo that application, regardless of what everyone else thinks.

Now obviously not everyone can do technical acumen – you need to be an engineer to judge that – but everyone can ask some questions about what the candidate is into, what they like to do on their own time, what their favorite repository is, biggest mistake they’ve ever made and why they thought it was, and what they’d do about it now etc. Questions that talk to what that candidate is – or at least thinks they are – rather than just “Can you tell me the code for Dot Product?”

NOTE: Be careful that your personal questions aren’t too personal. Run them by other people (or HR) first, just to be sure you aren’t contravening a law when you ask about the candidates family (in actual fact, that’s a no no anyway).

3) Do some of your technical questioning before the person comes into the office. By the time they get to the office – and are taking up resources time to sit and talk to them – you should already be fairly confident they can do the job from a technical point of view. Make them do a test – and don’t ever do that test while they are in the office. That’s just wasting everyone’s time. The fact is, you’ll probably get one day to determine if this person is going to fit into your team. One day. So the last thing you want to do is waste  it, putting that individual in a room by themselves, while they knaw on a pencil trying to remember the syntax for using STL.

It’s also worth pointing out that tests like this are entirely artificial. The fact is, if you employ them, they are not going to be working like this day in day out. They aren’t going to be standing and writing code on a grease board in front of three board mid level engineers. They’ll be looking stuff up on the internet, trying stuff, refactoring it and so on. The only thing that on site tests really tell you about a candidate is whether or not they do well in high stress situations where you’ve got a bunch of other engineers standing watching you and judging you, and where you can’t look up stuff. If that’s how your company operates as a norm, then you’ve probably got more problems than worrying about how your interviews go.

4) Your technical questions are not a competition, nor are they an excuse to hand out “Find me a pebble” questions.

I’ve had situations where I’ve walked into the interview and it’s become instantly obvious that the person on the other side of the table has their own self worth issues and needs to prove some degree of mastery over me instantly in order that they dominate in some way. I literally had one guy correct the very first thing I said – where I was being generic – and I just looked at him. In that instant I knew I wouldn’t take the job even if I was offered it, if it meant working with this guy. Any human who feels the need to establish a pecking order in the first sentence is not someone I want to work for/with.

Also, when it comes to technical questions, a lot of engineers either have their own pet questions to ask – where in reality what they want to know is “do you think like me?” They have a question that can have many answers and they have a favorite answer and if you don’t get it, well, you’ve failed. The reality is you haven’t read their mind or come to the same conclusion they would have, ergo you aren’t as good as them.

The bottom line is, I probably know as many really-hard-to-answer questions as you do, and I can ask them back, because my time is valuable too. If all you want to do is establish a pecking order, well, I can do that too, and make you look as stupid as you are set on making me look. Then what?

For many engineers – particular those with fragile egos – interviews are about proving they are better than the candidate (mainly because a lot have a worry that they are not, even though they’ve already got the job) – even more about discovering if the candidate is good in his own right.

The fact is, even if he gives you a different solution, that’s ok too. Explore that. Don’t get frustrated that he hasn’t come to the solution you would. Thinking differently is ok, and will almost certainly get you out of a jam some day, when you can’t see a solution and someone else can.

Also, be sure that your questions can be worked out by the candidate, and don’t require an either “you know it or you don’t” question. Examples of that are asking someone to write an STL vector prototype. If you don’t remember that off the top of your head, then you’ve failed – because there’s no way to work it out. This is why some of the questions from Microsoft in the 90′s were such a hit – asking “How many ping pong balls fit in a 747?” for example, or “How many gas stations are there in Seattle?” – these are all questions where it’s more about working out ways to get an answer than it is about what the answer actually is.
The more a question relies on some esoteric knowledge, the less valuable it is, because what it’s really testing is “Has this candidate come across this before” and not “Can this candidate work it out if he’s not come across this before”, which is what you should want to know.

And while we are on that subject, the more obscure the knowledge you ask for is, the more you as an interviewer look like a prick for asking it – this goes along with with point 1), where I’ve seen a lot of engineers, struggling to retain coder dominance in the interview, resort to more and more weird and specific edge case questions in a way of tripping up an interviewee. And lets not kid ourselves, this is exactly what it is – it’s not “exploring the depth of this candidates knowledge” – it’s a way of the interviewing coder feeling better about himself because he knows some obscure fact that the interviewee does not.

Also, asking for equations sucks. It just does. No one writes equations in code. If you need to know if someone knows the code for line intersection, don’t ask for the equation. Ask them to write the code.

Which leads me on to…

5) Ask for what you want. Don’t be clever and ask a leading question and hope to gently push the individual into what you really want. I had a graphics engineer once ask me for an early box discard algorithm – which is 4 if-then’s and that’s it; can’t get much quicker than that – but he wanted something else. In the end, what he wanted was a binary search algorithm. It took half an hour of me trying to figure out what it was he actually wanted. When I finally worked out what it was, I gave him his binary search algorithm, and then said “Look, if that’s what you wanted, then ask me for it. Don’t make me spend half an hour wondering what it is you want.”

It was done purely for the sake of the engineer in question doing it, and I have to say, it pissed me off no end.

Convoluted and obscure questions just waste everyone’s time and you may think you are clever for asking it; more than likely you are making the candidate roll his eyes internally.

6) Sometimes, knowing what the use you put something to is more important that knowing how it is generated. For example, Dot Product. If an engineer can describe what a dot product is (e.g., it’s the difference of angle between two vectors, described as from -1 to 1.) and give you four or five usage cases for it, that is way more important than being able to write the code from memory.

Some engineers put great stock by remembering formula by rote, and while there is some value to this, again, this is not normal day to day coding situations. If I don’t remember the code for a dot product, I go look it up. I spend some time comprehending what it is, write the code in my way, and forget about it until I need to do it again.
There is an argument that if you remember the source code, you ‘know’ the code, but that’s not actually real. Most coders who remember the source code couldn’t tell you what happens if you feed a dot product two vectors that are *not* normalized. If you can’t do that, then you don’t understand the root math.

Questions like this tend to show up a lot because they are easy to validate – either you know it or you don’t. Questions that really plumb how someone works are far harder – and require a lot more effort on the part of the interviewer – to set up.

The answer “I’d look that up” IS a valid response, even if you are mortally offended that someone doesn’t know the exact same things you do – or worse still, doesn’t associate the same value to it that you do.

7) Understand that your value system – of what’s important or not – is not going to be the same for everyone. Value systems are generated via experience, and by definition, everyone’s experiences are different.

Therefore, quite a lot of people will have very different reactions to what they see based on their experience – and sometimes the situation they are in too. Reacting to finding an incomplete API is very different when you have a deadline to get something done by, and find it’s blocked by this, than it is if you are just perusing the API docs and find something not quite right in it.

The problem with engineers is that they tend to be very black and white in what they believe. Way X is the “one true path” and everything else is just not. Any one who comes at it from a different point of view is therefore wrong, and to be argued with, in order that they see the error of their ways. Missing the point entirely that a) no one is likely to be swayed by your superior knowledge (just pissed off instead) and b) sometimes there is more than one way to skin a cat, and that’s – god forbid – ok.

8) Understand the guy in front of you is sweating, and wondering what it is that you want to hear, and will attempt to give it to you, regardless of the reality of their beliefs.

It’s an unfortunate statement that most people who are interviewing need the job, and therefore will contort themselves to be anything they can discern that you need. If you ask them leading questions, they’ll pick up on it and then try and mold the answers to whatever it is that they think you want.

E.g. “How do you feel about unit tests?” – that’s a leading question, and the right answer here is obviously “They are great, I use them all the time“. And that’s almost certainly the answer you will get, regardless of whether the candidate hates them with a passion or not.

You just aren’t going to get the truth by asking questions like this – that’s the reality here.

It’s taken me 25 years of interviewing to understand that I need to be myself in an interview, and not try and be what the interviewer necessarily wants. If I’m hired, then I’m going to end up being me anyway, and if that’s not what they want or can deal with, then I’m better off knowing that immediately rather than uprooting my family and moving across the world to take this job, and then find out that I’m really not a fit.

I don’t want to give anyone a false impression of me, so I have to be myself. If it’s not a fit then a) either I’m really not a fit or b) the people interviewing me really don’t have a good understanding of what they want. Either way, I’m probably not going to be happy there, and neither are they, so bullet dodged by both parties.

But most people aren’t like that, unfortunately (at least, *I* think it’s unfortunate). They want / need the job too much, so they’ll twist themselves into whatever pretzel they think the interviewer wants and then get the job and have a disastrous time because they are now going to revert to type. Life is too short for that I’m afraid – but most people haven’t gotten to the point of having it happen to them repeatedly, and haven’t learned that lesson.

9) encourage them to ask questions.

And what I mean by that is not “Do you do crunch here?” The point I am trying to make is that they have as much right to test your technical acumen as you have to test yours.

A lot of engineers don’t get that an interview is a two way street. They think “Hey, you are trying to get a job here. You have to impress me and not the other way around. I’m the one asking the questions.” Well, I’ve taken two jobs in my life where I’ve not done a technical due diligence on whether the people I am going to work with can actually get the job done, and in one case, it resulted in me getting stuck in Arizona for five years (and counting). Sure, I want to ask you about your technical abilities, what your development process is, how you QA stuff, what some of the biggest hurdles you’ve hit have been. If only to get an idea if some of the experience I have will be helpful.

Some engineers have their noses put out of joint when the candidate starts asking penetrating questions – this is an attitude that needs to be beaten out of people. They have as much right to know that you are going to work well with them as you do to know if they will work with you. The more that right is denied, the more you look bad as a potential employer.

Some thoughts on things that might be helpful.

I heard a story once about an engineer who, in his technical interview, sat down opposite the candidate, and then declared “I am a debugger. There is code that is crashing. It’s supposed to do X, but crashes when we do Y. What do you do?”

The interviewee then asked for more details, and the interviewer said “I’m a debugger. I can’t answer those questions. You can’t ask Visual Studio those questions and get answers – what would you do with Visual Studio?”

Eventually, the interviewee got the hang of it, and started asking things of the debugger that the debugger was able to answer – “What’s the stack trace?”, “What are the local variable values?”, “What does the source code look like?” and so on.

This is an excellent way of assessing how a candidate thinks, but while it’s great, it’s not without it’s problems too. The interviewer has to have all this stuff in memory and be able to reproduce it accurately, based on questions he cannot predict, and that’s difficult. One wrong answer and the candidate might not be able to solve the issue at all.

But, what it does tell you is exactly what the candidate would do – and it’s done in such a way that the candidate is more interested in what is going in in the interview than they are sweating out what they think the interviewer wants to hear.

One of the techniques I use now is to sit with a candidate, and describe a current problem I am having – what I know about the problem space, what the solution needs to provide and then say “Ok, what do we do about this? Lets work together on this.”

The idea is to mirror the experience he’ll actually have if the two of you collaborated on some design or implementation aspect, and get to see what he suggests. See if it’s off the wall, or what you were thinking or if he see’s issues you didn’t.

At root, you are attempting to see what happens in the real world of development at your studio, rather than the mostly artificial situation that an interview really is. How they work, how they think and how they collaborate.

Some great questions I’ve seen in my time include this gem – “Tell me, if I hired you, what would I most regret about that decision in six months time?” It’s a terribly leading question and really puts people on the spot because I guarantee you, they won’t have a prepared answer for that one.

The interesting aspect of that question is not what the actual answer is, it’s generally how long they take in answering it. Too long, and they are trying to find something that’s positive that they think you’ll accept “Oh, I’m too much of a perfectionist”. Or too little, and they are riddled with faults and are very quick to point that out.

Speaking of questions, the questions “Describe your greatest success” questions are interesting, but I’m not sure what they tell you about a candidate vis-a-viz the job in hand? “Describe your greatest failure” questions are more useful, particularly when followed up by the relevant “What would you do to avoid this in future” and “How would you fix that situation now?”

Something else I try and do is relax the candidate a bit. Most are pretty uptight – they need the job and want you to like / respect them. They aren’t at their best in this situation – almost no one is, so its your job to get them to relax.

At some point you need to say to the candidate “Look, there are no right or wrong answers here. There is no answer that is going to get you definitely hired or not hired. We are here to see how you tick and where your technical limits are. It’s not a problem that you have them – everyone does, and it’s all to do with experience. I’m just interested to know where they are. If you don’t know something, that’s ok – you aren’t being judged on that – I’m more interested in how you deal with something when you don’t understand it. It’s more a combination of everything. So relax, lets get some work done!”

Asking their opinion on something – asking why they did something, not in an accusing way but in way that asks them about their experience that brings out their conclusion – will grant you far greater insights into the candidate.

Also, ask them if they have questions and give them time to ask them.

Ask them if they want water or the bathroom. People do need to pee.

Last, remember, while you are giving this person a job and it means you’ll see them every day – which in itself is a big deal – for them it may well mean selling a house and moving a family across or continent, or even country. This is a big fucking deal for them. Please treat it as such.

The bottom line is, have some respect for the people who are sweating bullets in front of you, hoping to god they don’t say something you violently disagree with. Because they have no clue what you expect, what you want to hear or what is going to make you drop that black ball in the sack.

Posted in Game Development | Leave a comment

Good Luck Cliff Bleszinski!

Hey, so my friend Cliff Bleszinski has announced a new games company, and intends to make an FPS. A fairly unsurprising event, to those that know him (and those that don’t, I guess).

Now, I’ve read some pretty vile bile regarding Cliff (and please not, I’m not referring to him as ‘CliffyB’ any more. He wants to be called Cliff – that’s his name – and I would like to respect that. God knows the guy has earned that respect.) and it’s pissing me off a bit.

Cliff really doesn’t need me to come to his defense really – he’s laughing all the way to the bank and frankly, he has a thick enough skin, belief in himself and his abilities, and the proof of having been instrumental in the development and production at least three very large Intellectual Properties that he’s doing just fine by himself.

But I can’t help myself. People who have a pop at him have no real idea of who he is at heart. What I see is a damn smart guy who loves what he does, and loves every aspect of it. He’s just both so enthusiastic and knowledgeable about what he does, it’s sickening in some respects. I wish I had a tenth of his knowledge or energy, frankly. The only two people I know who have the same level of experience and knowledge are George Broussard and John Romero (and seriously, spending an hour talking to this guy is like being dropped in the memory pool. He even remembers the balancing values for old RGP games. It’s astounding).

The fact is, yeah, Cliff has a hot wife. Far from people assuming he is lording it over them (which is an attitude that I’ve seen a bit), my feeling is “good for him. He’s proven it’s possible to be a geek and still have a life”. Cliff is something to aspire to be rather than “something to tear down”.

In my experience, people who have to tear others down do so because they realise – usually unconsciously – they’ll never attain those heights, are the worst of what humanity has to offer, and me being my fathers son, I cannot help but point that out. Particularly when it’s someone who so completely does NOT deserve that on the receiving end.

Sure, Cliff has a media presence too. So what? He’s a clever guy – he’s got an agent and that agent earns his keep. That’s why Cliff is on Jimmy Kimmel and you and I are not. It doesn’t hurt that he actually has a personality, is funny in person, and damn well knows what he is talking about.

Again, this should be something we all aspire to, not something to bitch about.

Cliff needs to be judged on the quality of his games, not whether Kotaku decides to feature him or not. The reality is that if you do that, the man comes out ahead in just about every way possible.

Anyway, again, Cliff doesn’t need me galloping to his rescue – but for what it’s worth, I wanted to say Congrats, and Good luck. Whatever he does, it’ll make a splash and be fun, that’s for sure.

Posted in Game Development | Leave a comment