A Day in the Life: Video Game Producer

Introduction

I’m Ben Bascom (@ben_bascom) and I’m a producer at NinjaBee.  I’m currently working on Nutjitsu which releases soon on Xbox One.  My previous capacities include programming and design.  I've been a producer for several years now and I’m frequently asked what that means.  What is it that I do all day?  Well, it’s hard to do it justice in a few words.  I really feel like I should walk people through my entire workday so they can get a clear picture of what it means to be a producer.  That is what prompted me to document one of my days and share it.  I will preface this by highlighting that every day is different.  This should, however, provide some useful insight to all the aspiring producers out there.

8:50am

My alarm goes off and I hit the snooze.  No such luck.  My daughter spies movement from where she’s been sitting at the foot of the bed and tackles me. I slowly disengage from my 3 year old assailant and make my way to the shower.

I spend a little longer in the shower this morning because I’m tired – I stayed up later than usual playing games last night.

With the shower out of the way, I look at my phone to check my emails.  I’ll probably only reply to urgent emails right now but I want to get an idea of what I’ll be facing once I get to the office.

No urgent emails this morning.  So, I grab a glass of OJ and quickly finish getting ready.

9:40am

I hop in the car and start making my way to the office.  I like taking the time during my commute to think over game ideas.  Today, I’m running through the details of an Xbox One concept that hasn't been fully fleshed out yet.  I know the core experience is incredibly unique but it isn't enough by itself.  There needs to be more peripheral gameplay, more rewards.  Should I toss this idea or should I incorporate it into something else?  

We’ll see.

10:00am

I arrive at work and jump straight to my emails.  Nutjitsu has recently been sent off to certification on the Xbox One and Microsoft has some questions for me.  We’re working with the ID@Xbox guys.  They’re really helpful but this is all new still and, since we’re one of the first to go to cert with this program, there are going to be plenty of unforeseen hurdles. 

I shoot off some more emails to external partners and I hike downstairs to grab some soda.  One of the many cool things about working here is the free soda. 

No Diet Mt. Dew in the fridge and I forgo my standard backup Diet Dr. Pepper and Vanilla Coke Zero cocktail in favor of the Lime Diet Coke that catches my eye.  As I grab my soda, I tell myself that I should drink less of it – but it tastes so good!

10:30am

I walk around the studio to talk with my various teams to see how things are going.  We have an internal chat service that works great for facilitating communication between individuals and groups but I’m a strong believer that face-to-face communication still supersedes that.

I also look for opportunities to praise employees in-person for their work.  I work with some great people so it’s not hard to find things to compliment.

11:30am

It’s team meeting time.  We have a daily stand-up meeting – stand-up because it does a good job at discouraging people from relaxing and shooting the breeze.  This is where I have the opportunity to get a snapshot of where everyone is at that exact moment and to formulate plans of action with all the team members present.  It’s also a good time to share feedback, announcements and remind people of pending deadlines.

The team meeting is for a prototype that we are working on.  It’s nearing the end of the prototype phase and things are really starting to look cool.  I want to share details but, unfortunately, it’s still a secret at this time!

11:45am

We do yearly reviews with all of our employees.  Steve and I are reviewing Paul now.  He’s one of the last employees I have on my list.

I enjoy doing these reviews.  It’s not always easy to have a personal conversation with someone since most employees share an office space with at least one other here.  This is an opportunity to really dig down and see if there’s any way to improve on the workplace experience. 

12:45pm

It’s nearly lunch time so I make sure I round up any loose ends from the work day so far.  I answer the lingering questions that employees have posed me in our chat program and I run through the emails I have received since I've been away from my desk.

1:00pm

It’s time for lunch.  As a management team, we go to lunch together each day to sync on issues around the studio. 

Today, the hot topic is ID@Xbox.  It’s very prominent in our minds because Nutjitsu is in certification.  We talk about the pros and cons and what ID@Xbox could mean for the future.  Naturally, we compare it to our experiences with Xbox LIVE Arcade on the Xbox 360.  Both programs have their good points.  Other indies who are running through the program right now have been contacting us and we've been sharing our experiences in the hopes that they can make smoother progress through the certification process.

2:00pm

It’s time for what I call my daily walk-around.  I have this scheduled on my calendar and try to plan meetings around it wherever I can.  At this time, I try to make sure I get face time with each employee currently under my supervision.  If that’s not possible, due to time constraints, I will at least talk to key people. 

As I walk, or rather, shamble (my foot is currently in a brace) around the office, I have to avoid people doing reps of the stairs.  We have a five-week wellness competition going on at the office right now and one way to tally up points in it is to climb stairs.  I think we’re going to need to replace the carpet on the stairs once this thing is over!

While I’m walking around, I remedy my soda discrepancy from earlier this morning and, while there’s still no diet Dew, I pick up the next best – my Diet Vanilla Coketorpepper Zero cocktail.  I’m so creative, aren't I?

The walk-around time is also a great way to stay in touch and get a feel for what is going on in the studio.  As I move around the office, I walk past a table with all sorts of props lying on it.  Would it be weird to do my walk-around wearing a fake mustache and beard?

2:45pm

Our Nutjitsu submission is missing a file.  I shamble down to the QA department and get the gears moving to remedy the issue.  Jason is on it.

While I wait for that, someone from another studio asked me if we had addressed a similar issue to one their game is having.  I go talk to Paul and Peter to see what they say and shoot a reply back to the inquirer.

I also have a few other emails to send out to external partners.

3:30pm

I have the missing file to deliver but now it needs to be packaged and uploaded.  I need to zip up this file with the rest of the very large package that needs to be re-uploaded. 

While the package uploads, I take the time to review the prototype one of my teams has been working on.  I play it for a while and make some notes on problem areas.  Sometimes, I will have the QA staff enter bugs from my hastily scribbled notes.  This saves me time and, generally, produces better, more useful bug reports. However, since this is a prototype, the QA team hasn’t been involved.  It makes more sense for me to personally enter the issues in our bug tracker.

Lane sent an email letting everyone know a masseuse is coming in next week and there’s a sign-up sheet downstairs for free massages.  This comes around every few weeks.  I’m not normally one for massages but I may have to wander over to the sheet and put my name down – and grab some more soda while I’m at it…

4:30pm

I have some intern programmers on my team who are coming to the end of their internship.  I spend a while preparing feedback to send to their school.  They've been great to work with. This round of feedback isn't too burdensome to write out!

While I write this feedback, I backup the Nutjitsu build from earlier to our network drive.  It’s good to have it there rather than on my computer because the network drive has automatic backups in case of a hardware failure.

5:30pm

I begin rounding up my work for the day.  What this means is reviewing notes from meetings, mentally reviewing conversations I've had and scouring through emails to make sure I've addressed everything that needs to be addressed.  I know from past experience that this phase of the work day will take anywhere from 30-45 minutes on average but, on occasion, it can take much longer.

After the roundup work is done, I review what needs to be done during the next workday.  It looks like I have a day full of meetings lined up but I know I need to finish the remaining employee reviews that are assigned to me.  So, to make sure I have time, I set aside a portion of the day to do a review.

I also need to distribute a build of my team’s prototype to some employees outside of the prototype team in order to gather feedback.  Before I can put a build in their hands, there are some things that need to be fixed.  I scribble down a note on a post-it and stick it on my monitor.  I want to make sure that’s the first thing I see when I come in.

6:00pm

I get in the car and once again put time into thinking about game design.  I am still struggling with the same concept as I was during the morning drive.  I will grind out ideas for this concept over many days and document what I came up with.  I then leave the concept in “storage” for a while and will come back to it after a few days or weeks with a different perspective – maybe to develop it more or maybe to throw it out.

6:20pm onward

I spend the rest of the evening with my wife and daughter.  I receive emails intermittently throughout the evening.  Most I don’t need to respond to until I’m back at work.  However, I keep my eye on them in case there’s an email that needs a faster response.  There was a time where I would have responded to every email but, over time, I have developed a better understanding for what needs to be addressed immediately versus what can wait.  While it’s not always a perfect balance, it certainly works out better for my family now than it has in the past.

After my wife and daughter have gone to bed, I play video games to round out the night.  I’m a night owl, like many gamers.  I play for a few hours and then go to sleep – normally getting 6-7 hours of rest before waking for the next day.

iPhone Lessons

For the past few months, a few of our team members have been working on adapting Outpost Kaloki to the iPhone/iPod touch. This was our first attempt at developing for the iPhone, and we definitely learned a few things along the way. Since developing games for the iPhone has become so popular, we thought we’d share the lessons we’ve learned to make things easier for those thinking of converting an existing game or starting from scratch on iPhone development. We asked each team member a series of questions relating to their role in the project. We’ll start with programming, then move to art/animation, then design, and finish off with testing. If you have any questions you want the team to answer, leave them in the comments and we’ll write up a separate post to answer those questions.


Kevin--Programmer

1. Describe the level of difficulty in converting an XBLA game to the iPhone.

Converting the game proved to be much more difficult than I had anticipated so I'm going to have to classify it as "hard."

2. What things really tripped you up in the development process? What was surprisingly easy?

We ended up converting pretty much our entire Wraith game engine over to the iPhone which proved to be quite troublesome. This was problematic for a couple of key reasons. First of all, the iPhone SDK is written in a different language than Wraith. Fortunately we were able to "glue" the two together but it made things a bit messy. Secondly, our engine is used to owning complete control over inputs and external systems. The iPhone likes to own all those things and to update them on its own and tell you about events that happen. Eventually we ended up letting the iPhone do its thing on one thread while the game ran on a separate thread and the threads communicated together about input and events, etc.

Another thing that tripped us up during development was the difference in power between the Xbox and the iPhone hardware. I don't think we really had a good feel for what the iPhone could handle graphically and we were simply trying to give it too much to do and it was choking. Once we had a better feel for the hardware capabilities we were able to tone down a few systems from the Xbox and give the user a decent playable experience.

I'm not sure that anything really turned out to be surprisingly easy - the whole experience felt like it would be easier than it actually turned out to be.

3. How long did you originally estimate development would take? How long did it actually take start to finish (not counting submission to apple)? Why the disparity in time?

I thought it would take 1-2 months originally and it's turned out to be closer to 3-4 months. The disparity in time was due to the unanticipated engine conversion difficulty.

4. What are the biggest differences between developing for XBLA vs. PC vs. iPhone?

Our game engine is written to be platform independent, which makes it so we can pretty much make the game in one platform and the low level functionality is hidden. This way, once the engine is converted to whatever platform (the iPhone in this case), everything just works. Of course, this is what happens in a perfect world. The conversion of the engine to the iPhone turned out to be quite challenging, but it didn't change the gameplay much at all. You're really getting pretty much the same game you played on XBLA now on the iPhone.

5. What advice can you give anyone developing for the iphone?

If you've never developed for the iPhone, spend some time getting familiar with the capabilities of the hardware and plan plenty of time to get used to the unfamiliar API.


Taylor--Artist

1. What was it like converting the art from an XBLA game to an iPhone game? Was it harder or easier than you expected?

Converting art assets from an XBLA game to the iPod/iPhone was an exercise in amputation, a stress test of the "reduce, reuse, recycle" mantra that ultimately prompted the class that I gave regarding the texturing and UV pipeline (see blog post here).

Game design in general is very different from the Pixar-style art generation that I trained for in college, and we're always trying to shoehorn as much as we can into every byte we have. Specifically when taking game assets from the Xbox to the iPod/iPhone, we had to reduce poly count and texture footprint by as much as 98%.

There wasn't anything terribly hard about converting the assets, but there were many little choices about how to reduce the models and textures, and everything required unique attention. A simple macro script wouldn't be enough to make it work well. This was expected, but it did wind up taking longer than expected because of iterative testing and some extensive model alteration, reconstruction and re-texturing as tech specs changed.

2. What was the biggest challenge in working on the art? The most surprisingly easy thing?

The biggest challenge working with such drastically reduced asset budgets was to maintain a look and feel consistent with the original game. That meant making cuts that really matter, but look like they don't. I think that overall, we've been able to make the game look and play enough like its progenitor that it captures the fun of the original without making too many sacrifices.

Maintaining the look and feel of the environments was surprisingly easy, given the complexity of the originals. It turned out that there were a ton of superfluous polygons in the models, so even a quick optimization pass got us a fair chunk of the way to where we wanted to be. A few texturing tricks later, and we had environments of 120 polygons or so that were less sumptuous than the originals, but still set the mood well. The originals were over 3000 polys in some cases, so we got a lot of value out of those 120 polys. We were also able to reuse those assets a lot easier than ship or station assets, so the environments went very, very quickly compared to the rest of the conversion.

3. What changes did you have to make to get the art to work on the iPhone? Did you create anything new?

We made several new LODs (Level of Detail meshes) for the ships and station expansions. We also wound up making a few new textures to fill in gaps or to optimize visuals that were fairly loose in the original. Everything was "under the hood" though, since there were no new ships, stations or expansions added. Anything new we made was just a tool to make the game look right (like the original) in the iPod/iPhone format.

Paradoxically, considering the vast reductions elsewhere, I actually wound up making larger versions of some HUD (Heads-Up Display) elements. The loss of precision that comes with switching from a mouse cursor to a touch input scheme meant that we had to alter some of the game UI. Even there, though, it was just making "technically new" visuals to approximate the old visuals.

4. Any advice you would give to someone working as an artist/animator for an iPhone game?

Get your game running on the iPod/iPhone as quickly as possible, and make sure the art and engineering teams work together to optimize it. The hardware chokes on things that larger consoles handle easily, and the earlier you can nail down target specs, the sooner you can get productive work done. We lost a lot of time by starting the project without an engineer and without the game actually functioning on the hardware. We did reduce assets, but after we started testing them, we needed to do another reduction pass (sometimes a couple of reduction passes) because the vague guesstimates we did early on weren't stringent enough, and the assets choked the iPod/iPhone, even though they were reduced to 25% of the original size. This reworking took a lot of time that could have been saved with clearer reduction targets early on, and early testing with engineering guidance would have helped define those targets.


Ben--Designer

1. What was it like converting the design elements from an XBLA game to an iPhone game? Was it harder or easier than you expected?

I didn't really know what to expect in converting this game to the iPhone! I have never worked on or owned an iPhone, so, it was all new to me. I didn't imagine it being very difficult but there were many things I just didn't think about until it actually came time to start making tweaks on the iPhone. For one, the screen was very crowded. We had to make numerous revisions to the UI because important parts were being covered or because our clumsy fingers couldn't navigate the game very well.


2. What was the biggest challenge in working on the design? The most surprisingly easy thing?
The biggest challenge that I was faced with had to be figuring out what to keep in the game and what to get rid of. We imposed a very strict limitation on the size that the game could be and this meant we had to be conservative with what made the final cut. Fortunately, no gameplay was lost due to these cuts but we did have to remove some of the really cool ships that only appeared once or twice in the whole game.

I was assigned the task of cutting down the size of audio files in the game to save us some more space. If you were to play the games side-by-side you might notice a little difference in the sound. Fortunately, we were able to save plenty of space by cutting down the sound files, yet, the sound is still awesome in the game.

The easiest thing was probably shouting at Kevin every time the game crashed - even when it wasn't his fault. :)

3. What changes did you have to make to the design to get it to work on the iphone?

When shrinking the screens down to fit on the iPhone screen there were a lot of things initially that just looked terrible. There was plenty of shuffling around of pieces of art on the screen, as well as text. Some of the text which fit perfectly on the XBLA version bled a horrible death all over the screen on the iPhone.

We also had tons of awesome content that we wanted iPhone users to be able to access. Unfortunately, there was just too much content for it all to go in one game. Deciding how to split up the content to make it balanced fell primarily on Jeremy's shoulders, I believe. Jeremy worked on the game originally and was much more familiar with it than I was.

4. Any advice you would give to someone working as a designer for an iPhone game?

If I were to give a designer of an iPhone game any advice it would be a warning: Remember that people have fat fingers (or at least I do anyways)! All actions in the game should easily be performed by someone who has really fat fingers! Even if your game is called "Uber kool game 4 ppl w/thin fingerz" it should still adhere to this rule.


Jason--Tester

1. What was it like testing for an iPhone game? Was it harder or easier than you expected?

Testing on an iPhone is like testing in the future! It’s all shiny, smooth, and full of lights. Testing on it was pretty much what I expected, there’s a quick period of adjustment to adapt to the console and UI in pretty much every project.


2. What was the biggest challenge in testing? The most surprisingly easy thing?

The biggest challenge for me in any testing gig is just testing around bugs. For instance if there’s a lot of lag on a level it makes it very difficult to test the level effectively.

3. What crazy bugs did you come across that happened because of converting from XBLA to iPhone?

In one scenario asteroids are suppose to bombard the station, but something happened to the graphics and sound so they were silent and invisible. So I’d be playing and everything would be going along just fine, and then all of sudden half of the expansions on my station would just explode.

In the War Story scenario, war ships are supposed to come in and attack your expansion. When you destroy them, it helps you earn money and complete the mission. However, at one point in the game, the attackers would come in, hover around an expansion, then fly off without attacking. You could destroy the war ships but it wouldn’t count, which made it so you couldn’t pass the level.

4. Any advice you would give to someone working as a tester for an iPhone game?

Learn a couple of deep breathing techniques to calm down for those unavoidable times you’ll want to throw the thing across the room.

Testing, Testing...

[This blog post was written by Taylor Eshelman, one of our artists (and sometimes testers)]

My job description is "artist." I bill myself as a "technical artist" since I have a technologically savvy streak. I've even branched out into design here and there, most notably in an extracurricular collaboration project that's a variant of the "game in a day" that we did a while back. Today, though, I'm a tester.

Yessiree, I'm a QA drone. I've argued it before, and I'll do so again: Game testers don't get anywhere near enough credit for what they do.

In many ways, the QA (Quality Assurance) people are the last line of defense in game development. It's nearly impossible to ship a game with absolutely no bugs, but games that ship with egregious problems fail quickly and may never recover. Vanguard had a terrible launch, but has since been polished and refined into a much better game. Even so, that initial impression of a game that was literally broken in several ways has lingered, killing the early adopter buzz which can be so crucial for hitting sales targets. Gamers can be terribly fickle and judgmental, and a poor first impression (or a bad early review or two) can sink a game, whether that impression is well deserved or not, and whether or not real complaints are addressed adequately. As in so many other aspects of life, a "best foot forward" approach is crucial for games.

QA testers are the safety net for the game development process. There are so many cogs and fiddly bits that come together in any software project that there will almost inevitably be things that don't mesh well. The only way to find many of these problems is to play the game. Over and over. And over and over.

You see, game testing QA isn't very similar to the end user experience. QA people have to repeat the same procedures many times, trying to suss out how things might break. They actively try to break the game, which can include doing normal "gamer" things, and more, by doing really weird stuff. (You know that someone out there will do something so totally wacky with your game that they will break it in ways you never would have thought to test... but you still try to test as much as you can to head them off at the pass.)

That's inherently different from trying to "beat" a game. QA people do have to keep the concept of "fun" in the back of their mind, and notions like "balance" and "emergent gameplay," but for the most part, testing means actively trying to find *problems* in a product, not trying to find *fun*. That's why it's a job, and why it takes unique skills. That's not to say that "gamers" can't also be testers, just that the two aren't equivalent.

The writers over at the Elder Game blog rightfully point out that QA isn't something that is best done in a vacuum. Testers need to know how the game is expected to work, in order to try to break it. That may seem obvious, but it's an application of the "thinking outside of the box" cliche: in order to try to stretch an idea or game outside of its box, you have to know where the box is in the first place. The Elder Game article describes this in more depth, so I highly recommend popping over there to see what they have to say. Long story short, the designers, engineers and artists need to work with the QA department to make sure they have the tools and expectations to properly put the game through its paces. (The old "It's a feature, not a bug!" argument after the fact doesn't work all that well.)

Yes, ultimately it's the engineers and artists that create the content and string it all together into a coherent package, but they will inevitably mess something up. We aren't perfect. We're relying on testers to catch the things that we missed. We certainly self-test a fair dose of things, but sometimes bugs don't even show up until things start coming together. The project that I've been working on has unique bugs that show up when the code goes from the PC where I worked on the content to the final game platform (a different bit of hardware). I'll never see certain problems testing things on the PC, despite doing all I can as an artist to make things correctly and test them before committing changes to the database.

Even in an age of "ship now, patch later", good QA is vital to getting things as right as possible for the initial release. Games are such transient bits of entertainment that a buggy product can totally miss the window of opportunity on the market, even if it's fixed later. As such, good testers are often a key component to financial success (between content creation/coding and marketing), which, at the end of the day, is what keeps food on the table.

Game development is an organic process with a lot of give and take. QA is a crucial component of that refinement process, and I, for one, find a great deal of responsibility in the role, and a great deal of appreciation for those intrepid souls who do it day in and day out, often toiling with little recognition.

-Tesh