Around the Verse: Upgrading Ships to Item 2.0 Part 2 Written Thursday 8th of June 2017 at 04:00am by Sunjammer This Around the Verse transcript was single handedly done by one of our Senior Transcribers, Sunjammer! A tremendous thank you to him. As per usual, anything said during the show is subject to change by CIG and may not always be accurate at the time of posting. Also any mistakes you see that I may have missed, please let me know so I can correct them. Enjoy the show!

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

Studio Update U.K. Air traffic controller sprint: Initial groundwork complete and now moving on to more functionality including communication with ATC

Introducing a new hint system to make initial learning curve lower for new players

Changing how a player spawns into a level (Ex: if a component is added to a bed it will be assumed the player will need to be attached correctly to it and play the normal lie down/idle animation correctly), this removes a large amount of FlowGraph data and simplifies setup for the level

Continuing work for missions in 3.0 with progress on implementation of Mission Broker and Mission Manager These determine how a mission and all objectives are presented to/given to the player to complete and also be tracking what missions a player already has/how far through objectives they are

AI locomotion: Refining the way Ai walks/runs around a level Implemented a new path smoothing algorithm which makes AI traversal around corners more natural Currently working on making reaching that point and going into whatever animation required seamless as possible

Graphics team: Wrapping up/bug fixing major features mentioned in last update such as lit fog, real time environment probes for planet lightings, etc Tweaks to lighting model to improve appearance of ground reflections of the sun on planets at sunset/sunrise

UK Animation team: Continued work on FPS weapons with previous complete for Gemini L86 ballistic pistol Arrowhead now close to final with some minor polish work left for reload states Takedowns gone from implementation pass to more refined animation pass AI animation work ongoing with improvement to posing of enemy patrol states and reactions to sight/sound Team helping to export remaining gameplay story cinematic scenes so Design can implement and better visualize the story within levels they're working on

Derby Animation team: Finishing off facial animations for 3.0 mission givers and Eckhart's body animation is being polished/implemented Some of the team attended a PU audio/facial shoot in London

VFX team: Continued tests of new lightning entity focusing on smaller scale interior electrical effects Testing features in new particle system as provided by Graphics team including better trail options and depth buffer based collisions First Levski exterior VFX pass underway Cutlass flight ready VFX including interior damage and thruster effects now done Continued work on atmospheric flight effects with focus on play testing/bug fixing/testing new features provided by Graphics/Engineering teams Ongoing polish for VFX for new weapons and reworked version is continuing up to 3.0 release

Art side: Origin 600i concept process now finished Next ground vehicle moving along and about to kick off a whole new round of ships Ship weapons they've take Klaus and Werner styling from FPS weapons and used it to influence worn on Klaus and Werner laser repeater Looking at some cool looking MaxOx neutron repeaters

Art team: Working away at further Shubin Mining Station interiors Continued work on providing infrastructure to habitation pods including comms arrays/water collectors/small deployable communication units

Space scenes getting facelift for 3.0 release, adding texture and visual interest to space overworld big priority for 3.0 release Reworked some of the distant nebula in Stanton system Working on large scale nebula rendering techniques using Pyro system as a test case, techniques will help create interstellar scale nebula

SQ42: Exploring the look/feel of the Coil using powerful fluid simulations to help achieve this look

Ongoing work for Truck Stop Stations materials Work on solar panels Rest of Truck Stop team are finalizing main hull pieces before proceeding to front/back sections of stations Special consideration being made to ensure to nothing looks visually repetitive Detailing areas around landing pad ongoing including adding more visual complexity to back of landing pad/around the borders on edge of the pad

Surface Outposts: More archetypal outposts have had a dressing and lighting pass including emergency shelter As well as illegal drug lab which may/may not be on one of the moons Planet integration materials for outpost exterior tested/tweaked for sand/ice biomes Branding prototyping explored for procedural locations with Rayari brand as test case including main logos/text along with secondary logos, indents, etc This would procedurally swap brands depending on ownership of the outpost

Ship team: Reclaimer work completed on drone room with focus on drone deployment/storage mechanism Engine room also been completed making use of repurposed assets from Idris Exterior damage setup nearing completion with internal geometry being built to be exposed when ship takes damage

Work on derelict ship/wreckage elements coming to end for initial batch Support now in place for Design to create mission scenarios based on derelict ships in space/on planets Material variations of each ship created so ships will look embedded to the surface type All that's remaining are technical elements such as LODs, vis areas, collisions

Gladius cockpit revamped/relit for new cockpit experience Art side it's been achieved by clearing a channel between top support screens to reveal Gatling gun on the nose, making a range of interactive buttons, remodeling throttle for improved functionality Cockpit canopy extended for better clarity and new interior lighting added

Hull C exterior work on finishing landing gear mechanisms and detailing inner bay areas while creating initial animations and work towards final art Front section of interior now modelling complete and getting a detailed lighting pass Once complete tunnel section/rear engine room will be modelled and lit in same fashion

Live Design team: Moving ahead with content for PU, giving needed attention to existing Arena Commander and Star Marine maps Dying Star had procedural asteroids added Star Marine maps received balancing changes Echo 11 some adjustments to capture points Last Stand and Demien added a new EVA route from Marine spawn zone to Landing Pad B

UI front: New features making their way into mobiGlas Progress on home screen functionality and displaying elements of actor status, atmospheric readouts, suit status readouts, personal overview Player loadout management working as an app in mobiGlas, should easily carry over to handle ship loadout customization as well as is currently in Arena Commander frontend menu Working to get mobiGlas UI in general to be projected using new render to texture tech

Work on designing/implementing upcoming character customization menu on frontend which will be included in 3.0 Players will be able to create/customize various characters in PU

Audio team: Features for 3.0 release including Procedural Planet Ambience system Refining approach on how to produce ship armaments and first person audio Producing sound schemes for different kinds of diegetic user interfaces that will feature in 3.0

Preparation begun for foley session to ensure audio coverage for character clothing/armour and content to extend footsteps system further

Progress on foundational audio tech such as dynamic bank loading/actor status system/audio propagation system/music logic system/content production for derelict ships/bespoke 3.0 location sound design/ship damage effects/audio support/ship improvements/etc Ship Migration, Part 2 Seats the original seats were part of the vehicle system and controlled enters, exits, etc. 1.0 seats turned them into a more generic system but they couldn't play animations on the vehicle ended up with two systems vehicle seats for single seaters and 1.0 seats for multi-crew 2.0 seats solved this by creating seat, seat dashboard and a seat access items 2.0 seats required them to break out all the assets into different items and animations into different states had to do it ship by ship: all ships are very special snowflakes

UI 1.0 seats used an ISeatHost structure which many systems, including UI, hooked into the UI was listening to all these crazy events and had to rely on the seat host if the seat host disappeared but didn't unregister it could crash or cause all sorts of problems 2.0 infrastructure relies on the item components rather than the seat or vehicle currently have to maintain 1.0 and 2.0 system until they can switch off the old system

Events the original events system sent an event to the vehicle which dispatched it to every item the issues were every item got every event, they got them immediately and it ran the main thread replaced it with a multi-threaded event system: items have their own event system and can link to each other items process pull down and process events during their batch update then dispatch events to other items

Controllers with the old system each item would handle it's own full set of logic 2.0 introduced the new concept of a control manager, controllers and subitems player connects to the control manager (e.g. ship) which connects to controllers (e.g. power) which connects to items now items have very specific logic and the controller takes the input from the user and translates it for the items call it a control hierarchy



Full Transcript

Intro With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Sandi Gardiner (VP of Marketing). Timestamped Link.

Sandi Gardiner (SG): Hello and welcome to Around the Verse, our weekly look at development of Star Citizen, I’m Sandi Gardiner.

Chris Roberts (CR): And I’m Chris Roberts.

SG: It’s great to have back in the LA office, Chris.

CR: Yes back, a little bit of jet lag but I just returned about a month over in Europe at our Foundry 42 offices in Germany and the UK. It was good to sit down with the teams to work through the various aspects of 3.0 and Squadron 42, which we’re very hard at work at.

SG: You can find out exactly what all of our offices have been up to by reading May’s monthly report which we’re releasing tomorrow.

CR: Yeah, and to tide you over til then here’s Nick Elm’s with an update from our UK office which I think you’ll enjoy.

Studio Update With Nick Elms (Creative Director). Timestamped Link.

Nick Elms (NE): Hi everyone, my name is Nick Elms and I’m the Creative Director here at Foundry 42 in the Wilmslow office. Erin is on holiday this week so it’s up to me to give you this month’s studio update. As you would imagine Wilmslow office is still a hive of activity with tasks, bugs and features, all being worked on for both Squadron 42 and 3.0. Let’s start with the ongoing sprints.

With the air traffic controller sprint initial groundwork has now been completed and we’re moving on to more of the functionality including communicating with the ATC. From your cockpit when you want to land, you now target the station using the player interaction system, select the option to request a landing and you’ll be given the start of a communication channel with the NPC to have a dialogue with them. We’re currently in the process of implementing this in real world cases, for example, in our PU map we’re setting up Port Olisar so both requesting your ship as well as landing will all through the ATC.

As part of the push to make Star Citizen more accessible we’re introducing a new hint system to make the initial learning curve lower for new players. As the player begins their first steps into the Star Citizen universe various hints will get displayed from the UI, giving feedback in how to interact with the different systems. Whether it’s entering the proximity of the ASOP terminal or letting them about a mobiGlas feature after a given amount of time.

For 3.0 we’re changing how the player spawns into the level, currently this is done by spawn points. So each bedroom in the PU map has it’s own spawn point and then some FlowGraph logic to position them correctly in the bed and play the correct animation. As you can imagine with the number of spawn locations in the PU this is adding up to a lot of FlowGraph and set up. Going forwards we’re creating a new spawn component which can be added to any entity. For example if this component is added to a bed we will then assume the player will need to be attached correctly to the it and play the normal lie down/idle animation automatically. This now means that we can remove a large amount of FlowGraph and simplify the setup of the level.

Work is continuing for the missions on 3.0 with the progress on the implementation of the Mission Broker and Mission Manager. These will determine how a mission and all its objectives are presented to and given to the player to complete. They will also be tracking what missions a player already has and how far through the objectives they are.

In the AI locomotion sprint we are spending time refining the way the AI walks and runs around a level. We’ve found that just following a path, which is determined by the pathfinding code, gives a result which is very unnatural. We’ve now implemented a new path smoothing algorithm which makes AI traversal around corners in a much more natural way so it doesn’t look like they are going from one point to the next. Because they are generally moving to get to a particular place we’re currently working on making reaching that point and going into whatever animation is required be as seamless as possible.

The Graphics team have been wrapping up and bug fixing the major features mentioned in our last update such as lit fog, real time environment probes for planet lighting, and render to texture work for holograms and video comms. In addition they’ve made some tweaks to our lighting model to improve the appearance of the ground reflections of the sun on planets at sunset and sunrise.

The UK Animation team has continued to work on the FPS weapons with the previous complete for the Gemini L86 ballistic Pistol. The Arrowhead is now close to final with just some minor polish work left on the reload states. The takedowns have gone from an implementation pass to a more refined animation pass with concentration on a stronger composition, solid posing, clear silhouettes and polish to the mocap data to better sell the overall action. The AI animation work is ongoing with improvement to the posing of the enemy patrol states and reactions to sight and sound. The team are also helping to export the remaining gameplay story cinematic scenes so that Design can implement and better visualise the story within the levels that they’re working on.

The Derby Animation team are finishing off the facial animations for the 3.0 mission givers and Eckhart’s body animation is being polished and implemented too. Last week some of the team attended a PU audio and facial shoot in London. They captured some awesome footage from some great actors and we think it will go a long way to fleshing out the universe.

The VFX team have continued tests of the new lightning entity; this time focusing on smaller scale interior electrical effects. They have also been testing features in the new particle system as provided by the Graphics team, including better trail options and depth buffer based collisions, required for sparks for example. The first Levski exterior VFX pass is underway, including refinery flames and general ambience. The Cutlass flight ready VFX including interior damage and thruster effects are now done. Work has continued on the atmospheric flight effects sprint with heavy focus on play testing, bug fixing and testing new features as provided by the Graphics and Engineering teams. The ongoing polish for the VFX for the new weapons and reworked version is continuing up to the 3.0 release.

On the Art side the Origin 600i concept process has now finished and we’re really looking forward to seeing what you guys think: it’s one sleek ship. The next ground vehicle has been rocking along and we’re just about to kick off a whole new round of ships. On the ship weapons front we’ve taken the Klaus and Werner styling from the FPS weapons and used that to influence the work on the Klaus and Werner Laser Repeater. On the other end of the spectrum, we’re looking at some cool looking MaxOx Neutron Repeaters.

The Art team has also been hammering away at further Shubin Mining Station interiors, working out a few more areas to improve on … for its believability. This is done zeroing in on the functionality of the areas. Work has also continued on providing further infrastructure to the habitation pods, including comms arrays, water collectors and small deployable communication units.

Our space scenes have been getting a major facelift for the 3.0 release: we’ve been very busy adding large volumes of interplanetary space dust in the Stanton system. Adding texture and visual interest to our space overworld has been a big priority for the 3.0 release. As part of this sprint we’ve reworked some of the distant nebula in the Stanton system but there’s still lots more to come. We’ve been working on large-scale nebula rendering techniques using the Pyro system as a test case. These techniques will help us create our interstellar scale nebula.

Also for Squadron 42 we’re exploring the look and feel of the Coil which plays a major role in in the first campaign. We’re using powerful fluid simulations to help us achieve this look. Any work we undertake on improving the space for 3.0, as always, is a great benefit for Squadron 42.

Work is ongoing for the Truck Stop Station materials. This includes finalising the panel shapes, adding some hue and gloss variations, and elements of wear and tear and dirt. The unclad frames are also being finalised with structural elements surrounding the machinery and high frequency detail. We are continuing to work on the solar panels, trying different ideas out and getting them to a stage where they gel well with the rest of the Truck Stop. The rest of the Truck Stop team are finalising the main hull pieces before proceeding to the front and back sections of the station. Special consideration is being made to ensure all pieces work, as well as the modular set, don’t look visually repetitive. Detailing areas around the landing pad is ongoing and this includes adding more visual complexity to the back of the landing pad as well as around the borders around the edge of the pad.

In relation to the Surface Outposts more of the archetypal outposts have had a dressing and the lighting pass. This includes an emergency shelter which can be found dotted around the moons as a place for crashed pilots to take refuge. Also and illegal drug lab which may or may not be on one of the moons. Planet integration materials for the outpost exterior have been tested and tweaked for sand and ice biomes. This determines the amount of dirt build up that can vary for each biome and can be adjusted for each outpost for variation. Branding prototyping has been explored for procedural locations with the Rayari brand as a test case. This includes the main logos and text along with the secondary logos, indents, lines and signage. This would procedurally swap brands depending on who owns the outpost.

With regards to the Ship team the Reclaimer work has been completed on the drone room. We were keen to focus on the drone deployment and storage mechanism as we’re excited to see this become functional when drones come online. The engine room has also been completed making use of repurposed assets from the Idris. All reused assets go through the process of reskinning with Reclaimer materials to make everything feel consistent and cohesive. The exterior damage setup is nearing completion with internal geometry being built to be exposed when the ship takes damage.

Work on the derelict ship and wreckage elements are coming to an end for the initial batch. And support is now in place for Design to create mission scenarios based on derelict ships in space or on planets. The material variations of each ship have been created so that depending on which planet ships are placed on they will look visually embedded to the surface type. All that’s remaining for this phase are the technical elements such as LODs, vis areas, and collisions.

The Gladius cockpit has been revamped and relit for the new cockpit experience sprint. This has been an exercise in improving the player’s feeling of immersion and has been a collaboration between several departments. On the art side it’s been achieved by clearing a channel between the top support screens to reveal the Gatling gun on the nose, and making a range of interactive buttons for more interesting animations, and remodelling the throttle for improved functionality. The cockpit canopy has been extended for a better clarity and new interior lighting has been added to help bring it all to life.

On the Hull C exterior work is currently being done on finishing the landing gear mechanisms and detailing the inner bay areas while we create the initial animations and work towards a final art. The front section of the interior is now modelling complete and is getting a detailed lighting pass using new light groups controller. Once this is complete the tunnel section and rear engine room will be modelled and lit in the same fashion.

The Live Design team are plowing ahead with content for the PU and they’ve made sure to spend a bit of time giving much needed love to some of the existing Arena Commander and Star Marine maps. Dying Star has received a new lease of life with the addition of procedural asteroids which give a much more cinematic dogfighting experience. Both of the Star Marine maps have received a number of balancing changes based on feedback from the community. In Echo 11 we’ve made some adjustments to the capture points, and in Last Stand and Demien we’ve added a sneaky new EVA route from the Marine spawn zone to Landing Pad B.

On the UI front we’ve been busy chipping away at all the various features that are making their way into the new mobiGlas. We’ve made progress on getting the home screen fully functional and displaying elements of actor status, atmospheric readouts, suit status readouts, as well as personal overview. We’ve also got player loadout management working as an app in mobiGlas: this interface should easily carry over to handle ship loadout customisation as well as is currently in the Arena Commander frontend menu. We’re also working to get the mobiGlas UI in general to be projected using the new render to texture tech which will make the UI look much more properly integrated within the game world.

Work has continued on designing and implementing the upcoming character customisation menu on the frontend which will be included in 3.0. From here players will be able to create and customise their various characters in the PU, obviously dependant on how many character slots that player has. Initially the level of customisation will be limited but it will be expanded in the future to provide much more granular control of characters’ features.

The Audio team has been working on several features for the 3.0 release. These include the Procedural Planet Ambience system which is designed to place appropriate sounds around the player dynamically as they traverse planetary bodies. We’ve also been refining the approach on how we produce ship armaments and first person weapon audio. Further ensuring that they are satisfying for the player while reflecting player driven modifications and customisation.

[Audio Dev]: This example I’m going to show you today is for the Behring Size 2 Laser Cannon. We’ve basically changed the sound to a new, more exciting, big sound using our new system which I’ll explain. So this is what the new sound is like.

[pew, pew]

So as you can hear it’s basically ... yeah ... a lot bigger, a lot punchier, a lot more pronounced.

NE: The audio team has been producing sound schemes for the different kinds of diegetic user interfaces that will feature in 3.0, including the kiosks. The audio direction of these vary to suit their tech level and this presents some great opportunities to reinforce their look and feel.

Preparation has begun in earnest for a foley session at Pinewood Studios to ensure audio coverage for character clothing and armour, and content to extend the footsteps system further.

Progress has also been made on the foundational audio tech, such as dynamic bank loading, the actor status system, the audio propagation system, and music logic system; as well as content production for derelict ships, bespoke 3.0 location sound design, ship damage effects, audio support, ship improvements, and more besides.

We’re really excited about all the new content and gameplay that 3.0 will bring. And as you can see from what’s being going on here we’re getting closer every day.

All that remains for the UK update is send out a massive thank you to you, our backers, without which we would not be able to put together this amazing game.

See you in the ‘verse.

Back to Studio With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Sandi Gardiner (VP of Marketing). Timestamped Link.

SG: Placing procedural asteroids into Arena Commander should add a fun, new wrinkle to dogfighting.

CR: Yeah. No. It’s actually great to see the new technology we’ve been building for 3.0 and beyond … make older aspects of the game better and handsome. And also it’s also cool to see a lot of the new stuff we’re working on that was in the report, like the space … space wrecks on the moons - and we’ll have them out in space - going to be really fun to discover and explore.

SG: Very cool. One of the biggest upgrades coming to the game is Item 2.0. On last week’s episode we used ships to explore how this system opens a whole new world of possibilities for Star Citizen.

CR: Yeah that’s right. So when it comes to ships it allows for swappable components, ties into the new interaction systems, and even upgrades the seats and cockpit displays making the aspect of flying and controlling or using a ship much more tactile and visceral which has been the goal of Star Citizen since the beginning.

SG: For more on this here’s part two of our feature on how Item 2.0 is changing the way you’ll play the game.

Ship Migration Part 2 With Mark Abent (Gameplay Programmer). Timestamped Link.

Mark Abent (MA): Last week we spoke about the incredibly important migration of all our ships to the Item 2.0 tech, today I want to describe some of the challenges we faced.

We had these seats. And the seats are pretty nifty. They allow you to enter, exit and do some basic things. But they are only for vehicles. They’re part of the vehicle logic. So one of the stepping stones before we got to 2.0 was to turn that seat into more of a generic system. It was kind of like the in between of the vehicle and then the 2.0 system. And what that allowed us to do was to separate these seats into individual items to do you enter/exits. So we started porting stuff over to that system and we came across some problems that the original system solved but the new system didn’t.

Say we have a single seater fighter and we need to open up the canopy and then the ladder, and then you walk up and then you enter it. Now with the original vehicle seats you could do that. There are these things called “post actions” and, I think, “pre actions”. Basically we can play an animation to open those gateways and then the player could enter the entrance and then everything will close. Problem is with that 1.0, the new seats, is that you couldn’t actually talk to vehicle to play those things, but you could play an animation on itself.

So these 1.0 seats were mostly used for things like the multi-crew ships where you didn’t have to play those animations on the ship: you just needed to play it on the seats. So you needed … like the Retaliator has this dashboard so you interact with it and do stuff: that was all separated out of the vehicle. But if you still needed to play those animations vehicle you had to go back to the vehicle seats.

So what that led us to do is now we have two different seats. They solve two different problems. And what we want to do is remove these two seats and go with a 2.0 version that solved both of these issues.

What we had to come up with was we needed a seat, and this thing called a “seat dashboard” and then the “seat access”. The seat is only responsible for just plopping the player down and giving him control. The seat by itself doesn’t do anything. Then you have the dashboard. This is basically that infrastructure you see in front of you that shows the UI, shows this, shows the joysticks. Then you have the seat access which dictated how you got into that seat.

Now we could do all that. Which is fine. However we needed to break ... as you can see we now have three different items where those other original things just had ... like the vehicle seat just had it … just on the ship.

So now we have to break out all of these assets and put them into different items. We have to break out all of the animations into these different states. Yes the system allows us to do a lot more. It allows us to do things that some of the Animation team want to do but, because of the way the old vehicle seats and item seats were designed, we had to go back and revisit how we did those. Change the art. Change the whole process. Take our animations: cut them up in different ways. Just to get them onto the 2.0 infrastructure.

So it’s like the stuff we want to do way back then we couldn’t do so we kind of had to do some fakearoo. But because of that fakearoo we had to go back, cut them up to how we actually wanted to do it finally after - this is stuff we’ve been talking about with Animation/Design for a long time - and it’s just an extra step we have to do to move everything over. That’s one of the reasons why it’s taking a little bit.

We actually have a big master plan of moving all the ships over and it’s like “Before we can move this guy over we have to cut that animations up from here, to here, to here. Move this here. Move this here. Okay, does that work?” And so we’re doing that ship, by ship, by ship.

And of course all of our ships are very special snowflakes. They’ll do something a little bit different here and so we have to … since we have a defined plan of how this new setup is going to work we just have to figure out how that’s going to get cut up correctly so it works with the new infrastructure. One of the precautions we’re now taking with all the new ships is learning the problems of what we did in the past: of what the ship is doing wrong or different that’s causing havoc.

A very beautiful ship that’s causing us some fun is the Gladiator. You have two seats on the top. And then you have a bomb bay door on the bottom. And you have this line that has to come down to allow either one of them. The original thing wanted both the seats to come down. So if I’m piloting the ship and my copilot wanted to get out I have to come out with him. Luckily we were able to split that up so that a pipe comes down and either one can come.

But you still have the problem of that bomb bay door because that’s part of the landing system and the seat system, which is two different seats … connections that don’t know about each other. And the old system didn’t really handle that too well. But now on the 2.0 we’re going “Okay, you can’t leave until that bomb bay is open. So we’re going to open that first. Then you can come down. Then the seats can go back up.” So we have systems in place but ships are special cupcakes and we’re just going to make sure they work on this new flow.

When we’re splitting up the ship from … moving the vehicle from being the ship to this sub-hybrid thing called the “1.0 seats”, we had this thing called a “seat host”. And the seat host was basically trying to … trying to move that bit of logic of seat from the ship to a generic thing. And it was like a very beginning sort of structure. It was a weird mixture of things. The idea for that thing was so that vehicle, turret, generic stuff could use this HaveSeats. But because of that a lot of things started using thing called ISeatHost. So you had things in the player code checking to see if there was … if you were attached to an ISeatHost. You had things in UI checking to see if you were in ISeatHost. So you had a lot of these embeded things checking for this thing called an ISeatHost which was horible but it was the only way to get stuff going until we separated things into components.

We now have to take these things that relied on the seat host and make them more into a more generic thing.

One of the biggest challenges is going to be of course the UI. Things like the visor relied heavily on these seat host things. You pull events, pull information, out of … these events would get dispatched when … I have my ship again: this guy starts firing, this guy’s UI will listen to it and it has to go “Oh, I’m not the guy shooting so I’m going to ignore this block.” But not everywhere did that so you have the UI listening to all these crazy events and it had to rely on this thing called a seat host. But if the seat host disappeared and didn’t unregister you’d crash and all sorts of problems.

We came up with this new infrastructure for the UI - for the seats - where they relied on more of the item component themselves rather than the seat level. And what this allowed us to do was worry about just the item. So you would have a UI for power: it just relied on knowing about the power plant. It didn’t care about vehicle. It didn’t care about player or what it was attached to. And the beauty of that is I could technically slap this onto a Big Benny machine that has a power plant and you could see its power coming.

But … that was the dream and separating that UI bits and pieces is one of the biggest overhauls we had to do. Not just for UI but in all the other sections of the code. And we’re still dealing with it because we’re at a point where we have to maintain both the Item 1.0 and the Item 2.0 until we could fully flip the switch saying 1.0 is not supported. So you have some UI with that seat host. Some UI with just the power. And it’s that weird thing you’re trying to deal with to not break the old until everything can get switched over to the new system.

One of the other big architectural changes we’ve been working on is … going back to the vehicle, if we had items on here, we had this thing called an “event system” that sent an event to the vehicle and that would dispatch it to everybody else. But since we want to get away with that event system for one, everyone knows about it and, two, it was immediate and it was on the main thread. So what that meant is if I sent an event and I sent it to everybody the main thread basically has to wait until everyone got it, they all did their update, and then everything happened instantaneous.

So if a radar picked up some enemy and he sent an event saying this thing was added. The UI would get it and we’d have to create all these resources just to display. A lot of things would happen when one event dispatched.

So one of the big things that we’ve changed is instead of having this immediate called event system, we have thing called a “multi-threaded event system”. And instead of everybody connecting to the vehicle's event system they have their own and they can link to each other.

So now if the UI want to know about radars getting ... stuff appearing on the radar, it can listen to this thing called the “radar databank”. And the radar databank, when it picked up something from the radar, the radar would send an event to the databank. The databank wouldn’t process it right then and there. It would process it in that batch update, that I was talking about, during its own time: pull the events out, do its thing, and handle that big load onto that thread. And then when it would do something it would then dispatch events to other systems and they would do that same very thing. So we’ve just offloaded this heavy system into batches. And also allows us to guarantee that when this guy sent the event the other guy would pull it down when he ready not immediately occurring.

And with that nice event system we could actually do some nifty things where we could actually localise those events.

So before, as I was saying, we have … we separated the person who controls stuff from the actor to this thing called an “item user”. The item user has these main events, we call them “input events”, and he has an input and output event system. He could get inputs from all sorts of things and he could send off outputs. So if I press a button he might go “Oh, I need to turn on lights”. He’ll translate that to an out event system. He’ll dispatch to all items he ... they control but they’ll only pull it down when they’re ready to.

So the player hits a button. It may be a “switch on light”. The “switch on light” get sent to an event. It finds the controllers that he controls. Figures out “Oh, this guy needs to have it”. Cue zzzthis event. That light controller will pull the event down in its batch update and go “Okay I need to turn on lights” so I’m going to go through all my lights, send them and event saying “Hey go turn on”. They’ll go on their batch update and go “Oh, I should be on or off. I’m going turn on … off … on”. Whatever button you hit.

So now we’ve moved this thing that was a global thing on the vehicle - I send an event here and everyone gets it - to a more localised system that all gets using … utilising that batch update and the whole big infrastructure of our controllers and items.

This other thing that we have with this Item 2.0 infrastructure … with our old system, with the vehicle, when I sat down in a seat I would get control weapons, items, and all that stuff. And each thing would kind of handle their own set of logic. I’m hitting the fire button to shoot and then it would do its thing and shoot. We wanted to separate that into a much more coherent structure, and so after talking with Design, we came up with this new concept where you have the control manager, which is the ship, and you have the user and then the user connects to the control manager and he controls these things called, literally, “controllers”. So you’d have a power controller, a light controller, a door controller: basically these are the things that have control of subitems. So the controllers handle the input and then they sell things to the items.

An easy one: a power controller. So this power controller might have control of sub power plants. It will talk to UI saying “Here’s all the power plants that you have, what do you want to do with them?” So if I hit UI or maybe a button to throttle it will send an event to the controller; controller will go “Yes you can do that. No you can’t do that” and it will then tell the items to do something.

So now we basically have these subitems that are really kind of dumb, that hand very specific logic like power plant just needs to provide X amount of power. And then you have the energy controller that basically input from UI and input from the user and it translates what you want to do to those subitems. So we have these very specific things that handle the … I guess you’d call it the control hierarchy.

As Ash said in last week’s episode, although it’s a lot of work to implement, it is a game changer in every sense of the word. Item 2.0 touches every facet of the game and will ultimately create a much more immersive, interactive experience.

Thanks for watching.

Seacrest out.

Outro With Chris Roberts (CEO, Director of Star Citizen and Squadron 42), Sandi Gardiner (VP of Marketing). Timestamped Link.

CR: So as you can see Item 2.0 not only allows us to implement new features but also streamline others. It’s obviously a lot of work but it’ll provide a much more immersive experience. And you know how much I like immersion. So ...

SG: Yes you do! That’s it for this episode of Around The ‘Verse. Just a reminder that we’ll be updating Spectrum tomorrow so it’ll be offline for about half an hour 11am Pacific. Then make sure to swing by after that to check out all of the new features.

CR: Yeah they’re pretty cool. You can see threads with different view styles and all the rest of stuff. And also don’t forget May’s Monthly Report goes live tomorrow, along with update to our Production Schedule.

SG: Thanks as always to all of our subscribers whose continued support make shows like this possible. Click on the link in the description if you want to learn how to become a subscriber yourself.

CR: Yep, thank you to all subscribers. And of course Star Citizen is a reality because of the amazing support we get from all backers. So thanks to everyone who’s making the game possible.

SG: We hope you enjoyed watching and we will see you …

Both: … Around The ‘Verse!

Sunjammer Contributor For whatever reason, this author doesn't have a bio yet. Maybe they're a mystery. Maybe they're an ALIEN. Maybe they're about to get a paddlin' for not filling one out. Who knows, it's a myyyyyyystery!

Please enable JavaScript to view the comments powered by Disqus.