What are the typical day-to-day tasks of an entry level games programmer? [closed]

Question

What I would like to know is: What are the daily duties of a graduate programmer in the games industry workplace? Is it mostly coding, analysing, designing, or what?

Thank you.

P.S. I am in my second year of University at the moment and am working towards specialising in games programming, specifically gameplay, tools or UI programming.

Answer 1

Based on my experience (in the United States, hired out of college onto a project that had just gotten out of prototyping and was a team of about 50, was then cancelled, then we went on to make two more games over the four years I was there with a total developer base of about 200),

• You'll probably spend about 50-70% of your time programming. In this time, I'm including the 'fun stuff' like getting to make a really clever feature, as well as the times you're staring at a memory dump for 8 hours straight trying to figure out what crashed. Maybe 25-50% of that is actual sit-down-at-your-keyboard-and-get-in-the-zone long-form programming.
• Another 15-25% in meetings and administrative tasks, like bug triage, meetings about bug triage, scheduling, high-level documentation for other programmers and producers, email, whole project/company status updates, and so on. This depends on how much autonomy you have - if you have no autonomy, then you'll get to spend more time programming, because you'll spend less time setting your own schedule. If you take more control of your schedule, you might get to work on more interesting things, but then you need to spend time doing this stuff.
• Another 15-25% helping designers/artists, attending creative meetings actually about the game, keeping up to date with game design documents, and so on.

As you go up in pay grade, the time you spend programming is probably going to go down. You're going to have to make more administrative decisions, be called upon to help less experienced people on the team, and spend more time doing documentation and code / architecture review. On the plus side, the quality of the programming will probably go up; you'll get to work on more interesting features (and more frustrating bugs).

Whether the time you spend in helping designers and artists goes up, down, or doesn't really change, depends on the area you want to work in. If you want to work on UI, tools, and gameplay, expect that time to increase to upwards of 50% as you gain more experience. You'll be sitting down with senior designers to plan and demo new tools and see how they use the existing ones. Unfortunately, this time also comes out of your programming schedule.

Answer 2

Other than the high level discussion points that Joe brought up, there are a few other things you should be aware of.

• You'll typically be using some kind of bug tracking or task tracking tool that your lead will be using to assign you tasks. Sometimes they're the same (i.e. FogBugz). Sometimes your bug list will be through a publisher and your task list is on an internal wiki. You don't just sit down and start doing whatever, your tasks are going to be directed.
• Sometimes you'll be asked to estimate your tasks. This is implicit when using systems like FogBugz. Part of your responsibilities will/should/can be to break down a higher level feature into parts that you can use to properly estimate how long it would take for the purposes of seeing how on track you are to finishing milestones, etc.
• A lot of studios have moved to more agile/scrumm style methodologies. Updating burn down charts (i.e. saying you spent X hours on task Y and expect to be done in Z time) is fairly common. Daily standup meetings are probably a little more common. Either way you'll be providing some visibility as to what you're working on.
• You will be using version/source control. The bigger the studio, the more likely they are to use Perforce. You should be aware of the basics of it (checking out files, committing files, being able to resolve your local merge conflicts). You might also be called upon to understand branching and merging branches. Some studios work where all developers get their local branch and you can check in as much as you want and merging when your branch. Other studios (ours) just has a "don't break main" policy, so you have to make sure you update, do a quick test to make sure you didn't break anything, then check in. Some studios don't have that policy and people break shit all the time and it's super annoying and you have to learn how to work around that.
• Code reviews are fairly common. Sometimes they're code-department-wide. Our team uses a code buddy approach where it's more one-on-one for reviews on checkins. Either way you should expect to be asked to provide critical analysis of other peoples' code.

Answer 3

I just finished a 4-month internship at working on a very large game. The project was very late stage when I got there, so most of what I did was bug fixing. That probably would have been a decent portion of my time anyways ... using my experience with coding to fix bugs instead of my inexperience with game development to design or develop features.

A lot of what I did was also sort of IT related. Developing internal tools was a big thing -- some to directly help with game dev, some to automate things that were manually done before. And of course, bug fixes for other tools, including Microsoft's Games for Windows Live installer.

Playtesting was another decently large part, and I also was responsible for making some of the builds that got pushed to playtesters. Bugs in the game world are pretty hard to track down and require a lot of work to figure out the cause.

I did not specialize in games or graphics, so presumably any job you did would be more related to your expertise than this. But I hope it gives you an idea.

Answer 4

My final year project is on HTML5 canvas element. I am presently working on an internship for the past two month where I have to port an existing flash game to HMTL5 canvas.

From what I can tell you about my life here, well its tough. The requirements team have very specific demands. What mouse click is supposed to be doing what, how the effects should apply on the game. No matter how tough it gets for the programmer even for the silliest request, it has to be addressed, and after all the requirements are implemented. The bug reporting start. God is that annoying. It really begins to get on your nerves. An offset of 1px for a click can make your life hell, trust me! It can mean new structuring of your entire positioning and interaction space for that you could accommodate to their whims and fancies.

But its also fun! :) The sheer joy of writing that one really smart function, interacting with the community of how you could recreate a function that flash does automatically. All of it. Its times like that you don't regret having that job.. Makes it feel like the best job in the world, and to my nephews the coolest in the world.

So a regular day in my job would be coming over to work implementing a function. Researching and searching for that one function that makes a feature possible. Getting the hell tested out of that code. Fixing that code. Discussing with the community on how that code could be optimized. Then writing what I feel is the best program on earth :P

At the end of the day, mostly am satisfied with what I have accomplished, sometimes still tensed about where I could have done better and what I could have done different and perfecting that. I just in the beginner phase and so I may not be able to advice you on how it gets in the future but as of now.. I do think I have to coolest job :)