TL;DRVehicles are assigned to studios by project and available time rather than by manufacturer, usually staying within one local team, with other studios supporting audio and VFX, and work rotated to avoid burnout.
So generally speaking, the way we assign it is no one studio site has any particular manufacturer, but we'll do it by project. Let's say we were going to make, I don't know, the Crusader jalopy. Let's say. So we would figure out how long it was going to take by doing an estimate. Once we had a general estimate we'd see the resources and bandwidth, but generally it would try and stay within a single team, so it would either stay within the Montreal team and the designer of the Montreal team would handle it and the artists would take it through. Obviously not all studios have all the teams that we need, such as audio and VFX, so we'll have to go to a different studio for support for that. But for the actual internal vehicle team, we try to keep them local to the actual studio. So it's a lot easier to work within the same time zone for quick iteration on things. And the UK team, for example, is much bigger than some of the others, so we actually have the vehicle team from an art perspective split into three separate groups to make it easier to manage the different vehicles that are taken through the actual pipeline process. The vehicle team's gotten to the size from an art perspective where we actually need three different art teams within the UK side to do it. But generally speaking, I know that in the past people used to think that the US do all of the RSI ships, I think it was, and the UK do all of the Drake ships, but that was just what was assigned to them at the time. And it'll be like that moving forward. It's whatever time slots we have on different teams. It could be that one team might work on a big ship for 18 months, and a big ship is tiring for 18 months, so then we do smaller projects afterwards and the big ship goes to a different group instead.
Doing back-to-back capital ships is obviously quite... crushing. I think giving people a variety of manufacturers to work on is important. If you're only making Anvil ships for like five years, you're obviously going to get pretty bored of Anvil ships. So I think it is nice that people get the opportunity to work on different manufacturers from an artistic standpoint, like keeping it fresh, challenging yourself with learning new styles basically.
TL;DRPeople have favorite and disliked brands, and varied assignments keep creative staff engaged, while prior experience with a manufacturer helps them ramp up faster, so the team balances variety against skills.
I think you're absolutely right in that. People definitely have favourite brands and people have brands that they just don't particularly like, which is kind of, I guess, life in general. But I think it is super important to challenge people. A lot of people in the creative industry really thrive off of that challenge and reward. So giving people new opportunities to try out new things and get more experience in different fields is super, super important. And ultimately, if you are making the same thing over and over, different ships, but you're always on a particular art style, there is that element of burning people out with that. And all you really get from that is a drop in ideas and a drop in creativity.
The other thing worth mentioning about that is there is a benefit to having experience with a certain manufacturer. If you've worked on a Crusader ship before, you probably understand the style and it's going to take you less time to ramp up and get to know it. So there's certainly a benefit to people having a broad experience and being able to basically say, I've worked on Drake ships, I've worked on Crusader ships. That way, because we are divvying out stuff, it's not like we've got a Drake team or whatever. It's a double-edged sword. It's pros and cons. It's a healthy balance between variety and also making sure that people have the right skills to get the job done.
TL;DRThe team wanted wee-woo lights on the ship but ran out of schedule time, wants them added at some point after other work, and would need better controls for them.
Wee-woo lights, they weren't going to stop it going out. I was pro wee-woo lights. I think we were all pro wee-woo lights. However, I have read some feedback on the discussions over this, and I may be thinking that if we were to do them, we certainly need a better way of controlling them, because I believe that they can be a little bit intrusive if you're trying to be maybe a little bit more stealthy.
Yeah, but if you need to put your headlights on so you can see where you're going... To be clear, we wanted to put them on. It was just a schedule thing. It was a matter of time. We needed to get the ship out.
The exterior needs a bit of a pass anyway, with things like damage and so on as well. There were a couple of things that we wanted to get in for it that we didn't quite manage to get in time. We only had one guy working on it and it was sort of his first project as well.
Well, it's what happens when we do variants of older vehicles. Obviously, to release the vehicle with a new feature, because obviously you've been asking for the Medivac for years, we found a slot where we could get something in to do it, but we didn't have a slot big enough to completely gold standard the base Ursa, because that's what it is, it's a variant of the base Ursa. So that's why the front is still the old-style dashboard; it's not new and updated like the Lynx's is. We have so much time and we get as much done in that time as we can, but at some point it's a case of either nothing goes in that slot or something else goes in that slot, and it was a case of: we could get what we did in, but not everything that we want. We would have loved to do a full gold standard on the Ursa, but that isn't the time slot that we had. And if we did do a full gold standard on the Ursa, we definitely wouldn't have had time to do the Medivac. So it's just about seeing what we have time to fit in the slots that we have.
And I don't want the lack of wee-woo lights to distract from how good a job Harry did on the Medivac. He absolutely smashed it. There's a few things we missed off, but hopefully people will appreciate what was included.
TL;DRThe variants are a mixed case: balancing schedules, bringing older ships up to standard, and giving new staff manageable starter projects, with more variants to come, though not a deliberate turning point.
[On the 'Nursa' nickname] Only heard about that recently. I wish we'd figured it out during the actual development, because we always nickname ships when they're going through development, just because it happens organically with the team. We never came up with Nursa, and I love it.
I think it's mixed, really, because as we've already spoken quite a lot about, it's about that schedule Jenga, or Tetris, that you've got to try and play to get things to work together. It does tie into also bringing ships up to our current standard as well, because a lot of the time, going back and revisiting other ships to bring them up to the current standard, it's not a short amount of time, it's not a short amount of investment that goes into it. The Retaliator is an example. A lot of things have changed since that ship was made, and internally we're like, oh, it's like an onion: you take one layer off, you're like, oh, we need to do... okay, that layer comes off, you're like, oh no, that means we need to do that. And before you know it, you're almost back to square one.
Yeah, but you want to retain some of its original character as well. You don't want to go in there and make a Mark II. You want to build on it. But sorry, with the variants: if we're bringing stuff up to current standards and we're making a variant at the same time, it becomes a little bit easier, because you get more from the same one. Like I think you were saying earlier, when people have got into that particular zone for that particular vehicle or art style, whatever it is, it's quicker.
So I think we are getting a little bit more for our money by doing it that way. We'll often see a post or we'll be chatting and we'll be like, oh, it'd be great if we did... a Crusader jalopy, or a Cutter bounty hunting ship or whatever it is. There's lots of things that we talk around between ourselves because we're like, oh, that'd be super cool. And sometimes those things are, oh, actually, that'd be super cool and it fits. And sometimes it's, oh, that'd be super cool, we'll put it in the bank of ideas that we could do when we get time, when we get to it. But it's a big balancing act between what the game needs, what we want to do as a team, and what we're asked to do from other departments.
Variants are a great sort of new starter task as well, as their first real meaty project. We talked about this briefly at CitizenCon, that we had lost a lot of people from the team over the last year and we've been rebuilding. So Montreal, their first task was the two Cutter variants. The Nursa was someone's first project. Same for the Firebird, and then there will be more. And again, they're great things to... Here's an existing ship. You can see how it all works. We want you to change X, Y, Z. You get to see the whole process, get something out the door, and then you're ready for the next big thing start to finish. So Montreal did the Cutters and then went on to the Zeuses. So the Zeuses will be their first full start to finish, but they ramped up with the Cutters.
I would just add to that that it's great when the ship's fairly up to date. The gold standard passes tend to require a significant amount of weird CIG knowledge, I guess I would call it. You need a lot of understanding of how our systems work, just understanding really the in-depth stuff of the ship and how to take it apart and put it back together, right? Newer stuff, you've got a fresh start, I guess, or at least something more tidy to work with, more up to date with our current standards. So you're building upon something that's already quite polished. Whereas if you're taking something that's quite old, the standards have changed, the way we do things has changed, and you have to know the good practices to recognize the bad practice.
To be honest, even AAA games now take years and years. So it's not even like our life cycle is particularly long compared to a lot of other games that are a third or quarter of the scale of what we do. But a lot of the time you develop pipelines and processes and you lock that in. You get to a certain point in that game development and you lock it in and go, right, this is it, we're finishing it. Whereas obviously with our game, we have the luxury of constantly evolving our tech and our pipeline processes, and you can hopefully see the improvements with the latest patch as some of that stuff's come online. It really makes a massive difference to our player base. So we absolutely want to be at that cutting edge of making the best we can. So our processes do change, our quality standards change, our visual detail levels change. And yeah, we're always trying to push that stuff forward.
TL;DRThe Polaris will be fully flight ready and released to backers at IAE this year, not at 4.0, with just under half the UK art team working on its interior.
It will come out at IAE. Also, massive shout out to all the interior guys as well, because we've got a whole other bunch of artists that are smashing the interior. It's not at the level where we wanted to show it yet, but yeah, they are plowing through that work and it's going to be great.
TL;DRMark Gibson says quantum drives aren't too big for snubs; snubs are deliberately small, cheaper to run and fill a different role than fighters, so each ship should be the right tool for the job.
I don't think it's that they're too big. Snubs play a very particular role within the game. They're not designed to be used the same as fighters, but that's why fighters are bigger than snubs. They're supposed to be as small as possible to be able to take them into much smaller environments, and they're cheaper to operate, maintain and run because you don't have to have everything to support the quantum drive. Well, not disposable, because I mean there's a person inside of it. It's cheaper. It's the same conversation I've had with people in the past where they're like, oh, well, why would you not just use the best ship to do something, by best being the biggest ship, whatever. If I was doing a pizza delivery in my local neighbourhood, I'm not going to do that pizza delivery in a tank, because the fuel costs, right? But if I'm doing it in a much more dangerous environment, I'm not going to do it in a little Vespa, I might do it in a vehicle, right? So it's about bringing the right tool for the job. So once again, snubs, they serve a particular purpose and role within the universe. They're not designed to compete on the same level as fighters at everything, but that's why fighter is its own category compared to snub fighters.
Well, it'll be cheaper in the Caterpillar than the Kraken because we're talking capital-grade components, and the maintenance of them will be much, much higher. Granted, it's not something people massively have to worry about at the minute, but eventually you're going to have to repair them, and it's all the costs and fuel to operate. It's going to get much worse.
TL;DRThe panel recalls the Mule being debated as Drake versus another manufacturer, and the Vulcan drifting from Anvil, noting that designers shifting mindset between brands sometimes pulls ships toward other manufacturers.
Mule. Mule's an easy one. Kind of split the vote a little bit, didn't it? I think the functionality of the Mule leads more to Drake than necessarily... it is quite a high-end vehicle for Drake. It feels a little bit more refined, but a lot of the inspiration for the Mule came from what we see now in tractors and combine harvesters and that sort of thing. And they are very purpose-built, so they kind of tick that brief, but they are just a little bit nicer.
Yeah, if you look at the interior, the interior is all sort of moulded plastics, whereas if you look at the interior of some of our Drake spaceships, they're...
The Vulcan concept was Anvil for probably 80% of its concept development, and then it got towards the end and we're like, it's sort of not particularly Anvil-y anymore. It's getting towards Aegis, and then the whole cockpit bit of it changed to be more like the front of the Reclaimer.
Well, the big dirty secret is that there aren't 15 different manufacturers making all these. It's the people at this table who are making them. And so you've got to put your brain in, okay, I've got to put my brain in Drake mode, I've got to put my brain in Crusader mode. And sometimes the brain just doesn't want to do what you want it to do, and it will push you towards whatever these other manufacturers are. And occasionally that leads you to invent new manufacturers, when your brain just wants to do something completely different.
I remember just before I moved on to the Fury, I'd spent a little bit of time on the Corsair helping Lodit, and my entire visual library was just Drake. And then it's like, now you're doing a MISC racing ship that's kind of Mirai performance kind of thing. We weren't really sure which direction it was going to go then. And every time I modelled anything, I went square. I went big bolt, and Ben was like, no, rivets, metal, like chrome. I was like, okay. And every mechanism was more Drake-y until I remembered the direction of it.
TL;DRThe new Montreal team is not dedicated to a ship type; they are being onboarded on backlog ships and variants, with bigger ships planned for later once experienced.
I think it's a really dangerous thing to get into if you have multiple teams and you're like, oh, you're the A team and you're the B team, or you're team this and you're team that. And it's not a case of that. The way we prioritise our ships is we get our ship priority, and that comes from John and the execs and all the important people. And then we look at what resources we have and what people are best fitted for, and then we allocate work that we feel confident that people can achieve. If we had a new team come in and we're like, hey, we've got some capital ships for you, here you go, you're not setting that team up to succeed. You're just setting it up to fail. Realistically, our big capital ships take a sizable team to deliver. So yeah, initially we're getting them on board to help fill out some of our backlog ships, help do some variants of existing ships. At the moment we're just trying to, like I say, onboard them. They've been going for... April 1st is when they officially started.
And they're getting up to speed, they're doing a fantastic job of learning the ropes and understanding our processes and pipelines, working through a few ships that will be coming out at some point, and then we'll put them on something bigger.
That's the other thing, they're a brand new team, they're not massive. It's not like they're anywhere near the size of the UK ship team. If I remember correctly, it's three artists, one designer. Is it four artists, maybe?
Four, technically. Four artists, technically, but one's in the UK at the moment. And one designer, who was here for the last three weeks doing his onboarding. He's literally on a plane now back to Canada to carry on with those guys when he gets there.
And when you get a brand new team like that, it's not even just them learning how we do things, because obviously every team does it differently. The way you build an environment isn't the way you build a ship, and the quality and the techniques and everything are massively different. So if you've got a brand new team coming in, you're not going to throw them on a ship that's going to take them, for argument's sake, the next 18 months to develop, because the quality in their work over that 18 months, from when they first start to when they get towards the end, is going to massively change. With the larger ships, you need people who are more experienced, who are already embedded within the pipeline, because otherwise you're going to have such an inconsistent experience across the actual ship.
Small ships can be complicated, big ships are complicated. It's all fairly complicated stuff. But like I say, when you get to a capital ship, there's a lot of unknowns there. We've got Jason, who's come across from the environment art team, and he's got a whole wealth of knowledge on building environment assets and building out those kits. So he's got a huge amount of knowledge that we can lean on for building out our capital ships. But yeah, like I say, sticking someone on something for a year and a half when, initially, you want to get a few under your belt, learn the processes, touch lots of different areas of the ships, do interiors, exteriors, and just learn everything.
I think another point as well is that in general for interiors, at least, the quality of what we receive in pre-production is generally spread a little bit thinner. So the interior concepts for capital ships are generally key art and some fairly vague interior spaces. So the production team has to do a lot more of the exploration, whereas if you have a smaller ship, generally the interior concept's a lot stronger, because there's just fewer things to work on, right? You get a lot more detail, a lot more to work from. So yeah, definitely, coming into production, you have fewer things to figure out on smaller ships.
The other thing is with the capital ships, once we actually put them in, we want to try and build them in a way that makes it easier to then do the other ships of that exact same manufacturer. So once we do one RSI, we want to set ourselves up so that we can roll into the others a lot easier. So instead of having to reinvent the wheel every time, we have stuff as a foundation to just move it forward quicker.
TL;DRWork on the Hull C solved the last technical hurdle for ship modularity, so nothing technically blocks it now, though priorities and team building still matter.
So with the development of the Hull C, we've pretty much figured out the last hurdle. In fact, Chris is responsible for the test that I got him to do for it, where we can have object containers, which is the interior collection of assets, loaded as an item, loaded onto the ship, because that's how the rear of the Hull C is attached to the ship and moves with it. What had stopped us technically going any further with this was that items inside those object containers couldn't talk to the vehicle they were connected to. So the example of the Retaliator: the torpedo droppy arms, they're actually part of the exterior of the ship currently, because that's the only way they can work. So if we allowed you to swap the modules, no matter what module you had, there'd be a pair of torpedo arms dangling through the middle of it. Chris did a test where he attached a load of missile racks and torpedoes to the inside of the back of the Hull C, which is not going to ship with it.
Yeah, there is a shelf that says 'do not submit' in very large letters. And the pilot had full control of that, and they could fire them. So after the Hull C ships and we've found any more quirks with that setup, we're in a position where, to my knowledge, touch wood, technically there's nothing stopping us doing modularity now. That was the last big hurdle for it.
TL;DRPhysicalized damage is under heavy active development as part of a broader destructible-physics system called Maelstrom, though it won't necessarily be applied to every element of the game.
So it is really under heavy active development at the moment. The physics team have done a lot of work in the last six months on it. We're now at a point where other feature and gameplay teams have joined them to work out the quirks with it. The vehicle content team have provided assets of ships set up in this new way of doing things. I should caveat this: it's not a vehicle thing. It's an everything thing. Every destructible system in the game will use this. So whilst everyone uses the vehicle example of bullets going through ships, it replaces the prop breakable system, it replaces the environment breakable system, it replaces the vehicle damage system. There's another one I forget. So environment teams, prop teams, vehicle teams, we're all working on this at the moment, with a bunch of use case scenarios that are with the engineers.
But it's more than just the physicalized damage for ships. It is a global destructible physics system. We're not going to sit here and commit to it being applied to every single element of Star Citizen. There's always going to be performance considerations. But you develop the system, and then you start to see where you can plug it in and apply it.
TL;DRShip tractor beams are set up and working on several vehicles in the development environment, with some work remaining from another team, and sizes have moved to component sizing.
So the ship tractor beams, we've done a lot of work for them recently. We have the current implementation set up on multiple vehicles that are meant to actually have the tractor beam attached to them. The current implementation works from a vehicle setup standpoint. There's still some remaining work to do from the actual EU PU team. They're actually delivering the vehicle tractor beams themselves. But right now, in the environment we've developed it in, you can spawn the ships that have them in and use them. Another big bit of confusion is the sizing. When we did some of it, we did it to weapon sizes instead of component sizes, whereas EU PU have done their development on it, and they've decided they want to go in the direction of component sizing rather than weapon sizing. Some of the size numbers will have changed, but how much they lift is consistent with how much we've always wanted it to lift. So, for example, instead of going all the way up to, I think the biggest one we ever said was size six or size five or something, the biggest one now will be the size three. We might do size four if we ever do something for a very niche situation.
The SRV is a three, but three is able to move ships. Size twos can do 32 SCU containers. I can't remember how much size 1s and 0s do, but we've just reformatted it as the system's formalised a lot more. On the ships, we've got an implemented version of it working currently.
As far as the vehicle content team is concerned, we've done a pass on the artwork for ships that were supposed to feature a tractor beam. We've now added supporting geometry for them and made sure that it actually works, basically.
But we've done proper geometry integration for the ones where there just wasn't any, because there wasn't any on the Cutlass, there wasn't any on the 315, there wasn't any on the Nomad, so there's proper integration for them now.
TL;DRGold standard passes will fix component-swapping problems like doors too narrow, but until older ship interiors get that pass some components may not fit, though artists do quick fixes when they can.
A lot of that's what gold standard's for. So when we go through and do gold standards, using the Retaliator as an example, a lot of the components wouldn't fit through the doors of the Retaliator as you tractor beam them out and move them. So the doors and things have been widened so they would actually fit. Another thing is which components are actually meant to be taken out with a tractor beam. Size three and capitals obviously aren't meant to be tractor beamed out. You're supposed to go to a dry dock and someone else will take them out for you, because they're too large of components, because theoretically to get to them you need to cut parts of the hull out, because they're just too large for a person to lift. So size 0, 1 and 2, you should be able to tractor beam out. Doors that don't fit currently, gold standard will address that. But until we do gold standards on the interiors of a lot of the ships, there may be doors where you can't get them out, or places you can't get the components through.
There are a couple of random occasions where, as artists, we get, oh, can you jump on the ship for a half-an-hour fix to allow you to get your components out of your ship. We've got all of the ships divvied up amongst ourselves. So even though people leave and people join, there's the list of all of the ships, and it's like, okay, you're responsible for these. So if there's a component swapping issue on a particular ship, one of mine, I've forgotten which one it was, I had to remove a little bit of the room. Nothing players would really notice, but it's just enough to make the collision a bit more comfortable to move it out. So you get occasions like that where you'll get a random bug come through, and it's like, oh, if you've got a spare 10 minutes to do that, you quickly look at it, you're like, oh yeah, that's a really quick fix that will hopefully make your lives a lot easier. So we do try to. Even though I'm on this ship for X amount of time, I will disappear for an hour or two if it saves you guys the grief. It depends on the amount of work, right? If it's a massive overhaul, obviously that takes... But if I can sneak it in, I'll try.
Some of it's really quick wins, like when the ship was initially modelled, or when someone created the component base, they just forgot to cut a hole in the collision for the components. So it's literally impossible to remove it, because it's behind the collision of the exterior, for example.
I think a lot of our ships were made before there was any feature work that had been done on it, so we didn't know how we were going to tackle it. So we were just making the best decisions we could at the time, and now we know better. So that pipeline has evolved. Some of them are super quick; some of them are like, this door has no animation, it has no mechanics to do the animation, there's just a hole behind it, and they're the ones that take a bit more time. They need a proper art pass, proper design pass.
The Vanguard's a good example, right? It had that little railing, which from that point looked nice, having that little railing as you go up the stairs, where you just cut the railing off. It's a small little thing, easier to do, but at the time when we did it, looking from that standpoint, no one really thought, oh, that railing's going to get in the way of the components, because it wasn't something that people actively thought about.
Same with some of the component hatches that have doors that sort of clamshell open. So they open, it looks nice and cool, and like, yeah, it'll fit out there. And then when it comes to actually taking it out, they're a centimetre not far open enough. So there's all sorts of little things that you don't spot.
And this is the kind of stuff that happens with any video game. It's just usually they don't have a live environment in the middle of their development.
It's just tech debt, really. A feature comes online, it gets proven out, and then we have to reimplement that into a bunch of existing assets. We try our best to anticipate what kind of features will be coming, but we don't necessarily know how a feature will work. So part of the challenge of being a team that's affected by a feature is you have to then retroactively support it. So I think that's a big part of what gold standard is. It's: these are all the features we need to support in our vehicles, and it's basically making those vehicles comply with those features.
We had it with salvage as well, right? It was exactly the same thing, where it was like, oh, there's loads of quick fixes we can do, or, okay, we need to dedicate some time to this. And then when salvage first came online, we had quite a few of us working on it to really try and get that stuff sorted out. And other ships that were made maybe more recently, you go to fix it and you're like, this is fine.
It becomes a part of your validation. It becomes a part of the acceptance criteria for the ship, that it needs to support this feature. So we would bring those features into the review process and basically make sure, if we're making a new ship, it should have physicalized components, et cetera, that all of the features that exist for the ship will be validated as a part of the review process. So it's more the older content that was kind of... when we first started out, we were kind of discovering what a ship was.
The salvage thing was a really good example of how some things you just can't plan for ahead of time. Salvage is coming online. We know it's going to use the UV2 damage system. We've done all that for the ships already, because that's what damage does when you shoot ships. So we're good. And then when it came online, we're like, oh boy, we're not good.
We didn't realise quite how much the visuals would affect the actual data. So the parts of the ship that were slightly [hidden] wouldn't necessarily take as much damage, and it would look fine when you're blowing this thing up. But then it meant that you could never 100% salvage the ship, because you couldn't salvage certain panels. And obviously it just looks a bit weird that you'd be salvaging along and it would just stop.
Yeah, that's what I was talking about before. It's not supposed to tractor vehicles. It's 32 SCU cargo containers, the size 2. So it's getting changed to a size 2, but it's just part of the refactor of the tractor beam sizes.
It doesn't do any less or more than we said it was going to do originally; it's just that the numbering's changed, because we're now doing component grading instead of weapon grading.
TL;DRShutters for the Carrack will be added at some point, but there is no date; it depends on time and priorities, and more work like level of detail passes is needed.
Me, I guess. So, I want to put them on it. I just need to find time to do it. I was told today, after learning of it, because, again, I'm one of the newer members of the team, so I didn't actually know that the Carrack needed these shutters and stuff. That's for these guys, who know it inside and out, to tell me. So I was informed today, because the Carrack's one of the ships I look after. It's like, oh, Dan, if you get time, you know you can put the blast shields on the Carrack. And I was like, oh, and you're going to say it on live as well now. I'm going to get bombarded on Twitter until it's done. I will try for you guys, but yeah, it's just a case of time. Dan doesn't dictate his own priorities. When we talk about when you jump on, it kind of comes back to the salvage stuff or the tractor beaming of components. If I look at it and I go, oh, that's a quick fix, it'll be a quick thing. But if I look at it and I'm like, that is not a quick thing, I need to ask for some time because it will affect my other work, then it becomes a wider thing.
You can have a look at it and see how much work it is, and if the file's already been set up, all the animation data's there, it's all ready to go, and it's just a case of we just need to export it and do it, then cool. But if it's going to take you away, and you'll be on the Carrack for a week or two, then...
When the Carrack was developed, we did prove that... We made sure it would work, but that's it. What I'm saying is we just proved out the spacing, the animation mechanism and stuff. It's going to need UV2s, it's going to need LODs, it's going to need more detail, all that stuff.
TL;DRThe Banu Merchantman is deferred because its fully unique, non-reusable art and the loss of experienced staff make it a poor use of time now, so they will do other capital ships first and return to it.
I don't know what you're talking about. So we'll talk about the Merchantman briefly, because we discussed how we want to do the backlog of capital ships. So we want to start with RSI, because doing the Polaris first helps reduce the amount of work needed for the Perseus and the Galaxy. So those three will likely be a chain of dependencies from each other.
Yeah, there's a lot of shared assets between them. Obviously, the exteriors are quite different, but you do an RSI hull kit or corridor kit, floor kit, doors, beds, and it all gets reused across them, maybe with some slight material differences. So there are a few things that are problematic with the BMM. Firstly, everything is unique. So it's not like we do one corridor kit.
So yeah, we had a lot of people on there. We had some unfortunate people leaving who'd been here quite a while, so we'd lost a lot of that team knowledge, and part of it is rebuilding the team. Obviously, again, like we said, you don't get new staff members and go, hey, welcome to the Banu Merchantman, here's a completely bespoke thing that does not follow any of our existing art guidelines. And all the time we would have put into that would be just for that ship. We get no reuse from it. So yes, we will do it again. But personally, I think the time is better spent on other capital ships, to get people up to speed, and then we can start putting people back on it.
Yeah, there's definitely a lot of love within the team for the Merch. I think there's a lot of excitement there for it. It's just making sure that, again, like we said, the team's set up to succeed with it, and we can actually deliver it to the standards that we expect.
Can you imagine training new people on developing a brand new art style for a ship? I genuinely think the Merchantman is going to be one of the hardest ships we ever do, just because of all the additional factors involved: the scale of it, the fact that nothing is really reused, it's all unique moulded, all the rooms, all the floors, it's that cool art style.
It's a different style of modelling as well, right? In terms of our actual discipline of how we make ships. It's more like traditional vehicle modelling than it would be hard surface. It's hard surface meets organic, and it's weird.
We'd worked on that process, and we had a good process in place, and it was just unfortunate that they chose to go off and chase new adventures, and we wish them the best of luck, and it was a big loss to the team. That initial pre-production was done and it's there. We just need to get to the point where we can still deliver our current line-up of ships we want to deliver, and we want to be able to do it justice. It just takes a bit of time.
We're constantly supporting other feature teams. There's a lot of work for the tractor beam, there's a lot of work for salvage, other features coming online that we have to support, and all of them are time. Lots of time investment from our side to actually implement them in the ships.
TL;DRA good ship can look ugly or brutal if its looks follow its function, but each manufacturer should keep a recognisable identity, with sleekness suited to role, such as workhorses versus fighters.
It can be ugly, in a sense, right? Brutal industrial, right? I think that can be iconic. That can look good, right? I think it's led by its function, isn't it?
If you've got something that is a big workhorse, an Argo ship, you don't expect it to be super sleek and organic. Whereas if you've got something that's a fighter or something that's like a racing ship or something, you want it to look sleek and feel believable.
I feel when it comes to our project, it's really important that our manufacturers don't merge into one. Our manufacturers have their identity. And then within that, you've got a subclass of what the functionality is. If we were doing, like I say, an industrial ship that was made by Origin, you wouldn't expect it to be like an 890 with a laser beam in front of it. But you would immediately want to recognise its Origin still. It's fine for it to be industrial, civilian, combat, all having a very obvious direction that the visuals go, but at the same time you still want all of the manufacturers to immediately be recognisable from each other.
You mentioned things changing, and it is changing, and it's the perfect group of people, because Mark and Corey have literally, the last month or so, been working on updates for it. So completely unprompted, I'll throw it over to you two.
The biggest changes are more of a focus on an actual planning phase between pre-production and production. So we've actually defined planning as an individual thing, so we have to go away and estimate it. We've been looking at how we estimate how long it takes to do this stuff. Actually getting the team more involved. We're basically grabbing everyone, doing planning poker, which is kind of fun and a weird thing, but it works surprisingly well. We've rolled out a couple of new...
TL;DRPlanning poker is a team estimation method where members privately pick time or complexity values, reveal them together and discuss differences, which gives the ship team more accurate estimates and lets them adjust scope to fit available time.
I should have brought the cards. I used to manage the prop team, and I've recently transitioned over to ships, so that's why I'm here with these people now. So basically, I mean, it's probably not the most legit. I'm sure there are agile development experts out there who would shake their heads at how I do planning poker. Basically, you have a stack of cards. It's got numbers on it that represent values. I tend to just do it in days because art tasks are pretty easy to break down in days. But if you're doing more nebulous things, you can use a point system. It's kind of weird. I don't really like that. I like days as a measurement. Do you guys use story points for stuff?
We use points, yeah. The only difference really is, as you said, art is pretty straightforward and easy to estimate how long something might take, but engineering tasks tend to have all of this R&D and experimentation work, and it's very hard to guess. So we tend to quantify things in terms of the complexity rather than the time.
It's like a consensus on how crazy what you're asking someone to do is, right? It's not necessarily saying this is six months of crazy, it's saying this is 30 crazy, right?
So you could probably derive an estimate from that, but it's a bit different. Anyway, so that's a bit of a tangent. But basically, so you have these cards, they've got values on them. Everyone has their cards face down. And you say, OK, so we're going to look at how long do you guys think it will take to do the white box pass for the exterior of the ship, for example. And everyone will have a little think. They'll select their card. And then you say, show your cards. Everyone presents their card. And you basically look and see if everyone's got a consensus on how long it's going to take or if there's a massive deviance. And if there is, you say, Henry, you said it's going to take you 20 days to do this task. But John said it's going to take 10. Why is it going to take you twice as long? And then you might say, well, here's a bunch of things that John didn't think about. And then John might go, oh, OK. Or he might say, Henry, pull your finger out, mate. Come on. But basically, the point is that you've got the people working on a task, and you're trying to reach a consensus. It does take a bit of time as well.
I think in the past what we've tended to do is we've tended to do this on a ship scale. So we've basically looked at a ship as a whole and kind of gone, okay, well, we know another ship of roughly this size and this complexity, with a really well known art style or a completely unknown art style. We've kind of broken it down that way. Whereas what this allows us to do is the team to have more input into that. And also because the complexity of our ships has grown so much over the years, it's no longer a case of, oh, here's a small single seater and all small single seaters take X amount of time, because some of them have one wing that you can just mirror around. Other ones have completely unique parts and completely unique functionality. And it just allows us to get a better understanding of how long we think things are going to take and because of that, hit our targets better.
Compared to how we used to do it, it used to be at a high level, leads and directors would say, it's roughly going to take this long as a best-guess ballpark. Sometimes it's been so long since we've been actively doing some of the things that our estimates have fallen short, or new tech's made it more complicated or easier. So we don't have as accurate an idea of it anymore compared to the people who are doing it day in, day out. So we've had a couple of ships go through this process now and the estimates we've got from doing this have been almost to the day correct. And with some of them we underestimated the whole scope and cut back what we were going to do because we knew it wouldn't fit because of the better estimates, and everything got as much attention as it deserved, and we now know we just need to go back and revisit something else later, but we also know how much time that's going to take so we can plan for it better.
Yeah, we can adapt the scope of a project to the time we have, basically, because we have a better idea of how long each individual thing's going to take. So we can say, right, we've got 30 days. All this is going to take 40 days. Ben, what are you willing to cut? And then Ben will say, well, this task is 10 days, so we'll cut that. Better planning.
TL;DREvery ship goes from a one-line idea to a design brief, director sign-off, detailed concept, planning, then white box to test it works and grey box for most modelling, with reviews at each phase.
So TLDR, as we start out, John and his design team come up with the idea of, we want a ship to do this role and deliver this, and then I think you normally sit around, you pitch it to people, don't you?
We have the very high level, like one sentence: I want a space food truck van. We use that as an example for this. And it has to be Drake. And either I've come up with that or I've got it from Chris or Todd or Tony or someone like that. I give that to a designer and they flesh it out into the full brief. That goes back around all the design leads because there's a lot of design teams and they're all working on slightly different things. They all may have slightly different ideas; the designer who did that vehicle brief may not be aware of, say, what EU PU is going to be working on in nine months' time, which may have an effect. So they all have their feedback. We update the brief, it goes to Chris for the final sign-off, and then it goes into the concept phase. Pretty much unchanged.
But we spend a lot more time on the concept to make sure that everything is going to work now. So we do the interiors fully fleshed out to make sure that everything that's going to fit inside the ship actually fits inside the ship. And with the extra complexity we've now got, there's so much more to consider during the concept phase.
It would also be worth adding to this point, obviously I'm not the most knowledgeable about the concept pipeline, but I am aware that concept is literally not just drawing a picture. I know you mock up the geometry of a ship and the general shape and everything. So you have a reasonably clear idea of what it's going to look like.
It's much easier to make changes and to invest time when it's in concept than it is when you get into production. Because in concept you've got one artist working on it and it's fairly easy to course correct. Whereas by the time you're into production, you've got an art team invested in it, plus all the downstream teams and design and everything. It's a much slower shift.
And you've got to worry about performance and actually having it work and stuff. Whereas in concept, it's a visual representation of it. So it doesn't matter if you look at the geometry and it's really jank, because we've got a whole team of production artists to basically convert a concept mesh into something that actually goes in a video game and runs, right? And looks good.
And looks good. So concept's complete, we then do proper planning. Planning phase. And then it gets scheduled. I'm still learning the new production. And then into white box, which is basically, we do a fairly quick breakdown of the ship and all the parts that need to be in it and get it into engine as quickly as we can, just to allow us to run around it, make sure that what we think works visually actually works from a gameplay point of view, and make sure it flies, make sure thrust is in the right position.
At the end of each phase we have a review process where we sit down with everyone, get everyone in a room and make sure we're all happy with it. White box is basically: make it work. We don't really care what it looks like at that point. It's about making sure that we know what we're doing and it's all going to work. And then into grey box is where we do most of the modeling, most of the artwork.
TL;DRAfter grey box comes LOD Zero, a new phase split out of Final Art so audio, VFX and tech art teams can start earlier and the ship is signed off sooner, preventing late changes.
LOD Zero. So it used to be that Final Art would be the next phase we moved on to, but we found that the amount of things that got put into Final Art from an art perspective was so vast that having it all as one phase meant a lot of things bled over into each other, and it had a knock-on for other downstream teams like the audio team, the VFX team.
And TechArt, because theoretically they could get involved in doing their work earlier, but they didn't know when certain criteria had been met. So we drew a new line down Final Art and split it into LOD Zero and Final, so that basically the end of LOD Zero is when the other teams can then start getting involved and doing more of their work, and it just means they don't have to get involved immediately.
It was a very polite way of basically these two making sure that I don't make changes right at the last minute. It makes us sign the ship off at the earliest possible opportunity so that it can unlock other people to do their work. And I can't come in at the last minute and be like, oh, do you know what? Can we just move that wall just a little bit?