Get the latest Education e-news
 
  • A Day in the Life: Three Slices of Life from the Front Lines of Game Development

    [09.29.09]
    - Ben Schneider, Ben Lichius and Andrew Zaferakis
  •  Programmer

    8:45 AM I arrive at work and head to my office. At High Moon Studios, most programmers don't actually work in their offices. We work in open space areas, sitting next to designers, artists, and animators. My office is where I drop my stuff, check my email, and make phone calls. I share a large office with five other people, but only spend about 30 minutes a day in there so we are rarely there at the same time.

    9:00 AM I have my morning oatmeal, and I am now loading up the nightly build to examine the state of the game. The nightly build is automatically deployed to my development console so it's ready to go in the morning. I notice a couple of animation pops in the AI motion and make a note to ask the team about it later. Today's build looks good, no fires to fight yet.

    9:30 AM Time to start programming. At High Moon, we pair program the majority of our tasks. Today I'll be working with Robert, one of our junior programmers. Our pair programming stations have a PC with dual monitors, two keyboards, and two mice. Robert and I sit side-by-side and take turns programming throughout the day.

    This may sound strange to some people, but working with another person all day long has some incredible advantages. We are more productive, our code quality is higher, and the code is owned by the team, not an individual. In addition, pair programming helps bring new hires up to speed quickly and allows us to teach them our preferred programming methods, preventing them from developing bad habits.

    During my first programming job out of college, I had no idea what most of the code did, let alone where to look for it. Today Robert and I are going to implement locationspecific hit reaction animations on the AI when they are shot. We will be creating new AI logic, playing animations, special effects, and audio.

     10:45 AM Time for my first scrum of the day. The daily scrum is where people discuss what they worked on yesterday, what they are going to be working on today, and any impediments to their progress. In addition to being lead programmer, I'm also a scrum master. I'm responsible for the vision of one complete aspect of our game. My scrum team consists of programmers, designers, artists, and animators.

    This meeting lasts only 15 minutes and is done standing up. One of the artists mentions that he is having problems with his graphics card. The associate producer makes a note to follow up with IT after the meeting.

    11:00 AM Scrum of scrums. All of the scrum masters attend this meeting and discuss crossteam dependencies and impediments. Today there are no impediments to report for my team.

    12:00 PM Lunch! Our "studio mom" Samantha makes free catered lunches on Tuesdays and Thursdays, and breakfast and lunch to order the rest of the week. We also have a lot of lunchtime activities at High Moon, such as basketball, surfing, mountain biking, ultimate frisbee, gaming, or going to the gym next door. My activity today is eating Samantha's carne asada burritos!

    2:15 PM Some designers in the area are discussing a problem they are having with the AI. Thanks to the open space area, we can hear all about it. The designers ultimately ask us to jump into the conversation. Together we figure out a solution. Since this is a high priority issue for our team, Robert and I start working on it immediately.

    I've noticed that when people can see each other, they are more likely to ask questions. If they have to get out of their chairs, they probably won't bother. The open space area facilitates communication between disciplines, and having the team sitting in one area has dramatically improved our productivity. We constantly talk as a team without having to set up meetings or compose long email chains.

    2:37 PM I smell smoke, and where there's smoke there's fire. The animators are having problems importing animations onto a specific character. I talk over the problem with our technical director Sean, and we think we know the cause of it. Sean is busy fighting a fire of his own, so I move over to a free programming station and start debugging the offending code. I try to handle problems that fall outside of a specific team myself, allowing the rest of the team to continue uninterrupted. Before I get started, Robert and I have a quick discussion about what he will work on while I'm helping the animators, and then we both get back to work.

    3:15 PM The bug is fixed! Since I didn't pair with anybody while coding the solution, Sean comes over and reviews my code changes. He approves my solution. I check the code in, which automatically kicks off a new build of the game. Now I move back over to my previous tasks, and I find that Robert has made good progress on the AI.

     3:30 PM Build failure! We use continuous integration here at the studio: each time we commit code changes, a fresh build of the game is created. If one of our tests fails, the build is flagged as a failure and the team is alerted. I open up the build report to see what failed and who made the recent changes. When the build fails, nobody else can commit code until the build is fixed, so it's important to fix the build as soon as possible. Looks like programmers from another scrum team caused the failure. I walk over and discuss the failure with them, and they start working on the fix.

    3:50 PM Build fixed. The rest of the teams may resume code commits.

    4:45 PM Robert and I are working on our AI changes, and we found a way to optimize an expensive section of the AI logic. We talk it over with the other programmers on our team that sit next to us and estimate a significant savings in CPU time. This type of discovery happens often, and we want to keep track of new tasks so they are handled by the next available pair. We write up a description of the work to be done and pass it along to our producer for bookkeeping.

    6:15 PM Time to go home. As a lead programmer I find myself spending more time programming and less time in meetings. I'm constantly being presented with new challenges, and I enjoy coming up with solutions. I get to work with a diverse group of people from around the world developing video games -- life is good.

    - Andrew Zaferakis

Comments

comments powered by Disqus