Happy Hour Interview: Item 2.0 Discussion

So item 2.0 has kind of been thrown around as the savior of everything. It's going to fix everything. "Oh, we can't do that. We'll do an item 2.0." But what exactly is item 2.0? So item 2.0, whenever someone just says item 2.0, it's not literally item 2.0. It's just the technology that brings item 2.0 available and coming up and living. So what that will mean is, in our existing old stuff that we've been releasing for a while, we have these very centric gameplay logic blocks in the code and they do their thing and they work pretty well. But when you start wanting to use bits and pieces of that for other systems, it all falls apart because that one big logic block is all interconnected and you can't just grab something. If you grab something and you stick it in here, this thing might topple or this thing might not be set up right. You end up copying and pasting. It's just a mess. So one of the very first things you have to do for item 2.0 is we have this thing called a component system. And instead of having that big block of logic to define a cup or a ship, we now strip away those bits of logic and we implement them in their own component. So you have a component for physics, you have a component for animation, a component for certain gameplay logic like a shield or even a power plant. And now you have all these different components. You can start adding them to these, we call them entities, and you just basically define something new. And you don't need a coder to go and make a new chair. A designer like Kirk can just go into this tool we have, DataForge, plop all this stuff down, you have a new chair. Plop all this stuff down, now you have a new ship. So it's like trying to build these more complex systems that allow designers to make these bigger systems. And at the same time, when we had it in those single logical blocks, we had another thing with order. So the way that things updated was very deterministic. And we started adding all these things. We had to do one at a time on the main thread. And if you're doing like 100 of these things, it's not a problem. But when you have a big, gigantic universe where it might take a few minutes to hours to get to another planet, there's loads of items and you might have anywhere between 10,000 or more. Now they have to go one at a time and you end up slowing down the game because you have so many things you have to update. So one of the things in the item 2.0 or entity component infrastructure is this thing called batch updates. So now all those individual components that we've made before can now run parallel at the same time in the frame. So instead of doing one at a time, we could do a bunch in a row, then do another bunch, then another bunch. So our update went from something like this to something like this, but long ways now. So the more CPU cores you got, the faster the game is going to run. Basically taking full charge of multi-core, everything. So you have the components, you have the updates, then you have the DataForge, which is the thing that design will use, where it's our own internal data structure. So before, when we defined ships, items or anything like that, it was all XML driven, and the problem with that is anytime we load in a ship or something we have to open up a file. It's huge. So all these XMLs, you have to load it in, read it, and that is slow. So instead, we have this thing with DataForge where we have everything offline and we export it in one binary blob and we load that and we can chunk everything that we need and take only the bits that we need fast. Then there's a billion other systems that come into play, and the interaction system. The item 2.0 system itself uses all that technology and does a little bit more, where now you have this thing that designates who could control what. Then you have the item logics that talk to that, that talk to who could dictate what control and who should get what and who can observe. That's the item infrastructure. Well, everything underneath that is the entity level substructure, which the item 2.0 uses. There's a lot. I could talk for hours.

I think Mark did a great job of describing the underlying systems and how the engine will improve and will get performance increases from that. While we're doing this conversion, however, and this does involve that we do convert all of our existing items and systems to this item 2.0 infrastructure, we're also improving those items and their functionality. So we're improving the ways that you interact with ships to get into them, and while you're in the cockpit, how you interact with the cockpit, and how things like power plants and coolers and shield generators and quantum drives and weapons and thrusters will work, which allows design to balance them better. There's a little bit of Wild West systems when we were trying to balance things like power consumption, heat generation, EM and IR, and how those systems were utilized in the old 1.0 system. We've greatly simplified the way that we generate and manage those signals and how the player can figure out, okay, well, this is the amount of power I will need for all of these items that we have on our ship. I will be underpowered, so how do I improve that? Well, I can get a better power plant or manage my power more efficiently or pick maybe weapons that don't consume as much, so that I can make better gameplay choices for the ship loadout, and it'll allow you to affect gameplay directly by being able to control the parameters of those items.

Well, CryEngine originally didn't have an entity component system in it. So we get this engine. It has a lot of behavior that's in it. We're trying to make a game. We have a certain scope for that game. There's a certain amount of employees. It's much smaller than what we have now. And so we're focused on making vehicles, making ships, making all this behavior that we need. But as we make this game, we push out releases. The team looks and says, this doesn't scale, right? We need to get much bigger. So how do we scale? Well, a big thing that's been happening with engine tech is these entity component systems. And it's a good idea, I think, for lots of reasons. It's a good idea for engine performance, but it's also a good idea for design. It's a good idea for code maintenance. So it's just a really good idea. Our engine team looked at the code base and said, can we make this better? Yes, we can. And sort of working on it, but it's a really big change to the entity system. It's a big change to gameplay systems, a big change for the designers. So it takes a long time, but it's absolutely the right approach. It's where we need to go.

It's something we always knew we were going to have to do, even from the beginning. It's just when you're starting the project, you've got 10 people in a studio, and maybe another 10 in another studio. There's not enough resources to start on a project at this scale. So we had to scale, and then we could scale.

Well, at the same time, when we were first starting off, we had to start getting something [...] So that initial thing kind of helped us go, okay, we were able to get the stuff to a point where we could sort of prototype it. Now we need to get the actual finalized design and spec and engine and everything that will allow us to take this beyond and actually iterate on.

And speaking of scale, I think the componentization of these various systems is useful in that we can take the same systems. And so when we'll have space stations or bases on planets, instead of making bespoke power systems for that, we'll utilize the same exact system for handling power on that base, and ultimately we should be able to take a ship power plant, plop it into the power pipes for that base, and it should behave in the way that we expect it to.

And so when players learn how to manage the components of their ships, they'll be able to apply that information possibly towards the repair and maintenance of a space station?

Yes. As far as the component system and the gameplay goes, they're exactly the same, actually.

It does allow for it. So I own the interaction system, and one thing that we added into the interaction system was interaction locking and interaction authorization. So it means that two people can look at the same interaction and depending on some context, they will either have access to the interaction or not. We need a security system to now be built on top of that to say, when is the time that you can and can't use it? And we have work that's being done towards that, design that's being done towards that, as far as security tokens and things like that. So yes, it will allow for it. I'm not sure if we're going to get quite there for 3.0.

Okay, it's not a 3.0 thing, but it is something that is going to happen.

Yes.

And that same technology that he was mentioning is the thing we're now using on our ships. So we have the Super Hornet, which is a two-seater ship. And I'm sure everyone knows if you try to get into that thing and then have another guy get in, both people T-pose and it just goes ballistic. With the interaction system, we now could have the prompt come up saying enter pilot, enter co-pilot. And when someone's entering the other one, it basically blocks the other person from entering until he's done. Then he can get in. And that ensures it works across all machines so we won't have that funky, weird T-pose issue. And once the security or other systems come in, we can just plug it in and it prevents you from actually interacting.

Right, and programming is allowing design to actually set up those rules so that we can avoid situations like that.

Yeah, we want the players to be able to experience the joy of making the ship better. And so you'll be able to acquire better items, place them on your ships, and then experience better performance.

I think players have always experienced thus far how interesting it is to customize the weapons. I mean, that's the one thing that you have full control over and it's awesome. We didn't have quite the visibility on the customization for things like the power plants or the coolers or the shields. A little bit kind of obscured in what the upgrade path was. As we're tying these systems closer together, and again, simplifying the usage of power and heat generation and what that does to your shields, I think it'll be more interesting to figure out, okay, if I do get a better power plant, I will experience these enhanced features. There'll be some detriments too, like you'll generate more heat. So you'll have to increase your cooler capacity to ensure that you won't overheat all the time. But in stock format, maybe if you are using all your weapons and thrusting at 100% and you're taking damage on your shield, so your shield generators have to maintain your shields, you may run out of power. And so you have to make a decision. Okay, well, I have to cut power to my weapons right now so that I'll be able to escape from this particular battle and have enough shields. And then when your shields regenerate, turn your weapons back on, and now you're ready to enter the fight again.

To go on to that, one of the biggest things that we had problems with early on with the ships and the current [system], they were mostly decked out to handle single-seater fighters. When you had more seats, there were issues with control and who got what. I was talking about that a little bit on the segment the other day. So when we were doing this item 2.0 infrastructure, we wanted to do a pass on control and how that all works out, so that when you're in one of those bigger ships and you're a pilot, you maybe don't have control of the weapons. You could fly, maybe turn on power. You'll need someone else to go sit in the seat next to you to actually go and shoot. So if you see that Constellation or Retaliator out there and he's just by himself and he's just hanging there, maybe you can go up and battle him because there's only one person in there and all he could do is fly, maybe run in the back, go on the turret, then you go behind him, you could play cat and mouse with them.

Yes and no. I mean, we'll maintain our current keyboard shortcuts for those. We'll implement the ones that I think we'll need quick access to, but for the most part, all the interactions are going to go through our MFDs. So you will throttle power that's coming out from the power plant to your various systems through an MFD. You'll control how much the shields are asking for power through an MFD for shields. So you flip through those various pages and then you'll control how those systems function via those MFD interactions.

Which should give, I think, more gameplay for multi-crew ships, because it means that if you have more hands available, you can get more fine-grained with the adjustments that you're making.

Right, and that one person can be dedicated to a particular set of tasks.

And with the whole rebalancing, now that we're splitting all these components up and we have design going through and figuring out how power and heat's supposed to work with these things, we have a better understanding of the whole system and how they all work, so that these MFDs that we have, they're actually going through an art pass to display that information in a much more crisp, clear manner. So you know what's overheating. You know why you have no power. So that was one of the issues we had before. You have this MFD. It's showing you stuff, but you don't know what that means.

Well, in the past, I think the most control we had for things like shields was turning them off and on. Not super fun. So because we'll be able to throttle how much the shield generators are requesting as far as power, so that you can reserve power for the rest of the systems on the ship, you need to monitor that MFD pretty closely. That's rather difficult to do when you're also trying to fly the ship and not die. And so if we can dedicate a copilot or an engineer or whoever is sitting in another seat to be the shield guy, he or she can monitor the MFD for shields and then decide, okay, here's where we need to divert power to shields or divert power away from shields, or do things like a particular face prioritization, and do all those rather fiddly adjustments to the shields so that it'll ensure that your survivability in the battle is much greater. And because it's something that does require more concentration than the pilot is perhaps allowed during a firefight, that's where the advantages of multi-crew, I think, will be seen.

One of those balances is, in the old system, you had a bunch of items and then the HUD and other systems try to figure out how they can talk to who, and it was kind of a mess. So when we went to item 2.0, we said we're going to get rid of that and we're going to do something different. We have these things now called controllers. We have these things that are the actual items. The controllers are basically the interface, how the player will communicate to the items on his ship. So if you want to adjust the power, you have to gain control of this energy controller, and that energy controller will talk to the individual power plants to make sure they're doing what they need to do. So what that means is the guy in the turret, he could observe the energy controller to see the status of everything. And then if Kirk's in the pilot seat, he has that energy controller, he could change stuff dynamically, and the guy in the turret could see what's happening. So you can have a guy in the shield station who's monitoring what power is doing because someone else is doing it while he's messing with the stuff. So you'll be able to now see what you're doing when you have these multi-crew segments.

And then speaking of the future, when we get to maybe getting systems like repair finalized, you'll be able to monitor and then choose how to repair things. Hopefully the best solution would be, you can physically go to where that section is in the ship, rip out the damaged or malfunctioning shield generator, pop another one in there, and then you're good to go.

The room system is a generic way for designers to lay out volumes to describe areas that are associated with rooms that will have certain gameplay associated with them. The first kind of system that we're introducing into that is atmospheres. So we have these rooms that they lay out. It'll be in a ship or on a space station or on a planet, whatever. They lay out this room system, which is all these rooms with room connections, and then we describe, okay, what is the gas composition of these particular rooms in their atmospheres? What pressure are they at? And then whenever you open a door or an airlock, we start letting flow, change dynamically the pressures between the different rooms, and they'll start mixing their compositions, and people start dying, inevitably. Basically, the room system is a way for us to consolidate markup for the designers for several gameplay systems, which would be atmosphere, security, power distribution for stations and stuff, other things that we're still thinking of right now. But originally it was more of a procedural thing as far as the hangar. We still plan on doing that. It's just a different system, or at least a differently named system, that will do that.

There was some work done on the hangar. It did use this old technology called prefabs. The problem with that is you had to load all or nothing. And since we want streaming, we couldn't use that system. So we actually had another programmer named Ariel. He moved them all to this thing called an object container. And it's basically like a mini level that we stream in and out. So that's kind of the first step toward making an expandable hangar. So there's work here and there being done in different systems. It's all coming together.

What I like about Chad's room system, though, is that it's not a hacked system in which we're just using little triggers to determine whether you die or not.

One of my favorite bugs is, whenever I was working on the room system and working on these atmospheric containers and stuff and adding new features that the designers were adding, also there's this guy, Nicky, in Germany, who's working on the stamina component for the player. So it's kind of two halves of this behavior. We have the environment behavior that defines all the atmosphere and the atmospheric flow and mixture and composition, all this stuff. But then you need something to care about that. So now we have this stamina component, which cares that there's enough oxygen in the environment, or maybe I'll start suffocating and dying. And so he was getting that starting to work and working with the audio and effects people to start getting suffocation working. But there was a bug in his code where it worked even whenever you were in editing mode while in the editor. So you'd be doing anything, like messing with a vehicle or changing anything in the game at all, and you would start suffocating because you weren't in a room with an atmosphere. So you'd have to move inside while you're editing to catch a breath before you could go back outside and edit some more, or you would die.

I think for our first go at this, we won't have those restrictions quite there yet. But as we start balancing them, figuring out the best places that each of the items should live in, we'll figure out where those restrictions need to occur. What's appropriate, what's not. And then if we need to make bespoke items for ship types.

And the recent Banu Defender is a good example. It's got Tevarin shield generators, it's got Xi'an engines, and the power plant was from, I can't remember the third race, but it's got technology from three different races in it. So to some extent there will be some interoperability, but there will probably have to be, for balance reasons, some captured Vanduul ship where it's like, okay, you can't take the components out of that one.

We'll have to play with the system first and figure out exactly where we're at.

I have not heard of anything along those lines. I'm not saying it's not possible.

It's just not something we're working on right now.

I'm not aware of anybody working on that.

I suppose we could transfer MFD functionality to mobiGlas at some point. With the right API.

The UI is Flash, at least. Potential there, but no promises at all.

I mean, with the whole new controller manager, it was designed that you could have anything register a user and say, here's his priorities, because we're using that for the AI module, we're using that for the manned turrets, we're using that for the flight, like air traffic controller, we're using that for all sorts of things. So we could have mobiGlas register the person who has these priorities and can dictate stuff. But we also have to make sure that works the same in multiplayer. So the system allows it, the API. We just have to utilize it.