Advice and Tales form the Trenches


Alex J. Champandard, Phil Carlisle, Eduardo Jimenez, Mieszko Zielinsko

In this interactive discussion panel, these veteran game developers will tell the story about how they got started, share some of their experiences from working in industry, and give advice to developers who are looking to get into the industry as AI programmers.

Answers truncated/note form and not what they really said! I enjoyed the bits on crunch, wish I took more detail of what they said, there were good points, and interesting stories.

Answers are all pretty much paraphrased, never word for word.

What’s the average day like for an AI programmer?
M: It depends on what feature you are working on. You come in though to continue from work before. Can check with designers what it is meant to do. Check if something is broken, then add things to it.

How much time do you work on “academic” AI problems at work?
M: I am lucky enough to add things to the engine, so it might be 6%! Actually it’s more like 20%.

How much time do you spend in meetings?
E: Depends from week to week sometimes can do no meetings in a week, sometimes 8 hours per week. Not always working on the AI, sometimes things such as the rumble on the controller. I’m more of a general programmer who concentrates on the AI.

What do you first thing in the morning Miko?
E: Start with emails, and check what progress you are at with your current task. If you’ve finished it, check your task list. I guess it is not much different to other software programming.

Phil, what did you do first thing?
Phil: We started off with the standard meetings, then moved on from that and had management lay off that once they saw everyone working on the goal. I worked a lot with the artists not designers so making it look right, so maybe bit different.

What is the most proud moment you had making AI?
E: When things go right and everything comes together, it’s a great time. Having three different parts of code and then them working together and it all makes sense.

Phil: Going from really dull to being able to play it. The main one for me though is when Worms 2 was released and I was in a shop and someone brought it, and it was completely unscripted, no one asked him to or anything 🙂

M: Having changes to the engine, then implementing something finally in code and a designer coming up and saying “What happened?” and going “Did I break something?” and they say “No, it works better!”.

Alex: Doing a behaviour tree interface for the designers over holiday, then when the designers use it and they make use of it in ways you didn’t think of at all.

Would you consider yourself a generalise or specialist?
M: I’m a generalist in a specialist way. I work on generalist features in the engine.

What would you advise students to work on specific things or work on general programming?
M: If you want to really be an AI programmer, well, you’ll start as a gameplay programmer – maybe not the graphics, since you need to know the render components – but learn your math. It really helps, even though I’ve forgotten everything since university 🙂

Eduardo, generalist or specialist?
E: A generalist – worked on every game area of programming, and being a specialist is not a good idea. If you want to get into the industry, start working on everything – you might think you want to be a specific programmer, but you might like other areas. Start writing small games.

Question from audience: In interviews is it good to say you specialise or that you know many areas?
E: Usually they don’t ask for specific area knowledge, such as if you know Havok physics and they use PhysX. Knowing the terminology for specific interviews such as shaders and so forth for graphics, but for lower level or general areas you should have broad areas.

Phil: The companies have told me they want programmers who can program well, over everything else. You can occasionally hit the right kind of demo but in general it’s being a good programmer and showing something of really high quality.

Going back to “being a generalist”, with huge codebases and so forth, what can students do and do you have any advice for that?
Phil: From the indie background, not sure why students don’t go and make a new company for themselves to develop games. Going through the boring grind of creating a game is important to show. Worth trying a lot of these things with so many open source or free codebases.

E: Best thing is to complete a game, even a mini-game, so much better for a interview. They could use things like XNA or iPhone framework, and go through the release process – peer review, so no crashes and so forth. Really recommend.

M: Last 5% takes 90% of the work so going through that finishing process is a really tough job and worth doing.

Let’s talk about the last phases of development?
E: Sometimes asked to work heavy hours at the end of development. Now companies are working though to stop burnout, but people still have to crunch and work on other bits of code that you might not necessarily know. You want to finish it but you can’t ship if it crashes.

How do you feel about crunch Mieszko?
M: I don’t like crunch! You have to be prepared to work for long hours from time to time. It happens in every single company. You won’t get rich working in the industry. And that’s true, you won’t get rich. You need to gather experience at low pay, since you’re a small fish in the ocean.

P: Industry is a lot better at managing time now then before. 4 people on a Team 17 project crunched for a year and a half, shipped 2 million units then was asked to do it again, but after a while really got to asking why it’s like that. Even Team 17 has changed and added scheduling and so on. It has got a huge amount better but there are still companies that push it a bit too far, a place near me who do 55 hour weeks as a normal working week. You need to do your research into it.

I don’t agree with sustained crunch, but do you think these cycles bring your team together? Panels might say they don’t like it, but then over drinks look at it with nostalgia!

P: Wierdly enough, yeah. It’s really good to feel like a team going to it together. It does form that bond. Playing Quake at 1AM in the morning to stay away, and so on. There is some interpersonal relationship thing to build up over time – if you get that together it’s a powerful force.

E: In small doses crunch time may be beneficial, even for the team to bound them together. In general terms it is not good or necessary. You can crunch for a couple of hours more to fix a specific bug one day, doing then the next day, fix it then go home. Doing it because management says it is needed and good for the team and good for the CV’s, give you life insurance – woah, just stop! When I started I did 5 months crunch time, but could have done 2 weeks crunch time, 2 months normal work, 2 weeks crunch, 2 months normal and got the same work done since how crunch goes bad after 2 weeks. It is not necessary to have crunch to bond a team, as I don’t do it in my current company.

M: One advantage of crunch time is the company buys food. But in my opinion it will always happen, Eduardo’s company is a miracle. Productivity is a problem if people hack the problem not fix the problem. Gets worse and worse. Fix not hack!

Audience question: What do you think about crunch Alex being an entrepreneur?
A: If you work by yourself it’s good to do it, but if you work for a company make sure you are compensated. Luckily at the last company they paid for overtime. For an individual just look out for your wife!

Audience question: Got to ask “Why” your doing crunch time in the first place? Money running out and meeting deadlines and managers saying.

E: Getting called to finish something or the company goes down is a problem without compensation for the extra work. For big companies like Ubisoft or EA it’s not going to make the company suffer, so it’s just a bad way of managing people. There was some people having to crunch at the end since there was not enough people or time to hire people, luckily they got recorded.

Audience question: Crunch is lack of management. AI development is driven development where a feature is built then given to designers to work on. This can mean very fast things getting broken. How do you split this kind of work and split the work between designers and programmers?

M: Generally programmers work to implement tools for specific purposes. Training the designers is hard to do. Hard to convince them the new things are good as well. Can show them a map instead with the feature working on it is a good idea.

Would you recommend getting into it?
P: I had a dream I was going to change my job, got called down and shown some graphics and asked to start that afternoon. Yeah, I think I’d work again, but not for someone else.

E: Was lucky after my degree getting a job in Madrid, since there was a lot of opportunities at that company. Really happy doing it.

M: I’d do it again, start the franchise again. Moved around a few companies before becoming an AI programmer – if you’re not glad working it is worth changing jobs. Won’t change ever now!

Leave a Reply

Your email address will not be published. Required fields are marked *

Website and journal of Andrew Armstrong