Star Citizen Live: Points of Interest

It's part of what we just showed. It takes a while to mark up and create those derelicts, and it's just a matter of priorities. They just have to have the time and the resources to go through and make additional derelicts.

And of course, the ship team has to make more destroyed versions of whatever ships they have and give us those assets that we can actually work with as well.

Like most things in game development, it always just comes down to a priority. An artist can be working on additional derelicts or they can be working on something for a new location. It's one of those things that comes in towards the end of sprints, like when somebody finishes a sprint early. It's rare, but it happens. When somebody finishes a sprint early, it's like, okay, let's go and do another derelict, or let's go and do another turtle in a bucket.

It's a very popular question, one that me and Cory Bamford, if you guys know him, often discuss. So he likes to say that anything that's not bolted down is a prop. And I like to retort with, so is a space station a prop? Because it is not bolted down. I guess parts of the space station are. So when we're making a location, say if this is in the white box stage, and we've just placed down some of the basic geometry that might make out these areas over here, these pods, we'll come in and we'll do something that's called a prop request pass. And what that is, is we'll look at the concept art, and we'll look at what kind of small items might be in the concept art that we'll need that we don't naturally make as environment artists. And we'll put the request list through to props. So in this case it would be something like this box over here or this table over here, the lamp, some of these magazines, the cup. There is a slight blurred line, but it's mostly the sort of items that are dressing rather than large structural... yeah, I guess structural is the best way to describe it. In this case, something like rocks and these parts here, these kinds of beams and structures here are all part of, say, an environment art kit that we'll just bash together.

It's a combination of both really. We have something that's called a design white box pass in which an artist and a designer will come in and sort of lay out what the space is. Usually this is after the concept art is done as well. So we have the mood of the space and we have an idea of what we want to do with the space. So the designers and the artists will come in and do this pass, which is a very basic pass done with in-engine solids, as they're called, which is kind of these very primitive boxes with grids on them to just mark out the metrics of the space. And it's a longish process. We do it in pre-production and we kind of just figure out the things that we want to do with the space: foot travel time, where some shops might be. And then after that, it's mostly the job of the environment artist to come in and figure out the actual building kits that we're going to use for this. In this case, we'll make basic white boxes for these kits unless we have something that is already appropriate.

So a prefab is a collection of predefined items and entities. So this prefab here will be built out of some junk piles, some assets here like this, these kind of structural elements, ribs, these floor pieces, and that's sort of more of the environment part of things. But for example, this prefab has a table and it has the props and things like that, but we also have markup for sound, for design, say you might have a cup that you can pick up there. And it's just a predefined collection of those items. Prefab is short for prefabricated.

Those prefabs can include just about anything. They can include interactable items, movable items...

It's literally all kinds of stuff. It differs from an object container in that the object container is the final, I guess, resting place of all of these items put together so we can stream them in and out of the universe essentially.

Prefabs are for building the universe so you don't have to sit there and place every silly little thing, so the procedural generation tools don't have to go and place every silly little thing. And then the object containers are more about performance and streaming things in and out of memory and stuff like that.

There are some different things we can do with object containers that we can't with prefabs. Say we make a set of architectural pieces that we can tint different colors. We can put that as a modifier on the object container. So we can make all kinds of similar, but different colored areas and all those kinds of little things like that.

We certainly try. Very much try. Being stuck in a hole is one of the QA Ten Commandments. Can a player get stuck? It's one of the primary things they will always test for. First thing. The reality of the situation is that there's a whole lot more of you than there are of us. And you guys tend to be a bit more tenacious with where you try to get to than we can sometimes be. And this is true of any video game. I'm not speaking just of Cloud Imperium Games. QA the world over does their best to make sure there are no places where players can get stuck.

And of course, the scale of the game we're making means that it's much, much more difficult to test for every single little area that might be in the game.

It just reminds me of, depending on how long you've been following the project, in late 2015, we went live with 2.0, which was the first version of the Stanton system. And there was one item that wasn't bolted down, as it were. It was a Big Benny's vending machine. It was one single Big Benny's machine that was physicalized and could be moved. For months, maybe almost a year, all throughout 2016, we saw players just seeing where they could move that box, seeing where they can get them out of the space station, get them onto their ships, take them to other space stations. There was even a thing called the Big Benny's Challenge, where you had to get the box and get it back into the hab in which you spawned. And the hab that you spawned in was up a flight of stairs. So without being able to pick this box up, they had to just continuously go prone and roll and try to get the box to shift slowly up the stairs. And I saw people doing this for hours. Just hours.

There's one thing I know: players will do anything they can to put something where they shouldn't.

So that's always my example of when people say, why doesn't QA test for this? Oh, we test for plenty. But there's no way to account for everything that a player will do.

And they'll come up with things that you just never thought possible. Like what you just said, with the rolling.

Well, that's one of the key aspects of building a sandbox game. It's about building a world, or in our case, a universe of possibilities. So we are continuously surprised and amazed by what our community can do with the tools that we've provided them.

And it's always interesting as well to imagine, as we develop these tools and we make locations more versatile and we give players more control of things that they can do, what insane things are going to happen years down the line.

I was actually talking to somebody about this earlier. Let's just put it this way: nothing is set at this point. We're still in alpha. The purpose of being in alpha is that nothing is set or final. We're here experimenting, letting you play, watching you play, and then making adjustments as we deem them necessary. One of the more difficult aspects of setting LODs is the changing speed of ships, because the speed at which LODs adjust is relative to the speed at which you can fly or approach a planet. So as the speeds of ships are being tuned, we talked the other week about how combat's being retuned, or combat's always under tuning. Again, we're in alpha. So will the speed of LODs and stuff. So it's one of the reasons why when we jump into the editor like this, we can zoom out from a planet and zoom in to a planet far faster than a player can. So we tend to get more popping when we look at it in an editor like this, because we are moving much faster than anybody could in the game, so the LODs can't keep up. So it's a constant question of balance and adjustment.

And it's something that we do ourselves when we're making LODs and making all these performance passes. We'll start moving around really fast and start seeing things pop too quickly. It's like, oh, I think we need to adjust these LODs to pop more slowly, but then in reality, it's because we're going too fast.

Exactly. No player can travel as fast as we can. So you don't balance for the speed at which we can move. You balance for the speed at which players can move. And while that's in flux, so will be the LODs.

So they would be relative to the planet itself. And I could be very wrong here, but I believe basically the coordinates for everything on the planet are then sort of translated further. If you're in the Stanton system, like further out in other systems or whatever, you'll go through your map and you'll just see the coordinates on the map really. It's hard to say. I'm not too sure.

I've had this conversation with a couple of people in the past. I'm pretty certain I understand the answer, but it's been so long that I'm not as confident as I should be. So I'm going to keep it to myself and then we'll see if we can follow up on it. But yes, when we use go-to commands, which is something that QA or designers will often use so they can just get to the point that they need to work on, the go-to commands generally start with planet first and then coordinates after that.

When I need to go somewhere, when I'm running the client to try and fix a bug or something, I usually go planet-based rather than anything else.

But as far as coordinates like specific longitude and latitude, that's not really used. Usually there are waypoints assigned to these different POIs and we just go to those waypoints, which is one of the reasons why when questions come up like, hey, can we have a coordinate system and stuff like that, it's like, we don't actually use a coordinate system. Not to say that one doesn't exist or that one can't exist. We've discussed that before. And as we've stated before publicly, it's still something we want to investigate and work on. It's finding a way to make that manageable. Because any other game has coordinates generally for one level, one planet, or one star system, whatever. And we do not. We need something that scales with the game. It's a very large game.

That goes back to what we discussed earlier, which is when we're marking these up for the actual placement tool, which is something I would have done, but it would have been just a bit tedious for you guys to see. We put these huge boxes down, which I can actually show. Why don't we go back to that again? So these huge boxes come into, say, the derelict in this instance, and they clip out anything that's spawned by the terrain. This could be rocks, trees, or grass. And we can actually define some of those parameters ourselves. And that's sort of how we get that to not clip through. However, because I'm kind of just placing this stuff down without any of these boxes, you're going to start seeing, I'll use that example I used earlier, some of these pop through, or some of these plants like that. But those area boxes are part of our markup that we do.

We've discussed racetracks before. Actually, I think the first time we discussed a racetrack was with Luke Pressley back in 2017, if I remember correctly. So it's been something on our minds for a while. We actually showed an early mock-up once on ATV way back when. The issue is the planets are still changing. We try not to do work that we know has to be redone later. That's one of the ways you work smarter and not harder in game development. As we showed at CitizenCon, as you're seeing now, we just revamped the planets with Planet V4, which necessitated a recreation of all the planets, which would have meant redoing all those racetracks and everything as well. It's when the planets and the planet tech come along to a point where we feel relatively comfortable, like, yeah, this is what Hurston is, this is what Cellin is, this is what Daymar is. When we feel that they're locked down to a point where the changes are going to be minimal, then we can look at doing things like racetracks, because the team is very keen on not only doing things like racetracks but providing players the abilities to create racetracks of your own, like through markers and beacons and stuff like that.

It's about providing all these tools that we need to easily make the game and not do everything by hand like I'm doing now. This is sort of an example of racetracks, and this is sort of an example of things that we really need tools and a more solid idea of what we're doing before we actually start implementing those.