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!
working on improving existing systems for 3.0: ensuring existing vehicles and systems still work as intended and doing a polish pass
remade the old airlock effects for both the “high tech” and “low tech” airlocks
started shifting more focus towards Squadron 42 cinematic scenes
completed passes on the last two legacy weapons: Geminii L86 ballistic pistol & Behring P4AR ballistic rifle
finished Klaus and Werner laser laser repeater (S1-3) & Apocalypse Arms ballistic scattergun (S1-3)
started on Klaus and Werner laser laser repeater (S4-6)
Worked on general tasks for 3.0 including polishing, optimising, and bug fixing
Tech Art Team
finished multiple animation implementation tasks for the useables sprint & cinematics
continued to debug weapon animation issues
adjustments a few weapon rigs to make them more realistic and believable
work on a VFX Exporter primarily to support exporting simulated objects from Maya
continued to support the animation code with ground alignment R&D
spent time fixing outstanding issues and polishing up existing code.
identified and began fixing game code vs. engine code issues with the new airlocks and elevators
added the ability to hide a weapon from first person view in ADS mode
completed the technology to easily apply weapons skins
working on the Weapons System 2.0 and additional elevator and airlock feature polish for 3.0
working on more mission broker and mission system features for PU 3.0 and S42
adapted mission broker to support multiple players accepting the same mission & asymmetrical missions for multiple player
added support for takeoff and landing of AI ships: landing pads, ship hangars, other ships and celestial surfaces
adding quantum travel functionality for the new non-Kythera AI
focusing on adding more Subsumption AI support: using nav splines and entering/exiting AI behaviour
finished the second Buddy AI sprint: a step towards having companion AI that will intelligently follow and assist the player in combat
refined the handling of GPU crashes and proper reporting via the Public Crash Handler
worked on performance analysis and engine optimisations for 3.0
started to work on was a new Roads System and toolset to work in conjunction with the planetary terrain
making a pass on the Room System for Levski to ensure the player won't suffocate in random places
performed general polish and bug fixes for 3.0.
started taking a look at the Lorville: the next flagship landing zone
handled multiple test requests from the Engine team including a change to the Entity Component Update Scheduler
handled test request for area optimisations: improvements to door and elevator code
continued to support Subsumption and Subsumption tools testing
performance testing is underway for the PU
testing various gravity conditions on the new moons
experimenting with Levski having a full AI population and tweaking behaviours to avoid overcrowding areas
stress testing servers to determine the AI populations that can be supported without degrading performance
continued to work on scenes across all chapters of Squadron 42
continued work on the two dimensional render-to-texture display screen and holographic volume rendering
focused solely on applying some of the final touches for 3.0: colour grading for moons, integrating outposts and moon lighting, Levski bug fixes and polish
polishing and bug fixing existing content for the PU
added new areas and locations to Levski, a new shop and an admin office, and performed a final pass on garages
Started post-3.0 R&D: ArcCorp, procedural cities, and the planet Huston
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 ...
Will Weissbaum (WW): … And I'm Will Weissbaum.
SG: On today's show we'll take a look at the new Kiosk System coming in 3.0. We'll show you how this seemingly small mechanic is an important first step in building the game's dynamic economy.
WW: But before that let's check in with Brian Chambers for an update from our office in Frankfurt.
Brian Chambers (BC): Hello I’m Brian Chambers, Development Director of our Foundry 42 Frankfurt office.
Teams have been busy this last month as usual pushing on numerous fronts for 3.0, which is part of the larger Persistent Universe, as well as Squadron 42. The past month we had numerous visitors to the office, including both Chris and Erin. We find the travelling from the other offices time to time, to either work side by side with people or discuss the current status of things and future plans, is absolutely invaluable. So let’s start off this month’s update with the VFX team.
The Frankfurt VFX team has been working on improving existing systems for the 3.0 release. This includes checking all the existing vehicles and systems to make sure things are still working as initially intended and doing a polish pass on any effects if needed. With some of the new systems coming online, such as the oxygen system for rooms, they remade some of the old airlock effects for both the “high tech” and “low tech” airlocks. This month they also started shifting more focus towards Squadron 42 cinematic scenes that are required for the single player campaign.
The FPS Weapons team completed passes on the last two legacy weapons that were using our old system: completing a first pass on the Geminii L86 ballistic pistol and completing a final pass on the Behring P4AR ballistic rifle. They continue to make progress on the ship weapons: for Klaus and Werner laser repeaters they finished off all the work for sizes 1 through 3, started work on sizes 4 through 6, and finished off the Apocalypse Arms ballistic scattergun size 1 through 3. They also worked on some general tasks focussed towards 3.0 including polishing, optimising, and bug fixing.
The Tech Art Team finished multiple animation implementation tasks for both the recent “useables” sprint as well as cinematics. They continued to debug weapon animation issues and did some adjustments to a few of the weapon rigs to make them even more realistic and believable.
They also did some work on a VFXs exporter - this was primarily made to export simulated objects from within Maya. Having an active simulation on objects was causing some problems with the animation export and the best way to work around this was is to bake the simulation and export the animation, but that’s time consuming and leaves the scene in the state where the VFX Artist can’t do any changes to the simulation. So the exporter takes care of that whole process: it bakes the simulation, exports all the necessary stuff for the engine, and restores the scene so the artist can continue to iterate on whatever they need. The tool also creates all the necessary in-engine files so the artist can hit the export button and see the results immediately in the engine.
They also continued to support the animation code with ground alignment R&D: progress is going good and we’ll be able to show off some of the results very, very soon.
For Game Programming last month they spent time fixing outstanding issues and polishing up existing code. The new airlocks and elevators are now being used more throughout the game which exposed a few issues where game and engine code conflicted with one another; so those items have been identified and work has begun to sort them out.
They also added a small feature to weapons to be able to hide the weapon from first person view during aim down sight which falls in line with the design and will make things much easier when in the heat of combat.
The technology to easily apply weapons skins was also completed; it uses the work previously done for character customisations. There’s still some UI work to be on it and the skins themselves are placeholders for testing, but the work will now allow the simple and fast set up of weapon skins in DataForge.
They’ll now continue more work on the Weapons System 2.0 and additional elevator and airlock feature polish geared towards 3.0.
The AI Team has been working on more mission broker and mission system features mostly for PU 3.0 but also offering support for S42. The mission broker has been adapted to support multiple players accepting the same mission and they added the ability for mission instances to share information, which means players accepting the same collection mission for example will be sent after the same item rather than having their own distinct item to collect. They’ll now build on that work by adding support for abandoning missions as well as “unlawful and lawful” asymmetric missions for multiple players.
This month they added support for takeoff and landing of AI ships and surfaces: this includes landing pads and ship hangars, other ships and celestial surfaces.
We’re also adding quantum travel functionality for the new non-Kythera AI. This is part of an ongoing effort to create all ship AI functionalities we need for Subsumption-based AI.
For the remainder of the month they’ll be focusing on adding more Subsumption AI support, like using nav splines, and correct AI behaviour when entering/exiting all vehicles and seats.
They also finished up the second sprint for “Buddy AI”. Designers can now specify if they want to keep the AI in front or on the side of the leader or player. This sprint also brings the ability for an AI buddy to take cover in front of a player, and moving from cover to cover point while following the player. This is the first step in having companion AI that will intelligently follow you and and help you out in combat.
The Frankfurt Engine team, in cooperation with UK, refined the handling of GPU crashes and proper reporting via the Public Crash Handler. As we render frames we now include tokens into the command stream in order to pinpoint more easily what the GPU was last doing in case it starts hanging. This info is sent along with other crash information for post mortem analysis via our Public Crash Handler service. And these steps should make it easier for us to more quickly react on GPU issues found in the PTU that are otherwise hard to produce because of specific machine set up, OS, driver versions, etc.
They also did a large number of performance analysis and engine optimisations geared towards 3.0 release.
Another item they started to work on was a new Roads System to work in conjunction with the planetary terrain. The legacy roads were not suitable for our large scale terrain: there was a large performance hit and they also had Z-fighting and flickering issues when viewed from long distances. The new system is extremely fast and efficient, cache friendly, and fully multi-threaded to send draw commands to the GPU in the most efficient way. The new system uses a screen space approach: instead of drawing the geometry conventionally it’s powered by a projective technique like what we used on deferred decals.
It has two distinct rendering passes. First we draw the road geometry as a 3D volume which intersects the terrain. In this pass a stencil mask is generated to outline borders of the road. The same mask is then used in the next render pass to clip all pixels of the volume that are not affecting the terrain. Finally to generate UVs and fetch material textures each pixel’s position is reconstructed in camera space and then in local space by sampling the depth. All material attributes are finally written in the G-Buffer to compute lighting.Thanks to the nature of the projection this technique doesn’t suffer any Z-fighting or flickering related issues.
They also created a new toolset to give the designers the ability and flexibility to quickly lay down the new roads and modify them as needed. It’s still currently a work in progress and the terrain and textures in the video are currently placeholder for testing, but the progress is going well and it will be a nice addition to our growing toolset for planets.
The Level Design team is currently making a pass on the Room System for Levski, ensuring that the player won’t unnecessarily suffocate in random places, as well general polish and bug fixes for 3.0. They also begun taking a look at the Lorville which is the next flagship landing zone on our list to tackle.
The Frankfurt QA team wrapped up June with multiple test requests from the Engine team including a change to the Entity Component Update Scheduler, which affects how parts of entities are updated, as well as the particle code that was changed to run on threads. All code changes have the potential to introduce new issues to an already functional build so thorough comparison testing was performed to ensure that nothing new would be introduced in the Game Dev.
They also had test request for area optimisations. Recent code changes affected how things such as doors and elevators worked. These changes would give us roughly 1.5ms frame time back which is obviously an improvement.
Subsumption testing continues this month with new features and bug fixes going into Subsumption Tool weekly. They continue to work closely with the Design team and Tony Z to ensure that the tool is thoroughly tested to their satisfaction.
Performance testing is also underway for the Persistent Universe. They use the Performance Profiler Tool from Visual Studio to gather very specific data in areas of low performance. They gather as much information as possible within the internal QA team and continue to do weekly cross-studio playtests in order to increase the stress of the servers and to simulate an actual live environment as much as possible.
Melissa Estrada, our QA Technical Lead, has also had fun time this month testing various gravity conditions on the new moons.
The System Design team has been working on items for 3.0 and with a lot of focus on the Levski landing zone. We have Rob Reiniger from the Austin office visit and manage to get a lot of work done in a short amount of time. They are experimenting with Levski having a full AI population. The AI behaviours needed some work to ensure that they’re not causing them to overcrowd in any given area.
They also spend time stress testing our servers to determine what AI populations we can support and still get the performance that we need. During the process they worked closely with the Tech Team to optimise so we can keep the performance as solid as possible.
The Cinematics team has been continuing to work on scenes across all chapters of Squadron 42. This month they also spent time working with the graphics engineers to continue work on the two dimensional render-to-texture display screen and holographic volume rendering work.
This month our Lead Lighting Artist, Chris Campbell, was solely focused on applying some of the final touches on our 3.0 content including colour grading for each moon as you can see here, integrating the lighting between the outposts and the moons, and doing bug fixes and polishing on the Levski landing zone.
The Environment team has been hard at work polishing and bug fixing existing content in the PU. With all the various components coming together we want to make sure the visual experience for the player is as absolutely good as it possibly be. On Levski new areas and locations have been added that will increase the number of things that players can do and explore, including a new store and an admin office. The newly added garages received a final polish and dressing pass, making them ready to be used.
They also put a lot of effort this month into researching and development, looking at new features going to the game after 3.0. This includes work on ArcCorp, procedural cities, as well as the planet Huston. An important element of the research phase is that we find smart and scalable solutions that allow us to create more content as efficiently as possible moving forward.
Well that’s it for this month’s update. As always thank you so much for watching and all the support. Thanks for the subscribers that enable us to provide these monthly updates to the community. Take care and we’ll see you in the ‘verse.
SG: Lots of great stuff from our team in Frankfurt. Those in-game holograms are looking pretty cool.
WW: Yeah, it's really impressive tech that we'll be using a lot going forward. We captured a ton of ship-to-ship comms for Squadron 42.
SG: And I know that, because I spent a few hours sitting in a fake cockpit getting all of Pusher's comm calls.
WW: Yeah, I think all together we spent weeks capturing comm messages, so expect to see this tech used a lot going forward.
SG: Another new system that you'll be seeing soon is Kiosks. Arriving in 3.0 these devices will expand the shopping options and services currently in game.
WW: Right. Kiosks are an integral part of this game's economy and need to tie into other important back-end systems like Subsumption, so getting them up and running has required a lot of effort from numerous departments.
SG: Now let's take a look under the hood and show you exactly what it takes to upgrade your shopping experience
Rob Reininger (RR): Hi I’m Rob Reininger, I’m the Lead Technical Designer in Austin
Spencer Johnson (SJ): I’m Spencer Johnson, I’m an Associate Gameplay Engineer on the L.A. team.
Zane Bien (ZB): I’m Zane Bien, I am the UI Creative Director here at Foundry 42.
Treavor Wernisch (TW): I’m Treavor Wernisch the Principle UI Artist here.
Pete Mackay (PM): I’m Pete Mackay, Senior Designer on Star Citizen.
TW: The kiosk is our first foray into an economy into the game, a real living economy driven by the players.
RR: The kiosk is going to be the user's interface to purchase things or sell them within the game that are not physically within the shop in the case, purchasing or things in their inventory, things from their ship all selling with be done through the kiosk.
ZB: What that will allow you to do is view an entire store's inventory. You can browse through a list, you can filter it, you can sort it and view its stats and comparison to other things. It will extend to eventually the landing services. You can use the Kiosk to restock your ship and refuel and so forth.
RR: You’ll be able to equip a ship item directly onto the ship at the time of purchase if you want or have it delivered to the cargo hold of your ship.
ZB: It’s almost like ordering through Amazon or something where you can select a shipping destination. So whether you have a ship landed on a cargo pad or there’s a cargo area on the landing zone you’re at or you want to ship it someone like you can select that as an option.
PM: So I’ve been working on economy related stuff almost since January of 2013 and so I’m really excited that we’re getting to the point now that the stuff we were talking about in the early days of the project, we have tools support internally for that I can actually start building this stuff. In addition I work out things like the recipes for the supply chains and manufacturing. Recipe in the context of Star Citizen is somewhat similar to a crafting recipe in other MMOs. It defines the types of commodities and resources that go into manufacturing a given item like a laser cannon or even a ship. The way that we use recipes and the way that you may find them in another game is that those recipes generally aren’t used directly by the players, instead they’re used by the design team to really sculpt the types of goods that are bought and sold in a location in the world and that’s to make that location feel correct. So if it’s a factory that it buys and sells the kinds of things that you would expect from that location.
SJ: I’ve been working on the backend code side of the shopping and kiosk systems. The simplest way to describe making the shopping component we have is talking with the various systems that are all involved in the player making purchases and transactions. Through the whole process of using a kiosk or using the storefront to buy things and then have that enter into persistence.
RR: So commodities make up a big part of the economy because everything within the game is created from one of the resources that runs through this system. Iron, Gold, Titanium, Hydrogen, Oxygen, to get commodities into the game means we can start building the foundation for creating an actual economy where if deliveries aren't being made to a location then all of a sudden their manufacturing capability is no longer at its peak performance so their demand goes up, prices go up, you can start to get that fluctuation in pricing. So in terms of the beginning point, this is really a big step for getting that in place.
PM: Some of the big challenges for developing this economy is unifying the scale because as you know we have items from super tiny and inconsequentially priced, all the way up to these massive battlecruisers right? They all have to fit somewhere on the same scale and so that’s been probably one of the biggest challenges and the others are just the scope of the amount of work that has to get done in terms of building the recipes and you know even to the point of building the individual shop inventories because that’s all done by hand. We have a location and we want it to buy and sell certain things so we actually as designers have to go in and determine what is bought and sold there.
SJ: When you go and buy these commodities you’re going to buy a bunch of iron say, I mean where’s that iron going to go? Your ship right? That makes the most sense, gotta go in your ship, but what if you have multiple ships so obviously there needs to be a way to say, “Oh I want to put this in my Hornet or I want to put this into my Idris, I want to put my stuff I’m buying right now in this ship” and you’ve got cargo grids, you’ve got this whole other system that's being developed of how much stuff can we put in a ship and how's the player going to decide what ship to put it in. So a lot of these options lead to needing very dynamic solutions on the code side. We need to accommodate putting these commodities anywhere, we need to give the player the option to select where they’re going. We need to save where this stuff is kept because certainly you might think, oh it’s just in the ship, but it becomes very complicated on the persistence end of things when saving what the player has done, well where did they keep it? All of this iron you need to keep track of what was left in this cargo bay of this ship which was on this port of this space station.
A lot of these different systems are first of all not always running directly on your computer at home. Sometimes it's running in our backend systems and there’s also a lot of asynchronous events and calls. So you have to wait for things to happen basically, you have to send messages and wait for answers rather than just getting immediate feedback. Because again like I said the shopping component really exists at the centre of a lot of different things communicating.
PM: I also set the prices for commodities and it’s a similar process, it doesn’t have quite as much, it’s not as quite as intricate as the pricing for the items because there aren’t gameplay values associated with this that I need to take into account. We actually have a tool that we internally call “Trade Slayer” and another one called “Price Fixer” that help with this job and Trade Slayer is primarily for fixing… setting the prices for commodities. What it does is it helps me figure out what the base value for a commodity should be based off a bunch of different analytic data points and then it also helps me figure out what the range is that those should fluctuate in and then Price Fixer does a very similar task, but it’s quite a bit more complicated and that helps me set the prices for the items, but then it actually tasks that one step further and then I use those items to help me value a ship. So it goes all the way from pricing a countermeasure launcher to the price of a Constellation with the included P52.
RR: Some of the challenges that we face when designing this was CR really wants that tangible feel, he wants to be able tos ee the items, he wants to be able to see how it’s going to look on a ship or in the place that it belongs. So doing that in a way where people don’t have to navigate 5,000 different layers of a hierarchy in a window, having that be understandable and intuitive to the player was a big challenge here.
PM: Complexity for the economy is pretty deep because it is tightly integrated with the gameplay. A large portion of my time is spent interfacing with the tech design team just to make sure I understand how the item progression curves work and what the expected types of play are for those items so that I can make sure that they have the right price.
TW: One of the most exciting things about building the kiosk was the visual style side of it. There’s going to be as low end, kind of like a old Gold Dos Prompt BBS forum style and then we’re also going to have a mid end, like a mid 2000 web 2.0 style. If you go to Grim Hex is where you’ll see the low end kiosks, Port Olisar for example have the mid nice range kiosk.
ZB: One thing we had to take into account was branding of this interface. So when you go into a shop say Casaba Outlet you’ll see the logo and the colour scheme applied. It’s all one underlying system, but we swap out the graphics depending on the store and manufacturer.
TW: It was really fun to design the old school style, the low end one. It just kind of developed these frame by frame animations that you would see old you know Dos games and things like that.
SJ: When I talk about the shopping code and it exists in sort of this glorified middle man, this intermediating step between a lot of moving parts. One of those parts is subsumption, like backend shopping service. There’s a whole bunch of backend services we have as apart of subsumption and the Diffusion system, one of those is the shopping service. What the code that I’m writing does is it communicates to this backend service which exists on our CIG servers and gets inventory information. Olisar, Dumper's Depot, or Casaba has this inventory with these prices, this quantity of that item and every store has a unique set of information and so we need to communicate to that backend service and periodically update, restock, things like that and there’s just a large communicate chain of different moving parts that need to be talked to at different times.
There’s definitely a lot of communication that happens between these different teams like the UI Kiosk Team and myself, the Shopping Backend Team because we’re in different countries it’s a lot of back and forth, it’s “Oh okay we need an interface like this, we need to have this line of communication”, often times we’ll create function interfaces so it could say, “This is exactly the code you need to call, even if I hadn’t written it yet, this is what it will look like”.
RR: The kiosk actually requires a lot of different changes to go in for 3.0. We needed persistence for ships, persistent DB’s as far as their inventories so as people purchase goods they have to fly a ship to a location, purchase the stuff that they want on that ship, fly that ship to another location or sell it so it doesn’t allow people to go to any location they want and spawn any ship, it forces them to fly their ships around the universe. Previously you were able to do, “Oh I’m at Grim Hex and I want my Freelancer now or I want my Hornet now”. Now people have to fly these things around it’s going to force them to think about like, “Oh maybe I need an escort back to this other place because I want to leave this ship here but I want to get a different ship and bring it over here so I can buy or sell some things for this ship.”
PM: Prices will change based off inventory levels and stock levels and those inventory and stock levels are set on a per location basis. So you can have two different Casabas in two different parts of the world that have different pricing schemes and it may be that they have the same base price for a given item, but due to the fact that one of them might be farther away from a distribution point that it gets restocked less often and therefore the price stays higher on that item more regularly than at the other shop and that’s just one example of kind of the complexity that we should be able to deliver in 3.0.
SJ: Your player persistence is everything that you own as a player so it can be the commodities you have, how many SCU iron do you have or what shirt you’re wearing. So that would be your players persistence data. Luckily that system already exists and so it’s constantly making improvements to it and so the this new shopping code we have has to interface with some of the older parts of persistence and some of the new parts as well so that we really make sure we’re saving what you do.
RR: The big thing that is going to change for 3.0 is that it’s really going to start to feel a lot more like the overall experience that we’ve talking about for so long. Persistence is a big part of that, the ability to interface with things of in game through the kiosk is going to be another big portion of that. Cargo system is coming online, actually being able to carry things and having your ship keep track of the stuff that’s on it and require people to transfer goods from A to B, that was a big part of our hauling and trading professions.
SJ: That’s the exciting part, what we’re doing right now is it’s laying the foundation for these cool features we’re going to see coming up like systemic pricing, dynamic economies that really react to players buying things in certain locations and selling them in others.
RR: As these things start to come online, it's really going to change the experience people are having now and turn it much more into the game that we envisioned.
ZB: So the cool thing about the kiosk is it’s inworld like all of our other interfaces so that will have tie ins with the interaction system where you can bring up a cursor and interact with the screen. So that will be sort of our first foray into getting interactible screens in the world working with this unified interaction system so later on we’ll expand that to elevator panels and other inworld screens.
The kiosk is a nice test because it has quite in depth functionality like sorting and filtering and pop ups and things like that so it’s quite a complex interface over let’s say something simple like an elevator floor selection panel. So it’s a good test for us.
RR: This is the big step we’ve been waiting for, for a long time to be able to start adding a lot of these other professions and features into the game so I’m really excited about it, it’s going to be the beginning of a lot of great things for the player, it’s going to be awesome.
SG: I love the retro look of those low-end kiosks. They're really fun and have a lot of character.
WW: Yeah, you'll be able to tell a lot about where you are in the verse just by seeing what kind of kiosks are around. That kind of environmental storytelling is important considering how many landing zones the game will have.
SG: And that's all for today's episode. Thanks to our subscribers for your continued support. July's edition of Jump Point will be released tomorrow, so be sure to check it out.
WW: Definitely it's going to be a good one. And finally a big thanks to all our backers for helping us build this game. The level of community engagement at this point in the development process is just one of the many things that makes Star Citizen so special.
SG: True that. Until next week, we will see you …
SG & WW: … Around the Verse [Cliche Hand Wave]