Star Citizen: Building a Schedule for a Universe

Transcript — every row opens the video at that moment

1. 00:00:06

   [Music] I'm Aaron Roberts and I'm the head of global production for Cloud Imperium Games. My main task is to basically work with the whole of production. We're trying to do something which people just have never done before in terms of the quality and the level and the size of the content we're doing. For me, it's probably the large biggest challenge I've ever done in 30 years of working in this industry just because of so many moving parts. You know, you have the different artists, coders, designers, audio. So when you have so many different people in a lot of different offices, getting something that we can put in front of the community is a massive undertaking which involves you

2. 00:00:54

   know production staff of you know 26 27 producers who all work together to basically get all the information together to make that schedule. We usually have our high level kickoff meetings to actually start planning what our goals are going to be for the game. This typically comes with talking to Chris about what he envisages exactly what we need next. The kickoff meeting is to define with the directors and the leads and everybody involved what the goal and aim of that particular sprint is and how it ties into the bigger picture and then just start breaking it down into we've got this feature, what are the fundamental requirements of that feature, what are the building blocks. When we get the feature list or what we're trying to achieve, we basically have to evaluate what do we already have that we don't need to rework. What do we need to rework? And then what do we actually need to create to make this a complete feature. Say we want to do a

3. 00:01:41

   new feature for character clothing. Directors sit together and say okay what is the feature about? What do we want to achieve with that feature? Okay, these fundamental building blocks these are the tasks that are required to make this happen. You can then start actually building in right we think this task are going to take this amount of time for feature requests. Usually we start off with with the kickoff meeting director sit together and say okay what is the feature about what do we want to achieve with that features and then we build like a a list of task out of that. Usually we give that to production and then production puts them all into our Jiraa system which is our task tracking software and then they start scheduling them out and see how they can fit into like our timeline. So then you have this feature that uh we've worked into a sprint team and we've broken the task down. The idea of a sprint is you are

4. 00:02:30

   working towards one goal within one set period of time. So a way to think about this is the schedule is like a skyscraper. The floors are the subscaper. The walls are the sprints or the work being done. And the jurass are the individual bricks that have built this overarching schedule or skyscraper. In this scenario, engineering does sprints and there's quite a bit of work to do for this project. And you can imagine on the programming side, if they're doing sprints on their team, like we do here in LA, they'll stay focused again on what what are we trying to do this two weeks? What are they trying to do these four weeks? Tech design does sprints, animation does sprints, even our character team who does waterfall work, they tend to do sprints as well. Just to again, it allows for that quicker iteration and awareness. How we've been doing the sprints with the LA team in our engineering has been a little bit more macroscopic. We've been trying to figure out ways to deliver on incremental

5. 00:03:18

   technology improvement. You know, this is not, you know, delivering a gun or a character animation or, you know, small feature. This is how do we have systemic support for landing, takeoff, flights, and AI control. It's the same technology, but it's a very big piece of technology. So, our sprints, they're a little bit more complicated as a byproduct simply because of the technology that we're building. When you look at a massive project or a massive entity or within engineering, we have a lot of features we're trying to achieve. The larger it is, the more daunting it can become. And sprints allow us to distill that down to a very tight focus. And so if we we say this is what that feature is. Let's bring in all the disciplines UI and engineering and programming all the art teams and go here's what the feature is. Here's what design has already broken down based on Chris's expectations. After we've had that initial kickoff, they go back and they break their piece, their little

6. 00:04:05

   piece of that into work. So UI would come up with their UI experience, all the kind of work that they do, and those break down into little individual tasks for people on their team. Say our UI artist has his or her 15 tasks that they've got to work on, but those 15 tasks are for just that person. And now you have 15 tasks for every person on it. And this could be anywhere up to, you know, 10 15 developers. And so they all have 15 tasks. And then you take those and you match those up and that makes that one feature. And then that one feature impacts this aspect of cargo. But then you have these three or four other features that make up Cargo. And those each themselves are broken into 15 to 20 to 30 to 100 tasks, god forbid, and you find that all of a sudden all of these tasks directly impact the ability to deliver this one feature. And that's just cargo. That's just one. But we get an initial estimate, an initial bid for that. You know, we might have someone who says, "Oh, this will take me a week." But we

7. 00:04:53

   look back and and they just worked on something and it only took them two days and it's functionally the same thing. We're like, "Oh, well, you know, maybe this will only take 4 days." It's not an exact science. You know, a lead designer may be able to achieve a task in a certain amount of time, whereas a junior designer would be able to achieve a task in a more um a longer period of time just based on experience. And as production, we kind of have to keep that in mind when we're scheduling. Let's say it's just engineering and they've got 35 tasks. Those tasks are then given to the individual who's going to work on the work and they will come up with the bid of saying it should take me 3, 5, 10 days, 2 hours, 30 minutes, whatever the number is. We're always doing new things. So a lot of the time, you know, you're just guessing about how long you think something is going to take. And then once we understand that, the lead validates that number, put it into their into Jira. Once that Jira is created, that goes into project. Once project has

8. 00:05:40

   all the Jiraas, it then shows you here's what I need for just this one discipline. So we'll have kind of two estimates that we track against to get these historical data estimates and then the actual estimates. And then once we have that in one location, we say that's that one feature. And then that one feature makes up the grander hole of Star Citizen. That is a certain number of features that we're trying to drive for for our ultimate release. Let's take one example. Cargo. Cargo is a feature that we've talked about for a long time. And that feature is broken down itself into many sub features depending on disciplines or if you're running sprints. The first thing we have to take into consideration with cargo is the inventory feature. We need a way to track and manage that inventory. So we need the UI for that inventory. You have to think about potentially weight distribution within the ships which then impacts the IFC model. You have to think about the way that players interact with the cargo whether that's physically or

9. 00:06:28

   on a kiosk. So you have to figure out all the subsystems behind the kiosk to in order to understand how you're going to utilize cargo, whether it's in your ship or in your hanger, wherever it's going to end up being. Breaking that out even further, we need to know what the specific actions are and interactions are available for cargo. Can you walk into your cargo bay, pick something up, and take it out? That's another piece of work that we need to schedule. There's other things that need to be taken into account, too. How does the ship fly with cargo? How much cargo can a ship have? What types of cargo are available? What happens if you damage cargo? Then you need to consider all the things that interface with cargo. Can you buy cargo? Can you sell cargo? How? Where? Then there's the slightly more esoteric elements of cargo. How do we manage cargo? If I say take a piece of cargo out of a ship and I leave it on a planet, is it there for a day, a month, a year, forever? We need to take all of

10. 00:07:15

    these into consideration. Each individual component that touches each other feature. So one feature isn't just Cargo. It's Cargo. Cargo's sound effects. Cargo's user interface. cargo interacting with inventory, cargo interacting with everything else in the entire world. So design basically fleshes out a concept a bit further and then our engineering team works on a TDD or a technical design dock for the implementation in conjunction with the uh appropriate disciplines and directory input. And so then we teach take each one of these tasks we take each one of these work items and their subtasks and they're all collected underneath their particular epics and group of epics in this feature area. And then these features are all collected into their grand feature plans and feature sprints. The whole point of a sprint is to get cross-disciplinary work working together

11. 00:08:02

    in tandem to make decisions together. It involves multiple people from across the studio. No one team can simply generate a feature in a vacuum. I can't create sound effects with the team that I've got here in Los Angeles. I need the sound effects guys in the UK. I can't do zone system mechanics or change fundamental engine physics. I need the guys in Germany for that. There's team members across the globe who have to have a say if not an actual direct contribution to all of these major features. So when you see that bar that says cargo, it's broken down into an amazing amount of sub features that have itself each individual discipline in Jira's tasks. And all of this then stacks back up one piece at a time into this large master schedule. this huge culmination of all the work that's being done, all the work that's

12. 00:08:49

    being planned across the entire SK schedule and company. So each of those individual sub features or subcomponents of cargo impact cargo which ultimately impact every other large-term feature which then ultimately impact the overall schedule and when we can deliver it. If everything goes absolutely perfectly, there's no problems, no bugs, things don't change and that in real life doesn't ever really happen. as you're working on it, you might find areas that cause it to take a little bit longer and we adjust bids moving forward. We utilize Microsoft Project. No matter what uh database you use to manage your tasks, we try to use that as the main hub. So, there's several ways that you can um populate Microsoft Project with uh what we do a lot of our work in Jira. our actually our PU uh engineering director Paul Randell did some amazing visual basic scripting for us and

13. 00:09:36

    actually he uh allowed us to make it so we could pull Jurro tasks in per epic into project so we can do all of our massive scheduling. Once we do all that scheduling in our per discipline or per feature those all feed up into the grander schedule that can pull from each of them through a really cool feature in Microsoft Project. What I will say is that no matter what, there's always that unknown. And that's why it's when we're planning these schedules, it's the collaboration I find that really helps the challenge. That collaboration is production working with their directors and their leads. Well, you know, the interesting thing about scheduling is they're living entities. You can't just say, "Oh, we've made a schedule. We're done." It's, "Oh, we made a schedule. Now we can start with something the size of the persistent universe and crusader." The first thing you do is you you set down what you think you can accomplish and then you get a reality

14. 00:10:24

    check. Moving from uh our current version of Star Citizen into the new uh version, there's quite a few hurdles because we're going to put people into a bunch of new systems that didn't exist before. That in itself is quite a technical hurdle. How's all that going to work when we put everything we merge it all together and you are doing this seamless transition with all these new systems in play? The moment you add in any kind of new feature or new system, it does always introduce new bugs. Of all of the planning, estimating bugs is really the most difficult because there's so many variables, so many things could be involved in a bug. It introduces so many new unknowns that we have to plan for these unknowns. The sprint system or the again the twoe sprint allows us to kind of iterate quickly and go, "Hey, I had no idea that was going to break all of this stuff. Did you?" Nope. I wish we would have thought of that, but never done this this way. So, let's, you know, got to iterate through those bugs as we go. You

15. 00:11:10

    know, a a wall doesn't look right. That could be in the shader. That could be in the graphics. That could be in the graphics card driver. It could be in the assets and how they're laid out. It could be in the design. Or it could be pure gameplay engineering where we set up a visitor wrong. So bugs are the hardest to schedule. It can be complicated because everybody has their own schedule. Everybody has their own specific dependencies. We do work closely with the other departments just to make sure that our schedule aligns with theirs. And all of these tasks uh will be completed by one of or by multiple departments such as tech design, LA engineering, PU engineering, Squadron 42 engineering, characters, ships, tech art, environments, concepts, quality assurance. Well, they won't be completed it, but they'll be doing bug testing on it. And all of these

16. 00:11:57

    different departments and disciplines. There's none of them that work independent. There's parts of their work they can do independently, but most of them they work across multiple studios, across multiple regions, and they all impact each other for better or for worse. And of course, not all pipelines are the same. Weapons pipeline is a very traditional content pipeline. So what we create is a piece of content. It's a weapon. It's a fairly contained piece of art. There's a lot less unknowns than, for example, when we talk about AI. So building a game this size which has never been done before really bears a lot of unknowns for us and for AI systems. If we don't know how we need to break down a goal into tasks or if we don't know yet how we need to build a system we really need to start with prototyping and research. Unfortunately this takes a lot of time but we really

17. 00:12:45

    want to make sure we build the best we can. Actually the code has always been you know notoriously difficult. There's several factors involved with that. As soon as we know a goal is not that we formulated is probably not going to be met, we start communicating to the director so they know the goals they set will not be met and they are informed of what the reasons are. It's nobody's fault and there's no problem. We just need to figure out how to move forward. One of the um problems we have is competing demands. You know, we've got a finite resource of of programmers. Sometimes you just can't throw extra resources at something. Imagine you've got two artists working on a ship or three artists even. You can't just add another three artist on one small ship. You don't want to throw too many cooks in or even too many makers trying to

18. 00:13:33

    actually just piece something together. So figuring out like when do they have time and do we have the bandwidth is where the complexities then come in. We've got an animation programmer for example. So he's actually highly in demand. So you've got this one resource and then it's really a case of prioritizing, you know, what work he needs to do on the different features. I think on the production side, the the hardest part is definitely dealing with making sure that we're delivering the right features at the right time. From there, you know, you have to consider things like dependencies. Like let's say this track view is a really great example. Well, until we get that track view feature all the way done and and complete for the cinematic guys, the cinematic guys can't do all of their work. You basically build a schedule best case. Um you put in allowances, you put in time for your finger tape for bug

19. 00:14:19

    fixing and so forth. And then what you do is you then go through and on a daily level you track it and you basically go back to everybody say how's this going and so forth. Sometimes dates push, some things get done, some things we pull in early it, you know, you know, typically early is, you know, rare in this industry, but you know, but sometimes it happens and then and then we definitely give the information out and if you have that information, you know, on a daily basis, then you can make calls very quickly. If you're not tracking it as well and then you don't get information for a week or two and then all a sudden you find out you, you know, something's not going to work, that's not great because then you then you can't fix it. Every time I look at our feature list and I look at what we're planning to do, you you are just taken aback to be honest. I think that's the encouraging thing about it that we're always trying to push boundaries. With that comes those huge challenges, right? Um and I think you always want to be able to say,

20. 00:15:08

    "Okay, I've got a plan and we're ready." So for a project this size, it's really a challenge to align the resources globally. And this global schedule, we try and stack the order in which we're going to work on tasks. The biggest challenge with working internationally is just making sure that the teams that are doing the work for us get feedback from us in a timely manner. So that we get a really good look at where things are going to come in in sort of linear order. So we can say, oh well, you know, in this time we expect to do some of these bugs and we expect to deliver these features and these tasks for these features as well. It's the really about balancing that time difference so that they have everything they need before they start their day and they're not waiting on us for anything. There's no way to in a detailed granular way plan out a full project because there's so many unknowns in game development. The

21. 00:15:56

    schedule is never done. It's always changing, always being amended. It's just so it's just the nature of the business. It's the nature of the um the the unknown, you know, because in a lot of things we're doing on Star Citizen is just truly groundbreaking and you just don't have a precedent for it. In certain uh game studios that are aren't as front facing as we are, you know, this kind of thing happens all the time, but you you just don't you just don't see it. The crowdfunded nature of our project, people can see people see that all the time when when that kind of stuff happens. We have about conveniently 42 actual Microsoft project schedules that we maintain across all five studios. Each of those schedules not only has the high level understanding what those disciplines are doing but it has each of those disciplines broken down into individual tasks. So when we make a schedule we

22. 00:16:44

    have uh a couple databases we track our tasks down to the micro level. In our Jira database in our lifetime we have closed 76,196 bugs tasks subtasks epics. We currently have 18,046 currently open. That's 1,05 epics, 10,797 tasks and subtasks open and 6,131 bugs that are open. So the tasks and subtasks and epics were all scheduled and all planned for. You do have bug fixing time generally. So we do schedule for them. We don't necessarily know what's going to come, but we do try to schedule and plan for completing everything that shows up in that database. When something on our production schedule just shows one individual feature, what it doesn't show is the data we have in the back end, which tends to be a matrix that's 4,000 tasks deep and 4,000 tasks long. That really makes up this overarching single bar that tells you exactly when we're

23. 00:17:32

    trying to achieve it, what it takes to actually do anything that we're trying to do. Takes countless hours of people's time to not only establish how long should this take or what it would take to do it, but then doing it and then fixing it and then we get it out. I think the important thing is to realize when you don't know the answers yet and then to give the team time to find the answers. It's a very important part of game development and if you account for it and everybody's on the same page then it's really not that big a deal. It's just when you expect every sprint always has to have a feature at the end and nobody like everybody should magically know what they're going to do every day in the sprint that you run into problems in video games development that's just not realistic. individual tasks uh are rolled up into sprints which are rolled

24. 00:18:21

    up into epics or features which are rolled up into our detailed schedule just for uh AI FPS or networking or UI or graphics or audio or engine or gameplay and that's just our engineering team. We also have ships, characters, props, environments including planets, landing zones, space stations, etc. weapons, cinematics, VFX, audio, both sound and music design for Squadron 42 and for PU. We have tech art, tech content, tech design. All of this is for all the aspects of both Star Citizen and Squadron 42, which has a SK a jolt that's tracking up to a,000 tasks. Uh each one of them are on our up to almost 40 heavy, really heavyweight Microsoft project schedules that need to ultimately roll up into uh S42 and 3.0 PU schedules. We have so much talent that we have recruited uh to make this game. It's definitely a challenge to to

25. 00:19:12

    get it all in. We have a lot planned and I'm really confident that we'll be able to to break everything down and and get it into the game. This whole huge project is just like a um an amazing experience for everyone involved. It's a work in progress, but it's actually a lot of fun for us because we get to build something which has never been built before.