Will Hain

Well, quantifiable is a weird word here because we're not done. So we haven't measured how long it takes to make a planet because we can't make a whole planet yet. But the design and the whole way that we've built this tech is with speed of iteration and quality in mind. We're already getting quantifiably better quality in areas and we want to keep working until they're all of the areas of a higher quality as well. But also, we can't kind of measure how quick all this will be until it's done, until all the supporting systems are done. So just because we can pump out a planet in a day doesn't necessarily mean we can work out everything else that makes that planet an interesting and unique location. That requires content from all sorts of other things, from narrative to level design to locations to lore. There's no point pumping out a million alien worlds that are all lifeless. They've got to have meaning. And that's kind of what we've done really nicely with Pyro, I think.

Just to clarify, we're also not going to be pumping out a planet in a day or a million planets I mean, it's as long as a piece of string, isn't it? You could pump out something in a day, whether it's worthy of releasing in a day would be a very different question.

So it's kind of a bit of a toss up really. We use the term vertical slice specifically, and that's something I'll kind of dive into a bit. We've kind of tried to do a bit of everything so that we can see the whole picture and then kind of tweak our design from there and start finishing out each bit. And that means that yes, we could build a planet, but there's no way we could ship it. It's not performant enough. It's not varied enough. It doesn't check all of the boxes that we want. There'd be all sorts of problems with the tech that is working for the difficult bits, but not working for the bits that mean that you can have 30 in a solar system and then 30 in another solar system and so on. One of the reasons we've approached it like this is because there's kind of such a fundamental change in the tech. Like the Genesis and the Planet Tech improvements are not just kind of changes to the output of the existing system. It is a fundamental kind of reshuffle and redistribution of work, which is largely because V4 kind of addressed the needs of planets, although the Planet Tech that we have kind of addressed the needs of planets as they were at 3.0. But nowadays, there's a lot more requirements from that tech, whether it be kind of server meshing things, base building things, harvestables, persistence. So we've approached it from this vertical slice, which means, yes, we can build a planet, but it's not the standards we want. But we're now at that point where we take that. We can say, OK, well, here's what worked. Here's what we need to redesign. Here is what we know is great. We've solved some of the big tech problems. Now we're transitioning to more of a kind of milestone based approach where we're saying, OK, well, now we're going to finish out GPU spawning and now we're going to finish out the orbital look and so on. And we can start kind of taking chunks of tech and finishing it. And I think one of the really important things as well is that we're not aiming to release this as one big floodgates. And suddenly everything is out and boom, you've got Genesis. It's going to be features coming online, type bit by bit. And one of the one of the early bits of tech is actually already in the 4.0 streams that are going out to EPTU right now. The planetary rewrite of how we store and subdivide our planet into patches and so on is already out there in the world and working. And that's kind of one of the benefits of having done this as a vertical slice. It means that we're starting to reap the benefits already. In terms of greybox, Seb, you can probably explain better what you meant by greybox in your sections.

So in our process, we usually have whitebox, greybox, and then final and polish. For vegetation, it doesn't really work that well. Whiteboxes don't really represent vegetation assets super well. So we just make a very rough version of it. Also, we were asked fairly late into the process of making the videos to add those labels. And we might have been a bit sloppy. So the swarms were definitely further along than the jungle, for example. Jungle definitely very much what we consider whitebox. Swarms and redwoods a bit further along, with the swarms being the furthest. And yeah, it's all coming together. And we are working through them. And a lot of what you've seen in whitebox is further along now and might be close to polished and final. And then we just need all systems there, every other system to make it into new planets and then release the thing maybe one day. No, I don't know.

I can say regarding roads is that it's definitely something we want to do. A lot of the river tech when it was made was made with kind of like and roads in mind in terms of there's a lot of similarities in terms of kind of like dynamically creating and destroying things as you approach it on or across a long spline, because if you just load a mesh for a 100 kilometer road, that's obviously not going to work. But it takes some time and some investment into the tooling and it's making the assets and getting design and so on. We want to approach it. We're not approaching it this second.

Yeah, just to add to that, we've got Will's done a lot of the groundwork for that. So on the planet side, a lot of the work has been done or wouldn't take much to take it further. You know, there's not a huge difference on the planet side between a river and a road. Where the work remains is there's a bit of graphics work to do. Obviously, a road doesn't look like a river. We need whatever stylistically we need to change there. And presumably, you know, the whatever assets would be distributed at the side of the road would be slightly different to a river. But probably the biggest difference is we assume it would come from Starchitect. Like you would have to place all these locations on the planet. And then we have to figure out what would be the logical distribution of roads. There will need to be rule sets. You know, does this planet support roads? Is there areas of the planet that will and won't have roads? You know, maybe outlaw bases don't have roads. They don't want to be signposted with a big motorway to an outlaw base. But, you know, some places will. So it's that element that is the biggest part that's missing. And then obviously there'll be a bit of once you have decided to connect two towns or locations. There's some code to figure out what is the best path to get between these two. Do I carve straight through every mountainside or should I weave around them? So there's a bit there. So on the planet side, we've kind of done it. But mostly on the tool side, we're deciding where the roads would go. And then a little bit of graphics to actually make it look like a road.

That's definitely in the cards for sure. I don't know if we want to talk about the whole entity thing. But conceptually, yeah. We'll definitely be able to have them. Right now they're tied to the biome they're in. But in the future we can be more specific and spawn them on cliff sides. Or where the rocks fall down at the base of a cliff. And then you will find them there and stuff like that. That's definitely possible, I think.

I think we want to treat a harvestable like any other asset. If it's a mining rock, we want to spawn it according to parameters that we would spawn a regular rock. We don't care whether it's a here's a game entity that you can mine versus here's a static piece of geo. We want to do them with the same rules. And it'd be the same because you get those revenant trees that you go in. No, revenants are bushes. Then there's the heart of the forest tree or whatever. We want to scatter them just like any other vegetation based on the same data and the same rules. So if you're asking is it going to be more realistic, then I would say yes. I think Seb also alluded to the new kind of entity management spawning-y stuff. I don't think that's going to help the specificity of the locations. But it's definitely going to help the density of these things. And I won't elaborate into that right now because the managed entity system is a very techy, boring subject that you can't cover without a TED Talk.

This is kind of linked to what I said before with chopping down trees. There's kind of a few complications that come here. If you think about I want to knock over a tree in my ship, that sounds like a simple behaviour. But there's all the gameplay stuff about how you would go around and chop a tree and the kind of design behaviour from that. And so none of that's done. So we need to wait for that. And then from our end, there's kind of three core bits that we need to worry about. There's promotion, which is taking our very kind of highly optimised tree asset that renders in a particular way and is spawned by particular system and replacing that with something that we can interact with and uniquely address and tell what to do. There's the management system, which I alluded to, which is essentially about making spawning of entities server meshing friendly and persistent. And then there's persistence itself, which is kind of like, OK, well, you've crushed a forest with your Idris. There were, what, 700 trees under there that we now need to remember have not done something. And actually just creating 700 entities and chucking them in the entity graph is not an efficient way of going about that. So we need to make complex decisions like if a tree becomes fallen over next to your base, you probably care about that tree. But if you knock over 500 trees on your way to New Babbage, we could probably come up with something different to record that there are fallen trees in this area, but not 700 unique entities for each fallen tree. So there's a whole tonne of work that goes into stuff like this. And it's not even like it's not even really kind of planned for or guaranteed at this point. All I'll say is that we want our system to be able to support more complex behaviour and start to approach these problems.

I think we'd like that because we feel the small too, especially as we introduce more and more advanced atmosphere. It breaks our nice illusion that our planets are full scale, which I hope all of you continue to believe because I certainly do in my heart. The thing about bigger planets is it stretches the complications with precision more, which we're hoping to be able to do away with. But that's one problem. Obviously, we need high resolution textures. At the moment, if we have a global texture and it's, say, 2K, that gives us a certain number of kilometers per pixel. And obviously we have local data, too. But if we make a planet have twice the surface area, then suddenly we have half as much resolution for the same kind of budget. So we need to consider those decisions and consider how the tech can deal with that. But you also get kind of gameplay problems with that as well. If I make a real life size planet, we have fast ships, but like suddenly getting from one place to another takes 10 times as long. And it's not necessarily good for gameplay to have that. So it's a convoluted question. We appreciate the reason that people are asking that we feel the same. But also there's a certain amount of the why question, which I guess you can ask for a lot of our features, which is what we have works. What we have is great. Should we invest more time in making it bigger? Is that a good use of our time versus going and doing rivers, too, or finishing out something else sooner? So if you put up a poll that said roads versus bigger planets, I bet roads would win. So, yeah.

I'd probably add that eight times is probably, like I say, it probably pushes all of them aspects too much. Too low res, it's too much memory, it's too much of a knock on for the gameplay. A smaller increment would be more appealing, I think. You know, like a doubling or something like that. Because just being able to double the scale of our mountains would be nice. Double the scale of our global features, our mountain ranges would be nice. So something 2 or 3x, we know would be more chill. But 8x, pushing a few too many areas at the same time probably for us. Yeah. And then the other thing we talked about, we didn't mention, is content density. We have to fill it with stuff as well. We'll see with Starchitect hopefully helps fill that gap a bit. But we just don't want to, like, if the current game, we don't want to put things miles apart. As we start to see the product of Starchitect, we might be able to see, okay, yeah, things are feeling too crammed and, you know, claustrophobic. Maybe we do need a bit more space and we'll try and explore that. But yeah, probably 8x is probably pushing it, I think.

Engine programmer could be anyone really, working on the engine, but more specifically I work on the planet tech team. There's four of us, five depending on who you count, and we work on all of the procedural tools like the rivers, like the planets, like some of the graphicsy stuff, because we're kind of a graphics team and yet kind of not. But generically, I'd say an engine programmer is just going to be working on core tech and low-level engine stuff. Specifically, I work on the procedural, the building big things from small amounts of data very, very quickly sort of side of things.

Such as?

Such as the planets, such as the rivers, that's what we do. We have these enormous giant-scale planets that we build from less than 10 megs of data, and we do it at runtime as you fly around them. That's what my team manage and work on and improve and develop new features for.

I'm Will. I'm a two-dimensional character. I exist purely for Cloud Imperium Games. I went to uni down in Cardiff, where I studied game design and development. I've done programming since I was about 11. I used to use a program called DS Game Maker where you could make very, very bad games and then put them on one of those R4 ROM cards you can put in your DS with a micro SD card in. And that's my first exposure to programming. But it just kind of snowballed from there. I really wanted to do music for a long time, but I refused to do it academically because I wanted it to be organic. And then I thought, well, I need to do something that will definitely earn me money so that I can afford to do my music, and I thought I'm pretty good at programming, so I'll roll with that. I did the course in Cardiff, which was great, and I did a dissertation in planet terrain generation where I essentially made this GPU-powered planet generator based on ridges and rivers, which would then propagate out to an entire planet. Very bad it was. Anyway, I applied to a couple of jobs a couple of months before I was going to graduate. I applied here. Marco, you know Marco, he picked it up, interviewed me, really liked the stuff in the dissertation. He was like, so we're doing something similar, and just brought up New Babbage on this big screen in the interview room. And I was like, yeah, that's cool. And that's how I got here. That's who I am.

Absolutely. I had this game. No one's allowed to copy this. I had this game idea when I was about 11. I wanted to create a game called Infection, where you were essentially a little nanobot flying around in someone's veins shooting viruses, was my concept. Anyway, I spent a very long time in MS Paint making 2D backgrounds of veins, I guess, and this little ship that would fly around. And then tried to make that happen. And you could just about move around. We had, we, I had this, it was we, I didn't have a studio at 11. You could paint the map down and then you could paint a magenta overlay to show where you wanted collision to happen. So there was no real physics. It was just if you hit the magenta, you bounced back sort of thing. And it was tacky and horrible and terrible. But that was the first thing I did.

In one of those programs, the games that let you make other games.

It wasn't a game as such. It was made by some other young guy. I think he was like 15 or 16. And it was made in Windows Forms. So it was a real program. And the idea was you used one of those GameMaker-y, Scratch-y sort of programs. You used event blocks to trigger stuff happening, but you could go in and look at the code behind those event blocks, which I think was in C. And so I started copying events and changing little bits to try and make it do something similar. I had no idea what I was doing, but I just experimented until something worked and pestered the guy who made this game maker far too much.

Well, rivers is a funny one. So back to that interview with Marco, when I'm sitting there looking at a picture of New Babbage on the screen and he's saying, how do we solve this problem? How do we solve that problem? And then he says, can I have a look at your dissertation? So I bring it up on my laptop and I've got rivers. I mean, they're just trenches at this point. And I say to Marco, have you got rivers? And he says, we haven't got rivers. So about five, six months into working at CIG, Marco asked me to start working on a terrain modification system. You remember we did the first ISC about that, my first, not yours, because we had no way of modifying the terrain currently. It was fixed because of all the shared data and nothing being local, blah, blah, blah. Anyway, so I started working on a solution to that. And then I said to Marco, this is going really well. I could use this to make rivers. Do you mind if I do? And he said, no, that sounds cool. So I did. It was really nice to have that freedom, and obviously I couldn't put that much time into it to start with because it was kind of like a side project. I remember the first version of it, we deformed the terrain and then raised the ocean to fill the gap, and it was a real gimmick. It looked really bad. The waves were going the wrong way. And it was the same mesh, so we had no control over it or anything really. But it just about worked. And anyway, he showed CR and we managed to get some time scheduled for it. And that's how I started working on rivers. It was really cool to go from saying I want to work on this to it being a feature. And I remember it coming up on the roadmap for the first time and being really excited. I worked on something that's on the roadmap, and being able to tell people about it. It was cool. I really like the rivers. I still need to do more on them. They're still my baby. No one else takes the rivers.

Yo, Chat. Rivers. The reason I think rivers are really, really cool and really, really important is they are almost just a catalyst to improving the planetary tech in and of itself. So everything that has been built around rivers and built to allow rivers to work has generated improvements on the planetary tech itself. So we didn't have terrain modification. We wouldn't have taken that as far if there wasn't as big a mandate as rivers. We didn't have this specific control over what spawns in what area depending on local features. But because we wanted it for rivers, we drove that and now we can use it everywhere. So it's not just a cool feature in a cool location, and it doesn't just add to the realism of the planets and add unique locations that we really didn't have before. It is a way of not only showing off new development in the planet tech and the procedural tech, but also a catalyst for generating the need for work and the drive to provide these new features. It's all well saying, well, I want to be able to control specifically at what level all these rocks want to spawn. You say, well, why do we need that control? What feature demands that? But actually what you can say with the rivers, you can say, well, we need it for this. So we make it for the rivers and now we've got it for everything and we can use it for all the other locations. And when we start introducing more unique POIs, we have this control and we have this technology that we wouldn't have otherwise.

Cliff sides. So the new river cliffs in 3.18 are really cool, actually. So the piece of technology that allows them to exist is this thing called on-demand spawn points. I won't go into too much technical detail, but the spawning system is run by a piece of code called Biome Builder, which I help look after in Planet Tech. And that has lots of cells across the planet, a grid of cells across the entire planet, each of which have a set of spawn points. Spawn points are usually random, and then they take their properties from the terrain in order to decide what to spawn. On-demand spawn points is a little bit of code that allows us to hook into that and say, we want a spawn point here. We want it right here. And we want an object to appear. And you can even specify some overriding stuff as well, which is pretty cool. Now that was developed for the rivers and then for the cliffs, to allow us to say, well, we've got all these rules about where we want such and such a rock, but you can't always just cover for this all in rule sets. Sometimes you need specific art direction. Sometimes you need to say, well, this is a river gorge. We need a wall of river cliffs going along the side. So that's the kind of tech that's driven that. We want to be able to place this on naturally occurring cliffs across the planet as well, which will be really cool, because then when you get those really steep slopes that naturally appear on our planets anyway, we will be able to populate them with the really beautiful cliff meshes. But there's also some rumours and some talks about going a different direction with that and doing more of a technical approach, which I won't spoil, but it would be really cool if we end up doing that. I hope we do. But the on-demand spawn points are driving it at the moment, and they're really cool.

More of a technical approach?

More of a technical approach. GPU-y stuff. I'm not going to spoil. That's not my place to spoil.

If I could choose what I was going to work on next, God, there's so many things. I really want to go back to the spawning, and I want to make our planets more physicalized, which means nothing. I want the planets to be realistic. So we currently have our climate, we have temperature and humidity. I want more detail, more control, more proceduralness, so that you can click a button with some randomised parameters and generate an entire unique planet just like that. So I want to say, well, this is the local sun of the solar system, and this is where the planet is, and these were the materials that were around when it was forming. Where are we likely to have continents? Where are we likely to have resources in the soil? What plants and rocks are likely to have come here? I'd like to, and I don't know if we'll ever be able to do this, but I'd like to do full terrain simulation. You could do those cool simulations where you have a flat piece of terrain and you start introducing water droplets and it forms the naturally occurring erosion, because that's not what the rivers are. The rivers are finding where a river works given the current terrain, because we can locally edit terrain with a terrain modifier, but we can't completely reshape the planets, because our procedural tech is relying on reading these fixed height maps that we have. We can tweak it here and there, but we can't reshape the whole thing currently. But it'd be really cool to do a full erosion sort of thing. Whether that's ever going to find its home in the PU, though, in our Star Citizen, where we're finding hundreds of planets and stuff, I don't know. But that's the sort of thing I'd love to work on.

It's hard, because I don't think anybody's going to say we don't push technologies in ways that maybe other games sometimes don't. But there are always considerations for the multiplayer aspect, for the MMO aspect, for the server. There are things that we could easily do just for a single player. You can control the perspective. You know it's only being seen from one place.

Exactly. I mean, with the planets, the best example is if you've got one planet and you've got 20 gigs of hard drive space, you can go into so much detail and you can have so much locality. But actually, that's not where we need to push the boundaries. What we need to do is push the boundaries so that you can have hundreds and hundreds of planets in minimal, minimal data in one game download. And as well, if you wanted accurate height maps of Earth, that's terabytes. And if you want the level of resolution that we have on our planets on Earth or something smaller even, it's just not possible to read it from raw data. You can't do that. You need to be streaming it in like Microsoft Flight Simulator does. And even that, that's a really, really, really beautiful game. But you go to the terrain and it's not the fidelity that you'd expect when you're walking around the terrain. It's a flying game. It's designed to look good from above. And it really does. But that's not the problem we're trying to solve. We're trying to generate these beautiful, unique planets, and we're trying to do it in such a way where it's scalable, because we don't need a one-to-one replica of Earth that is down to the centimetre in every single place. We need fully explorable planets, and we need many of them, and we need it to not take up several terabytes on each of our users' hard drives or SSDs. So pushing the boundaries in the right way, I think, is the right takeaway from that.

There are probably six or seven people all running to Reddit right now to make a post about how somebody at CIG said they can't do Earth and Earth isn't coming. He's talking about the current tech and the current place that we're at and the current resources we have and the current intentions and the current directions. Obviously, folks who have been following the project for a long time know that Earth still exists in the 30th century. And when it comes time for that point on the development wheel to roll around, we'll be discussing how and when and where we'll be doing that.

I'm not unconfirming Earth. I'd say if you're working on planet tech and you want to make Earth one day, then each of the decisions leading up to that needs to take it into account to some degree. You don't want to accumulate all of that tech debt.

I want to work more on the spawning stuff, but I want to make it more physicalized. That's one thing. I could work on any number of things. I want to do lava and volcanoes. Lava, volcanoes, that'd be cool.

Did you say volcanoes?

I'd love to do them. I'm not saying I will. I'm saying I'd love to.

It's just like a vertical river out of a mountain. Just turn it on its side.

Maybe for a lava river you could say that. It's like a slow-moving river with more VFX. But what if you want the lava to set? And what if you want to put on your fire hazmat suit and walk through it? There is tech and there is work and there are more features needed to implement something that looks like an aesthetic change on the surface, because it's all the gameplay. That's what we got with rivers as well. When we got it looking good, when we got it ready to release, the thing I was working on in the months leading up to putting out our first river was not making the rivers look better. It was the gameplay. It was making the grav-lev vehicles recognize it. It was making the player drown if they take off their helmet underwater. It was the VFX not spitting up dirt and stuff when you fly your hoverbike over it. It was all of the gameplay and none of the beautification anymore, because there are so many facets to putting something in a sandbox world like ours. It's not a simple, well, here it is, it's done. You've got to think about everything the player can do to it, everything the player can do there, what's going to look stupid, what's not going to work. It's a big job. It'll be the same for lava when it does come. I think it will come. Someone said it would come. I hope so. I want to work on it.

Look into that camera and say, we are definitely doing lava.

That's not my call to make, Jared.