Vai al lettorePassa al contenuto principale
  • 10 ore fa
Un video riassume le principali novità che saranno introdotte grazie all'update 3.0 di Star Citizen. L'aggiornamento è previsto per il 29 giugno.
Trascrizione
00:23I'm Aaron Roberts, and I'm the head of global production for Cloud Empyrean Games.
00:27My main task is to basically work with the whole of production.
00:30We're trying to do something which people just have never done before in terms of the quality and the level
00:34and the size of the content we're doing.
00:36For me, it's probably the biggest challenge I've ever done in 30 years of working in this industry, just because
00:41of so many moving parts.
00:43You know, you have the artists, coders, designers, audio.
00:46So when you have so many different people in a lot of different offices, getting something that we can put
00:51in front of the community is a massive undertaking,
00:53which involves, you know, production staff of, you know, 26, 27 producers who all work together to basically get all
00:59the information together to make that schedule.
01:01We usually have our high-level kickoff meetings to actually start planning what our goals are going to be for
01:06the game.
01:07This typically comes with talking to Chris about what he envisages exactly what we need next.
01:11The kickoff meeting is to define with the directors and the leads and everybody involved what the goal and aim
01:18of that particular sprint is and how it ties into the bigger picture.
01:22And then just start breaking it down into, we've got this feature, what are the fundamental requirements of that feature?
01:28What are the building blocks?
01:30When we get the feature list or what we're trying to achieve, we basically have to evaluate what do we
01:34already have that we don't need to rework?
01:35What do we need to rework? And then what do we actually need to create to make this a complete
01:40feature?
01:40Say we want to do a new feature for character clothing.
01:43Directors sit together and say, okay, what is the feature about? What do we want to achieve with that feature?
01:48Okay, these fundamental building blocks, these are the tasks that are required to make this happen.
01:52You can then start actually building in, right, we think this task is going to take this amount of time.
01:58For feature requests, usually we start off with the kickoff meeting.
02:01Directors sit together and say, okay, what is the feature about?
02:04What do we want to achieve with that feature?
02:06And then we build like a list of tasks out of that.
02:09Usually we give that to production and then production puts them all into our Jira system,
02:15which is our task tracking software.
02:17And then they start scaring them out and see how they can fit into like our timeline.
02:22So then you have this feature that we've worked into a sprint team and we've broken the task down.
02:27The idea of a sprint is you are working towards one goal within one set period of time.
02:34So a way to think about this is the schedule is like a skyscraper.
02:37The floors are the sub schedules of that skyscraper.
02:40The walls are the sprints or the work being done.
02:43And the Jira tasks are the individual bricks that have built this overarching scheduler or skyscraper in this scenario.
02:49Engineering does sprints.
02:51And there's quite a bit of work to do for this project.
02:53And you can imagine on the programming side, if they're doing sprints on their team, like we do here in
02:56LA,
02:56they'll stay focused again on what are we trying to do this two weeks?
03:00What are they trying to do these four weeks?
03:01Tech design does sprints.
03:02Animation does sprints.
03:04Even our character team who does waterfall work, they tend to do sprints as well.
03:07Just to, again, it allows for that quicker iteration and awareness.
03:09How we've been doing the sprints with the LA team in our engineering has been a little bit more macroscopic.
03:14We've been trying to figure out ways to deliver on incremental technology improvement.
03:19You know, this is not, you know, delivering a gun or a character animation or, you know, a small feature.
03:24This is how do we have systemic support for landing, takeoff, flights, and AI control.
03:31It's the same technology, but it's a very big piece of technology.
03:34So our sprints, they're a little bit more complicated as a byproduct simply because of the technology that we're building.
03:39When you look at a massive project or a massive entity or within engineering, we have a lot of features
03:44we're trying to achieve.
03:45The larger it is, the more daunting it can become.
03:47And sprints allow us to distill that down to a very tight focus.
03:51And so if we say, this is what that feature is, let's bring in all the disciplines, UI and engineering
03:55and programming,
03:56all the art teams and go, here's what the feature is, here's what design has already broken down based on
04:00Chris's expectations.
04:01After we've had that initial kickoff, they go back and they break their piece, their little piece of that into
04:06work.
04:06So UI would come up with their UI experience, all the kind of work that they do,
04:10and those break down into little individual tasks for people on their team.
04:13Say our UI artist has his or her 15 tasks that they've got to work on, but those 15 tasks
04:19are for just that person.
04:20And now you have 15 tasks for every person on it, and this could be anywhere up to, you know,
04:2310, 15 developers.
04:25And so they all have 15 tasks.
04:26And then you take those and you mesh those up, and that makes that one feature.
04:29And then that one feature impacts this aspect of cargo.
04:32But then you have these three or four other features that make up cargo, and those each themselves are broken
04:37into 15 to 20 to 30 to 100 tasks, God forbid.
04:40And you find that all of a sudden, all of these tasks directly impact the ability to deliver this one
04:45feature.
04:45And that's just cargo.
04:47That's just one.
04:47We get an initial estimate, an initial bid for that.
04:49You know, we might have someone who says, oh, this will take me a week.
04:52But we look back and they just worked on something and it only took them two days.
04:56And it's functionally the same thing.
04:57We're like, oh, well, you know, maybe this will only take four days.
04:59It's not an exact science.
05:01You know, a lead designer may be able to achieve a task in a certain amount of time, whereas a
05:05junior designer would be able to achieve a task in a longer period of time, just based on experience.
05:11And as a production, we kind of have to keep that in mind when we're scheduling.
05:14Let's say it's just engineering and they've got 35 tasks.
05:17Those tasks are then given to the individual who's going to work on the work.
05:19And they will come up with a bid saying, it should take me three, five, 10 days, two hours, 30
05:25minutes, whatever the number is.
05:26We're always doing new things.
05:28So a lot of the time, you know, you're just guessing about how long you think something is going to
05:32take.
05:33And then once we understand that, the lead validates that number, put it into Jira.
05:37Once that Jira is created, that goes into project.
05:39Once project has all the Jiras, it then shows you, here's what I need for just this one discipline.
05:44So we'll have kind of two estimates that we track against to get these historical data estimates and then the
05:48actual estimates.
05:49And then once we have that in one location, we say that's that one feature.
05:53And then that one feature makes up the grander whole of Star Citizen.
05:55That is a certain number of features that we're trying to drive for for our ultimate release.
05:59Let's take one example, cargo.
06:01Cargo is a feature that we've talked about for a long time.
06:04And that feature is broken down itself into many sub features, depending on disciplines or if you're running sprints.
06:11The first thing we have to take into consideration with cargo is the inventory feature.
06:14We need a way to track and manage that inventory.
06:17So we need the UI for that inventory.
06:19You have to think about potentially weight distribution within the ships, which then impacts the IFC model.
06:23You have to think about the way that players interact with the cargo, whether that's physically or on a kiosk.
06:29So you have to figure out all the subsystems behind the kiosk in order to understand how you're going to
06:34utilize cargo,
06:35whether it's in your ship or in your hangar, wherever it's going to end up being.
06:38Breaking that out even further, we need to know what the specific actions are and interactions are available for cargo.
06:44Can you walk into your cargo bay, pick something up and take it out?
06:46That's another piece of work that we need to schedule.
06:49There's other things that need to be taken into account too.
06:51How does the ship fly with cargo?
06:53How much cargo can a ship have?
06:54What types of cargo are available?
06:56What happens if you damage cargo?
06:58Then you need to consider all the things that interface with cargo.
07:00Can you buy cargo?
07:01Can you sell cargo?
07:02How?
07:03Where?
07:04Then there's the slightly more esoteric elements of cargo.
07:06How do we manage cargo if I, say, take a piece of cargo out of a ship and I leave
07:11it on a planet?
07:11Is it there for a day, a month, a year, forever?
07:14We need to take all of these into consideration.
07:16Each individual component that touches each other feature.
07:20So one feature isn't just cargo.
07:23It's cargo, cargo's sound effects, cargo's user interface, cargo interacting with inventory, cargo interacting with everything else in the entire
07:30world.
07:31So design basically fleshes out a concept a bit further.
07:34And then our engineering team works on a TDD or a technical design doc for the implementation in conjunction with
07:40the appropriate disciplines and director input.
07:42And so then we take each one of these tasks.
07:46We take each one of these work items and their subtasks.
07:49And they're all collected underneath their particular epics and group of epics in this feature area.
07:54And then these features are all collected into their grand feature plans and feature sprints.
07:59The whole point of a sprint is to get cross-disciplinary work working together in tandem to make decisions together.
08:04It involves multiple people from across the studio.
08:07No one team can simply generate a feature in a vacuum.
08:10I can't create sound effects with the team that I've got here in Los Angeles.
08:14I need the sound effects guys in the UK.
08:16I can't do zone system mechanics or change fundamental engine physics.
08:20I need the guys in Germany for that.
08:22There's team members across the globe who have to have a say, if not an actual direct contribution, to all
08:29of these major features.
08:30So when you see that bar that says cargo, it's broken down into an amazing amount of sub-features that
08:37have in itself each individual discipline in JIRA's tasks.
08:40And all of this then stacks back up one piece at a time into this large master schedule, this huge
08:47culmination of all the work that's being done,
08:49all the work that's being planned across the entire schedule and company.
08:53So each of those individual sub-features or sub-components of cargo impact cargo, which ultimately impact every other large
09:00-term feature,
09:01which then ultimately impact the overall schedule and when we can deliver it.
09:04If everything goes absolutely perfectly, there's no problems, no bugs, things don't change, and that in real life doesn't ever
09:13really happen.
09:13As you're working on it, you might find areas that cause it to take a little bit longer, and we
09:18adjust bids moving forward.
09:19We utilize Microsoft Project, no matter what database you use to manage your tasks, we try to use that as
09:25the main hub.
09:25So there's several ways that you can populate Microsoft Project with what we do a lot of our work in
09:31JIRA.
09:31Actually, our PU engineering director, Paul Reindell, did some amazing Visual Basic Scripting for us,
09:36and actually he allowed us to make it so we could pull JIRA tasks in per epoch into projects, so
09:42we can do all of our massive scheduling.
09:43Once we do all that scheduling in our per-discipline or per-feature, those all feed up into the grander
09:48schedule that can pull from each of them through a really cool feature in Microsoft Project.
09:52What I will say is that no matter what, there's always that unknown, and that's why it's when we're planning
09:57these schedules,
09:58it's the collaboration I find that really helps the challenge.
10:02That collaboration is production, working with their directors and their leads.
10:07Well, you know, the interesting thing about scheduling is they're living entities.
10:10You can't just say, oh, we've made a schedule, we're done.
10:13It's, oh, we made a schedule, now we can start.
10:15With something the size of the Persistent Universe and Crusader, the first thing you do is you set down what
10:20you think you can accomplish,
10:22and then you get a reality check.
10:24Moving from our current version of Star Citizen into the new version, there's quite a few hurdles
10:32because we're going to put people into a bunch of new systems that didn't exist before.
10:37That in itself is quite a technical hurdle.
10:39How's all that going to work when we put everything, we merge it all together,
10:42and you are doing this seamless transition with all these new systems in play.
10:45The moment you add in any kind of new feature or new system, it does always introduce new bugs.
10:49Of all of the planning, estimating bugs is really the most difficult because there's so many variables,
10:53so many things could be involved in a bug.
10:55It introduces so many new unknowns that we have to plan for these unknowns.
10:59The sprint system, or again, the two-week sprint, allows us to kind of iterate quickly and go,
11:02hey, I had no idea that was going to break all of this stuff, did you?
11:05Nope. I wish we would have thought of that, but we've never done this this way,
11:08so let's, you know, we've got to iterate through those bugs as we go.
11:10You know, a wall doesn't look right.
11:12That could be in the shader, that could be in the graphics, that could be in the graphics card driver.
11:18It could be in the assets and how they're laid out.
11:20It could be in the design, or it could be pure gameplay engineering where we set up a busy area
11:24wrong.
11:25So bugs are the hardest to schedule.
11:27It can be complicated because everybody has their own schedule.
11:30Everybody has their own specific dependencies.
11:33We do work closely with the other departments just to make sure that our schedule aligns with theirs.
11:37And all of these tasks will be completed by one of or by multiple departments,
11:42such as tech design, LA engineering, PU engineering, S-42 engineering, characters, ships, tech art, environments, concepts, quality assurance.
11:54Well, they won't be completed it, but they'll be doing bug testing on it.
11:56And all of these different departments and disciplines, there's none of them that work independent.
12:00There's parts of their work they can do independently, but most of them work across multiple studios,
12:05across multiple regions, and they all impact each other for better or for worse.
12:08And of course, not all pipelines are the same.
12:09Weapons Pipeline is a very traditional content pipeline.
12:12So what we create is a piece of content that's a weapon.
12:15It's a fairly contained piece of art.
12:18There's a lot less unknowns than, for example, when we talk about AI.
12:24So building a game this size, which has never been done before, really bears a lot of unknowns for us
12:30and for AI systems.
12:32If we don't know how we need to break down a goal into tasks, or if we don't know yet
12:37how we need to build a system,
12:39we really need to start with prototyping and research.
12:42Unfortunately, this takes a lot of time, but we really want to make sure we build the best we can.
12:47Actually scheduling the code has always been notoriously difficult.
12:51There's several factors involved with that.
12:53As soon as we know a goal that we formulated is probably not going to be met,
12:58we start communicating to the directors so they know the goals they set will not be met,
13:04and they are informed of what the reasons are.
13:07It's nobody's fault and there's no problem.
13:09We just need to figure out how to move forward.
13:12One of the problems we have is competing to mountains.
13:17We've got a finite resource of programmers.
13:20Sometimes you just can't throw extra resources at something.
13:23Imagine you've got two artists working on a ship, or three artists even.
13:26You can't just add another three artists on one small ship.
13:30You don't want to throw too many cooks in, or even too many makers trying to actually just piece something
13:34together.
13:35So figuring out when do they have time and do we have the bandwidth is where the complexities then come
13:41in.
13:41We've got an animation programmer, for example, so he's actually highly in demand.
13:45So you've got this one resource, and then it's really a case of prioritizing what work he needs to do
13:53on the different features.
13:54I think on the production side, the hardest part is definitely dealing with making sure that we're delivering the right
14:01features at the right time.
14:03From there, you know, you have to consider things like dependencies.
14:05Like, let's say this track view is a really great example.
14:08Well, until we get that track view feature all the way done and complete for the cinematic guys, the cinematic
14:12guys can't do all of their work.
14:14You basically build a schedule, best case, you put in allowances, you put in time for anything you can take
14:19for bug fixing and so forth.
14:21And then what you do is you then go through and on a daily level you track it and you
14:24basically go back to everybody and say, how's this going and so forth.
14:27Sometimes the dates push, some things get done, some things we pull in early.
14:30You know, typically early is, you know, rare in this industry, but, you know, sometimes it happens and then we
14:36definitely give the information out.
14:38And if you have that information, you know, on a daily basis, then you can make calls very quickly if
14:42you're not tracking it as well and then you don't get information for a week or two.
14:46And then all of a sudden you find out, you know, something's not going to work, that's not great because
14:49then you can't fix it.
14:51Every time I look at our feature list and I look at what we're planning to do, you are just
14:56taken aback, to be honest.
14:57I think that's the encouraging thing about it, that we're always trying to push boundaries.
15:02With that comes those huge challenges, right?
15:06And I think you always want to be able to say, okay, I've got a plan and we're ready.
15:11So for a project this size, it's really a challenge to align the resources globally.
15:15In this global schedule, we try and stack the order in which we're going to work on tasks.
15:21The biggest challenge with working internationally is just making sure that the teams that are doing the work for us
15:27get feedback from us in a timely manner.
15:29So we get a really good look at where things are going to come in, in sort of linear order.
15:34So we can say, oh well, you know, in this time we expect to do some of these bugs and
15:38we expect to deliver these features and these tasks for these features as well.
15:41It's really about balancing that time difference so that they have everything they need before they start their day and
15:47they're not waiting on us for anything.
15:49There's no way to, in a detailed, granular way, plan out a full project because there's so many unknowns in
15:56game development.
15:56The schedule is never done.
15:58It's always changing, always being amended.
16:01It's just the nature of the business.
16:03It's the nature of the unknown.
16:07Because a lot of things we're doing on Star Citizen is just truly groundbreaking.
16:10You just don't have a precedent for it.
16:12In certain game studios that aren't as front-facing as we are, you know, this kind of thing happens all
16:17the time, but you just don't see it.
16:19The crowdfunding nature of our project, people can see.
16:21People see that all the time when that kind of stuff happens.
16:24We have about, conveniently, 42 actual Microsoft project schedules that we maintain across all five studios.
16:32Each of those schedules not only has the high-level understanding of what those disciplines are doing, but it has
16:39each of those disciplines broken down into individual tasks.
16:43So when we make a schedule, we have a couple databases.
16:46We track our tasks down to the micro level.
16:48In our JIRA database, in our lifetime, we have closed 76,196 bugs, tasks, subtasks, epics.
16:55We currently have 18,046 currently open.
16:59That's 1,015 epics, 10,797 tasks and subtasks open, and 6,131 bugs that are open.
17:06So the tasks and subtasks at epics were all scheduled and were all planned for.
17:09You do have bug-fixing time, generally, so we do schedule for them.
17:13We don't necessarily know what's going to come, but we do try to schedule and plan for completing everything that
17:17shows up in that database.
17:18When something on our production schedule just shows one individual feature,
17:21What it doesn't show is the data we have in the back end, which tends to be a matrix that's
17:264,000 tasks deep and 4,000 tasks long,
17:29that really makes up this overarching single bar that tells you exactly what we're trying to achieve it.
17:33What it takes to actually do anything that we're trying to do, it takes countless hours of people's time to
17:38not only establish how long should this take or what it would take to do it,
17:41but then doing it and then fixing it, and then we get it out.
17:44I think the important thing is to realize when you don't know the answers yet,
17:48and then to give the team time to find the answers, it's a very important part of game development.
17:55And if you account for it and everybody is on the same page, then it's really not that big a
18:00deal.
18:00It's just when you expect every sprint always has to have a feature at the end and nobody,
18:07like everybody should magically know what they're going to do every day in the sprint,
18:13that you'll run into problems.
18:14In video games development, that's just not realistic.
18:18Individual tasks are rolled up into sprints, which are rolled up into epics or features,
18:23which are rolled up into our detailed schedule.
18:25Just for AI, FPS, or networking, or UI, or graphics, or audio, or engine, or gameplay,
18:31and that's just our engineering team.
18:32We also have ships, characters, props, environments, including planets, landing zones, space stations, etc.
18:38Weapons, cinematics, VFX, audio, both sound and music, design for Squadron 42 and for PU.
18:44We have tech art, tech content, tech design.
18:47All of this is for all the aspects of both Star Citizen and Squadron 42,
18:51which has a schedule that's tracking up to a thousand tasks.
18:54Each one of them are on our up to almost 40 heavy, really heavyweight Microsoft project schedules
18:59that need to ultimately roll up into S42 and 3.0 PU schedules.
19:04We have so much talent that we have recruited to make this game.
19:09It's definitely a challenge to get it all in.
19:13We have a lot planned, and I'm really confident that we'll be able to break everything down and get it
19:19into the game.
19:19This whole huge project is just like an amazing experience for everyone involved.
19:26It's a work in progress, but it's actually a lot of fun for us,
19:29because we get to build something which has never been built before.
Commenti

Consigliato