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!
Focused on getting shops related to PU/landing zones functional first and will be making a pass of Area 18 shops as well
Armour can now be bought piece by piece
Remaining ships have been implemented into the price fixer tools
This tool is also used as a way to gauge whether or not the ships they’re building are over/underpowered for their intended purpose
Progress has been made on getting Miles Eckhart ready to go, lot of work on the feather blending system and got him working with a small subset of his animations
Received additional code support to allow reputation to dictate his conversation paths with the player
Now have the ability to assign specific missions with mission brief tags
Josh Coons finished images/videos of the Cutlass Black and moved onto create base material and whitebox meshes for Cutlass variants
He will complete the first pass on exterior looks for the variants before moving on to the Constellation Phoenix to allow Design to flesh out some key gameplay system for Cutlasses
Chris Smith working on bugs for Hornet/Constellation Andromeda and will move on the promo video for Constellation Aquila next
Backend Services team preparing for deployment of diffusion, game servers now have full access to diffusion API and they’ll start using it with the shopping service in 3.0
Started converting the persistence cache and general instance manager into smaller stateless, full diffusionized services
PU Animation team started research/development for how to implement their wild line(dialogue spoken by an NPC) system
Feather blending allows them to blend performance capture of the wild lines with a large number of useable animations
Going through existing animations and filling in gaps missing from original performance capture with new transition animations
Austin Ship Animation team continue to refine the cockpit/turret experience
R+D phase of implementing button presses using Item 2.0 system, this helped finalize dashboard/cockpit metrics across different ships that use same cockpit type
UK Engineers refactored some backend systems allowing to fully implement blending of base G-force pose blend spaces
DevOps team working on increasing capacity of build/deployment pipelines in preparation for 3.0
Making additional change/bug fixes to support new delta patcher
IT department upgraded Austin network
Audio team member Jason Cobb continued work on derelict crash site sound design for different moon environments/performed a variety of particle audio implementation experiments for revamped ship debris noises/playtested and mixed refinements for ship emergency state audio and captured sound effects for various props and materials
Austin QA has been testing new Cutlass Black
New missions/wrecks/NPCs in Stanton
Ship testing continued as more ships converted to Item 2.0 system
Large scale playtests of Arena Commander, Star Marine and Stanton ongoing weekly
Testing more mobiGlas applications like Starmap, the personal manager, mission manager and mission board
Testing character gravity/free fall as well as cargo mechanics
Engine/editor testers are testing new tech like capsule based actor entity, entity component update scheduler and director/actor animation and control
New stamina/oxygen breathing system are getting some balance changes
Four new people joining the Player Relations team
Ground vehicles can now be added to the ship matrix as well as anything that comes up
New sizing scheme for ships
Resdesigned ship detail page
Reworked ship matrix database to make it easier to update
Spectrum v0.3.6 with Evocati
New features include new text editor
New tools like hyperlinks, hyperlink formatting, preview posts and drafts
Mini profile which include post count and karma
New jump to track reply
Working on refreshing some UI elements
Engineering team working on getting most of the digital distribution channels ready for the Delta patching system.
Sandi Gardiner(SG): Hello and welcome to another episode of Around the Verse, our weekly look at Star Citizen’s ongoing development. I’m Sandi Gardiner.
Chris Roberts (CR): And I’m Chris Roberts.
SG: It’s great to have you back, Chris.
CR: Yeah, quite nice to be back here in LA and I did enjoy getting to spend a few weeks with our Foundry 42 team in the UK and Germany reviewing all the awesome work they’ve been up to on Squadron 42 and Star Citizen.
SG: One of the many things being worked on by the Foundry 42 team is the Tumbril Cyclone, which was unveiled last week. On today’s episode we’re going to take an in depth look at this rugged new ground vehicle.
CR: Plus we examine the tech behind game wide persistence by showing you how it is used to get one ship to persist inside another ship’s hangar.
SG: But first let’s check in with Austin and Turbulent for their monthly updates.
Jake Ross (JR): Hey guys, Jake Ross here, Producer in Austin. We’re picking up speed with Gamescom and the 3.0 release fast approaching, let’s jump right in and see what’s been going on here in Austin this month. To start over the last month LA Engineering refactored the shopping code enough so that Austin Design team could start plugging the items back into the shops. This is also includes the first pass of getting the kiosks up and running for the commodity trading, we have been focusing on getting all the shops related to the PU stations and landing zones functional first but we’ll also be making a pass of the Area 18 shops as well. We’ve now got the ability to purchase armour piece by piece so we’ll be adding that to the feature list.
We’ve also finally implemented the remaining ships into the price fixer tools. The price fixer is a spreadsheet that allows us to see each ship's physical loadout, see the price of each item in that loadout and determine the overall cost of each ship. This is important because it’ll allows us to more accurately assign a ship their respawn value which covers the cost and respawn timers for the ships being released in 3.0.
We also use this tool as a good way to gauge whether or not the ships we’re building are over or underpowered for their intended purpose, we’re very close to completing this task and will be moving on to balancing the shop inventories and item prices that you’ll see in 3.0 after that.
Lead Designer Rob Reininger took a trip to the Frankfurt office this month to work with the AI and Subsumption team and made a ton of progress on getting Miles Eckhart, the mission giver, set up and ready to go. We figured out a lot of work on the feather blending system and got him working with a small subset of his animations. Since that time we have received some additional code support to allow reputation to dictate his conversation paths with the player. We’ve literally just received the ability to assign specific missions with mission brief tags, so we can have him playing different lines depending on what missions are available. Beyond this we’ve just been plugging away trying to make the mission giver experience as good and polished as possible for the 3.0 release, we can’t wait to get Miles Eckhart into your hands and get his missions for you guys.
On the Art side, Josh Coons finished images and videos of the Cutlass Black and moved onto create the base material and whitebox meshes for the Cutlass variants, the red and the blue. However while he will complete the first pass on the exterior looks for the Cutlass variants he will move on to the Constellation Phoenix next to allow Design some time to flesh out some key gameplay systems for the Cutlasses a little bit more.
Chris Smith has been working on bugs for the Hornet and the Constellation Andromeda. He’ll start moving on a promo video for the Constellation Aquila next.
The Backend Services team have been supporting 3.0 features and preparing for the deployment of diffusion, the game servers now have full access to diffusion API and we’ll start using it with the shopping service in 3.0. In addition we have started converting our two monolithic services, the persistence cache and general instance manager into smaller stateless, fully diffusionized services. Out of those two services will come nearly a dozen smaller services, each with very specific roles that can be scaled independently. These will provide more reliability and performance, most of our work has been lower level, under the hood type changes that don’t have any front facing bling to show off. Going forward we’re plotting the path beyond 3.0 and starting to mill many small services that will provide functionality and support for a large number of gameplay features and help unload work from all the dedicated game servers into our distributed infrastructure.
This month in the PU Animation team, we started research and development for how to implement our wild line system. A wild line broadly speaking is any dialogue spoken by an NPC. The wild line we’re working on are things like greetings, cheers, shouts and other verbal expressions barked out by NPCs. We’re working with the new technology feather blending, mentioned previously which allows to blend our performance capture of our wild lines with a large number of useable animations. This will get us as close to our actors performances as possible while still keeping the functionality of what the NPC is doing intact. We’re also going through all our existing animations and we’re filling in any gaps missing from the original performance capture with new transition animations.
The Austin Ship Animation team has been hard at work with our continued efforts to refine the cockpit and turret experiences. We’re in the midst of an R+D phase of implementing button presses utilizing the Item 2.0 features. This has helped finalizing dashboard and cockpit metrics across the different ships that use the same cockpit type. The UK Engineers have refactored some backend systems allowing us to fully implement the blending of the base G-force pose blend spaces, allowing added animations for button presses as well as playing different hit reaction animations based off of hit direction, damage amount and overall health of the ship. As always, we’re diligently at work fixing bugs for our next big release.
The DevOps team continues to work on increasing capacity with our build and deployment pipelines in preparation for 3.0. They’ve also been making additional changes and bug fixes to support the new delta patcher and so far the internal tests have been really promising.
Our Corporate Technology team or IT department has just completed another major upgrade to the Austin network, they’ve added more hardware to the build systems so we can deliver more builds in parallel.
Our resident Audio team member, Jason Cobb has had his hands full this month as well. He’s continued work on derelict crash site sound design for the different moon environments, performed a variety of particle audio implementation experiments for revamped ship debris noises. He’s playtested and mixed refinements for ship emergency state audio and captured sound effects for various props and materials as opportunities arise.
July has also been an exciting month for Austin QA and it’s impossible to describe everything we’ve been working on but here are a few things. We’ve testing the new Cutlass Black, while in Stanton we’ve had new missions, wrecks and NPCs as a big ongoing focus.
Ship testing has continued to be very busy and more families that have been converted to Item 2.0 come online. Large scale playtests for Arena Commander, Star Marine and Stanton have been ongoing weekly alongside our LA QA cohorts and we’ve also been conducting cross studio playtests with the team in the UK.
We’ve also been testing more mobiGlas applications like Starmap, the personal manager, the mission manager and the mission board as they’ve become available to QA over the last few weeks. Some other fun items we’ve been testing are character gravity and free fall as well as continued testing of cargo mechanics, we’re still providing support for the animation team here in Austin as well by continuing to clean up mocap files to help free up animators for other work.
Our normal engine and editor testers are still extremely busy testing new tech for the developers such as capsule based actor entity, the entity component update scheduler and director/actor animation and control. Some features like the new stamina and new oxygen breathing systems are getting some balance changes with QA helping our designers there as well.
The Player Relations team has been busy recruiting new team members in anticipation for 3.0. In addition to starting to grow the Evocati ranks, the team is adding four people to the Austin office. We’re excited to have these new additions join the team in the run up to learning and testing for 3.0. That’s everything we’ve got to show you for this update guys, we look forward to delivering everything we’ve been working on to you all in the upcoming release and at Gamescom, thanks for all you do for us and we’ll see you in the ‘Verse.
Benoit Beausejour (BB): Hi guys, this is Benoit from Turbulent and this is your platform update. This week we’re going to hear from Paige Saunders who’s going to talk to us about the upcoming ship matrix changes and we’re also going to be talking with Victor Bonnet-Mile who’s also known on the forums and the chat as Fulgrim to talk to us about the next Spectrum update.
Paige Saunders: I’m Paige and I’m a Full Stack Developer here at Turbulent in Montreal. I’m working on updating the ship specifications in the database to reflect more accurately where CIG are at with their vision on the game and the ships that are in it. A lot of new things have been added to the ship matrix so we’re taking the opportunity right now to include things like Quantum drives and Quantum fuel tanks as well as smoothing out all the existing components to make more clear exactly what is in each ship.
The challenge with the ship matrix has been including the new ground vehicles into it, so added capability to add ships, ground vehicles and anything else that comes up. There’s a new sizing scheme for ships so you have weapons maintaining their size 1 through 12 and the other components maintain a more easy to understand small/medium/large system that’s related to the ship sizes so that you can tell what goes on what ship and whether a ship has a size that fits larger or smaller than it typically would have.
So, I’ve redesigned the ship detail page so that you tell for each component what size it is and see from the icon what type it is. As well as what can be upgraded to and what could also fit in the slot, then you can zoom out and see an overview of the ship with all the slots that are currently populated and the slots that are available for you to upgrade your ship with.
Backers have noticed that the ship matrix in the past hasn’t got a lot of love so reworked the database to make it a lot easier to update. From this point on we’re going to be able to as things change in the game, quickly get in there update the ship, make sure that it's up to date and reflects accurately what the game experience is going to be.
Victor Bonnet-Mile: Hi everyone, I’m Victor… QA at Turbulent. You probably know me as Fulgrim on Spectrum, I am the QA on the RSI website so Spectrum and the website and a little bit of the launcher. So I’m going to talk to you today about Spectrum. So Spectrum 0.3.6 is on the PTU with the Evocati. 0.3.6 includes new features like the new text editor so when you would write something on the new post for example. You will have new tools like hyperlinks, hyperlink formatting like the emoji toolbox would be there and more important the preview of the post and drafts. So now when for example you’re busy typing your thread and you want to check what your friends are saying in the forum or on the chat lobby, you can just go check what they do and everything will be saved. So now we have drafts.
0.3.6 includes too the mini profile, the mini profile is like the current profile but with new features like the post count and karma so the post count will be important from the old forums so people with a lot of posts in the old forum won’t lose all those posts and the karma is once you get… every time you get an upvote on a thread you made or a comment, you will get one karma point and it will be on your profile too.
So we’ll add new feature too which is the jumped to new track reply so for example, you know I’m staff so we’ll post something in the thread and a backer will be able to just go down the thread see the small icon of staff reply, click on the icon and it will be directly jump to the reply of the staff and if there are more than one reply of staff replies… you will be able to jump between reply using a small button. So everything is good, this feature is available too for organizations so you can just set it up in your settings, in your settings. This is a feature that you asked and we give you.
BB: Thanks guys for your update, a little quick note on the launcher, the team has been working really hard with CIG engineering to try and get major progress done on the new delta launcher which some with the delta patcher which is a faster patching method. The team has really been working on refreshing some of the UI elements, we’re keeping the same UI base but we’re refreshing it with some of the 3.0 new imagery. We’re changing the entire core of the application in this update so we’re going in full swing testing out multiple platforms, you know, installation paths. At the same time most of our engineering team has been working on getting most of the digital distribution channels ready so that we can get those objects as fast as possible to you when you request a game version so that requires also security reviews and you know deployment script but that’s basically where we’re at with the launcher. We’re really working hard, everyone's working really hard to get this patcher out for you guys for 3.0. We’re hoping we’re going to make it, we’re pushing real hard so that’s our update for this week on platform, see you guys next time.
SG: Miles Eckhart is proving to be quite the popular test subject for various systems.
CR: Definitely. He's the new cafeteria really. The design and subsumption teams really put him through the paces to get stuff like the reputation system and feather blending working. All that effort is going to make for more interesting and realistic NPC interactions in the game which is our goal.
SG: With the introduction of our vast interplanetary tech, another aspect of the game that's recently gotten some extra attention is our fleet of ground vehicles. Last Friday we revealed the Tumbril Cyclone.
CR: Yeah, we did. It's very, very cool, and let's take a closer look at the Cyclone and it's many variants.
Paul Jones (PJ): My name is Paul Jones. I'm one of the art directors here at Foundry 42.
Stephen Hosmer (SH): My name is Stephen Hosmer, and I am a technical designer at Cloud Imperium.
PJ: We're sort of starting to enter into the world of land vehicles. That gives us a wide brief. Buggy? It's a … it's a good one. This is a new manufacturer. It's always exciting to have a sort of clean slate. According to the lore this manufacturer ... this company … been around for a bit. Used to sort of provide a sort of super rugged vehicles for the military.
SH: So the Cyclone is intended to be a land vehicle where you get in and drive around on the surface of a planet. It's supposed to be a fun vehicle to drive fast. It has four-wheel drive. It's got four-wheel steering also. Something you're supposed to be having fun while you're driving around on the planet taking jumps off ramps. Just doing all the things you can in a wheeled vehicle.
PJ: You can sort of tell that it's got military roots in the way it's got … it's very functional, but there is that sort of hint that knowing it's market, and it just wants a little bit of flair, so there's a touch of artistic flair designed aesthetics in there, and now this is sort of their first entry into manufacturing and providing it and selling a new vehicle. It's based in functionality basically. It's design. So, it's very much approached from that point of view.
SH: The Ursa Rover I would call it a tortoise, and the Cyclone I'd call it a hare. Where you have the Rover, it's going to be slow and steady. You've got the Cyclone which is going to be fast and fun to drive, and then the Nox is going to be a speedster that's going to get out there, but it's not going to take as many hits. So, it's like kind of in between.
PJ: That pretty much defines quite a few things right off the bat. You know just ergonomics. We know what it's meant to do whether it's … like I said it's not meant to be a crazy sort of six-legged vehicle or anything. We want it … It needed to be fast. It needed to look super rugged. It could take a hit. It still has open elements to it, so you're still going to feel the wind in your hair so to speak. If you have any hair. We hit it quite … hit it quite early on actually in the process probably within the first two weeks we knew where we were going with it. So, the modularity is something that was specified by the design department, and so I think it works really well. It's almost … It's kind of … It's very similar to real world in the sense of having a truck, and then you've got your flatbed at the back, and then you can add and subtract basically.
SH: The first variant is just the base. It's just the regular buggy with a flatbed on the back that's meant to carry cargo. So if you're just sitting around on your homestead, and you want something to go from place to place and carry a little bit of cargo, that's the one for you.
The next one is the turret version, the TR, and that's mostly a military version kind of harkening back to the old days of Tumbril. It has a turret, so you've got a third seat for a turret operator, and it's got a 360 degree arc, and it can fire in any direction. It's kind of like an infantry support vehicle. If you're a boots on the ground operation, this is your cavalry. This is the thing that's going to get in, get around all the other troops and kind of support them.
The next one is the Recon, and the Recon is RN version, I believe, and that one's meant to be something that goes under the radar. It's got stealth components, and then you can get into an enemy base. Scout around. Use your radar to find emplacements or something like that. Use your beacons. You can put them down. Use them to light up a target that you need the guys in the sky to come down and rain fire upon, or you can just use it as an exploration vehicle. You can go out. You can map terrain. You can … you can go on to one of the planets that has a dust storm or something. You can drop it outside of the dust storm, drive in, find whatever you're looking for whatever objective you're trying to find, place your beacons and say, “Hey, this is the landing spot in this storm.” You can bring your ship in. You can find those beacons. They can call you down. You can pick up whatever you need to get there.
The next version is going to be the racing version, the RC. It's mostly just … we're taking the base Cyclone and we're putting basically nitrous oxide in the thing. You hit the boost on that thing. You can take those jumps as fast as possible. You can get around as quick as possible. It's like if you're in Baja. You're going over the dunes and hitting the boost, and you're just going as fast as possible.
And then the last one is the anti-air vehicle, and that one has two size two missile racks, so you can either have a size ... two size two missiles or four size one missiles, and then it also has a countermeasure package which includes chaff, flare, smokescreen and a size one EMP.
PJ: You know you always think, “It's good. It's interesting. It's fresh.”, but you sort of sometimes you think, “Oh yeah, we'll nail this. No problem.”, and then it's just the little things that trip you up and keep tripping you up. It's just getting aware of all the things we need to take into account: enters and exits, the whole cabin, all the instrumentation has to be in the right place, and you're constantly sort of jiggling trying to hit what the game needs and then what others/artists want to push in there and experiment with. You know there were a couple of things that maybe we could have improved on, but we'll … but when it goes to the production team we'll have a chat with Nate, we'll have the kickoff, and they'll be like, “This went well. Less happy with this. Maybe you guys can flesh this out a little more, sort of really advance. Again the manufacturer, so we know when we're building Tumbril vehicles. Okay this is what we do. These are the materials. This is the cloth. This is the metal. This is the paint. This is the color. Here's our decals. Here's our UI style”, and just clarify all of that basically.
Probably the most challenging thing is probably always the deadline. [chuckles] The beauty of this being the first one you have a certain amount of naivety in terms of you are not quite … You know you're doing a land vehicle, but you're not quite sure of the problems you're going to hit, and often with this sort of stuff hits very much you make one change, and it has a ripple effect of the whole vehicle. So, you make a change the front, suddenly your front is out of balance with the back, so now we got to change the back. Okay the back's changed now, so that's affected something somewhere else, and so it's trying to manage all those little tweaks and changes and still hit the deadline basically. So, that's always a tough one for me. I mean we always do it, but it's always … always team effort. You know, how do we do it.
CR: So the Cyclone is going to be a great addition. Not only does it look like a lot of fun to drive, all of the variants should provide for some pretty interesting and varied gameplay.
SG: Of course one of the main questions that's popped up is what ships will it fit into? If you're looking for that answer then check out this week's Cyclone Q&A.
CR: There you go, and if you're interested in knowing the tech involved in making that happen, then this next segment is for you.
SG: As you'll see, getting a ship inside another ship's hangar and keeping it there isn't as easy as it seems.
CR: It never is.
Chad McKinney (MC): My name is Chad McKinney and I’m a Gameplay Programmer here in the Los Angeles studio. We’re talking about ship in ships which is a topic that touches on a few different systems. On one hand you have just kind of the physics and game code involved to actually make the ship in ship behavior work consistently, but there’s actually a whole larger other topic that it touches on which is persistence, how do you get the ship in there in the first place. You can just drive it in there, but if you park your ship at a spacestation, log off, log back on, you really want that ship to be there the next time you spawn it, you want to have your Dragonfly or your Nox and so the question is how do we get there?
In 2.6 this isn’t possible, you won’t get that ship back in your Constellation or whatever, it won’t be there, but if you do want it to do be there we need a whole host of technologies in our engine and in the backend services to support that behavior. It’s this little thing that seems so small which requires a lot of effort to make work correctly, but that after also enables a lot of other behaviors into the game that previously weren’t possible.
So right now in 2.6 what we have is effectively a very simple system that just tracks player accounts and specifically loadouts and player accounts. So it tracks your specific loadout that you have equipped as well as any vehicles that you own and their loadouts. This is fine for the gameplay that we have right now in the game so yeah you’ll have your weapons the next time you log into the game, if you do a modification on your ship it’ll be there the next time you log into the game, but if you make any kind of change in the game world or in kind of inside your ship, that’s not going to be reflected in any way because the persistence database doesn’t know anything about it. This is a great limitation whenever you continue the kind of game that we’re trying to make. We want to make this large game, this living world that can change and be dynamic, but this persistence behavior that we have is completely ignoring all of the nuances that are required to achieve that behavior.
One large part of that is this fact that we’re so tied to loadouts, because of that there’s no concept of a loose entity. So let's say you have a ship, a Constellation and you park a Nox inside it. The Nox isn’t attached to the Constellation right? It’s not on the wing, affixed to a gimbal or a turret as it would be, it’s just lying there in this ship. In order to make that work we have to completely refactor the way the game code handles persistent data and make it in such a way that instead of tracking accounts, instead we’re tracking the map of entities that point to parents and potential item ports that they’re attached to and offsets.
What this requires is that we need to look in the persistent data record for the ship, we’re gonna find all of the children of that ship so we’re going to find all of the item port attachments that will be on the guns and now that we’ve made some refactors in the persistent database we can also find loose entities in that ship so it’s going to find the cargo item that we left in there as well as that Nox that we left in there as well. Loose items now also offset information in the persistent data record that informs the spawning code where to line them up. So we spawn the ship, the Constellation, we spawn all its children, we spawn loose items and we have to spawn them in the correct location in the zone space so they line up correctly. We also needed to introduce them correctly into the zones of their parents so that they don’t fallout. If you don’t put the Nox in the Constellation zone, they’ll either collide and explode or it’ll fallout and just leak into space.
So we have to do a lot of fix up and spawning code, but if all goes to plan we’ll spawn everything in the right order in the right place in the right zone, comes in, you see it, it looks exactly like you saw it last and works perfectly. This makes it to where something doesn’t have to be in a loadout for it to be physically owned by another entity, but that touches on another thing. The old methodology only had one concept of ownership, you just owned something or you didn’t and that’s fine again whenever you’re dealing with your ships, if you have an attachment like a gun you’ve bought that or you’ve acquired it through some means, that means you can attach it or not, but in gameplay you may get a hold of something that you didn’t buy and maybe in the game world or maybe something you want to take from another player, how do we track that in persistence?
Well previously there was no distinction, what we need is a distinction between physical ownership and legal ownership so that you can legally own something, you’ve bought it, but you don’t physically have access anymore because somebody took it from you, it’s in their ship now. That was another larger set of changes to make this distinction between physical ownership and legal ownership, it has large ramifications on how we store and manipulate the data, have large ramifications on how we do this thing call network ownership.
Originally whenever a server would connect to the backend services the persistent cache that the player connected to would make a request for all the items that the player has and it would then ask the server to entitle these to the new account, then those items are sent to the server and cached locally. They’re also sent to the the client and cached locally on the client. What this meant that there was a large set of data that exists both on the game server and on the client that is mirrored, but if any changes need to happen to that persistent data, changes would have to happen synchronously both on the server and the client and this is a large technical problem. Previously we avoided it because we didn’t really have this dynamic behavior. We had some shop behavior that could change it and we had some kind of hack code in place to manipulate it on the client and the server synchronously, but once we start having larger systems directly manipulating this persistent data, having fragmented clones of the data across the network is a huge issue both for security as well as for behavior and sanity of the data.
Instead we’ve needed to move over to a system where the server is the authoritative owner of the data and clients don’t actually have a copy anymore. Instead they have to make queries to the server whenever they want to display something. So let’s say you go to a kiosk and you want to buy some cargo, well instead of directly checking the data that we have cached on the client, we make a request to the server. The server will collect all the information that’s required and sent it to the client. This makes it to where it’s always up to date, it’s always correct and everybody in the network always sees the same information. It also makes it to where some nefarious behavior on the behalf of the client isn’t possible anymore because we’ve kind of closed off the ability to introduce information that wasn’t there to start with.
One issue that we have right now is that I mentioned before was physical ownership and legal ownership. Well if want to establish ownership, that means we also need to allow for transfer of that physical ownership. To give an example let’s say there’s some cargo that’s in an outpost on a planet. That cargo might be spawned in with something called an object container which is just something that we’ve touched on in previous material that we’ve put out. So this object container just contains entities that get loaded into the game. If you want to pick up that cargo and put it into your ship, there’s several steps that have to happen to make that work correctly.
First we need to do the persistent transfer of the piece of cargo, but there’s an immediate problem that we run into. The cargo in the object container isn’t a persistent entity, it got loaded in with the object container, it was never persistent to start with. So we need to do something called promotion to make it into a persistent entity and to make it what’s called network replicated. Then we have to make some modifications to the way that object containers work. Object containers assume a certain fixed set of entities will get loaded in and we’re actually modifying this list so we have to modify the way that object containers work so that they can have changes to their entity list, networked across the network and to support late joiners so that anybody who joins in later into the game sees the changes to the object container.
So we’ve done a promotion to the cargo item, we’ve removed it from the object container, now we’re gonna transfer the persistent ownership of that to the player who picked it up. The player has it, it’s in their persistent data record, now the player walks into their ship and they put it into their ship. We do another physical transfer of ownership from the player to the ship. The ship now physically owns it and the persistent data record is updated to where the piece of cargo is in this ship. Now if the player logs off and the ship gets unspawned, next time they spawn the ship the piece of cargo is going to be in there.
However if somebody steals that ship, then they will have access to that piece of cargo as well and it will be under their physical ownership even though the first player yourself legally owns it. In order to get ships in ships working requires identifying physical ownership and legal ownership, it requires doing all this persistent tracking, but it’s that same technology that also allows us to make our game world at large more dynamic and have more life as far as its behavior. So that means you can make a change now to the world and that can be tracked.
There are some limitations still. Changes in the world at large are going to still be what are called session level persistence so you can make a change to a planet or you can make a change to a space station and we can track that for the lifetime of that server, but it's tied to that server, but that does mean you can start actually changing the world. If there was some cargo at that space station, you can take it and somebody else won’t see it anymore or you can maybe leave something behind that they will see. If you left your ship there, well that ship is still there and someone else can come along while you’re talking around on that planet, they see this nice ship sitting there and maybe they’ll take it away and it won’t be there anymore. Now we can begin hooking up criminality systems to maybe give someone a wanted level whenever they’ve taken a ship that isn’t theirs or taken some cargo off a ship that wasn’t theirs to start with. It also means if you for instance want to fly under the radar, have some stolen cargo in your ship that’s not in your cargo grid so it’s not in your manifest, you can do that but it leaves it open for other people to then take your ship or take that loose cargo easier and it’s going to make pirating more dangerous and it’s going to make cargo more interesting I think, and other things in the game as well whenever you can take it from somebody else.
Another thing that this allows for is collecting right? So you can, if you find a Big Benny’s machine in the world, you can kick it around, maybe with another ship, you’ve gotta do some work but if you try hard enough you can get this Big Benny’s machine in say your Constellation Andromeda. Cool now you have a Big Benny’s machine and you take it with you and you own that thing, well you physically own it at least. You sign off you sign back in again it’s still on your ship. Maybe you can find another one somewhere, start a collection, you can have three or four of these. You can trade with your friends, give them a Big Benny’s machine, maybe they give you a weapon. It allows for some more emergent gameplay. You don’t necessarily have to have a gameplay system in the game that is specifically tracking Big Benny’s machines, but you can still play with them because now you physically have access to them and that access is tracked in your persistence data.
We’re starting to introduce Diffusion which is a whole new way of interacting with the backend services. That gives us some very interesting possibilities for the future. For 3.0 it’s just going to be a small set of Diffusion services that are going to be online, but moving forward we’re going to greatly increase the number of these Diffusion services and that has some really interesting impacts on persistent gameplay because it means that you can now have some Diffusion service that’s tracking an economy and persistent changes you make to the world will impact the economy, it’ll impact the cost of items, it’ll impact the location of them, maybe the delivery of them. There could be services delivering missions that missions can be based on persistent changes in the world. You can have services based on pirate activity or services based on AI activity. It allows us to have the combination of persistent data and persistent changes to be utilized across the server instances and have these services enable more higher level behavior and higher level modifications to ingame actions based on Diffusion services.
We’re taking it to the next level to where we can get a more global universal look at persistence. We can start caring not only about player persistence, but the ships persistence, spacestation persistence, planet persistence, universe persistence. Ideally we want to move to something that we call the server mesh which has either a larger or a single mesh of servers that govern the entire universe and all the players are interacting with each other across this large server mesh. That will allow some truly persistent behavior in the world so that any one change you make one a planet, any planet, or on any station is going to be persisted for all the players across the entire game. It will make it to where if I leave something on the planet, it’s not in one server, it’s on that planet, there is one planet and that has that change.
For 3.0 we’re introducing these serialized persistent variables that will allow gameplay features to start tracking persistent information. This will include features such as ship health and player health as well, and stamina. So if your vehicle has the wing blown off of it and you spawn your vehicle, it’s not going to have that wing. If it becomes unflyable you’re going to have to start engaging with some of the other gameplay systems that we have. So for instance you could have it repaired at a repair station or if it’s beyond repair or you don’t want to through the effort you can make an insurance claim on it if you have insurance for the ship. This will be expanded to include other behaviors in the game so like I said damage and health for the vehicle, but also stamina for the players. So certain kinds of effects will be persistently applied to your player.
There will be other things in the game such as ammo, your ammo is going to be persistent. If you run out of ammo you’re going to have to buy more ammo. It’s not going to be the way it's been where you can just fire away and you don’t have to be so concerned about consequences. Additionally there will be other things. The interactable entities in the game will now have the capacity where if we want to, we can identify certain entities and make their state's persistent. So say there’s a data pad you interact with. Maybe switch its behavior to be in an on state as opposed to off, that could be tracked to be persistent. We’re identifying everyday new places in game code where we have certain behaviors that have traditionally been networked across the network to keep the clients and server in sync, but it’s very easy to just turn on this persistent flag and start having that now be a persistent value that’s tracked across game sections. So we’re looking for these opportunities to take these gameplay behaviors and make them more permanent as far as the lifetime of their effect.
I think it’ll be a very interesting world to play in and a very interesting set of gameplay features that really no other game has.
CR: So that piece was a great way to show how all our systems tie to together under the hood. It was a massive undertaking to lay that groundwork, but it gives the game a ton of functionality once everything is up and running.
SG: And that’s all for today’s episode. Thanks to our subscribers for supporting all of our shows.
CR: Yup, thank you guys.
SG: Tomorrow we have a special Happy Hour GameDev planned. Live Designer Gareth bourne will be building a solar system using the SolED tool with help from the viewers. Tune in to our twitch channel at 11am Pacific to catch it.
CR: Yup that sounds like a lot of fun so you don’t want to miss that. Finally thanks to all our backers, we couldn’t build this game without your continued support.
SG: We could not and until next week, we will see you..
SG/CR: Around the Verse.