Star Citizen Live: Building a Vehicle Experience

Last year was crazy. We launched a completely new flight model, completely revamped flight model. That was a long time in the making, that started in 2018. So we launched that, and that was a huge learning experience, especially because it brought in renewed interest among the community to chat about the flight experience, and we learned a lot about the combat and flight in that whole process. And then we also went forward in the year with more improvements. We tried hover mode, which ended up not being exactly what we wanted, but we learned a lot in doing that. And so the subsequent changes that we've started to implement, like proximity assist, are on the back of that learning that we've done with the community. So we think we're getting better and better as time goes by. And so hopefully in 2020 we can take all of that learning experience that we got last year from the community and make it even better.

How about you, John?

From an overall side, 2019, we sort of reorganized a lot of the vehicle teams. We introduced Pillar Talk last year where we briefly talked about what the pillars are. So the vehicle teams got their own pillar. And it's essentially five teams within that vehicle pillar now. So there's two vehicle feature teams, there's two vehicle content teams, and there's the new vehicle experience team. And putting them all together under one director, myself, and working with the other directors, has enabled us to do a lot better planning in terms of: this team's going to be working on this, they're going to need some support from this team, it ties into the content. At the start of the year it wasn't quite there, but as we got towards the end of the year and into this year, we're starting to try and deliver on ships with features coming with them. Maybe it's not the full feature, maybe it's just a taste of it, but it allows that ship to sort of work with that. And then content-wise, we had ships of all sizes last year, which was a huge learning experience. So we had the Archimedes, which is one of the smallest, if not the smallest, ship in the game. And then we had the 890 Jump, which is 200-odd metres bigger than the Archimedes. So we learned a lot about those two very different styles of making ships. The Defender as well was a big challenge last year in terms of learning alien art styles. The first ship of a new race or new manufacturer is always a tricky one, and we learned a lot planning-wise on how to accommodate that, that's gone into the Prowler, and then we'll go into the Merchantman as well.

So a feature team is primarily programmers with design support, and then we sort of dip into the other downstream teams. Maybe we'll be doing a feature like hover mode. So Dave would be doing programming, we'd have the design team retuning the ships, we'd need tech art to help make the thrusters behave visually how we want. Content teams is primarily just the ship art team and design, and then those same downstream teams. So they're making the actual ships. The feature teams are making the features that make the ships ships.

And then of course, kind of outside the periphery, you have the gameplay system designers who are doing things like mining or salvaging that are designed independently of the ships.

Yes, so the vehicle teams use those features that the other gameplay teams do. So we have other teams like the actor team who are dealing with things like healing and body dragging and all that sort of stuff, that are not vehicle-specific features, but vehicles will use them. Mining, yeah, a good example of something. So whilst the first instance of mining in Star Citizen was on a vehicle, it was developed as a general system that was then expanded into handheld mining.

So it's called Vehicle Experience because it sort of covers everything about the vehicle experience. It's not just limited to combat, of how vehicles fight. It's the whole living, breathing aspect of, it sounds cliché, but experiencing your ship. Because combat's like a byproduct of a bunch of other features. It's a byproduct of flying. So if flying your ship doesn't feel good, fighting in your ship doesn't feel good. If interacting with things in your ship isn't good, then flying your ship is going to be bad and then combat is going to be bad. So it's sort of a holistic look at all these features that tie together the vehicle experience, and working on them. So the first thing the Vehicle Experience team worked on was the new or improved camera systems, which went out in 3.8. We had a prototype of this years ago and it was like, that's a really nice thing, but we've got other things to do at the time. So it's sort of simulating how TrackIR or other head-look programs do when you're flying and you look into the turns like a race car driver does. And whilst functionally it doesn't give you any benefit to, on paper, how ships behave, it makes that experience much more realistic, it makes it much more fun. It doesn't look like there's just a 2D printout of a ship cockpit stuck on the screen. It makes it feel alive. You start feeling the ships, they have their characters to them, it makes you have fun in the ships. Even though you're just flying around like you were in 3.7, it adds that extra layer to it.

A lot of the Vehicle Experience team is about supporting feature teams as well. So when feature teams are working on a feature, the Vehicle Experience team can provide guidance on how that feature might interact with other systems, so that the whole experience stays consistent along the lines that we want it to.

So the main thing that we want with landing aids is the old radar-like view of the landing pad that we had in [...]. The problem with that is that it's a really complicated piece of 3D UI. And if you remember from the CitizenCon UI talk, a lot of the UI tech is being revamped at the moment. And one of the current focuses right now in January is 3D. And so we're working with them at the moment to add a lot more 3D elements to all of the UI, HUDs, MFDs, etc. And obviously one of those things is the landing UI. So once that 3D UI tech is developed a bit more, we're going to come back and rebuild that landing aid. And then that, in combination with lights facing down or cameras that face down, will help that whole experience.

The first thing we did with the new Building Blocks UI was the 2D, because it's the easier side of it. And we saw that in the CitizenCon demo where you had the elevator panels that were the actual buttons you interact with. So that would traditionally have been all Flash, which is great. You make that one elevator panel; in another ship, now you make another one, and it's duplicating it all. Whereas with Building Blocks, it's just sort of inheriting of style sheets, as a very simplistic way of putting it. And then 3D is the next step. So we do actually have some very primitive 3D support now, but it's a whole different ballgame from rendering a cube to rendering one of our ships on it.

And when you mention lights and cameras, I want to make sure that folks know those are things that we're exploring. This is not a guarantee that every ship is going to have a camera system underneath it. It's just we definitely know that there are ways to make landing easier.

Yeah, there's a lot of ships whose lighting state is suboptimal, and we want to go through and fix those. So primarily you have the headlights, so you can actually see where you're flying. Some of them are a bit too dim. Some of them are broken. Those will get fixed. And then we're going to look into having, when you're in a landing mode, landing lights that come on that show you, like a real-life plane, a more illuminated area beneath you.

So I'm going to assume that's talking about physically based damage and armor. So that is in production at the moment. It's something that Chris is actually... He's got a local version of the code where at the moment we define mass by a value in the XML, but how it's going to be is it's going to be defined off the actual vehicle's model and materials. So if we make a ship out of a plastic material, it will work out the volume and the mass of it from that, based on the materials that are applied. So it will behave like a plastic ship, versus someone like me putting 10 million tons in the XML. So that's the groundwork for it. So the ships will be physically, weighted is the wrong term, but they will be appropriately massed, appropriately designed and set up with all the materials. So if it looks like metal, it's going to weigh like that. If it looks like carbon fiber, it will be lighter and have the same tensile strength.

So it's not just a measurement of the volume, which is kind of what we're doing now.

It's the volume plus the material. And then the ships aren't just one material. So there's sort of various aspects of it. You might have a ship whose body is made of a really dense metal, but its wings are made of paper. Those will behave differently. So when you shoot bits off, it will not all just behave like, oh, this is 10% of the ship that's fallen off, so take 10% of the mass off. It will work out like that. And then that drives into the next step, which is penetration, drives into armor, moving away from just removing hit points to sort of adjusting the strength of the material. It all starts happening now.

So you need the system where it does the dynamic mass.

The start of the system is we need to work out what the ship is programmatically, because marking it all up is how we do it now, and that's not sustainable or usable for the desired end system. At the moment we go: left wing has 500 hit points, right wing has 500 hit points, left end wing has 100 hit points. We're going to move to: it's the left wing, it's made of this material.

We're a lot happier than we were a year ago, that's for sure.

Bits and pieces are getting to where we want them to be, but there's other areas that are definitely not.

So one of the things that's obviously a well-known upcoming feature this year is the thruster efficiency curves. That's probably the most explored feature that we're working on at the moment, and part of that necessitates an aerodynamic rebalance of the ships, because that's one area that I think is suboptimal at the moment, the aerodynamics. It's pretty cool and it's pretty good, but especially when the thrusters are much weaker in atmosphere, the ship behaves differently than it has done before, because before the thrusters could overpower the aerodynamics, and now they're not so able to. And so we're working a lot on both how the aerodynamics is calculated, how the drag is calculated and worked out on ships and stuff. And that will hopefully improve that whole experience. And we're also adding jerk, which is the next derivative after acceleration. So that will make the ships a lot smoother and more dynamic feeling, maybe not quite as rigid in their movements. And that will be something we work on in the future. And hopefully those two together will really make the ships feel a little bit more, especially in atmosphere, and in space, a little bit more alive, a little bit more interesting motion.

Those two things are sort of what we're trying to get to: the end goal of what hover mode was trying to achieve in atmosphere, but doing it a different way.

I want this to get to something that feels more different. Right now, the atmospheric flight is space flight, but with this extra thing pushing on your ship. And we want to get it to more like how real planes fly, but with differences that are caused by how spaceships are designed. So for a lot of ships, they're not very aerodynamic, and so the way that they fly with pretty strong thrusters, even if it was perfectly realistic, it's still not how a plane would actually fly. And we want to try and capture that, so that if you fly other plane games or you have some experience with how planes fly, you will realize that, oh, I can see how this is working, but it's a whole different experience because of how this ship works. And that's the experience that we want: an interesting, deep aerodynamic model that's something new, that seems like it would be the most realistic outcome, given the way the ships are designed.

Realistic by today's standards, but then 940 years advanced in the future through the additional technology.

I say realistic, but it's our guess at what realistic flight might be like in 900 years. That's really what it is. Because nobody's flown a spaceship 900 years in the future in the atmosphere.

So it was a really interesting experience, I think, for all the departments that were involved in it, because it was almost cross-company, across every single studio that we have in CIG and Turbulent, to pull it together and deliver it. I don't think there's many features Star Citizen has where it touches every single studio that has to pull together. Normally there's a couple of studios and then one might support, but we're all working on it at the same time. So we learned a lot about cross-studio, cross-time-zone communication and planning from that. We learned a lot on the art side of the technical limits of what we could do. Something we wanted to do was proper interior material customization, and we didn't have the ability to do that. So what we did was these seats and beds that gave you that experience, and we made the interior of the ship sort of respect all of those various combinations. We tried out all these interesting interactive props; they took a lot of time, and I think they were actually one of the most popular bits of it. What we thought would be really popular was the paint, but it wasn't as popular as other aspects that we had done. So we learned what people liked, what people wanted, got a huge amount of feedback from the community on it. In terms of manpower, doing something to the extent of the 300i again is equivalent to another ship in the pipeline. So when we choose to do another one, you sort of have to bear in mind that it's that block of time. It's not like a one-week task to knock out a few paint jobs and these items. There's a lot of time and a lot of people that go into doing that.

Presumably the second time would be faster, more efficient than the first time. Because the first time is always about all these lessons that have to be learned, quite honestly, the hard way.

Yeah, it would absolutely be more efficient.

Still, though, it's a pretty sizable outlay. It's not to say that we're not going to do it. We absolutely are. We're committed to it. We really like this idea. I know Chris is behind it. It's just a matter of finding the right place, the right time, the right situation in order to bring it back. Definitely got plans to do more of it.

Yes, it will. The new shield tech... so previously we had a mesh.

Every part of the ship has a duplicated, expanded mesh that is what detects the shield. As you can imagine, ships have lots of parts. It's easy for bits to not quite mesh together.

The way the new shield tech works is we have a thing called an SDF, which is a signed distance field. It is a field around the ship that encodes how far away every point is from the ship. And so using that, you could say, here's a bullet, and then ask this SDF how far away you are from a surface on the ship. And that's all calculated programmatically, dynamically. It's not a mesh. And so it's much more reliable at figuring that out, and it's not going to have any holes, because it's just programmatically generated from wherever the ship's shape is.

Unless the ship has holes.

Sort of twofold. There's the actual teams making use of these signed distance fields, like the vehicle feature team will be working on making the old shield system use the new shield system. We've got bits and pieces done, that's fine. Once we've done that, then the VFX team have to essentially go and re-author all the shield effects for all the ships, because at the moment you have the blue sort of splashy effect and you actually have hit effects coming off it. Because the old system uses something completely different to anything else in game, they need to make a new shield hit effect for SDFs. So they've got to do all that. But one of the biggest challenges is actually on the core engine side: this is a new file format that has to be baked into our existing assets. The resource compiler, when we're making the builds, has to automatically do this. But to do it, someone needs to mark up what of the ship it should be made from. So it's working out all these core pipelines: a tech artist has to go into the ship file and go, the ship is these parts. Because if we just let the compiler go, 'I'm going to do everything in the ship', it's going to be making SDFs for the buttons on the cockpit or the joysticks, which is just unnecessary time to compile and hard drive space for actually building these things. So we want to only use the exterior. So someone has to go mark those up. Then we had to make it so the builds actually picked up that data and generated it. And then there's a little bit of work still to come that's not blocking us at the moment from progressing, but a lot of our ships animate.

Right, the signed distance field has to adjust.

It has to dynamically adjust to those things, because in the old system it was just a part attached to the wing. So when the wing animated, it moved with it for free. Signed distance fields don't do that out of the box. And it's not just using signed distance fields for shields. We want to use it on other things as well. So that same signed distance field we'll use for atmospheric entry. So at the moment, when you come into an atmosphere, you get the glowy stuff on the front of your ship. If you went in backwards, you'd still get the front bit on the front of your ship, because it's just attached to your ship in that area. And we could do one for every single area of the ship to account for that, but that's just a huge amount of work. So the signed distance field will allow us to play that effect on the appropriate face when you're going in. Assuming you're going fast.

So we do actually have two standards for ports. So we have the circular ones that you see on a lot of ships. Those are two meter diameter, so it's big enough for a player to just walk straight through. If the docking collars are side to side, you'll literally just be able to walk through them. Any that are circular will be two meters diameter. If they're not, those ones will be changed. I think there's one on the Reclaimer that's like 1.8 or something like that. Things like that we'll go and change. And then we have the rectangular ones. The best example is the one on the front of the Hammerhead, in the mouth. It's four meters by two meters. That's the larger capital ship standardized docking port. So the Idris has them, the Javelin has them. Space stations support both of those. When we have docking in-game, we have these, like you see at an airport, a jet bridge that goes out, and on the end of it is a small round one and a large rectangular one. Any ships with docking collars would be able to dock at any space station that has that. And square peg, round hole: round ones to round ones, square ones to square ones. We don't really support a small ship with a round collar docking onto a larger square one, because the larger square one is probably going to take half the ship inside it trying to dock. It's not to say in the future we might not have specialized docking or boarding ships that do some funky two-in-one door, but those will be the exception rather than the rule.

So most of that work's already been done. Those ships were built, or they were rebuilt previously, to those metrics.

And manned turret access hatches, they're also two-meter diameter, so when turrets get blown off, there's another way into your ship.

Yes, it's still planned. The extent of it, we're still sort of going backwards and forwards on. We actually had some discussions this week on it. Obviously with the Origin customizer, we provided preset colors for that. That is definitely something we're going to do. How far we let users customize the colors beyond that is still to be determined. But what we do want to definitely do is let users pick emblems or decals to go on their ships, naming their ships. Obviously, they'll have the serial numbers put on there. And the emblems themselves will be from a pre-selected pool of things. So I'm trying to think of a good example. The Vanguard on its upper wings has like a 42 decal on it, and it's 42 on the tail fins as well. That would be a generic decal slot. So when you go to a paint shop in game, you'll go, I want to change that from the default, I want it to be a big smiley face or a star or something, and then apply it to all of those things.

For those of you who remember very early conversations about the potential for uploading emblems or decals, this is not to say that that's not a possibility. It's just that's not in the design that we're looking at right now. You start with what we can do, with what's internal, with what we can provide you first, and then we examine those possibilities afterwards.

Having a nice preselected pool stops what we all know people will do. Solves some problems.

There's a few parts to this. And one of them that we're focusing on more at the moment is the MFD screens, because the MFD screens are obviously a big part of how you interact with ships. And so we're working on an MFD rework that will come in the future, and part of that discussion is obviously how MFDs are going to work with multi-crew and what that system is for doing it. So we're still working through this, but obviously we are exploring the options of having unique MFDs for certain stations in ships, or having maybe some kind of permission system where you can allow certain players in certain seats to control certain things about the ship. Because right now, in a lot of ships, when you sit down in the pilot seat, it takes MFD control away from the other seats. And so there isn't really any adequate multi-crew gameplay there. So that's the first part. And then I think, John, the other part of multi-crew is more physical things that you can do in the ship and interact with.

Going back to the eloquently put murder bus, it's not that we don't like murder buses.

We'll continue to have murder buses. It's just we want more.

A lot of the multi-crew stuff at the moment is purely because turrets are the best way of getting people in a ship and doing something. The Mole expanded on that nicely, so it's less lethal. We've seen people having huge amounts of fun together in a group, communicating and working together to get the best they can out of that ship. Outside of the UI, it's making sure the ships have reasons to work together. A big thing we're missing is having the items inside the ships and having them be damageable and repairable. As soon as you have that in, there's your engineer role out of the box. That gives someone something to do. The UI side helps pilots and co-pilots work together, helps a captain control his crew, hopefully, navigators setting stuff. All of that requires the UI to work together. Because at the moment, like you say, when you sit in a seat, you grab control. It's very binary. The person that was in the other seat doesn't know that they've lost control. So they're trying to press the buttons, nothing happens, because the guy over here now can do that. And they don't see what each other are doing, so that's a big failure.

It can often look like a bug, actually. I was using this panel two minutes ago, and I come back to this panel and I can't use it. It's because somebody else is sat in some other chair.

Especially if you're sat somewhere away from the bridge, like on an engineer station, you're just happily moving power around, you're seeing stuff happen, and then someone just gets in the pilot seat. They take control. You're doing this; it doesn't do anything anymore.

They do actually have a small amount of aim assist at the moment, but it's not enough, or sort of appropriate for what we're doing. So we want to add gimbal assist to turrets, which will help sort of smooth out the turrets. It's one of the tricky things to do, because the ships are moving so quickly. So one of the other things Vehicle Experience is doing is trying to bring those combat ranges in. That was one of the goals with the new flight model, to sort of bring it in, and we've been slowly working over the last year to try and do that. We're aware people aren't fighting as close as we want them to, which in turn makes turrets worse, because you can't see what you're trying to shoot. So putting gimbal assist on is not the ultimate solution. It's one of the solutions to getting turrets better.

Turrets have been a struggle for Star Citizen. I don't think that's a mystery to anybody. We've made a number of improvements. There were some improvements in 3.8. It's still not quite where we want. When we talk about adding additional aim assist, because there is a little, we do want to make sure that we're not taking the skill away. Combat in Star Citizen should still be a skill-based affair. This is more about making that experience a little more enjoyable for people who don't focus on combat.

Especially as turrets are a very defensive thing. Some ships are offensive, but the majority of the time you're trying to stop someone from damaging your ship. So any help you have in that regard... Unless you're in a Hammerhead. I find the Hammerhead is a very offensive turret ship.

That is an excellent idea. We're evaluating ground vehicles as well at the moment.

Yeah, they're another thing, like turrets, that we know they're not where they need to be.

That idea is really cool because it sort of unifies that control between space vehicles and on foot and ground vehicles. So we'll add it to our pool of explorations and ideas that we'll evaluate when we look at ground vehicles.

On the surface, this seems like a good idea. Sitting here and hearing it, I can't think of a reason why it would be a bad idea. But that's why it's important to put these things through testing, because all games, but especially Star Citizen, are a combination of a myriad of game systems that are all working together and all interacting with each other. And standing on its own without any interactions, it might work fine. But with a dozen other systems that are at play inside a ground vehicle, it may cause unforeseen issues. So it still needs to be explored, it still needs to be tested, it still needs to be vetted before we can sit here and say, yeah, we'll do it.

So that's actually something that I have to do once I get out of here: I'm going to go over to Tech Art's desk, because they've actually gone and done this on a few of the ships. There are problems with that. The current sort of ledge grab system we have doesn't do a check for what's at the end of the ledge. So say you've got the Cutlass side doors that open. We've got a ledge grab on there. You go run up to your ship, you ledge grab in. Great. Someone shuts the doors. It's still going to try and make you do that. It's probably going to be a coin flip of: do you just go straight through the doors, or do you hit the doors and fall back out again? It's something we want to do, but we want to do it in a way that's a bit smarter about it. If the doors are closed and you try and ledge grab up, just don't, rather than go through the whole state of checking.

It's worth pointing out as well that that kind of engineering decision, that has meant that that check doesn't happen, is usually because of a trade-off. In a lot of situations, in environments, a check like that is not necessary, and putting one in would be a cost to performance that maybe is not worth it. But in the particular case of a ship, maybe that cost is worth it, or maybe there's another solution that isn't as expensive.

The other aspect of that is the doors not opening all the way down to the planet. That's another case of making them, rather than just be a canned animation, systemic or procedural: opening them to the point they hit the floor and then backing off a tiny little bit, so they don't lift the ship up. So we tend to be safe on the amount we can do, which, as people have seen, when you start landing at really funny angles and you've got one leg off the ground, puts the ramps into this position. The two are sort of tied together. There's things we can do, but often they cause more problems than they solve, and we need to be smarter about how we check it.

Maybe, yes. However, part of the reason why the speeds are lower now is because when we re-evaluated grav-lev with the new flight model, we decided that we wanted it to be closer to the ground and a little bit more exciting. With the old grav-lev, you ended up riding over the rocks and trees.

It was more like flying low than being on a speeder or something.

We wanted it to be down close to the ground, stuff flying past you at full speed. But the problem with that is that there's a lot of obstacles. There's a lot of rocks. In some situations there's trees. There's a lot of obstacles. And so traveling at super high speeds makes the gameplay just really annoying, because you just constantly hit things.

And you never get to those speeds anyway, because you're hitting stuff.

So that's why the speeds are lower. But if, for example, we find a solution to making that less painful, then yes, we could potentially increase the speeds. Or maybe there's some places on planets where there's not as many rocks, and then we can let the speeds go higher.

It's all about trade-offs, like we mentioned before. We didn't just take it away because we wanted to. There's reasons for doing that.

I have a really good answer for this. This is interesting to me. So currently what we do is we voxelize the ship. So we take the shape of the ship, we break it up into little cubes, and then in each of the dominant directions, we'll calculate the area of those cubes. So we get an idea for the surface area in different airflow directions. And then we'll use that surface area to control how strong the drag is. So for example, if you're flying a Gladius like this, the surface area is this little tiny section here. If you fly like this, the drag is significantly more, because it's this huge section. That's what it does now. But there's another bit that's complicating this, which is that on a lot of ships, the main thrusters are super, super powerful, and they can overpower the drag a lot of the time. And so this is what we wanted to do with that thruster efficiency curve thing: because we've reduced the strength of the thrusters, the top speeds of the ships are now significantly lower, because the drag was so high previously. So now we can decrease the drag and make it more in line with what it should be, because the thrusters are so much weaker. And then it behaves a lot more correctly. But there's an extra thing that we're exploring, and we're just in the early ideas of seeing if this would even work, which is using the SDF tech that we're using on the shields to work out the shape of the ship, so that instead of just having a surface area in front of the ship, we can use the SDF to figure out the actual shape. So for example, a wedge shape like this would behave differently to a shape that's a flat wall like this. And the SDF would give us that information. And depending on how that exploration goes, that could result in the shape of the ship mattering a lot more than it does now, because you could have two surface areas that are the same, but they have a different shape, and so they'll behave differently. And that will make a huge difference, assuming it works.

We touched on that a little bit before. That's pretty much a similar answer. So there are issues with MFDs that are what we mentioned before, which is that the permission system is pretty simple. So when someone sits in a seat, you lose control of the MFD. That's one issue. That's a huge issue. It comes up a lot. But there are other issues.

Usability is a big one we're going to hit, because really you're forced into using a mouse and keyboard on them, and we want whatever device you're using to be able to use them, and to use them quickly, because there's nothing worse than trying to use a really finicky small [...]. I think we'll come back at some point to talk about MFDs.

We've got a lot of stuff that we're exploring with that right now that's really exciting. There's loads of stuff we can do, like saving the state of your MFDs and maybe customizing them, navigating with a joystick, all sorts of stuff like that.

There's loads of neat things that don't actually add anything to the functionality but help the experience of the ship as well. At the moment, when you get out of the seat, the frame you hit exit, your screens go off. We'll be able to keep them on. Because when you get out of the seat, it sort of looks like your ship turns off, because your screens go off. We'll be able to keep them on. Other people will be able to see what you're doing on your screens, rather than just looking at someone mindlessly moving a blank screen around.

So we chatted about this some time ago. Right now the thrusters have this safety feature where they'll turn off when they start to get uncomfortably hot, in the same way that a CPU turns off when it gets too hot. But we had discussed the idea that you could optionally just not have that safety feature and push the thrusters to be hot. And they'll be damaged, they'll be worn, they'll take physical damage, and maybe they'll start to fail and misfire. But if you wanted that, you'd get it.

The sort of byproduct of the quite short amounts that we have at the moment is you don't really notice the granularity of that. Quite often if you're trying to afterburn out of atmosphere, you just go straight through the warnings of thruster overheating, straight into overheated, start falling back, you're still holding afterburn, you get caught in that, it cools down enough to let you afterburn again, then you go straight back into overheating. On top of all that stuff that Dave mentioned, we're always looking at the tunings of these things. Maybe they're a bit too aggressive on some ships, and we're always going to look and tweak them. They're not all just two seconds, but maybe they need to be a little bit more on some ships.

We study a lot of physics. I don't know how to say that in a really exciting, cool way. We do a lot of research, and we have a lot of contacts that are real pilots, and we ask them a lot of questions and learn about their experiences and the sort of things that you might not get in a textbook for physics or even a manual for a plane. And that stuff is all brought together, along with a bunch of other research, to get a picture both of the technical details and the experience of using a plane or a jet fighter or something.

There's a lot of hands-on, not that we go out and fly spaceships. But there's obviously a lot of games. They do things differently. We're always looking at how other things do it, and sometimes there's nice bits in there that work nicely but that wouldn't work with Star Citizen, so what about if we did things like this, on top of all the research, on top of all the simulation? At the end of the day, it's got to be fun to play. If it's not fun to play, then nobody's going to play it, so it doesn't matter how realistic it is.

As long as it's not really annoying. Imagine driving over Daymar and just getting a flat tire every ten minutes, all those rocks giving you flat tires. It could be really annoying. But assuming it's not, we could explore something.

Yeah, wheels have damage states. At the moment, they just sort of crumple, but...

Part of the issue is, because the physics is this super systemic moving tire physics collider, if you damage that collider, the physics can break down really quickly. And so we tend to keep them in a pretty good state a lot of the time to keep the simulation stable, because if we don't do that, it can get out of control. Maybe you just lose one tire and it just becomes a nightmare.

We had that a lot. The tires on, I think, the Cyclone came off if someone breathed on them, and that just completely immobilized the Cyclone. You'd be driving along on a completely flat surface with no rocks, and a wheel would just fall off because you hit a one-inch dip in the ground. So we sort of, not disabled it, but made it increasingly unlikely to happen, because it does completely ruin the experience, and you've got no way to get the vehicle back to repair it, so it's just left there.

So posting on Spectrum and telling us about your problems and your experiences is absolutely the most useful. Very often, I think, people like to be helpful, and so they give us suggestions about things that would make the game better.

They suggest solutions without the problem.

Without the problem. To be able to implement a solution like that, we need to understand the problem that you have. And so if you help us in understanding the problem, we can implement that solution and understand that solution much more effectively. So just post on the forums and tell us about your experiences and the issues that you have, and why maybe you think you're having those issues. Help us empathize with your experience, and then it'll be much easier for us.

Player Relations also do surveys and feedback reports with every patch cycle that go to all the relevant people. So we see the most common things that [...], and then it's working out the solutions from that. So those reports sort of aggregate all the problems, so we get to see them. But it's problems for everything. So talking in the forums, on Spectrum, and we can collect it.

And for those experience reports, those are run by [Bayer], if I'm not mistaken. There's a special section on Spectrum for those. And of course, when you're talking about sharing the problems, suggesting solutions is always helpful, always continue to do that. It's just being as detailed as you can about the problems is generally more helpful, because with a bunch of interrelated systems, very often the cause of something, even if it seems obvious, may not be the actual cause of that thing. And so that can tend to lead us down the wrong path.

Some of the best feedback I've ever seen is like: here's this thing that is going wrong in gameplay, here's five things that I think might fix that. Great. Very helpful.

But just in case you aren't that creative, still explaining your problem, being as detailed about it as you can, being as dispassionate... This is one of those situations where try to remove emotion from it. It just helps. We do have a very passionate and dedicated fan base, and that's tremendous, and you want to keep that. It's just in presenting feedback reports, the more clinical you can be about it, the better.

That's a hard question. I think for me, the biggest lesson is in how to listen to the community about feedback. I feel like I'm going off the back of the last question, but it honestly is the most significant one. Learning how to interact with the community and learning what is important to them is a skill that I got much better at in 2019.

I think for me, it's the content side, and it's something that we've already put into motion: working on ships with fewer people. So we work on more ships, but they run longer. Because in the past, we've been guilty of putting a ton of people on a ship to just try and get it done, and you're all working on top of each other, trying to cram stuff in. You get the ship technically quicker, but it's a significantly greater human cost on that side. So it's taking a step back: rather than having 10 people work on two ships, it's having 10 people work on five ships. So you work on it for a year instead of six months for a ship. And that allows you to take it slower, put more time and effort in. If something goes wrong, you've got longer to correct it. If someone was ill for a week, that's a huge amount of time in a three-month schedule, versus over a year, where it's something that is easily accounted for. So people will see that in the ship schedule over 2020: more ships, less often. So there'll be more in development at any one time, but they won't all be coming out three or four in a patch. They'll be spread out more.