Around the Verse: Building Solar Systems and Nox Preview Written Thursday 22nd of June 2017 at 12:00pm by StormyWinters, Sunjammer and Desmarius As per usual, anything said during the show is subject to change by CIG and may not always be accurate at the time of posting. Also any mistakes you see that I may have missed, please let me know so I can correct them. Enjoy the show!

TL;DR (Too Long; Didn't Read)

Studio Update Level Design finished the main part of the work they needed to do for the surface outposts had white boxes for both the modular hangars and garages approved currently focusing on implementing the markup required for locations (room systems, interactions, etc.) Levski will have a combination of hangars and garages to spawn ships and ground vehicles respectively moving on to the remaining Stanton system landing zones: Area 18 and Lorville, then Orisin and New Babbage

Engine worked on enabling seamlessly blending between global atmosphere and local cubemap based lighting implemented an improved compression algorithm for the new pak file system to allow efficient data streaming worked on PlanEd to unify the code for marking up areas on a planet making it easier to reuse and extend

AI worked on “buddy AI” where NPCs will intelligently follow a designated leader. made progress on ship AI, getting it one step closer to being fully controlled via Subsumption. spent time refining behaviours for first reactions to enemies seen and events heard did additional work on friendly fire so friendlies are identified correctly in combat situations

VFX continued working on effects for various planet surface types including footsteps, weapon impacts, and vehicle tyre effects experimented with rigid body simulations and destruction/deformation animations for Squadron 42 cinematics

Lighting bringing all surface outposts to their final lighting: fixtures, temperature charts, and rules Created a library of prefabs combining existing props with lighting elements

Tech Art continued to create numerous Mannequin animation fragments for the Cinematic team implemented the game entity for the new KSAR Custodian SMG energy weapon added features to our internal Playblast tool to make it easier to create clips for review made great progress with the new weapon dynamics and secondary motions using both ingame physics and simulation

Build Engineering grew by 1 employee to a total of 2

Environment Art the ecosystem ground materials have been improved on all three moons close to wrapping up work on the landing pads that will go with the surface outposts Delamar: surface is getting a final polish with geometry and materials updated and an effects pass Levski: final touches for the customs area, garages are close to done, and elevators models updated to fit the modular building set

Game Programming finishing up the remaining weapon features for 3.0 completed the first iteration of the doors and airlocks technical design new weapons system's network code is being fleshed out; research phase is coming to an end

Cinematics testing first pass of the brand new holographic projection volume entity tech made great progress across multiple chapters for Squadron 42

QA continued testing the new CIG DataPatcher (started testing in May) CopyBuild 3 has also been rolled out to QA and is in its QA testing phase Subsumption Editor testing continues to be a regular part of the weekly tasks testing multiplayer gameplay in the Stanton system Persistent Universe

System Design continued to expand the library of useables to be used for both the PU and Squadron 42 Air Traffic Control is also making headway started work on the FPS companion/buddy AI, including all orders and the behaviours needed affect them Actor Status system is being internally tested right and getting final tweaking and balancing put some finishing touches to the conversation system to assist the cinematics team

Weapons blocked out numerous universal grip and optics attachments converting the older blocked out attachments to work with our new Attachments Rail system completed initial blockout for the Klaus and Werner Demico laser light machinegun finished Preacher Armaments Distortion (S4-6) initial blockout for Klaus and Werner Laser Repeater (S1-3), Neutron Repeater (S1-3), and Apocalypse Arms Ballistic Scattergun (S1-3)Level Design

Ship Shape

Nox is more geared towards racing or combat versus exploring and scouting for the Dragonfly

Concept was provided from England and they started with a 2D concept instead of their usual 3D

Tried to infuse Xi'An technology and use a mix of heavy metals and exotic materials

Nathan Dearsley and Gary Sanchez assisted in concepting

Skin of the bike is going to be a more armoured type and it has these shells that come up above the rider’s back to protect a little more from behind

Nox will have more of a forward leaning stance like a racer

Going to use a holographic HUD system Behind the Scenes: Building Solar Systems An unsung hero of Star Citizen tech is the Solar System Ed or SolEd tool that simplifies all facets of solar system creation The old system for solar system creation in 2.0 was all based upon individual placement around a point of origin that didn't allow for scalability or later changes without basically redoing the whole piece of work Actual astronomers and astrophysicists were consulted to push the envelope on variety with feasibility in mind as well as gamer enjoyment in the creation of these different solar systems The final result was extremely detailed and realistic with a huge amount of data collected and used One concession was that a one-tenth scale was adopted for playability and feasibility purposes The SolEd will also allow the time dilation that is decided upon to be implemented easily Over the course of a year the numbers given from the consulted scientists were double checked against the lore provided for consistency Asteroids in the game will be much closer to one another in game than in reality as they would pose no gameplay challenge for players otherwise Many times the scientists offered many creative avenues for feasible and realistic differentiation within the solar systems to be created “Space be crazy” SolEd is being used for procedural planets, but not Crusader as it's a gas giant, and the tech for it is not fully developed yet Even at one-tenth scale the distances at quantum speed take a very long time to travel Quantum travel is always in a straight line as an antigrav bubble protects the players, but turning would negate this, and so is not possible It takes 15 hours to drive around a moon of Crusader They hope that the players realize the vast numbers and care taken into the creation of these systems along with the balancing of realism vs gameplay and of massive scale vs the crafted experience

Full Transcript

Intro With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Eric Kieron Davis (Senior Producer). Timestamped Link.

Chris Roberts (CR): Welcome to another episode of Around the Verse, our weekly look at Star Citizen’s ongoing development, I’m Chris Roberts.

Eric Kieron Davis (EKD): And I’m Eric Kieron Davis.

CR: So on today’s show we’ll examine what it takes to build a solar system, a process that includes everything from extensive astronomical research to the creation of a new tool we’re calling SolEd.

EKD: Yeah, plus we have a Ship Shape that you will Nox want to miss.

CR: So bad.

EKD: But first let’s pay a visit to Frankfurt for a studio update.

Studio Update With Brian Chambers (Development Director, Foundry 42 Frankfurt). Timestamped Link.

Brian Chambers (BC): Hello. I’m Brian Chambers, Development Director of our Foundry 42 Frankfurt office.

This month the team grew by an additional two people bringing us to a total of 76 employees. This month we had 20 of those employees participate in a local 5k run here in Frankfurt. Nobody necessarily participated in hopes of winning but it was a good opportunity to hangout after work and have some fun and exercise. So let’s start off this month with checking in with the Level Design team.

The Level Design team finished the main part of the work they needed to do for the surface outposts and they’re now in the hands of the Environment Art team. They also had white boxes for both the modular hangars and garages approved and those were handed over to the Art team as well for their visual exploration phase.

With the white boxing phase complete they’re currently focusing on implementing the markup required for all our locations. This involves everything from room systems and breathing; environment interactions like vaulting, elevators, and consoles for spawning ships and vehicles. Levski will have a combination of hangars and garages to spawn ships as well as vehicles to explore the planetary surface.

With the bulk of the work completed on the previously mentioned locations they’re now moving over to the remaining flagship landing zones for the Stanton system. The first ones on that list are Area 18 and Lorville followed by Orisin and New Babbage.

The Engine team worked on consistent capturing of both atmosphere and sky in cubemaps so we can seamlessly blend between global atmosphere and local cubemap based lighting. This will ultimately give us a higher level of visual fidelity.

They implemented an improved compression algorithm for the new pak file system to allow for more efficient data streaming due to reduced CPU overhead during decompression. This is part of the new incremental patcher which will ultimately make patches and updates much more efficient.

They also did some work on our internal tool called PlanEd. We have several needs for marking areas on a planet to identify where specific objects should be spawned within an ecosystem, areas to be punched out to embed brushes or complex structures such as landing zones. The code for this was unified so it’s easier to reuse and extend in the future as even more functionality in this regard is needed.

The AI team has been busy as usual. This month they did some work on “buddy AI” where NPCs will intelligently follow a designated leader. They also made progress on ship AI, getting it one step closer to being fully controlled via Subsumption.

One sprint they did this past month was focused on human combat: they spent time refining behaviours for first reactions to enemies seen and events heard. The reactions vary in direction and speed from casual situations to quick reactions to loud events and so on. The clips you see here are put together in a way that just verifies the behaviour via triggering the appropriate animation from a start pose to the action intended. Once the behaviour is verified they’ll get fully hooked up in game and the popping won’t occur.

They also did some additional work on friendly fire to make sure friendlies are identified correctly in combat situations if and when needed.

The Frankfurt VFX team has been continuing to work on effects for the various planet surface types. This covers a wide range of effects from simple footsteps, to weapon impacts, and vehicle tyre effects.

They also did some early experimenting with rigid body simulations and the workflow for Squadron 42 cinematics. This will cover the many mesh destruction and deformation animations that are required for the Squadron 42 single player missions.

The Lighting team has been very busy bringing all surface outposts to their final lighting. This involves creating a consistent set of lighting fixtures, temperature charts, and rules which we can use to define how each type of outpost looks. We’ve also created a library of prefabs combining existing props with lighting elements which can be easily iterated on and propagated across all outposts.

The Tech Art team had a variety of tasks this month. They continued to create numerous Mannequin animation fragments for the Cinematics team. They implemented the game entity for the new KSAR Custodian SMG energy weapon with the blocked out mesh and rig. Now that it’s implemented other departments can start working with it ingame such as Animation and VFXs. They added additional features to our internal Playblast tool to make it easier for the animators to create simple “playblasts” of their work which are primarily used for animation reviews. They also made great progress with the new weapon dynamics and secondary motions using both ingame physics and simulation. The initial results are promising and secondary animation will add one more level of subtle detail and realism to the ‘verse.

The Build Engineering team grew by one member this month bringing us to a total of two here in Frankfurt. So a good amount of time was spent getting him up to speed on how we function. They’re ultimately both responsible for build support for our European offices as well as working on both mid- and long-term plans to increase both efficiency and reliability of our build process.

For the Environment Art team this month, with the updated material distribution, the ecosystem ground materials have been improved on all three moons, adding a more varied break up of materials on the ground.

The team is also close to wrapping up work on the landing pads that will go with the surface outposts. These landing pads will give the players a stable, solid landing point on what otherwise might be a rough landing.

The surface of Delamar is getting its final polish with geometry and materials being updated and fine tuned. The surface is also getting an effects pass, adding an extra layer of visual interest to the environment and atmosphere. The area around Levski will also will also have more areas of interest for players to explore.

In Levski final touches are being put into the customs area: all player traffic in and out of Levski will have to go through this checkpoint so extra effort is being put into making visually interesting and ultimately hard for players to smuggle in unwanted goods. The work on the garages is close to done and ready to be included in the level: once this work is completed players will be able to request a vehicle from the garage and go out and explore the Delamar surface. The elevators in Levski have also been updated with new models fitting the modular building set that we’re using across the entire game.

The Game Programming team has been working on finishing up the remaining weapon features for 3.0 such as the railgun cover animations, delayed recoils, and delayed ADS reticle.

They also completed the first iteration of the doors and airlocks that we mentioned recently. Now the technical hooks for adding VFXs and sound effects are being implemented, and they’ll be ready for the rest of the team to use.

With the help of other engineers from both the UK and LA offices the technical design for the network code for the new weapons systems is being fleshed out and the overall research phase is coming to an end. The first test implementations will be started as soon as all other 3.0 tasks are completed.

Cinematics is working with UK Graphics Engineering to test out first working of our brand new holographic projection volume entity tech. This piece of tech essentially provides a target holographic volume with content fed from a source scene that gets rendered into the volume. It will allow us to example have larger than life characters communicating via hologram with characters in a scene or have the hologlobe switch to a scripted mode and show mission briefings all in real time without resorting to things like pre-rendered motion graphics. This tech, minus the holographic component, will also be used to get comms calls from other ships in your cockpits in real time, such as the cockpit MFDs or other displays.

As usual the team has also made great progress across multiple chapters for Squadron 42 and we look forward to showing things off in the near future.

The Frankfurt QA team started testing the new CIG DataPatcher in May and testing has continued through into June. Patcher testing is done daily as well as on the client, editor and dedicated games server copied via CIG DataPatcher. Our main goal is to make sure there are no differences between builds pulled via the new patcher and builds pulled with our current internal build tool CopyBuild 2.

CopyBuild 3 has also been rolled out to QA at the beginning of June and has been in its QA testing phase in conjunction with CIG DataPatcher.

Subsumption Editor testing continues to be a regular part of their weekly tasks as new versions with new features become available. QA works closely with Tony Z and Francesco Roccucci in order to ensure that each Subsumption Editor release is free of any thing that could block the development process.

They also spent a good portion of time testing multiplayer gameplay in the Stanton system Persistent Universe level.

The System Design team continued to expand the library of useables to be used for both the PU and Squadron 42. The Air Traffic Control is also making headway and you should be able to experience this in game fairly soon. They started work on the FPS companion/buddy AI, including all the orders you can give them, and the behaviours needed for those orders to take effect. The Actor Status system is being internally tested right now and is going through its final tweaking and balancing. They’ve also put some finishing touches to the conversation system to allow our Cinematics team to create the best experiences possible.

The Weapons team have blocked out numerous universal grip and optics attachments. They’re converting the older blocked out attachments to work with our new Attachments Rail system; and doing a quick first pass to test them on the existing guns to see how well they work and if any of the designs need to be adjusted.

They also completed the first pass blockout for the Klaus and Werner Demico which is a laser light machinegun.

For ship weapons they’ve finished the Preacher Armaments Distortion size four through six, and upgrade levels one through three. They also did a first pass blockout, including rough animations, for the Klaus and Werner Laser Repeater size one through three, the Neutron Repeater S1 through S3, and the Apocalypse Arms Ballistic Scattergun S1 through S3.

And to close out the update earlier this month a large amount of people from the office attended a local Bar Citizen here in Frankfurt. Good people, good conversation - it was a really fun time and we’re glad they organised it.

That wraps up this month’s update from Frankfurt. We all really appreciate the support and feedback you give us. We couldn’t do this without you guys and we’ll see you in the verse.

Back to Studio With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Eric Kieron Davis (Senior Producer). Timestamped Link.

EKD: The VFX work on planet environments, it’s really looking great.

CR: Yeah, being able to see your footsteps in the snow or have your vehicle kick up dust while speeding across the desert are those little details are those little details that’ll make you believe that you’re really in those environments and be much more immersive and you know me I love immersive.

EKD: We do. Another way you’ll be experiencing these environments is from the seat of a Nox, although the concept sale begins tomorrow, we have a special Ship Shape today to give you a sneak peek at this open canopy racer.

Ship Shape With Chris Smith (Lead Vehicle Artist), Patrick Salerno (Associate Technical Artist). Timestamped Link.

Chris Smith (CS): Hi, my name is Chris Smith and I’m the Lead Vehicle Artist in the ATX office. I’m currently working on the Nox bike which is a Xi'An bike made by Aopoa. It has Xi'An technology involved much like the Scout and it's, you know, a very stylish bike and it’s supposed to sort of compete with the Dragonfly. While the Dragonfly was made with a lot of sort of exploring and scouting in mind, I think, this bike on the other hand is a little bit more purposed towards either racing or combat. Going to be very fast and nimble and it’s going to be very powerful in combat.

The concept was provided from England this time, it was only a 2D concept though. Usually here we start with 3D concepts, for this bike though we really didn’t have too much time for that initial concept phase, it was worked out in a fairly quick manner and only on 2D. So this was a bike I got to actually build from the ground up, literally from the first poly from the ground up which was quite enjoyable.

So building the Xi'An bike wasn’t terribly challenging ‘cause we used Xi'An technology that uses magnet technology and it kind of made connecting points a little bit easier so we decided to have the nacelles floating and connected by magnetism and the handlebars the same way and sort of the plates slide along. We tried to infuse a lot of style of the Xi'An technology in there and use like a mix between sort of like heavy metals and exotic materials. The main challenge was to make sure that we sort of… Nathan Dearsley who helped in concepting it with Gary Sanchez, he told me that he really wanted to from afar look like this little monolithic sort of simplified thing. Sort of ominous looking shape from a distance and when you get closer it reveals more detail.

The main challenge was to kind of get that feeling across and make sure I hit that. The Xi'An technology, the skin on the bike is definitely going to be an armoured type. The rider itself is protected by the bike, when he gets on it has these sort of shells that come up above his back so the rider has a little bit more protection from behind. The main thing that sets Xi'An technology apart from like let’s say RSI or Aegis would be the rider has a much more aggressive stance on the bike then on the Dragonfly. So the Dragonfly is more the upright stance, this Xi'An bike has a race bike type stance so you’re forward leaning. It’s more racer type, your legs are back, that gives a little bit more maneuverability and also that way you can get a little shell and a little bit more protection over the guy.

I mean it’s still open on the sides and everything but you just get a little extra protection from the shells in the back. The Xi'An bike is actually going to use a holographic HUD system in order to try streamline everything and make it technologically advanced we try to minimize the amount of screens as much as possible. Once you get on the bike initially there is not going to be any screens there, there’s one little screen by you and right in front of you but that’s sort of flat and comes up a little bit but everything else will like come up as a holographic image in front of you which looks really cool and the start up sequence is pretty neat.

Patrick Salerno (PS): Hi, I’m Patrick Salerno, Technical Artist at Cloud Imperium Games. I focus on mainly destruction systems and optimization for the spaceships. Functionality too at the end I make sure things work but I kind of have a checklist of things that I got through when I’m doing the spaceships, it’s like… there’s a couple tech art passes the ships go through. In particular we’ll be talking about the Nox today and the set up that went into that, if it differs from any other ships I’ve worked on. Most of the ships you see in game I’ve probably touched in terms of either lighting or particles or damage or something during some point in the process.

I get the model from the artist, he’s like ‘it’s done’ and before this we’ve talked about how it’s going to break off, which pieces are going to break off of where. Sometimes there’s small changes down the process, we’re like ‘oh, those intakes or weapons racks might be able to break off’. You know, we can add a little bit more detail or gameplay so I’m working with design, I’m working with art and I’m trying to make sure that by the time I get it, there’s really no back and forth.

You know, I don’t have to go ‘oh, Mr. artist guy there’s something you have to do here’. So I take it from there and what I do is if we’re looking at this ship here I will look at it in Max and I’ll break it apart and we’ll say ‘ok so if the nose comes off from the front of the ship then it has to detach and fly off, how do we do that, how do we make all those pieces work together and look good’. For that I usually hop into the XML from there so before I even working on the art side of it like making the metal wear and stuff I have to work on the functionality side, where the debris happens. So… pew, pew, pew, shoot the ship and it explodes. The pieces have to fly off in certain directions, those are called vectors, those are impulses you know boom ship happens it explodes.

Now what happens is I’m kind of tying in multiple effects together at the same time, I’m saying I have particles to work with when I’m shooting the ship. So all these little green squares you see here are kind of what are called helpers in Max and helpers are all these little green squares you see and they can serve a bunch of different purposes for what we want to use them for. For my particular purpose I use them like C4 charges, like little explosives that will happen and what they’ll do is they’ll burst in let’s say a radius and I’ll set the radius in my list and on the name of it and that gets put into the XML. From there I then update the ship and I shoot the ship and I can test my new particles, so it’s a bit of back and forth right. You know, you want to go in shoot it and see what happens, check your particles, check your fire, make sure everything looks all right… if the modelers put in specific things like wires and girders and stuff and tubes, you want to take that into account when you’re putting down a particle.

Now mind you I don’t necessarily make the libraries and I go in and I’ll pick from say low tech, high tech, Xi'An tech, Vanduul tech type, you know particle libraries. So luckily these guys had a cool one, they’re kind of like high energy blue alien tech so I had a lot of fun with that, just sort of like shooting and testing it. So once I get the debris flying off, let’s move on the next phase, I set up what is called the UV2s and the damage map. That is our system where the ship actually melts and wears, now when we do the system we have to take into account the underlying surface detail, very important so the modelers will actually model girders and underlying stuff and there’s two types of underlying sort of surface detail. There’s 2D and 3D geo, 2D geo is like this… it’s called a POM, parallax occlusion map it’s this one polygon that goes under the surface of the hull no matter what the shape is. If you shoot the ship and it melts you’ll end up seeing that underlying sort of metal or girders or wires or whatever is not actually like supposed to be there so you don’t see through the ship. Polygons are only one sided, right so like it hits it that’s it but if you’re looking at the other side you can see right through. So we take that into account.

So for that to work the ships need two UV sets and in case you’re not sure what a UV set is, a UV set is what maps your texture so like the wood on the surface or some kind of other wear like thing. So UV1s are for you ship texture and UV2s are for the procedural damage map. Once we start shooting that everything kind of works in conjunction so I have my initial debris with the pieces flying off and the breakability, activating the particles which then set off say fire, smoke, electricity then spins off. Then fades out, now after I’m done with all the fun creative stuff, there’s the making sure things work and is optimized and runs well.

There’s also another layer to that, when you’re doing the shader damage and it’s doing the melty effect and it’s trying to show the underlying stuff. We use what are called vertex colours on the ship and vertex colours are basically every vertice a polygon is made of one of these little points, points are vertices, each one can hold data. We use that colour data to tell the map that it can be transparent or not so what I do is I’ll go in and all these different colours just mean a slightly different level of damage, right.

So, say for example there’s really no damage under the nose but I still wanted to show the UV2, it still looking like it’s getting denting and worn. I can set it to a certain colour that can block the punch through of the damage which means you might not be able to see the underside of the ship. Now for somewhere in the back I can do it a little differently where I can layer the damage, so if there’s really nothing under here I can set that, you can’t punch through but you can slowly whittle through different areas of the ship.

I just go through and kind of layer that across the ship and create levels of damage, it creates a little bit more randomness when you’re firing at it. Some areas will get huges hole punch throughs and other areas might look like they’re just wearing a bit harder but after I have all that setup I kind of work on the lights. I want to make sure lighting works, most of the time lights are set up by the artists themselves, the ones who are doing the ship or the lighting artists. So if they’re no lights set up which I was lucky enough to have at the time with this, I had a little back and forth with Chris Smith about it and he polished it off.

Basically I got to set up some of the lights on this ship and this was kind of fun because as an alien ship the theme was more of a high tech sort of vibe. Most of our ships have more traditional fire, sparks, smoke, etc, etc. Luckily there were Xi'An libraries and some high tech libraries I got to play with for this ship and when I was shooting it, different weapons have different effects. We shoot this we see we get sort of melty burny wear. If we pull out a rifle we get bullets, now the bullets can sort of tear a hole in the ship which is fun, boom. Then change the lighting additions, fire, smoke, etc, etc.

So at the end that’s how all the pieces come together, the process takes a bit longer than that but at the end it’s pretty fun and just sort of picking which pieces explode and killing the ship and I mean it’s important to take into account the functionality of the ship when deciding how it’s going to be destroyed. You know with this guy there are really only two or three pieces you can blow off like nose, sort of the seat area and the tail. So how do you make that look different every time you want to blow up the ship, you know, I don’t really like when damage always looks the same so my goal is to add sort of randomness variety to it.

One more cool thing I have to show is this new debug gun we have for testing the damage. Normally I shoot it, I use different weapon types to see what happen if you’re going across a ship but we have this thing called a damage gun now for debugging our materials. See all I have to do is look at the ship, this doesn’t help me with actually blowing off pieces of the ship, that still doesn’t quite work but that’s where I shoot the ship with an actual gun.

You can see I can test out my damage map which you can see up here in the corner then that wears away, this is what I was talking about with the transparency, you can see it slowly eats away at the ship so if there’s really nothing under there I don’t want to actually expose that to the player, right. So I just do the vertex colours that you see over here to block off certain areas like this has lots of vertex colours. I’d say that’s pretty much it then I test it all and I bring it all together and I give it polish then I hand it off to the final people for functionality and testing.

CS: Working on the Xi'An bike was actually pretty neat because it was the first non-ship that I got to build for this company. I did use bike references for some of the details like engine details because the Xi'An are sort has a naked bottom it’s not totally covered. It shows some of the mechanics so I definitely used some real life motorcycle references for that and I’m into motorcycles so I was really glad this fell into my lap. Very sexy so I had a lot of fun working on it.

Back to Studio With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Eric Kieron Davis (Senior Producer). Timestamped Link.

CR: As Chris Smith mentioned building the Nox was made easier because the Aopoa ship pipeline was already established. Having such systems in place are key to reducing development times going forward.

EKD: Yes, especially building a game of such size and scope. Another example of the SolEd tool we’ve created to make building solar systems easier.

CR: Yeah, that’s right. CryEngine as you all know wasn’t meant to handle game with maps the size of an entire solar system let alone even 10 or 20 km across. So it made placing objects difficult and time consuming, so now let’s take a look at what it takes to build a solar system from scratch. beh

Behind the Scenes: Building Solar Systems With Cherie Heiberg (Archivist), Dave Haddock (Lead Writer). Timestamped Link.

Luke Pressley (LP): I'm Luke Pressley. I'm lead designer on Star Citizen Live.

Cherie Heiberg (CH): Hello, I am Cherie Heiberg. I'm the archivist here at CIG. [Waves]

Dave Haddock (DH): I'm Dave Haddock. I'm the lead writer over at CIG.

LP: Recently I was on a BritizenCon panel, and I got asked if there are any unsung heroes in the Star Citizen tech. Things were … aren't flashy enough to get their own kind of featurettes or anything, but which make our lives possible kind of thing. We're building a solar system. Well, we're building a galaxy. So, how do we build a solar system? We recently got a new tool called the Solar System Ed, or SolEd as we call it. It was something that was kind of … we made the brief here and then Sascha Hoba in Germany actually built the tool. What it allows us to do is ... well build a solar system. Build a hierarchy. I bring in a sun, and then I give it children which are the planets. Then I give those children which are the moons, and then I can give those children which are satellites, and I can very easily give them an orbital distance and just have created the whole thing in a matter of minutes, and that sounds really simple. It sounds like something we should have been able to do from day one.

DH: When we started getting close to the deadline for the Star Map we had to do a kind of heavy internal push to generate a lot of star systems. We were sort of thinking you know all of this would be cool to have a system like this and oh it'd be cool to have a star like this and you know astronomy virtually every day you're finding new cool stuff that's happening so it's … we're trying to get as much of that stuff in there. We were sort of faced with this thing of like, well we should probably see cause there's such an emphasis on like realism and while it may not be entirely accurate, like plausible ...

CH: Yeah, yeah.

DH: … I think was sort of the term.

LP: When we were building Crusader for instance for 2.0 what we'd have to do is we'd bring in Crusader, and we'd set that down at the origin, which is 000 in the xyz, and then we'd bring in the moon, and that would be on 000 as well. To get it to the right orbital distance we'd have to move it in either just the x or just the y away from the planet, and that's in meters as well. So, you can imagine how many meters away a moon is from a planet, and then obviously if you've got three of these moons you don't want them all at 90 degrees from the planet, so that means you've got to add some rotation on. Which means what we had to do was like we'd put down another object in the middle of Crusader at the origin, and we'd physically link it to the moon, and then we'd start twisting that would move the moon around too, and you wouldn't be able to see it, cause it'd be too far away, and at the moment you've moved it off of like pure z or pure x or pure y, sorry. You've lost that one pure number. It becomes some … two numbers that you have to do maths on to figure out. So it's not … it wasn't allowing us to be able to change what's in future. Imagine if this scale changed. We'd just have to start again. What the SolEd allows us to do is if we change the scale of the Universe, we just scale down the numbers for the orbital distance away from its parent. Like in a matter of minutes you would have a rescaled solar system.

CH: We try our best to make things as accurate as possible, but still respect the need for the players to actually enjoy what we have.

LP: So we got a bunch of astrophysicists. The writers gave them the brief for each of these solar systems. They went away and came back with this spreadsheet that has an unbelievable amount of data in there … more than we could ever use.

DH: There's a service that actually, a collective of scientists and researchers and stuff like that who basically volunteer their time to screen writers, video games, stuff like that. You can contact them, and they basically will put you in touch with an expert.

CH: Yeah, there was an astrophysicist who had served as a consultant on other properties before. We learned about star types and green bands and how long it takes to evolve life and the density of asteroid belts, and we basically got a crash course on how to build a system from scratch if you're not a scientist.

DH: They went to town on this, so the list that basically Cherie worked with them on was like everything from the size of the system itself to where's the green band start, where does it stop, where does the frost line start, [Counting On Fingers] daily rotations, orbital rotations, perihelion. I mean I'm going to throw out terms that I don't know what they mean but like the odd orbital patterns, you know inclination, decli ... all this stuff.

LP: We kind of just take for now the size and the distance from ... the orbital distance from it's parent, but obviously things like the density will affect the gravity of the thing eventually. It even goes into details like how the mass of an asteroid ring. So if you took all of the asteroids and combined them together, what the mass of that would be. It's extremely detailed and these guys know what they’re talking about, so our solar systems are going to be extremely realistic. Obviously we scale it to keep it at a playable, because no one would actually wants to drive around the Earth, but also to keep the tech working we can't make any planet say bigger than Earth right now, so that means we have to bring everything slightly in so that we can do these super-Earths like ArcCorp.

CH: They were able to build the systems with respect to orbit … they didn't want to cause like a bad orbital resonance situation, so the planets were a certain amount of au apart and in a certain position so that the orbits wouldn't fling planets out of the system. So, an au is an astronomical unit. It's a standard unit of measurement used in astronomy/astrophysics, and it's the distance between the Earth and the Sun. It's used so that you can easily communicate vast distances in solar systems. Our solar system for example is around 50 au if you include the Oort Cloud and Pluto and all of that. It's basically so that you don't have to say something like this system is 575,809,000,000,473 kilometers.

DH: It'll factor in based on what our time dilation system is, like how long a day is in the game. Whether it's that set of scale, because it might actually in a weird way (I don't know about the formula), but it might actually balance out. That basically if the time was running at a tenth or 90

percent faster or whatever then it would equal out the distance travelled would make sense if you scaled it back to normal time.

CH: I think it was almost a year trying to get all of the numbers in and we went through many processes of going back and checking to see whether or not the numbers that they gave us reflected consistently with the lore we had given. Whenever we had questions about stuff that we wanted to make real but couldn't we'd talk to the astrophysicists, and they would usually give us good ideas. There are some things we weren't able to keep entirely real like asteroid belts for example. In real life asteroid belts the distance between asteroids is so vast that it wouldn't pose an issue or an obstacle in any kind of race for example. You would just mosey on through it. It would just be like going through regular space. Asteroid belts in our game are denser. It's not like real life, but it's a lot more fun.

DH: And also we would have situations where they would say, “Hey, you know what you have presented in the lore is not possible, but what you can do is if you change this, this and this it's a minimal retcon for the backer's perspective, but it will kind of pull it into scientific feasibility”, which was sort of the middle ground we kind of aim for, but the thing we also learned is that space be crazy. You know, oh this can't happen, and then a week later something would come out and the NASA or someone would be like oh by the way there's a diamond planet, and we're like. [Throws Hands Up In Resignation]

CH: Yeah there's a diamond planet. There's a planet where it rains glass. There's a stellar cloud that tastes like raspberry schnapps. Space is really weird.

DH: There's a gas giant that's the color of coal like pure pitch black that we stole.

CH: Yeah, we definitely stole that. [Chuckles]

DH: Yeah, space be crazy.

LP: The things we're placing with the SolEd are obviously right now they're procedural planets. Crusader will be a different entity, because it's a gas giant. It'll be a gas giant entity that we've not got the tech for yet, but we'll have an amazing shader that goes around it and creates these wisps and eyes and storms. Obviously we can also as I've said before plan … put satellites going round and things like that. We also placed for the asteroid ring around the solar system with it.

CH: They are building the systems on a one-tenth scale. So, for example, if we have a system that's 200 au in our notes it comes out as 20 au in the system that the designers are building. So that number one it's a lot more fun for the players this way, because systems that if we had a 200 au system it would take I don't know years for players to get across it even. It's such a ...

DH: It's a ridiculous amount of time.

CH: … It's an incredible distance, so we needed to scale it down so that number one it would be fun for the players and number two that we could build the whole thing in it seamlessly within a origin.

DH: Quantum travel is kind of locked at around one-tenth the speed of light, so even at that you know it's going to take a really long time ... [Chuckles]

CH: [Laughs] Yeah.

DH: … to fly from place to place. With real long haul travel things it's going to take … I won't say where the example took place, but there was a situation where something was going to be traveling in quantum travel for twenty minutes, so you know …

CH: Oh yeah.

DH: … break out your cards …

CH: Yep.

DH: … and load up your Netflix queue. While you're in quantum travel you could get up out of your chair … I mean considering you have a multicrew ship, you'd get up out of your chair and stuff like that and if something yanked you out of it, then you'd have to run back. It's also the thing that quantum travel, travels … the idea was that quantum travel only moves in straight line. The reason why you don't … your body doesn't liquify is that there's this sort of antigrav bubble around you, but because you're moving in a straight line you're not getting that sort of the intense pressure, but if you were to turn suddenly you'd go flying against the wall at one-tenth the speed of light which would probably hurt.

CH: Yeah might, might hurt a little. Just a little bit.

DH: It feels like this sort of adherence to you know again even at like a one-tenth scale I mean … in 3.0 we're starting off with the moons, the moons of Crusader, and I mean they're huge. It takes 15 hours to drive it like around once. The interesting balance is going to be how do we achieve this sort of like the crafted experience with the massive scale like that vast openness, but still feel like there's you know that there's interesting flavors to all the places you go.

CH: My hope is that the players will see the numbers that we have generated for them, the care that we've put into designing these systems, and we'll know that they have all this information at their fingertips and know how real we want these systems to be for them.

LP: We will never be able to create one solar system, let alone the hundreds of solar systems we're going to be able to … we're going to have to make. If it wasn't for this tool you can imagine the amount of hours it would take to hand move these out, because the CryEngine was never built to do this. Again I say it sounds extremely simple, and it is a simple tool, but it wasn't there out of the box.

Outro With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Eric Kieron Davis (Senior Producer). Timestamped Link.

CR: So an incredible amount of work went into coming up with over 100 systems and scientifically vetting them. Now we have all the information it makes it easier to build them in SolEd.

EKD: For example, the Stanton system which we’re currently building out is just over 800 million kilometers across even after scaling it down by a factor of ten.

CR: Yeah, that’s a pretty amazing amount of distance. So anyway, that’s it for today’s AtV, thanks to all of our subscribers for helping us make shows like this each week.

EKD: Yes and thank you to all our backers, we really couldn’t do this without you. If you’re as excited as I am to hop on a Nox and speed across a planet, don’t forget to check out the concept sale tomorrow.

CR: Yeah, definitely check it out. Until next week we’ll see you…

Both: Around the Verse.

StormyWinters Director of Fiction Moonlighting as a writer in her spare time StormyWinters combines her passion for the written word and love of science fiction resulting in innumerable works of fiction. As the Director of Fiction, she works with a fantastic team of writers to bring you amazing stories that transport you to new places week after week. Sunjammer Contributor For whatever reason, this author doesn't have a bio yet. Maybe they're a mystery. Maybe they're an ALIEN. Maybe they're about to get a paddlin' for not filling one out. Who knows, it's a myyyyyyystery! Desmarius Transcriber When he's not pun-ishing his patients or moderating Twitch streams, he's at Relay pun-ishing their patience as a member of the transcription staff. Otherwise, he can be found under a rock somewhere in deep East Texas listening to the dulcet tones of a banjo and pondering the meaning of life. "If you can't do something smart, do something right." - Sheperd Book

Please enable JavaScript to view the comments powered by Disqus.