OE: Item 2.0 is one of the big things for Star Citizen 3.0 what are its major advantages over item 1.0
ST: It’s a really good question and I’m glad you ask because we don’t communicate this necessarily as well as we could sometimes. Players have had some form of item 2.0 for a very long time. It’s items that have been componentized vs entities that have a whole set of properties on them. So Item 2.0 is really is the componentization of functionality per item. Maybe that isn’t a perfect way to frame it in one sentence but what it does is takes all the properties and generalizes them as much as possible so we can apply gameplay components onto them or any item regardless of its entity type.
What we are doing is taking the Lumberyard engine from being a purely entity driven engine to being a componentized system, meaning you can share components between different items or entities so you don’t have to write bespoke code for every single entity.
An animated object within Lumberyard was an entity and that had a certain set of properties so of the big ones being a model, animations and some physics. All of these were written in terms of the item entity so instead to componentize that and move that entity from an item 1.0 to an item 2.0 you would have to decouple all of those properties from the entity itself. So you turn it into an item first of all but it cannot do anything by itself, we call it a game object, it’s just a concept of a container waiting for components.
The first component I add is the geometry component, something which can be shared across pretty much any item. Then you might have an animation component which would be added to the same item and at this point we almost have the same entity in a componentized way. We have to write all those components up, so the conversion is a slow one as we have to slowly removing all the bespoke entities from Lumberyard and turning them into a componentized system.
EKD: Which allows for some really exciting gameplay implications because once you have things in this way there are more interesting things you can do with them. Which is a large part of the gameplay aspect of what we are making is, utilizing that level of granularity which is really cool.
ST: It also just makes things easier to make, by far. The geometry component was the most obvious one right out of the gate, so that was the first one we wrote. Now we can assign geometry to any item through this one component, this one block of code that applies to everything. Rather than whole separate entities dealing with their things independently and if we change something we have to change it across 100,000 different entities, which creates too much work.
So one of the other things on top of this is the performance it brings us and the ability to optimize. When you have so many entities with so many different properties you have a hard job doing large scheduling updates. What we can do with these components is make an entity scheduler and make it update the component so many times per frame or if an item has a geometry component that’s over 10 feet away say don’t updated that one. It is these kind of optimizations we can make in a component based system that is the whole reasoning behind doing it.
OE: How much does the aerodynamics of a ship effect flight and what other things will affect flight such as wind or air density?
ST: The way i have to explain it is that there isn’t a separate flight model. It is completely seamless, at some point when you get into the atmosphere you are at 0.001% of hitting the atmosphere. The first reason of why we don’t have a whole new flight model is when do you make that switch? It would feel like something is happening and that’s not something we want. What we want to do is make our flight model which is made to fly ships around which aren’t aerodynamic is still what is being used in atmosphere just the variables applying things to the ship have changed and pretty dramatically.
Those two things you’ve mentioned wind and air density are the more important things and everything that would affects those two really are the things that would do anything. Drag is affected by air density, the amount of wind from weather from all different places. What’s going to happen when the ship hits the atmosphere they thrusters are going to keep the flight model the same except the external forces are still acting on it like drag and lift are now a lot more obvious but the model itself hasn’t changed. We have actually have a guy with a Phd.
EKD: A very smart guy
ST: we stare at his screen of formulas and bar charts. He [John Pritchett] is our flight programmer and he’s been on the project from the start.
EKD: The complicated maths behind the newtonian physics and that model. That brings back to the simulation as much as we possibly can. What would actually happen if you take this ship into atmosphere.
ST: So to answer more clearly, the shape of the ship will absolutely effect how it handles in atmosphere, but it’s not due to a different flight model. More because those external variables are different, less drag because it’s more aerodynamic, more lift because it has wings and more like that.
We constantly clash in terms of its a game thing that happens in game development of what happens in reality and what’s just a game part of it. John hates the hand wavey game stuff. He’s like “Noooo that’s not how it would work” the the G-Force conversations are just none stop. There’s a way we do it in games that is fun and feel s cool and then there is the reality of what it would do to you. You definitely have to come to a balance but it is nice to have the accuracy of someone that understands it in the real world.
EKD: It is nice to see that level of passion in each person’s individual aspect of what is Star Citizen. Everybody you interact with in their field or thing that is exactly how the conversations go. The passion is deep and rich and it is a discussion you have to have and then ultimately we get to what you get to play but it is across the board with everyone.
