Star Citizen: May Subscriber's Town Hall feat. LA Design Team
The developers discuss the component and Item 2.0 rollout, starting with shield generators, power plants and coolers, plus multi-source shield pooling, ship damage, debris physics and time to kill. They also cover the Caterpillar's size and cargo handling, the Mako, the Starfarer Gemini, LODs and optimization.
It's all the basic stuff. All the stuff that sort of falls out of having these systems is going to be incredible to explore. But I'm just excited to touch the ship. It's crawling around and checking out all the little nooks and crannies and all the bits that move around. That's what sort of gets me going.
Yeah, while you're trying to repel boarders, you're up in the cockpit on a console opening and closing doors, trying to trap boarders in with your security forces and stuff so they can't progress through the ship.
TL;DRMulti-source shield work is going well, with back-end tech for shield pooling and more meaningful shield management, and shields moving to a form-fitted look, which they say is coming in the next month.
Actually, really well. I actually want to say Sandy posted an image a couple weeks ago onto the main Facebook showing one of our programmers, Chad Zamzow. He's been doing a lot of work getting the back-end tech that we need to get the shield pooling up and running, so we've got some really cool stuff in the works for that with just making shield management involved and not just, okay, I'm just pushing it to this face, but the trade-offs and the consequences of reinforcing a shield, of letting a side get weak, of how much power management you're doing to keep the shield values at optimal level.
The moment to moment is a little bit more meaningful. The amount of time that you spend at any given shield priority can drastically affect the outcome because of the different weights on how things refill, on how much health it takes, how much health it has and how much damage it takes accordingly. It makes those split-second decisions much more important than they used to be. And now that's also further supported by the ability to make those deeper loadout decisions, because now that you don't have just the one shield generator to the one shield, then we can have a lot more interaction between the components on that.
And visually speaking, we're going to move away from the kind of blobby looking shield and more to a form-fitted shield, and we're changing the way we're implementing shields in general. Instead of using these shield meshes all around, we're going to use the collision that's already there and kind of push that out and then create the shape of the ship from those collisions that we already have in place. So that's coming in the next month.
TL;DRBurning and smoke effects on detaching debris are already possible and wanted, and they're looking at heat-driven damage over time in a controlled way, though nothing is promised.
We already can do a lot of that kind of burning and effects work. So when something detaches, it can trigger the effects to play and we can add fire and smoke and things onto the debris. We definitely want that vision of the Titanic breaking apart and the fire and the debris falling out. So that's where I'm always trying to push towards.
We've also been talking about driving similar behaviors in the actual flow of damage, where your component could reach a critical level of damage that isn't so critical that it explodes, where it's actively taking damage over time. You need to shut it off or cycle your systems to address that. So we're beginning to look at how we might actually implement the concept of... But we're doing that in sort of a controlled approach, because Star Citizen is big and just introducing something like that can get crazy. So we're looking at it more in terms of how does the broad scale of heat lead to the behaviors that we want to see in ship destruction, either explosion or failure or possibly the fire state.
Yeah, for setting up any of our ships, especially anything with an interior now, making sure that we get the physics grid in there, that we have a high enough detail of the grid geo inside that we can line it up to the ship, but not so over-detailed that it starts becoming problematic in terms of performance and gameplay.
TL;DRTransitions between physics areas have been hard and partly solved with temporary code; interactions across the local physics grid must be built in specifically, and explosive decompression is still in design.
Certainly we've had problems with the transitions between different physics areas, like going from open space into the back of a ship, and we've kind of conquered some of that. There's a lot of work that has yet to be done, and we have some temporary code in place that's making it work, but we know there's a solution that's going to make it much better in the future.
The localized physics grid specifically stops that interaction from happening. The whole point of it is that I want to be standing on a ship which itself is moving through the universe. Implementing it in this way specifically breaks that connection. And so in these specific cases where we want there to be a connection, where you want to have momentum carried through the space, where you want to have physics interaction here interact also in the interior physics grid, those things have to be now built in specifically, because that way they can behave the way we want them to and not the way that whatever the physics code might believe they might work, which tends to be much more chaotic.
It's pretty challenging making flying FPS levels through a larger space level and then being able to transition out of one into the bigger one and then into somebody else's. It's probably one of the most ambitious aspects of this game. I'm constantly amazed at our progress with it.
Even just on the PTU right now, I was kind of blown away Monday getting in and seeing the handful of videos of people who did figure out a clean, functional way to pull the Merlin inside the back of the Starfarer. And that's dead on what it would have to be because, no, you can't just fly it in nose first because of how the wings handle on that. Getting it in cleanly, getting the door shut cleanly, getting it landed and seated cleanly. You can already see the improvements to the physics grid, because in the live version, you try and do that in, say, a Constellation. Well, no ship that you can sort of cram in there is going to sit cleanly on the floor. So as soon as you go into quantum, it detaches, it flips back, it blows your ship up. But now with the scope and the size of the grid in the Starfarer, it's like, okay, well, this is big enough now. This is almost safe enough now for how it's compartmentalized to let you bring that ship in and have it sit down cleanly. Doesn't mean you'll get 20 of those Merlins in there, but being able to pull a couple of those things in, we definitely do want to make sure that works, and it has to play nice with the physics grid. You blow up when you go to quantum.
As for the explosive decompression, that's another thing that has to be specifically built. But I've actually seen some designs being worked on that seem pretty well featured. Those are still in the design phase, and I'm not directly involved with it, so there's no telling how that'll shake out, but I know that we want to have atmosphere.
We've seen the very beginnings of it in the pipe system preview that we had on ATV Fast Forward the last two weeks, shooting out the glass and watching all the cargo that's in that room fly out and stuff.
I think CryEngine has some kind of object that can actually pull along a stream. So we're kind of planning on putting those at the airlock areas. And if you breach it, it'll just kind of suck in what's in this cone. And so we should get that nice effect.
TL;DRMako broadcasting and filming gameplay is still being figured out; the bare-bones plan is an unobstructed camera view for the co-pilot, with more gameplay layered on over time and not the full scope hoped for.
So we're still figuring out a lot of stuff for the Mako. When that one was originally pitched and I was working on that, even to me, I was like, okay, this is a little bit lofty, but just the community interaction that you guys have brought to us, it's something that we want to make sure our streamers and our players have that kind of hook and that kind of opportunity for gameplay. So it's very much going to be like a layered-on system. It won't be the full scope of what everyone's probably hoping for, even five years out from launch type of gameplay opportunities. But at least in the very bare bones setup of it, we want to make sure that if you're the co-pilot on a Reliant Mako, you're looking through that camera, you have this just great unimpeded view. We want to make sure you won't have any HUD in the way so you can just capture a full-frame image of whatever you're pointing at, whatever you're looking at, looking at trying to do some better things to make sure you get enough zoom and distance so that you don't have to put your ship right in the middle of a firefight to get a couple good images. But then the long term is just to sort of layer on everything else that we can do with that and make it compelling. So some aspects of info running are even going to bleed into the news service aspect, where just identifying who was in what system and when, like tracking people's movements, tracking general intelligence about what is going on in a system. And making that another aspect where it's like, okay, hey, this reporter now just saw you effectively commit a war crime. Do you try and go chase them down? What if they get that back to the right news service in time? But a lot of these things are still those layered-on gameplay features that we need to build on the pieces that we know we can do really well now, and then just slowly keep moving forward and adding newer and newer layers on top of that to really flesh something out.
Basically what the core of the entire Star Citizen experience is: build it right in front of the people. They'll see an early version and then it will continue to iterate.
It's been kind of our philosophy all along. We know where we want to go, but we know the tech that we have currently to build it. So we'll put in the initial versions and then build on that over time as new tech comes in.
TL;DRDebris currently lacks physics and will regain it with Item 2.0, which should also allow component-based explosions and radial damage, but none of that is front-facing in 2.4.
You might be talking about the... We have an issue with debris right now where it no longer has physics when it detaches from the ship in the current build. It's going to be part of the Item 2.0 upgrade that we're currently in progress on. So we will get physics back on the debris items so they won't hang in space. But I think right now you can just pass right through those debris items and they won't kill you. But as for an explosion effect, the ship leaving the explosion behind, there's ways we can attach those effects to stay with the ship as those effects fire. So we'll be looking at reviewing effects. So part of what I'm doing right now is assessing our whole fleet of ships, all 30-odd ships that are out there flying right now, and looking at all the missing pieces of tech, tech that could be improved, and just making sure everything is set up in the same way. And as each new piece of code gets written from engineering, we have to go back and kind of redo a lot of the ships. And as you can imagine, as ships get added, that iteration through the entire fleet becomes a little longer each time.
We are starting to do that. Again, Item 2.0 is going to allow us to do the radial damage with effects on nearby components, and then through power pipes and overheating, and then kind of a buildup. That cool video we showed a while back with the explosion, we're still working toward that as our visual and the feel. So you're going to have time to repair during a critical phase of the ship and bring it back down to a nominal level.
The goal is that that's not just the death mask, that's the result of the systems behaving according to the situation you've put it in. The damage that you took, the amount of damage, the type of damage, what you've done about it since then is what leads to that behavior.
And also just how you're running your ship, where even without damage, if you're running it basically redlining everything, you're going to wear your ship down and all your stuff down faster, because you're just pushing it so much harder than it's safely rated for.
You should also be able to equip your ship with safer components. Generally probably a lower output, but will be less likely to explode, or if it does explode, will probably be less devastating to your ship. These are all choices you can make.
So yet another thing that Item 2.0 will allow us to do in the future. So not stuff that you're going to see front facing in 2.4. One of the bigger things with 2.4 is the item port system. It's an under-the-hood implementation that's going to allow us to build out everything from components to explosions. It affects so many aspects of the game. It's one of the more exciting aspects of 2.4.
TL;DRPhysics needs work and big ships are pushed around too easily, but physics is taking a backseat to Item 2.0 during a tech transition, with hopes to improve it sooner rather than later.
Yeah, so our physics does need a little work. When things blow up, it's like papier-mâché sometimes, and it just troubles me. So we're looking at those kinds of things, and hopefully we can get to that sooner rather than later.
Launching a human. I love the EVA guys, and they launch themselves at the ship and come in and just blow it out with themselves. That's so funny. We definitely want the most realistic physics as we can. We're just in a transition period with the tech, so the actual physics is taking a backseat to Item 2.0. What that will bring, which is not only different types of interactivity, it's also networking sync, but it also has a lot to do with optimization. One thing we found was the interior of the ship needs to be separate from the exterior of the ship, but the way CryEngine works is, if you want to interact with the inside, it has to be part of the outside. So I won't go into more detail with that, but when we can truly separate the interior from the exterior with Item 2.0, we'll be able to cull out a lot of the geometry that you're seeing or you're drawing from a distance, and therefore you'll have better performance. So we're looking forward to that.
TL;DRThe Starfarer Gemini is intentionally nearly identical to the Starfarer, since Aegis buys it from MISC and does a utilitarian military retrofit of components rather than a redesign.
The Starfarer Gemini is still the Starfarer. Aegis buys the Starfarer from MISC and then retrofits it for military use. That's a switch-out of components and stuff, the bigger centerline thruster. But they don't redesign the ship. So that's why it looks very much the same. When you're buying something from MISC and you're repurposing it for the military, it's not about making it prettier, it's not about changing it fundamentally. It's more a utilitarian change-out of components and certain aspects for military use, increased armor and stuff like that. So you're not going to see a big visual difference, because why would they spend that time? That's not necessary. The military's not interested in having the Aegis name plastered all over the things. I had a long conversation with John Crewe, which is why I'm answering this one. It just makes more sense for immersion that they would just buy it, change out the parts that they want, retrofit it a bit, and sell it to the military. So that's why the Star-G is like it is. And I like it a lot.
TL;DRAll ships just got new level-of-detail meshes and more optimization is coming, but real culling gains need Item 2.0; optimization is ongoing patch to patch, with a possible optimization section in the 2.4 post.
Optimization is... We've just finished a full pass of all ships adding new level of detail meshes. You might see some ugly meshes out there. They switch a little too fast right now. That is in, so everything should LOD and be visible in game and be fairly optimal. Right now, there's further improvements we're going to make, which is material ID reduction and combining meshes at a distance so there's fewer meshes to draw. So we've done a lot of that already as well. The big thing is, again, the interior needs to be separate from the exterior in order to properly cull the entire thing out. Because what you have right now is these little joysticks. They're so dense. And then you're drawing it while you're still looking at the ship from the outside, because the joystick is interactive, and therefore, due to base CryEngine, we need to have it as part of the exterior. As soon as Item 2.0 [is in], then we can separate it, and then we'll have proper culling and a lot less to draw than we currently are.
Another big thing just to keep in mind with optimization in general is, while we're constantly making performance improvements, it's not really a one-shot solution to fix everything, especially while we're still building out all the game assets, because we can optimize for what we have now, but we're still adding more ships, we're going to be adding more landing sites, space stations, planets. Once planets, their surfaces and all the new objects that are associated with those go in, as you keep increasing that load, what you need to consider for optimization also keeps changing. So it's not something that we'll have a one-and-done solution for, but it's absolutely something that's worked on patch to patch.
And we're actually looking at having a section devoted to optimization in the 2.4 release post that we do. Every time we release a new patch, 2.3, 2.2, we do a big old post about what's involved and whatnot. And I know we've got some guys actually writing up a bit about the process of optimization. So no promises, but we're working on that, and hopefully that'll be in the post by the time 2.4 is ready to go live.
TL;DRFPS is a consideration in large ship design but not the driving force; ship sense comes first, with FPS tweaks added afterward, as in the Caterpillar's moved catwalk.
Well, it is part of the gameplay, so the potential for FPS is everywhere, and we have to kind of allow for that because different people have different play styles too. You want to board a ship and take it over by force. That's part of our gameplay. If you want to avoid that, then don't hang out with pirates.
Coming at it from a perspective of FPS levels, there's an element of that that is about supporting the FPS gameplay, but there's also the element of just determining what it's like to move through the ship. And what's realistic for actual life isn't really that realistic for game space, because you don't interact with that space the same way. You don't treat the same distances in the same way. If you model out a room one-to-one and put it in CryEngine and then walk around, it will feel very cramped. It will feel very different from how it actually feels to be in that space. So you can't think about it in the same way of, we build out a blueprint like architecture and then expect it to actually work. You have to actually take into account the distances at which players interact with things, the field of view that's available, the walking speed. These things all come into account, in addition to the potential that somebody could be shooting at you.
When we say flying FPS level in space, I'm talking about the technology. It's that technology, not that we've designed an FPS level that's meant to go around. I would say FPS is a consideration, but it is not the driving force behind your material.
Yeah, we wouldn't add a wall to impede going down a hallway just so you could peek around and shoot, because you want to still have traversal from one side of the ship to the other really smoothly.
The really apropos example would be the Caterpillar, which we just had the deep dive about, and that did include a consideration for FPS, where we moved the catwalk over to one side. That helps you have visibility on the people moving through your ship. It gives you the crossfire if you find yourself in that position. And it doesn't really cost you that much in terms of cargo, because we do still allow you to fill that space, because you have the catwalk, which can't be occluded by cargo, so you still have a way to get through the ship.
I even think it can open up a little bit more opportunities, just because of the tractor beam set that you had on it, where now, instead of having to worry about pulling a piece of cargo or some object into the ship and having it run up to that center catwalk in the middle of the hull, now it's all the way to the opposing side of where the cargo would be loaded in by the tractor beam. So you do get a much better clearance room for bringing things into the ship, for rearranging the cargo in your ship and making sure it all fits, as opposed to having that blocker right in the middle of the ship.
I mean, good luck getting anything out of it, but as long as you are capable of doing it, it happens. I expect we'll probably see plenty of people doing tower defense mazes.
The tractor beam is sort of fundamentally in flux at the moment, because we're playing around with a couple of different approaches: a single object push-pull, having a force, having a point of attraction. There's prototyping to be done. And the work in the Caterpillar was more to be like, does this feel like a space where I feel like I have control over the dot moving around space? And so I felt like I had a pretty decent view of the ship to make that call. But the actual tractor beam design is still something that's being built out, because that also takes into account some of the considerations in Austin, with Tony Zurovec. I know he has a lot of desire to sort of see that system move forward.
TL;DRCargo is meant to be grouped using grabby hands, cargo jacks, pallets or tractor beams, so you plan the layout and move it in a single trip instead of hauling items one at a time.
Grabby hands. Grabby hands is one of the ways. There's actually, the cargo design has a lot of opportunities for aggregation. The idea isn't go to the beach and grab one drop of sand and bring it back and just keep making trips, but I want to go over there and lump everything together using the cargo jack, the pallets, potentially using the tractor beam as well. We had a couple other proposals for ways to bind multiple groups of cargo together so they can be moved as one. And then you would sort of slide in there as a single unit and then take smaller objects and fill in the remaining spaces. What's interesting about cargo management is the plan, not the action. Walking back and forth carrying things is not interesting. What is interesting is having the tactile element of manipulating something directly and having the higher macro level of how does this fit into this space that I'm designing now with the cargo. So in order to alleviate that middle step, you want to sort of group things together. You've made your plan for this, now it's just move the one time. Like packing a car for a long family road trip, if you have really cool equipment. My long family road trips are never so well planned. It's a mess from start to finish.
TL;DRShip destruction versus disablement is meant to emerge from the damage systems, so targeting choices matter; disabling will sometimes yield an intact ship but not always, and it may leave a dead husk.
I mean, that ties back into what we're talking about. The goal is to have it so that these behaviors, again, are driven by the system. But that also means that if you're able to make intentional decisions about what you're targeting, you're able to drive specific kinds of behaviors. So if you're up against somebody who runs a hot power plant and you want them to just explode, that's a pretty good choice. If you want them to not explode, you're going to be wanting to avoid shooting that spot. And I think that's actually one of the things that's really cool about it, is that what your goal is in this conflict has a lot to do with how you're going about it, because the systems are just going to react to what you do.
Well, even then, even with disabling a ship, what a lot of this new system will allow for is a much more hard disable, where it's not a temporary disable, but also something where it's not just going to be rampant ship inflation of, oh cool, I stopped your power plant for five minutes, boarded you, killed these guys, and now I'm just taking your ship outright. It'd be more like, well, no, we can fry that power plant and the ship is still just a dead husk ready to be salvaged, but the people inside, some of the other components inside, some of the other systems inside could still be up and running. And so you can get some nice intact parts out of that, but it won't always just be a free ship haul for disabling someone.
But it will be sometimes, but not always. That's where it gets really tricky to describe, because if you go at it with the lightest possible touch, then it's potentially possible to put that power plant, even the one that can explode, into a position where it is disabled, not destroyed, and within range of being field repaired back into working condition. Depending on the situation, that could be a really, really narrow window. Perfectly possible to happen, and given the way that things are going on the PU, anything possible will happen.
TL;DRA full item port menu system exists, and this is the earliest iteration, with plans continuing through several later patches; "if it fits, it sits" is not absolute because of technical limits and gameplay.
You are seeing the earliest iteration of the item port system. There are plans for it that go through 2.5, 2.6, 2.7, and I don't see it stopping. The item port system is so important to everything in Star Citizen. It will just keep adding and building it out and refining it as we continue to build Star Citizen.
Although even with that old term of if it fits, it sits, it's not an absolute truth, just because there's always going to be some level of technical limitations and paring down and abstraction that's needed to make sure that the gameplay stays fun. It's why not every ship just gets to magically be a pocket carrier, but there will still be tons of room for what you'll be able to do inside of the space and what's allowed and accessible inside of those spaces. It won't be like you're building your house in The Sims, where you get absolute control over everything, or like a lot of the house building in some other MMOs. There's still just going to be a load of options for what you can do.
The Buccaneer sale is just for the Buccaneer. The Buccaneer concept sale will be releasing the Buccaneer upon the community. So that's what's for sale with the Buccaneer.
TL;DRThe Caterpillar is huge, roughly 107 to 110 meters by the speakers' uncertain recollection, with the exact size not final until it is fully built out in CryEngine.
This big? I don't remember offhand. I'm pretty sure we passed 100 meters. I think we're at 107 meters, but I might be making that up. It's huge. I really feel like I'm remembering that from a conversation with Elwin, because the way that we're building it out made each of the modules a little bit thicker. So we gained a few meters there.
At least a couple. I haven't had it fully intact. I've pulled it apart. But you can see it in the Ship Shape. The front of the Caterpillar at its current size, give or take a few meters, is right next to where that Freelancer is. And the back is the floating engine behind the back walkway. So it'll go all the way back to that engine. So what is that, like four Freelancers? Absolutely no help.
Everything you're saying right now is going to generate posts and threads that I will have to deal with for next week. It's a big ship. And then it still has to be built out in CryEngine. When it gets fully built in CryEngine, that's when we know.
And the numbers still won't be the absolute final numbers until it's built out, until we've been running around inside it, and the physical thing, that's when we know.
TL;DRDrake ships aim for easy access to most parts and durable, simple components, while repair ties into reclaiming materials and swappable subcomponents; the repair gameplay is still in the design doc, not implemented.
So a big thing with that is just making sure that whatever components come stock on a Drake ship, and also even into the larger ships like the Caterpillar, wherever we stow these components and have to put the panel access, to make sure that it's very easy to understand. Okay, in the engine room of the Caterpillar, everything that you need to ensure propulsion, you're going to have some way to affect that from that one room. You aren't going to have to go running around from an engine room to a shield room to a computer room or anything like that. Onto the smaller ships, it's just making sure that the idea is you should be able to just pop the hood once and have access to 80%, 90% of the parts that you're going to have to work on, as opposed to having five, six different panels covering up the different parts.
Yeah, the Drake approach tends to be like everything's exposed and it's out there. But I think this also ties into some of the work that you've been doing on the component definitions, because certain components will... Like the difference between a high-class component, it might be the Jaguar of really good performance, but don't hit it with anything. Don't look at it wrong. Whereas you could have extremely high durability relative to lower performance. And you're more familiar with that system.
Yeah. People who have a lot of classic cars may understand this, where if you're taking care of your car, even if it's not the most powerful thing, you're able to get... I've heard of Honda Civics with 300-plus thousand miles on them. Most cars, you get about 100,000 before it starts shaking a bit. And so it's just having that built-to-last kind of thing, just easy access and not an overcomplicated mechanism. It's not some overly ornate engine or shield generator or power plant that will ever be in a Drake ship. It's going to be what it needs to function for what that function is made for. That doesn't sound confusing enough.
And repair is going to be tied in with reclaiming quite a bit, because we're going to need these resources that you're gathering. We're talking about stripping the hull off of derelict ships, and you gain those materials to then craft new components. There are sub-components to shove into a fuse. You make a fuse or something. This is in our design doc right now, so we're not in the implementation phase, but our hope is to have some gameplay where it's really fun to put these fuses in and make it work again. Maybe even think like a BioShock minigame or something. I don't know. The pipes.
It won't be pipes, but there will be something. But yeah, absolutely, the subcomponents are going to be a huge part of that, for also tuning and adding some character to your individual loadout. So even if we both had the same ship with the exact same manufacturer and line of parts, I could have all my subcomponents in those parts leaned, if I want to, say, focus more on energy cooldowns, making sure all my systems are back up and replenishing faster, where yours may be just raw output, raw performance. You want the biggest number on the power plant output, the biggest number on the shield health output.
We've been looking to have those subcomponents tied directly into the behavior and performance of that component. So you'll have your base stats that is the item itself, but then when you put the subcomponents in, or you alter out the subcomponents that it already comes outfitted with, that will shift that balance a little bit. You can think of it like those are the points that you can move around on your stat sheet. But you can bolster it a little bit towards this performance or that, depending on what you need. If you need more durability on this high-performance, low-durability component, a subcomponent might be a good way to do that. They're also the easiest as far as a field repair, because you just remove a thing and put a new thing in. So that gives you an element of that consumable for repair.
TL;DRTime to kill on large ships is expected to grow once component damage and repair gameplay exist, but that isn't in yet and is not the current focus, which is Squadron 42.
Right now every single part of the ship has a health value. So if you nail a single part, it'll drive its health down, and then if that part dies, any further damage will transfer up. So that's the current system, but once we get to the component damage system, where it's radial damage and pipes and all that, you'll see more strategy involved in taking a ship down instead of just, okay, just nail this one area until it explodes kind of situation.
I mean, yeah. Similar to before, when we had only single-seaters, I think the time to kill was even shorter. It's not super useful for us to increase the time to kill to what it will be when the gameplay to support it isn't there, because that just leads to you repeating the same action over and over again without getting the reward for repeating the same action over and over again, because there's no gameplay for it to progress into. So as those things come online, as there's a thing that you would be doing during that time, then it makes sense to start increasing that.
Yeah, we'll be balancing the bigger multi-crew ships so that there is that time to repair. There is that time to do that gameplay to survive. It's just that the interaction of repair isn't in yet. And we may not see that until we're focused more on the PU. Right now we're obviously all on Squadron 42 and the ships that are involved in Squadron 42 mostly. So our attention is there, but when we get to just pure PU stuff, then that's really where the salvage and repair and all that stuff will be tuned to be fun.
We've also been talking about ways to link that directly to the ship a bit better. For instance, currently our health is just: I open the Hornet and I say that it has this much health, and that's how much health it now has. We're looking at tying the health to perhaps the mass, because it makes a certain kind of sense that the materials that are actually used on the ship could contribute to how much health it has. And what that means is that because we assign health on this sort of large scale, like I set the health of the Hornet to be something, versus if it's by mass, then this panel of the Hornet has this much mass because it's this subsection of the ship. So that makes it so that as you lose parts of your ship, you're losing health more directly related to what's actually happening to your ship, because there's less abstraction between the health and the actual condition.
TL;DRShield generators are the first priority, hopefully alongside power plants and coolers around the same time, with no dates given; the base Item 2.0 code is nearing completion.
So I think the real big one that we want to get in front of you guys first is going to actually be the shield generators. To pair along with that, we've also been doing a lot of work with the power plants and coolers. So hopefully those three should all sort of go online around the same time, because they all have the most impact for driving your ship performance, where it's like, okay, your shields are that refilling health. Your power is just how much can you ever do. And especially once we get the coolers really fleshed out gameplay-wise, it's like, well, okay, this is sort of that limiter on stopping you from just overtaxing the ship at all times without consequence.
We are starting to implement Item 2.0 items right now, and there's this base amount of code, and now we're specializing into the various different disciplines of what components are and what they can do. But the base code is nearing completion.
TL;DRGame tech is never finished; tools like DataForge and a ship-authoring toolbox keep improving, and flight tuning is being optimized so a designer could hopefully tune a ship in about a day instead of a week.
Any game, you always have more tech to end with than you begin with, and it gets easier all the time, and we're doing things more correctly than we were initially without the current tech. It's always a moving target, game development, so we're always trying to think ahead, but we're doing what we can now.
And there's always going to be tools optimization. Just over the past year, we've really been working on this thing we've talked about, I think, one or two times called DataForge, which helps us rapidly author items, where before we were basically doing a lot of hand-edit work, magically turning an Excel sheet into an actual game item. And this is going to be more of a front-facing, collective spot where it's like, okay, here is all of one type of a component in the game, the high-level view of everything at once, a unified template to build everything out of, as opposed to just sort of patchworking things together. And those kinds of improvements are constantly ongoing. Even just with building the ships, you've made a bunch of the tools that we use just for taking a ship from 3D Studio Max, defining just the basics of what the hardpoints can do, but then actually having a tool that will author out a functioning XML template for us to start hooking everything else up into and actually getting the ship flying.
There were times I'd be coming into the office at 1 o'clock in the morning, and you and Zane, and I'm like, why are you guys still here? It's like, because our work never stops.
Well, Calix is also a wizard. You never know if he's left the office for the day or got in early, and you don't know how he managed to flow graph something, but he managed to flow graph something.
I've seen your flow graphs. Your flow graphs are terrifying. There are no rules. It comes across really at every level. We have an optimization coming from John Pritchett that's going to make it... I think it's almost done. I'm not sure, but I think it was very promising words. But the flight tuning, each ship took about a week because of everything involved. And most of that week was spent having it completely wrong, because if it is not perfectly tuned to start with, it just fails in baffling ways. And once you get it to that point of perfection, now you have to ease it up a bit to get the behavior that you want, because now you have a perfectly flying ship that has no characteristics whatsoever, because you had to iron out all those characteristics just to get it working. So that process was very involved, very technical, and also it was information held by three people total. So if someone got sick, a ship was thrown off, because it was so complicated, so arcane, that it was impossible to work with together, much less to have something that got postponed for any length of time. That has been optimized to the point where, with only a bare level of introduction to how the systems are intended to work, it should take any of our designers a day to do a ship when we get those things online. That's not just an improvement for the game.
Once you've made those decisions. Before, you would make a decision, and it would be a week of painful toil before it could actually be a thing that happened.