Rainer Ricq

That's where staggered development comes into play, and that's where having a team of, including Turbulent, around a thousand people between our five collective studios comes in. Not everybody works on everything at every given moment. There are teams dedicated to Pyro and there are teams dedicated to the underground facilities, there are teams dedicated to Lorville, there are teams dedicated to this, just like there are teams dedicated to the platform fixes and the stuff that's going on there. And that all exists that way because, well, what's the common analogy? Nine doctors don't deliver a baby in one month. There's an inflection point in developing any feature where adding more people to it doesn't make it any faster, it doesn't make it any better. And you don't want any one thing to become a roadblock or to become a bottleneck to other things. Sometimes it's unavoidable. But for the most part, you try to avoid that by having this team on this, and this team on this, and this team on this, so that if something pushes, everything else behind it doesn't have to knock on. There are always going to be dependencies and stuff. And like I said, the only constant in game development is change. But the idea, and it works out this way more times than not, is that by having these staggered teams all working on different things simultaneously, we can continue to deliver content to players at a steady pace.

Because if we're all on Pyro, there would have been no Ghost Hollow, no 600i crash site.

And even when, Nemanja, you said, "I just started on building interiors," that was you having moved on to building interiors. Obviously, we've shown work of other folks already starting on building interiors.

So talking about Pyro, I'm also supporting a team, if they need, for the derelict settlements. So for example, we're using the Raastar tool to create those, and we're building right now the library of all our modules to create the settlements in Stanton. But every single module that we create for Stanton can also be reused in Pyro. So the work we're doing in Stanton is just making our life easier in the future whenever we get to Pyro. For us, it's going to be a matter of a week or two maybe to create one settlement, max. And then we're going to be able to churn out a lot of those.

Best case scenario.

I actually gave you the worst case scenario, because the Raastar tool is a pretty cool tool. It works well. So two weeks for one settlement.

To follow up on what you said earlier: yeah, Lorville may not be the biggest priority, but that's the point. We overlap things. People on building interiors are already coming in as we're wrapping up and polishing.

And the building interiors work for Lorville applies to buildings in ArcCorp, applies to buildings in Orison and stuff. The underground facilities are designed to be placed within Stanton, they'll also be placed within Pyro, they'll also be placed within other systems.

We're building the foundation for things to be used everywhere. I just want to mention that when we built the space clinics, that was the first project where we got to use the early version of the procedural tool that will now be used for the building interiors. So it was like the proof of concept. So everything has a foundation and a use for the next steps.

We talked about the building interiors, we talked about the underground facilities, even things like the space stations. Even the stations of the Stanton system can serve as the basis for many of the decrepit space stations in Pyro and stuff like that. It's all designed to feed, and that's the whole reason we do as much as we can modularly.

At Turbulent, yeah, but the team is back home.

Oh, even a different team than that?

Yeah. So before I jumped on the UGFs, I did a few settlements, I believe Sean as well. So that was in between things: as the UGFs were getting prepared, before we jumped on that, we were helping out the settlement team. The 600i and the Star Runner on Daymar. But there's still a team right now working, progressing on that, testing out the Raastar tool, as Nemanja was talking about before. So they're using what we built and just adding on to it and trying new variations, new setups.

So a good example is the 600i derelict settlement took us about a couple of months to do, two or three months.

The big one on Daymar?

Yeah. And now we're going to have a variety of those ranging from small, medium to large. I think we're aiming to ship 15 of them. We just passed the white box today. So that shows you the difference in the scale and the speed at which we can work with the Raastar tool compared to doing it by hand, where we did one in three months. Now we're doing 15 in three months.

And the Reclaimer was about six months. So the Reclaimer and the Daymar crash were both mostly hand placed. And once we got the Raastar tool, they've been doing settlements, like you were saying. We have two new Reclaimer ones coming in that are bigger. It also helps that last year we worked a lot on building the library, which they're now using. We really started putting together a formula for that.

Because there was nothing quite like that at the moment, and we started taking things and destroying them. And once you guys finally figured out what you wanted to do with them, now it's going way faster.

We showed a bit of the derelict sandbox, the various degrees, in ISC towards the beginning of this quarter. So the other team, I don't want to speak for the work of other teams, but that team is currently putting together a bunch of settlements and such that's currently scheduled for 3.20, if I'm not mistaken. And we'll actually be filming with them in Montreal for next season of ISC in a couple weeks.

There are some refreshing elements, that's not a good phrase, to ArcCorp coming as part of the new player experience. I think it was recently added to the public roadmap. We'll be talking again more about that next quarter when we come back from hiatus on ISC. The first version of the new player experience is centered around ArcCorp. So that has required some new signage and some updates and stuff. I think folks actually saw a sneak peek in the weekly newsletter a week or two or three ago. That's what that was, with the cool new signage and everything that's being added around ArcCorp. So not the full scale of what's happening with Lorville at the moment. But if there's one thing I've learned about this project in, I hit eight years in like a week, it's never say never. So not today, not tomorrow, but it's possible.

I mean, there are things on ArcCorp that could be touched up, but for the most part, I think ArcCorp's in a pretty great condition. We looked a lot through ArcCorp for Lorville and how they built their formula from a modern, more built city in the game. But for the most part, I think ArcCorp's in great condition.

And the building interiors part was also a big factor in why Lorville had to be redone, just so they could take in those interiors. Some buildings were, like you said before, too small.

Yeah, we had to resize them, scale them up, build them for building interiors.

Yeah, so it's like future-proofing the city.

The thing is, Ian is the art director, and me as assistant, actually, I'm just helping all the team to stay on track, because we have concepts to create our environment. So I'm not going to decide, okay, today we're going to do this or that, because all that has already been decided. So it's just giving support and just being sure that people stay focused on the mandate and where we're going.

And it's seeing the high level, right? Because you have your leads under you who can take care of your team. So Nick is there to do the very high level stuff with me where we can see things coming in advance.

Next mandate. And I'm still giving support. I'm still working in the editor. I'm not just high level and just talking in meetings.

I'm still assigning bugs to you.

Yeah, it's true. Fixing bugs and stuff.

You channel the information, and it trickles down from Ian to Nick, and then to us, the leads, and then to our teams.

QA is the starting point for so many people. We have lead producers who started as QA. We have directors who have started as QA. It's a wonderful entry point for almost any path.

It is, I would go as far as saying it is the best entry point. The best producers, it looks like I'm patting myself on the back here, but the best producers I've known in this industry came from QA. Just because it's so versatile, you have your hands everywhere, you have such a top vision of a project when you work in QA, it's pretty similar. When I made the transition to production, it wasn't that big of a jump. Just because I had visibility on the entirety of the project, how it was going, when the patches were coming out, how many bugs were there, what state the maps were in. And to answer the question of minimum requirements, I just hired a dev QA embedded on my team who has zero experience, but the guy has a good background and he looks hungry to learn. And sometimes it's even better to get people with no experience because...

You have to untrain them.

Exactly. It's a blank slate. They didn't catch any bad habit yet from other places. So sometimes it's a blessing in disguise.

And I guess the will to learn is a huge point. When we hire juniors, when we go through the filtering in the interviews, sometimes it's them showing the willingness to learn. That's a big factor, I find, for selection.

The most important.

I like an inexperienced person with potential a million times more than an old wolf who doesn't really want to prove himself.

Because there's less baggage and bad habits.

And is over it. Because there are a lot of those too.

People that show passion. There are still good old wolves who still want to work and have this fire inside.

Oh, there's a ton of that too. I'm not generalizing, but...

I'm working on the derelict habs. So it'll be habitation pods or even maybe garages or little workshops built from ship pieces. So that's something that we'll be bringing into the following releases, something to dress up the crash sites. So we saw one of the early ones in the Ghost Hollow mission. That was one of the first habs that we made. And we're just adding more of...

Creating this library of...

Yeah, we're creating all the puzzle pieces to just be able to pick and choose then which one we want to spread around the 'verse.

There's all sorts of different functions to these habs, like workshops or maybe just sun barriers or shelters. Cover.

They look great. You guys are going to love it.

Yeah, we'll see those on, I think it's the first ISC back after the new year. We'll have a segment on the new derelict habs and the big asset library zoo that we're creating.

Right now, we're thinking about making more on Stanton because Pyro is not ready yet to create too much stuff on it. So, yeah, we'll say that, but eventually we're going to have a lot of them. It should go to Pyro. Not right now, but soon. For the next year, we'll be more Stanton, but eventually we'll be everywhere.

I mean, I can give you the scoop that we're starting to look at that in Q1.

Yeah, with the use of the Raastar tool and its development, Stanton is basically the testing bed for that tool. They're placing down the new upcoming outposts with it now. And then, yeah, it will, of course, be used for Pyro when that time comes.

And to go with one of your questions, while we were here, actually meeting the guys working with Raastar, that was one of the reasons why we came, to get some training on it and see how it works live. Sometimes training is a bit easier doing it in person rather than over Zoom or Teams.

For folks who maybe don't follow the entire breadth of Star Citizen's development, Pyro can't be added to the Persistent Universe until Server Meshing is in. Server Meshing needs prerequisites like Persistent Entity Streaming coming in 3.18, and these things all take months and months to do. Stanton's not finished. I saw somebody say Stanton is finished, and Stanton's not finished. We're still building Stanton. We're still building Pyro. We're still building Nyx, stuff like this. It goes akin to what John Crewe said, actually it wasn't John Crewe, it was Ben Curtis, in our IAE All Ships Supertalk Spectacular from a couple weeks ago, which was also taken out of context, where they talked about where's the best place to put your work and your effort right now. If you can work right now to put something in the game right now, that's a better use than if you can work to put something in the game six months from now, because you can work next month to put the thing in six months from now. So game development is a constant series of priority shifts and adjustments. The priorities change and shift dramatically during the course of development, but it always prioritizes what can be done now and what can be done next. So as we move closer to the time where, okay, now the underlying systems are in place and we can actually put Pyro into the Persistent Universe, that's where the ramp-up on that stuff goes. That's why, when we had presentations on Pyro during DCC, he talked about how Pyro is basically 80% complete. They bring the planets to that 80% and then they pause, because there's no need to finish it off now when the technology will continue to grow and continue to evolve. When it's ready to go in, that's when they will finish it off and polish it up with the technology and the tools and the procedures that are available to us then. So I don't think I'm telling anybody anything that isn't already out there. That's just how game development works.

The building interiors. So in the future, I'm going to develop the building interiors and I'm very much interested in developing the procedural level building basically.

And building interiors are not just to be able to walk inside a building and have more stuff to look at. You mean building interiors so that we can do mission content and gameplay content and stuff like that inside.

And mine would be the opposite, doing exteriors, since I've been doing a lot of interiors since I started, well, besides Ghost Hollow. I don't know if I can say what I'll be working on...

Yes, you can. Nothing you guys are working on is secret.

So I'll be jumping onto the UGFs, the underground facilities. And the Montreal team is going to start with the first zone, the surface parts. So working directly on the planet and making a big compound.

That's another thing that we came here for. We wanted to meet with John Griffith and company so that we could get a solid kickoff and hit the ground running in Q1.

Yeah, since they'll be working on the UGF as well, but in different zones. So we'll be working as a team, but Montreal will be working on the surface and Manchester will be working on one of the floors, and then we'll switch and dig.

And that's the thing you want to be working on that you're not already working on.

Actually, our next mandates are so awesome that... We always pick what we want to work on.

Exactly. I try to make sure that everyone goes on to something that they're passionate about. So, yeah, we've hammered this out in the past couple months and we've distributed our teams on mandates that would motivate them.

The buildings there are going to be crazy. All those buildings over there, maybe not all, but a lot of them will have content in them. We'll have some industrial, residential, commercial, rooftops, maybe sewer. We'll be able to connect each other, so we're going to add so much gameplay.

And holding cells, I think, like prisons.

Eventually, we're all looking at that. We're seeing what works, what doesn't, and yeah, we'll hammer out the proof of concept for this, and then we'll be doing a bunch of those.

Making a world more world.

And how about you? You get to have a vote.

Well, I'm really, really excited about the mandates that they just talked about. And yeah, we're going to have a lot more in the next year. I think you guys are aware that Montreal is ramping up the team. So we're going to take on more and more super exciting mandates. But sadly, I can't talk about all of them. So it'll be for next time I'm over. I can tell you guys about it.

I was going to add something. With the UGF, I think one thing that's going to be different, because all the other mandates we had were very local, everything was made in Montreal. So for the UGF, that's going to be one mandate where we're really going to work with the Manchester team.

More collaboration.

Yeah, a lot more collaboration. So it feels like we're becoming more and more part of the family, which is cool.

It's one of the initiatives of coming over here to meet those teams.

Yes.

That's all UGF is, right?

Well, not only UGF, but building interiors would have some procedural elements. Those additional derelict locations that we were talking about, with Raastar, we're going to take those pieces that we built in the past few quarters and we're going to spread them somewhat procedurally. So yeah, pretty much everything we'll be working on in the next year follows that pattern.

And the early tests that we did with the space clinics, we made them in modules and the level designers used those modules to build. So we built one initial space clinic as a target, and then the tech level designers used that to create a recipe to populate all the other space clinics in the space stations.

And some rules basically, right? So that every piece would actually fit together and that we never procedurally put two things together that don't quite fit.

Yeah. They've been discussed.

We're talking about it. I don't remember the name. What's the name of the big, big, big station? Port Olisar. Thank you. We were talking about maybe we're going to crash Port Olisar on the planet somewhere eventually.

But for now, I don't think this is a mandate that's going to be on us. And if it is, it won't be for now.

But that could make a nice silhouette.

This is where I have to remind people that talking is talking. We discuss a lot of things. It's just concepts and whatnot. We will explore many ideas. I already see the one running to Reddit right now: Nicholas said they're going to crash Port Olisar on a planet.

No, I said we thought about maybe we could crash Port Olisar on the planet.

We've had lots of discussions over the years about what we can do with Port Olisar. We've even talked about it here on this show and on other things. I think there's a definitive intention to end Port Olisar's life at some point. How we're going to do it and in what manner is still being discussed. It could still be years away.

Oh, it requires some planning, guys.

Because if that's on the surface of the planet, it's a huge undertaking.

Well, no matter what we do end up doing with Port Olisar, it's going to need careful planning.

Yeah, because it's going to be unique, so it takes a lot of time, a lot of people.

We'll see. I don't even know necessarily what we have against it, other than it's really old and really resource intensive because it was made with the procedures and knowledge that we had in 2015. And we desperately want to replace it and improve it, put something better that's more performant, that serves more needs and stuff like that.

It'd be a poetic way to end it, turning the page on an old relic and kind of giving a story to Star Citizen.

A proper send-off.

I mean, a project of that magnitude is... it's hard not to be flabbergasted by whatever you're seeing. And the fact that it's already playable and out there in the world is something that most of us really haven't experienced. It's all hush-hush for years, usually. And now we're building it, and we can see people reacting to it as we're building it. We can see how it resonates with people. And I think that's something that not a lot of us have experienced in the past, developing those super long productions that we have to keep secret for three, four, five years sometimes. So I think it's an interesting way of developing games.

And sometimes forever. There are some games that we've worked on that got scrapped. So it's kind of sad to work on something that looks amazing, and then, sorry, can't show it. It's gone. So to work on something that has frequent patches, playable in alpha, it's very encouraging, motivating as well.

It feels like we're working for the players and not investors. It's a team effort. We're not the big money pocket guys. We're just working for everybody that loves the game and the whole community. So it's a very different feel; that's what attracted me the most.

And as artists, it's also just a really good looking game. It's a passionate thing for us too. It's kind of funny that we'll be able to update our ArtStations before our previous games get to ship. So that's how quick it moves.

But also, when we work on different projects, you're always asking yourself as a developer, imagine if this game was actually coming out on the next gen or on the next CPUs and GPUs. And currently, that's pretty much what we're doing here. It's hard to run this game even on high-end PCs. Being able to work on a game that's built for the future but that currently is in a little bit of a shaky state is very exciting as a developer, because you get to just constantly try to push those limits as much as you can, because you're expecting that eventually hardware is going to catch up. So it's exciting to not have those limitations already put in place on day one, and then you work on a game for four years, and when you release it, it's been four years of new releases of hardware. As opposed to right now, we're just constantly trying to push the limits, even if the hardware can't necessarily always keep up.

I liked also, to your point, Rainer, just before that, the hospitals were the first full levels that the team has put out in the patch, which is very nice, really cool. But it's the fact that you can actually read the feedback from players when they see them. Even though they're not completely available right now in 3.14, even just having the lobbies, I know you went in and you guys were taking selfies in game, like, look, we're in the game. And that's really invigorating, to be able to ship often.

And see positive comments, too. And just to see praise on your work so quickly, because I joined last December and already I get to see what I've worked on in the past six months is already getting better. It's nice to see comments already.

Well, there's us artists. We're still working on the hospitals. Jason and I are on the space clinics. That's going along pretty well, pretty quick too. We're approaching final. So I guess it was a small mandate compared to New Babbage. It was a lot of reuse, but it had its own challenges, since it's a map that we're using to also test out the procedural tools. So there's a bit of problem solving with that: how can we keep the thing looking interesting while being compatible with the procedural tools?

I was about to say that actually those modules that they are creating right now are a good element for us to play with for the new version of the tool they are using right now, because we are revamping that tool with our own proposal. And we are using the building pieces they are making to actually test it for the new context and this new way of setting them up. So hopefully we'll get to improve those [issues they] can have already using the previous version, because we are definitely expecting to have those solved by the next version.

Well, how can we generate a lot of environments quickly? For example, the first mandate we checked was for the space station. So we want to create a lot of them. But if it takes you one month to do a space station because you assemble the different rooms manually, it will take years and years to do all the space stations for all the star systems. So what we are doing: we already have a tool, the procedural layout tool, that is a way to stitch those rooms together. You give some rules, you want the kitchen next to the bedroom, something like that, and it can generate different layouts. But the problem with that at some point was that it didn't give enough control to the user to define exactly what you wanted. And so we are designing a new way to do this procedural approach so that we can assemble those bricks more quickly and easily, and so that every artist can say, okay, I want that there and specifically that there, giving different rules, and so that we can generate a lot of them that are interesting and beautiful and fit with the fantasy of the game. And so for that we are integrating Houdini, which is a software used for procedural, into the editor, so that it can communicate between the two: the editor you normally use to create the levels, and this tool that is made for using those Lego bricks and making rules to assemble them. So it's mostly how can we do that.

One super interesting aspect to what the guys are doing is, in other companies, when you have the pressure of being on a two-year project or a three-year project, there's a lot of pressure to do tech and tools super quickly. And developing this type of idea that the guys are putting together, which essentially took a good, and correct me if I'm wrong, six to eight months of actually really thinking about it, looking at the architecture of the project and seeing how you guys can implement this, is not usually a luxury that we have on a project. So having CIG give the team the time to develop and think about a solution that can scale throughout the years was a godsend, essentially.

You've got to remember that one of the missions for the studio is to be able to create star systems. You can't create a star system by hand. The mission that Benjamin, Guillaume, and the rest of the procedural team have is basically to assist all these nice artists and level designers so that they can make more of the good stuff, in a way that keeps gameplay interesting and fun. And one of the things, you guys are a bit modest in your approach, is that it's also in the small things. Yeah, you can stitch a space station, and it's really great, but it's also in the small things. Let's say a small cable run or placing objects and stuff like that, and the ability to make that procedural so that every step is faster.

Yeah, because we think big at first with procedural, like planets and all that. But when we see our environment artists work, like if you see the books behind me, if you want to place them by hand in a level, you will have to place them one by one. You lose a lot of time, when you can say, okay, fill this shelf with books. And that's the type of tool we can do also with procedural. So we try to tackle the big stuff and also the small stuff to help them fill the world with interesting stuff.

So that Jason and Rainer don't have to spend all day placing Lego bricks.

Yeah, we can focus on the important stuff.

Yeah, placing books in a bookshelf is not always the funnest part of the day. So any procedural tools to speed things up and get into the more important stuff. And as I said earlier, the scope of this game is so massive. It's tools that we need to help us create content at a quicker pace.

Do we really need it? We need a meeting to talk. Are you sure?

For an artist, what is it going to look like?

And then we need an Excel sheet to define all of the departments that are going to need to work on that door, and then ETAs, and then add a two-week buffer for that ETA because something is going to go wrong. Something is going to go wrong, for sure.

Tech art, what's your question when somebody says door?

Either you want it closed, either you want it open all the time. That's what you want. Do you want it to open and close? No, you never want it to open or close. You want it to stay open or stay closed. You don't want the animation part of it.

You don't want to have the detection part of it. It's so complicated, because how do you deal with the collisions? Do they move at the same time as the door? What happens if you attach a gadget to the door and the door opens or closes? Does the gadget fall on the ground? Does it explode? Do you lose your gadget? How do bullets react with the collision? How does the enemy react with the doors when a door opens or closes in front of the enemy? Does it cut the nav mesh or doesn't it cut the nav mesh? Do we have that check in the game? This is just the tip of the iceberg.

Now, the best one is: this door normally auto-opens when you get close to it, except during mission stage three, if the dude said the door is now locked. And then we start with a door, and then one month later there's a co-op door, and then a month after there's a double door, and then another month there's going to be a security door.

Then there's a breakable one and a metal one that's unbreakable, one that locks with a key.

And once you think that it's rock solid and that you've seen every possible thing that could go wrong, you give it to QA, and within five minutes, they break it.

He looks at it and it's broken. And then, what does concept do with a door, really?

It can't be a simple rectangular door. You've got to see how much detail you can fit onto this door, how many decals you can put on it, maybe a warning sign on your door, how many panel lines you can put on the door. It can't be a simple metal door. No such thing.

Warning, this is a door. It opens.

Brittany, what do you think Pierre-Luc would say in the concept door review?

He would say it's not door enough, it just needs to be more door.