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!
Knocking out a massive amount of component descriptions needed for the 3.0 release
Working on NPC voice packs for 3.0: wrote and recorded roughly 2800 lines for generic NPCs
Created the Persistent Universe Character Tracking Sheet to recorded details of all dialogue
Reviewing locations and noting what's needed to make more immersive environmental storytelling
Wrapped up developing the Cargo Grids to provide the visual element of transporting commodities
The number of commodities you have manifests as stacks of crates located within the ship's cargo hold
You can put vehicles and loose items into the cargo hold as well, but it will limit the amount of grid space
Finished up implementing the solar system content (aka object containers) into a hierarchy
Provided object container editing so that content in an object container can be edited from within a normal level
Reworked the handling of vehicle internal damage states so they are significantly easier to setup and debug
The IFCS update process has been converted to batch updates as it does not need to be in lockstep with physics
Completed the new Quantum Drive 2.0: refactored the drive component and added new features; ready for Design, Art and UI
RSI Aurora has gone through a final art check; established 14 different skins for designers
Anvil Terrapin is finalising its greybox phase and moving to final art; also in Tech Design greybox
With the Item 2.0 conversion underway it was time to update update the ship stats page on the website
Tech Art & Animation
Reviewing the release to identify code and content fixes that would dramatically improve performance
Statoscope produces, manages and plots graphs from the data logged on a per frame basis
Improved the animations save format: scene load times reduced by up to 82>#/p###
Female transfer mesh created, male transfer mesh updated
Identified and fixed an issue with eyelid vertex normals being flipped
Knocking out countless costumes for Squadron 42 and Star Citizen
A female character in-game assets is being finished ready for texturing
OMC undersuits have finished in-game modelling and on their way to texturing
Levski specific civilians and miners are currently being textured before being rigged and implemented
Reworking legacy UEE and Pirate armour to bring them up to the quality of our current modular assets
A select group of hairstyles and eye options coming in 3.0
Male Marine BDU, Male Deck Crew, Female Light Armour and Female Explorer Flight Suit are all implemented
Clive Johnson, Foundry 42 UK's lead network programmer was terrified at the prospect of networking Star Citizen, but soon took the impossible problem and broke it down into smaller impossible problems
All the thousands of elements and entities in the game that might be used thousands of times with certain behaviors or uses has to be implemented in code for both Squadron 42 and Star Citizen
Though there are 60 programming engineers and six networking engineers with only three dedicated to making the game work in multiplayer, all have to make sure individually that their code works in multiplayer
Application Programmer Interface (API) cushions the programmer from the problems they want to solve by allowing them to say exactly what it is they want to do, but without saying how to do it
Like with assisted driving the API can take action to prevent programmer's mistakes from causing a crash
APIs simplify the programmer's jobs not unlike how driverless cars simply require a destination
Multiplayer games from the purview of programmers are simply many tables and values that correspond to different properties of an entity
These tables help track variables and how their values change over time
Programmers write code that references multiple tables to produce what one sees in a game-play
Multiplayer requires the servers after making changes to these tables to copy them and send them to all of the client machines so that everyone's in sync
Since there are hundreds of these variables or properties that must be kept in sync over the network one can periodically send a state of all the tables out, but that can cause bandwidth related issues with higher numbers of entities
Alternately and what is done now is to only send out a copy if the table is changed for an entity
Entities are built by putting different components together
Problem is with exponential growth of components they also had increase in networking work needed to cover all different entity types, this is when they came up with serialized variable
Now programmers just need to write code as normal and item variables to their components as needed with the only extra step being marking variables they want networked in a special way
Serialization being the process of packing up data in a form that’s more efficient and better suits being sent over the network or serialized to a file
Program only needs to write the additional lines that are highlights and on the right and add them to their class definition, this tells the system which members of the structure to watch/update
Previously they would have needed specific functions for each class and programmers would have had to manually look at the variables they wanted to serialize and write them out into the serialization stream, this leads to extra work and possible errors
Now programmers mark up which variables they want serialized and it’s handled automatically through one unified system, there is also now no need to group things into sections anymore
API detects when something’s been modified and let’s the netcode know, even writes the code to handle serialization for them
Update messages are now about as optimized as they’re going to get
Serialized variables just don’t work for multiplayer and networking, instead of sending tables/values/variables between server and client they can now store them in the database or save them as a file
Serialized variables is also a cornerstone of building a persistent universe, it’ll require multiple servers communicating with each other
This means several servers can be aware of an entity all at the same time, how they decide which one gets the final say is using tokens
A token can only be held by one computer at a time, this means by linking serialized variables and tokens they’ll be able to transfer authority from one server to another as quickly as flicking a switch
Chris Roberts (CR): Hello and welcome to another episode of Around the Verse our weekly look at Star Citizen’s ongoing development. I’m Chris Roberts.
Erin Roberts (ER): And I’m Erin Roberts.
Both: And together we’re Roberts squared.
ER: Anyway I’m out in L.A. working with Chris and the team on the upcoming 3.0 release, Squadron 42, and beyond.
CR: Yeah and it’s nice to have you out here hosting ATV with me.
ER: fun to be here.
CR: We’ve got a lot of cool stuff planned going for 3.0 and beyond and making sure the entire production team is on the same page is essential.
ER: Absolutely. Tracking the progress of all the new features and assets we have planned is an absolutely massive task.
CR: Yes it definitely is and there is a lot of technology coming online soon that we’re excited about. One of those is serialized variables which is the subject of our featurette today and while it may sound like high school algebra it’s actually a critical system that's a core element of what we call Star Network.
ER: But first before all that let’s talk to Eric Kieron Davis right here in Los Angeles for a Studio Update.
Eric Kieron Davis (EKD): Hey everyone welcome back to Los Angeles. I’m Senior Producer Eric Kieron Davis back with our monthly Studio Update.
Since I last saw you we’ve been focused on closing out final features and tasks for SC Alpha 3.0 and Squadron 42. Part of this month I visited our Frankfurt, Wilmslow offices and worked closely with their teams for a variety of reasons; and now I’m glad to be home to give you this update.
Our Narrative team has been quite jampacked this month as well. With Item 2.0 coming online they have been knocking out a massive amount of component descriptions needed for the 3.0 release. Everything from coolers to shield generators to quantum drives. The team has been also working on an NPC voice packs for 3.0 as they wrote and recorded roughly 2800 lines for generic NPCs to really liven up the world.
Speaking of massive amounts of dialogue lines, one of the challenges in dealing with a universe of this scale is keeping track of the various characters and lines that the player will encounter. To keep track of all this the team has created a first pass at the Persistent Universe Character Tracking Sheet to provide a simple resource for reference of lines, file names, for departments like Audio, Animations, Facial Capture and Performance Capture; and overall status and priority for the massive amounts of dialogue NPCs, mission givers, and much more. Once this is completed it will help us immensely as we move through integration of new mission givers and NPCs in the future.
And lastly the team has been in the process of walking through the locations and writing up documentation of what we’d like to see as far as props, posters, signs, branding and set dressing to really make much more immersive environmental storytelling.
Also as part of the upcoming 3.0 release we’re very excited about introducing cargo’s mechanic. And to ensure you’re ship is technically equipped we wrapped up developing the Cargo Grids to provide the visual element of transporting commodities like minerals, scrap and food. The number of commodities you’ll have will manifest as stacks of crates located within the ships cargo hold, limited in capacity by the dimensions of the grid your ship can use. You’ll be able to park vehicles and other loose items into the cargo hold as well, but just beware that it will limit the amount of grid space you’ll have available for bought or scavenged commodities. Code is wrapped up on the feature, while Design has now implemented the Cargo Grids into all the ships that can carry cargo so you’ll be hauling to your heart’s content in no time.
Engineering has also just finished up implementing the solar system content - or what we’ve been calling object containers - into a hierarchy to ensure that outposts on a moon or planet, as well as space stations in near orbit, are all in the correct planetary grid at all times. So for instance Grim Hex is now located inside the grid of the moon Yela, for the time being.
And then speaking of the all powerful object containers, we’ve also just been provided the much needed object container editing. When creating a gameplay level we build that level with a combination of assets and object containers. Originally object containers had to be built in a dedicated object container level, which unfortunately made the contents of the object container only editable in the actual object container level. Are you confused yet? In other words when designers are building levels with object containers but want to modify the contents of that object container the only way to do that is to exit the current level, open the object container level, do some tuning, save, export and leave; then they’d have to move back into the level. What the team has done now allows the designer to edit the contents of an object container, save and export; all while inside the level. This creates a much better experience for our Design team and is really going to save tonnes of time.
Now as a general approach in game development we alway try to make something once - and make it perfect. But since reality never meets expectations we’re always looking for ways to reduce the time needed in what we call the “discovery phase” of a problem. One of the hardest parts of getting a code bug is finding out what is causing it and where it’s located. So establishing tools and processes to reduce that time, not only helps get to the speedy resolution, but also gets our talented programming team back to that feature we’re all so excited to develop. So to that end we’ve reworked the handling of vehicle internal damage states to significantly easier to set up now and debug. Interior damage states will be changed based on the cumulative health of a ship. Formerly it was written in FlowGraph but now it has been integrated into the vehicle component so that it can be used in a variety of places. This new debug and set up process should do just that: help us find the problem quickly, solve it fast adn get back to feature dev time.
Now on IFCS we’ve now moved the entire Intelligent Flight Control System of our ship’s update process to batch update. Because IFCS is very isolated from the physics engine, taking in values like velocity, mass, center of mass, etc. and outputting one linear and one angular impulse there’s no reason IFCS needs to be updated in lockstep with the physics thread. This change will be much more efficient and will be eliminating a major bottleneck and hopefully allowing a larger number of simultaneous players on a server.
We’ve talked about also making progress on this for a little bit now and we’ve now completed the new Quantum Drive 2.0. We’ve removed the old code from the previous quantum drive system that controlled things like VFXs and sound effects playback, as well as object … obstruction detection and alignment code. We’ve also move the targeting of a quantum point to the target selector on a ship so that drive now only cares about the travel point itself. This reduces complexity of the drive code and should make it run smoother. We’re doing some bug fixing as well as some features that are attached to the quantum drive, such as closing all external doors when doing a jump to help “accidents” by jumping out of a ship traveling at high fractions of the speed of light. This should all result in a smoother working quantum drive that is ready for Design and Art to really start tweaking and implementing on all the ships. It’s also ready for UI to start creating a much more realistic feel for how such an event should be handled in game - as well as a few other features like the Star Map.
Now over on the LA ship front the RSI Aurora has gone through a final art check this week. All that remains are any incoming bugs while going through design implementation, animation updating, sound effects, VFXs, etc. which this ship. And we’ve also established up to fourteen different skins for the designers to utilise as well.
The Anvil Terrapin is finalising its greybox phase which means it’s setting up the exterior hierarchy, polishing proxies, baked and migrated animations. For the interior we’ve currently polishing the geometry in the cockpit and the habitation, and now moving into final art. We’ve just handed the Terrapin over to Tech Design for their greybox setup on the ship as well.
Also now that the conversion for ships to Item 2.0 is underway it’s made sense to update our ship stats page on the website. And we’re really excited to finally be able to get to the up-to-the-minute stats for all of our ships for all you min-maxers out there. The design has now been finalised, icons finished and refined meaning, and everything’s being updated on the web as we speak. They’re being implemented onto the RSI website with more details to come in the very near future.
Now Tech Art’s roles tends to increase the closer you get to a major release and as performance begins to take priority over feature and asset development. Using a plethora of internal tools Tech Art has been reviewing the release to identify code and content fixes that would dramatically improve performance. One in particular is called “Statoscope” which plots graphs from the data logged on a “per frame” basis and, more generally, it’s the system that produces and manages that data. In essence it provides a way of recording values such as FPS, number of draw calls, etc. from Star Citizen and showing how change over the course of a play through. This really helps our development team find ways to improve performance by looking for frame time offenders.
Now Tech Animation improved the animation format that animations are saved as and then reloaded into a scene. In our worst case scenario a scene could take up to 50 minutes to load into Maya due to the amount of characters and length of the scene. But with this improvement the worse load time has been dramatically reduced by over 82%, meaning Cinematics won’t be waiting long to make quick iteration.
And over on the skinning front a female transfer mesh has been created and the male transfer mesh has been massively updated. Now these transfer meshes are used in conjunction with all of our skinning tools to automate basic skinning of all of our new characters. Tech Animators can now spend time affecting the weighting of a mesh, allowing for a higher quality and a more accurate deformation in less time.
On many of our heads we’ve run into an issue where the eyelids had some vertex normal issues which led to eyes looking pretty odd. Our Tech Art team has now identified the issue and because the vertices of the eyelids were so close together the normal would get flipped - but only on a few verts. So this has now been fixed and characters can now sleep with ease.
And speaking of characters the team here has been knocking out countless costumes for Squadron 42 and Star Citizen. Currently in production another female character is finishing up here in-game asset and will then be sent over to texturing and rigging; along with our OMC undersuits that have all finished up in-game modelling and are heading on over to texturing. The team also has several other Levski specific characters: the civilians and the miners which are currently being textured, then will head over to rigging and implementation into their final resting place in game on the great planet of Delamar.
And now in other exciting news, now that we’re in a modular armour system we’re reworking some of our legacy UEE and Pirate armour to bring them up to the quality of our current assets. This will allow them to be swappable with all those assets. We’ve officially started high poly on some of your favourites, then we’ll be moving on to the in-game modelling and texturing pass rework.
And speaking of customisation, along with the new eye options, we’ll have multitude of styles of hair coming in the upcoming releases starting with a select group for 3.0. These are in various states of production and heading towards the final finish line. We’ll have select group ready for the initial release and we can’t wait to cover up those hairless heads.
And finally we have more finished, rigged and implement characters starting with the Male Marine BDU which will make it’s appearance in several places including the bridge of the Idris. The Male Deck Crew can now safely EVA outside the ship in the vacuum of space when doing his work. And lastly the Female Light Armour has finished up her implementation pass along with the Female Explorer Flight Suit which will support her in the far reaches of the galaxy.
Well that’s about it and wraps us up here in Los Angeles. As always thank you for allowing us to create this game we’ve always dreamed about. And we look forward to giving you more updates in the near future. Have a fantastic rest of the week. We’ll see you back in Los Angeles in no time.
CR: So it’ll be nice to see people hauling something other than Big Benny’s vending machines and unsuspecting NPCs as great as all those videos were, the team has worked hard to give you a proper mechanic for the 3.0 release.
ER: Yeah and cargo is just one of the many important features we’re currently working on. A lot of them like cargo and say derelict ships which is easy to see, while others like serialized variables aren’t as visible, but are just as critical to the game.
CR: Yeah no, they definitely are critical to the game because when you’re attempting to build a game as large and complex as Star Citizen, it’s essential to come up with a new way to streamline the data being transferred the server and the client.
ER: And so here to explain exactly how serialized variables will improve our networking capabilities and of course most importantly your Star Citizen experience, let's hear from Lead Network Programmer, Clive Johnson.
Clive Johnson (CJ): My name's Clive Johnson. I work for Foundry 42 UK where I'm the lead network programmer. I'm working on Star Citizen. Today we're going to talk a little bit about serialized variables.
So what are serialized variables? Well they're not really something that you can see in the game, and ideally if everything is working the way it should then they're not something that you'd really have a need to think about, but they are the answer to a question which I think is quite important, and that's how do you network a game like Star Citizen? One of the first times I asked myself that question was shortly after I joined the company. I think my first reaction was one of sheer terror ... you know, tears, panic. Once I'd kind of calmed down and the tears had stopped you do what any engineer is going to do when faced with an impossible problem. You try and break it down into smaller impossible problems. When trying to answer the question, how we network Star Citizen, one of the first things we've got to think about is exactly who’s going to do the work. Who's going to network everything we have in the game. Star Citizen itself is made up of thousands of different elements, and some of these are visible like planets and ships and players and coffee cups. In other words you don't see missions or the logic assigning out landing pads. Each of these elements is really a different type of entity, and each type might be used thousands of times throughout the game, but all the types behave in specific ways or have certain uses, and that has to be implemented in the code, and most of them need to work in both single-player, Squadron 42 and multiplayer, the Star Citizen. In other words most of them have to be networked.
So, who's going to do the work? Currently we've got about 60 engineers coding different parts of the game, but we have only six network programmers. Half of these work in Austin on back-end services, and that includes our core online services such as matchmaking or friends and player authentication. The other half is my team hear in the UK, and we focus mainly on the networking between the client and the server. So, it's kind of up to us to make sure that all the entity types are correctly networked and everything's functioning the way we'd like it to in the multiplayer game, but with 60 programmers, or thereabouts, writing new code and making new entity types. If we've only got three actually making it work in multiplayer my team needs to work about 20 times faster than anybody else. We're good, but not that good, so clearly leaving all the networking to the network programmers is not going to work.
So, what we need to do is have every engineer make sure that their own code works in multiplayer. The problem with that is that network programming is really very hard. It can take years to learn all the different ins and outs, so we need a way to simplify it, so that non specialists can learn it and everything they need to do in like just a couple of hours. What we need is an API, which stands for an Application Programmer Interface. That's really a cushion between a programmer doing the work and the problem they want to solve. The API kind of simplifies things by allowing the programmer to say exactly what it is that they want to do, but without saying how it should be done. So, you can kind of think of it like driving a car. So, obviously you've got your steering wheel and the pedals and other controls, gear stick lever … That's not how the car drives. They adjust the controls that tell the car what to do. So under the hood the driver's commands are turned into different settings for fuel/air mixture or engine timing or hydraulic pressures for brakes and power steering, and that's kind of the interface pass of an Application Programmer Interface. By building the right set of controls you can change how the API actually works without having to change the code.
So, what about driver error? Car's equipped with assisted driving. Can take action when the driver makes a mistake and possibly prevent a crash. We want the same sort of thing from the API that we're going to develop. When a program is used it actively prevents them from making mistakes that might cause bugs or negatively impact performance, but we can go a bit further though. So, currently the technology for driverless cars is being developed. When that happens the skill needed to operate a driverless car drops to just say where you want it to go, and this is what we're trying to do with our network API. [Chuckles] Serialized variables are a really big part of that, by giving our programmers a simpler model to work with they can quickly and safely network the game elements that they're working on, meanwhile those network programmers are freed up to try and ensure that the API not only works quickly and efficiently, but also it deals with all the problems that you can get while networking anything.
Before we go any further we probably need to talk about another question, and that's: How do online multiplayer games actually work? If you were to see the game's as programmers often look at it, you'd see that everything is essentially lots of tables and values. Every entity in the game has it's own table and each value corresponds to a different property of an entity. Because we need to know what each value's for, we got to give them all names. So a table has two columns, names on the left-hand side and values on the right. A row in a table is what we call a variable and that's mainly because its value can change over time. A ship might have variables for shield strength and how much fuel it's got left. Players can have variables to say whether they're running or walking. Most but not all of these variables will have an entity called a Position, and that's going to tell us exactly where they are in the game's universe. And even though we kind of need three values for coordinates in 3D space, we tend to think of a position as a single variable, because one part changes the other parts tend the change. So when an entity moves it does so, because the position variable is being changed. That, that variable is not really just keeping track of where the entity is, it's actually saying where the entity is.
Programmers can write code that looks at the values in a table that belongs to the entity. We can use those values to calculate some changes to other variables. Some of those variables might be in the same table or some might be in other tables belonging to different entities. So as the game progresses these variables are modified according to the actions of players and AI, and these changes update the graphics that you see on the screen and they can trigger particle effects and sound effects.
To make this work in multiplayer we've got to take one machine, the server, and have that make the changes to the tables, and then the server then needs to copy the modified tables to all the other machines, all the clients. It does this by sending messages over the network a bit like a group text message. And if everything works correctly, the clients and the server all have the same value in the tables, and everyone's in sync.
Now entities in our game can have dozens or even hundreds of these variables or properties. Most of them need to be kept in sync over the network. There are a few ways that we could do this. Probably the most straightforward way is every now and then just to send the state of all the tables, and that works really well for very small numbers of entities, but as the number of entities increases then the bandwidth that you're using to do that increases and if we're not careful that can cause us other problems.
You might notice that most entities in the game don't tend to do much until someone does something to them, so what we can try is not sending the table for an entity unless it is changed. For now the game code got to keep track of which entities have changed and which haven't and that can be tricky to get right. It's a manual process that the gameplay programs have to do. Getting it wrong means that in certain situations the tables for particular entities will no longer be in sync. We call that a desync, and the effects of that can range from like minor bugs that are just little annoyances to completely breaking the game. The only way to find these bugs is through lots and lots of time consuming playtesting.
Perhaps worse, we haven’t really solved the bandwidth problem either. By adding more players that means that more entities are being interacted with and having things done to them, so more tables are going to be getting updated and more messages need to be sent out over the network and the bandwidth jumps up once again. We still need to reduce this so we might notice that when an entity’s table is modified, not all of the values in it are changed. So instead of sending the whole table, we can try sending a few at a time, so we can split the table into sections and then we’re saving bandwidth by only sending a section. If one or more of the variables in it have changed, if we put variables that are likely to change together in the same section then we can save even more but now the game code has to keep track of not just modifications to entities but modifications to individual sections and that’s even harder to get right.
We also got to write some extra code to say which variables need to be put into which messages and since different types of entities have different sets of variables, they also need different sections. So this extra work has to be duplicated for every different type of entity. So the thing that really kills this plan for Star Citizen is entity components, a component is really it’s just a piece of code and some variables that implement a very specific piece of functionality. So entities get built by plugging different components together and by choosing different components that you want to plug together, that gives us different types of entities.
If you need an entity that can move around and collide with all the things, you have to give it a physics component. If your entity needs shields, give it a shield component. The number of different entity types we can build this way grows exponentially with the number of different components that we have. What also grows exponentially is the amount of networking work we’ve got to do to cover all these different entity types so clearly this isn’t really going to work for us. Our networking API has to be smarter, what we wanted were controls that were simple as those for a driverless car and what we had felt like it was as complicated as piloting a space shuttle. So that’s when we came up with serialized variables.
So with these gameplay programmers just need to write their code the way they normally would and their item variables to their components as they need them and the only extra thing they need to do is mark the variables that they want networked in a special way. That just shows that these ones are ones that need to be serialized. Serialization is a process of packing up the data in a form that’s more efficient and better suits being sent over the network or serialized to a file. This makes life so much easier for our programmers, you can see how the code on the left can be simplified and be reduced to what’s on the right. It’s really just like writing normal code and calling out which of the variables we want serialized. The program only needs to write the additional lines that you can see highlighted and appearing on the right and add them to their class definition and that tells the serialized variable system which members of the structure to watch and update.
Previously we would have needed specific functions in each class, one for net serialized for networking, full serialized for the saved game and if we wanted to talk to the persistent database we would have needed an extra function, something like persistent serialized. In these functions the game programmers would have had to manually look at the variables they wanted to serialize and write them out into the serialization stream. So, there’s lots of scope there for extra work and possible errors if they forget to add a variable.
Now when a program writes a new class, they just mark up which of the variables they want to be serialized and everything else is handled automatically and efficiently behind the scenes. That all goes through one unified system that we can profile and optimize as opposed to having to worry about optimizing literally thousands of different functions.
Once the variables have been marked there’s no need to group things into sections anymore and there’s no extra code to write. The API detects when something is modified, the value of a variable, it lets the netcode know so that can deal with it. The new API even writes the code to handle the serialization for them and this kind of level of automation not only saves us time but it eliminates human error. I mean we have a lot fewer bugs and we can just get on more quickly and more efficiently.
So because the netcode is now being told about changes to individual variables we’re on the networking side of a much clearer view of what’s actually happening in the game. So, you can kinda think of like switching to a 4K TV when all you’ve ever seen before was grainy black and white and we’re kinda using this extra information at the moment so that we only send exactly what is changed and that means that there are bandwidth update messages, the size of our update messages are now probably about as optimized as it’s possible to get.
We’re also using this information so we can profile what’s being sent by the game code, when it’s marking variables there so we can see if anyone’s hit anything particularly quickly and maybe there’s a bug in the game code that needs looking at. Really the only overall improvements we’re going to get from now on is by optimizing streams of network messages, calling out who’s sending messages at all and how often messages are being sent. We can handle all that on the network side, on netcode side.
So it’s kinda like I was saying before where we got this interface of the API that separates game code from what we need to do and we can make our changes without affecting that. While we were working on this new technology, we noticed that one of the entity types started sending about 80% less data, at first we just didn’t believe that. We were certain that the numbers had to be wrong or a bug’s throwing away most of the data, it wasn’t until we went back and we double checked everything that we really started to realize that this saving was actually real and that it’s due to the new code. That’s probably not going to be typical but it still kinda shows the difference this kind of approach can make.
That’s not entirely where the story end though because one of the other cool things about serialized variables is that they don’t just work for multiplayer and networking. Instead of sending the different tables, values and variables between just server and clients we can also store them in the database or save them to a file. That means that the with no extra effort at all the gameplay programmers can use the same serialized variables. For persistence we call them what the state events these are is in our persistent universe and we can even use them for saved games in Squadron 42.
Personally one of the best thing about serialized variables is that they’re one of the cornerstones that we’re using to build this big seamless persistent universe. Achieving it now is going to require spreading the load over multiple servers because it’s seamless we’re going to have to have these servers communicating with each other. That’s going to mean there could be a lot of servers aware of any particular entity so let’s say for example, an AI pirate. Now we don’t want all the servers trying to tell the pirate what he should be doing, cause first that would be a complete waste of computing power and the second reason is that the servers might not agree on what the AI should do next. So, we need one server that’s in charge of the AI pirate and only that server can send updates for that AI pirate entity and the other servers just listen to it.
So the trick is going to be how we decide which server gets the final say and we’re going to do that with something that we’re calling tokens. A token can only be held by one computer at a time, when a computer is finished with a token it just passes it onto the next one that wants it. By linking serialized variables and tokens together we’ll be able to transfer authority from one server to another as quickly as flicking a switch. What that means for our AI pirate is that control over it’s AI mind can pass seamlessly from one server to another and since different servers, at least initially will control different regions of space. This combination of tokens and serialized variable will allow our AI pirate and everything else to move freely through a seamless persistent universe that’s being simulated by lots of servers all working together. So hopefully you’ll agree that serialized variables are not only a key part of the current technology but are a building block for future ones. That’s really not bad for something... you’re never going to say, that’s often the reality of game development and what you see in game is just the tip of an iceberg that’s being buoyed up by a massive systems and technology all working together. You know out of sight, fingers crossed out of mind.
CR: So as you can see the serialized variable tech is an important feature for several reasons: it not only improves the games networking, but also simplifies the coding for our programmers so there will be fewer bugs going forward and the same data can be serialized over the network to the persistent database or say the state of the game meaning we have one unified way to communicate or save game state throughout everything which is important for a big, huge, universe like we’re building.
ER: Absolutely. Anyway that’s it for today’s program, but before we go we wanted to remind all backers to keep your account safe by enabling two step authentication. You can do that by visiting your account page and clicking on the security tab under settings.
CR: Yes, probably a good idea to do that, and thanks to all of our subscribers. Your continued support makes ATV, Bugsmashers, and all our programs possible.
ER: And don’t forget to tune in tomorrow for another one of our subscriber supported shows, Happy Hour Friday. This week Ben Lesnick will be playing Wing Commander III and discussing the history behind the game and its development. In mine and Chris’s case that’s a long time ago.
CR: About 24 years ago we were developing it so anyway! Time flies. Finally I’d like to thank all our backers, your support and enthusiasm for the game has made all this possible. We couldn’t do it without you.
ER: So until next week we’ll see you…
Both: Around the Verse.