My name's Chris Bray. I'm the studio head and senior producer at Stardock Baltimore. I've been in the industry for about 12 years, at Bal Stardock for four or five in production positions. And at Ubisoft for most of the rest of my career for about eight years in a variety of production and design positions. So today is just going to be a brief overview of what it is a producer does, different types of roles, production related roles and just a couple examples of how things are scheduled and how a release cycle might work. So a producers role, the really the crux of it is you're responsible for everything on a project, right? So if it's not somebody else's problem, it's your problem. If you're the safety check, you're kind of the safety net for everything. It's your responsibility to keep really everything that's going on in the project at a high level. In your head or at least in your notes so that people who are looking at very, very specific parts of a project, just the level art, or just the design of a given feature. It can use you as resource to see what they're missing or what they're not connecting the dots with. Another really big part of that is understanding your game from both a design sense and a marketing sense. And kind of being able to boil the whole thing down into, you know, why do people want to play your game, what makes it unique? And making sure that all the decisions on the project are supporting those goals and that vision. And then scheduling is obviously a huge, huge part of all that, is just planning things out. Getting information for the team to make sure that dates are going to get hit, you have the appropriate amount of people on the project, the resources are going to the right spots. And then coordination with, there's obviously the dev team is the vast majority of your time spent interacting with people actually making the game. But there is quality assurances that a lot of your time is going to go to a quality assurance. Working with people in the marketing department, working with business development people, I'm kind of the management side of your own company. And the people that are Set it up or partner of relationships of other companies for promotion of your game or integrated technology, that sort of thing. And then the last is kind of is the high level bit that producers often Often a big part of the role is to kind of be the buffer between your team and other tensions and developments. So you might have demands coming from partners or publishers or different directions team wants to go in. And your job is to kind of make sure that people have the information they need to get the job down and filter out some of those distractions for them and make sure that everything is staying on the right track. So common production positions QA, I added QA in here because that's a very, one it's very tightly integrated with producer roles, and it's often a common career path for people. So QA Analyst is kind of the in the trenches, testing the game day to day. Above that you have the QA lead who's organizing those people, maybe scheduling out some QA work. And then next is associate producer. So that's when you get into more traditional production roles. This person might be in charge of the feature team of maybe five or ten or even more people, artists and engineers together, working on, in my experience, I was working on the combat for one of the Ghost Recon games. And we had, I think three artists, two or three engineers, and a designer, and we all worked together on that subset of features. A producer is, you know, obviously the kind of the meat and potatoes. This person might have responsibility for a subsection of the games or a really big project they might be responsible, the producer for multiplayer, the producer for the single-player campaign. Or on a smaller team you might they may be a producer for the entire project, which is often also the role of executive producer, it's kind of the same thing. You draw the distinction there between somebody who, a producer is mostly dev team facing, whereas an executive producer is making most of the high level marketing decisions. And some of the more heavily involved in some of the partner deals and green lighting decisions on a company level. What projects are going to go forward or won't. To give sort of an idea of just the day to day life of a producer getting in the day, you might spend a couple hours just sorting through bugs that have come in through QA. Making sure you understand what the problems are in the game. Making sure those bugs are getting assigned out to the right people. That QA is checking the things that you're expecting them to be looking at. That there not testing parts of the game that are not ready for testing yet. And making sure everything has the proper priority so there not bugs that are getting sent to people that really don't need to be worked on yet. Or aren't as important of say a feature, or some other part of development. The next thing you're often tasked with providing marketing content. So there might be a release coming up and marketing needs new screen shots or video capture from the game or even just a public facing change list for a new update. And all those things you may or may not be providing those or creating that content directly. Sometimes you are, depending on the size of the team, but sometimes you're just coordinating with the person capturing the video. You might know the best new features that should be highlighted in that or the best parts of the games are the way to show off certain content that you know looks really, really good or shows off the game in the best light. Another thing you might often be doing is just reviewing a new feature as it goes in the game. So an engineer or artist checks something in. You want to make sure that it's working generally, that the tasks complete, and there aren't obvious fine tuning to be done. So sometimes that's done by a producer, sometimes that's done by a designer, sometimes it's done by both. A lot of time is spent, just the bulk scheduling of the project, and then planning, and also really clarifying and communicating tasks. So when an engineer goes to work on something, if the initial description isn't 100% clear. Or it's leaving out a lot of details, you may be defining exactly what the details of that task are or of that feature. Or sometimes you're just going to make sure the designer follows up and provides all the details and what precisely, how precisely they want that scoring mechanic to work, or that game mechanic to work. And then coordinating with partners is just another one. You might be emailing a middleware company about a problem you're having with something you're using. You might be emailing a hardware company with a driver issue or maybe a first or third-party publisher with some marketing or co-promotion or whatever else. So that's certainly not everything but those are the sorts of day-to-day tasks you might expect to do. So, scheduling is obviously a huge part of it. A lot of it comes down to, what people refer to is the production triangle, or the iron triangle. A lot of times it's fast, good, cheap, pick two. The way I think about it is, you have scope and quality on one end, and those aren't, some people will say quality, but it's not. Quite the same thing right you may the right decision for your product may be to have a. Well Fallout 4 just came out that's a great example maybe the vast scope of the game is just more important then making sure that every single bug is fixed just because that's the vision they're trying to create. And there's only so much they can do within the amount of time, the amount of resources they have. So obviously next is time. And then you have resources, which a lot of times comes down to money but it's also, it's certainly manpower, staffing. And which sometimes translates to money, sometimes doesn't and what the, whose available within the company or within team and then you also have opportunity costs. Things those people give, different projects they could be working on or different features or whatever else. Probably the most common production methodologies are Waterfall and Agile. So, Waterfall is basically a long list of times tasks where Task 1 is performed and when that is done after that's going to take a week, then task 2 begins, task 3, so on and so forth. That's good typically used for things that you can consistently predict the time that they're going to take. So art assets are a good example, if you get into the project, you have 40 characters to model. After you do the first two or three, well, they're about averaging a week. Week or week and a half or three weeks. And then after that you can kind of set up a long term Waterfall schedule. Agile is very very common now and it's as its name implies, it's intended to be more flexible. And it's usually used for design and engineering tasks that aren't easily estimated or easily predicted. And the basics of that are, one, to kind of compile all of the features that you would like in the game and the tasks to be done into A backlog. Which is a big, long hierarchical ordered list of all the tasks on the project. And prioritize them, accordingly and basically you're just pulling things off the top. And you're often doing that in two week sprints, were you'll. You'll take the highest priority task, two weeks of work, usually themed around a common goal as much as possible. Do that, evaluate it, so you have that frequent checking back on progress instead of just kind of through along a list and only reviewing things when you happen to have time or a break or whatever. And then reprioritizing those things on a regular basis as well. So common software that you'll be using, Hansoft is a very, very popular one with large studios, specifically for mostly used for Agile. Microsoft Project also popular, Teamwork, those are more project management. And then for bug tracking Jira is very popular and there's a handful of other ones I'm forgetting. And then other tools, just Excel and Google sheets and Google Docs and all those things we'd be using on a regular basis, and then source control software. Perforce is probably maybe closest to the industry standard. Source Safe is another popular one and that's to allow everyone to check in and version control all the changes that are being made constantly by large teams. And that's up in the, on the student projects with two or three people is not nearly as big of a concern. So that's something you wouldn't really get used to until you really start working in the industry. But, good very good to learn if you've got the opportunity, early. Production milestones the traditional production milestones are you have a pre-production period where you are figuring out what the game is about, proto-typing the core gameplay loops, determining a visual style and then from that once that's solidified, often work first playable, which is a slice of the game. Sometimes with art, sometimes with just place holder art. Or you can actually play the game experience it, and it gets kind of to the core of what's going to be fun or what's going to be unique about the game. Next up is Alpha, which is traditionally you are feature but not content complete. So any feature in the game is fully represented, so if you are a flying game. You have, that has helicopters, you have a helicopter that has a helicopter flight model, and flies around property, and has all of it's weapons. But you may end up having seven different types of helicopters in the game. And those aren't in yet, and that's totally fine for say half a milestone. Beta is traditionally you have a both content and feature complete and really just bugs and polish to work on after that. At that point you have release and then after that you have post release updates. So this has actually a lot in the industry over the last couple of years with really two things, one is games as a service. And two with early access, so, you're often having players getting in a game in a pre-alpha state. But you're often also having the game, in some cases with free to play games, we're really becoming both public earlier and it's major releases coming after the first release of the game. So you might have some major content come out, or major expansion come out, that's just free to all players. A year after the game initially comes out. So those are two big things that kind of throw a wrench in that traditional production milestone. And then lastly just a real quick overview of a release cycle. It's kind of specific thing, but it gives a good example of kind of the planning that might go into a specific part of a game development. So if you're coming up on a public release, or even a very important internal mild stone. You'll typically want to plan for, you set a goal of we're going to say put out our alpha inter early access, it's going to have these features, this is our goal. You set a date along with that. We want to release this on January 23rd or whenever it is. But beyond that you need to set a lock down date that's much earlier than that so that you have the opportunity for QA to test and verify that build. Fix any bugs that might come out of that. On the larger projects, or more important milestones, you also may split some of those dates up. Where you have the art locks down first. Most of the content creators stop adding content to the game. Code maybe goes a week after that where they can continue to make code changes and then lastly you have just that lockdown period. So, it can get a lot more complicated than that, but that's an example of specific,
