Transcript: Around the Verse – What is Mega Map?
- Sandi Gardiner (VP of Marketing)
- Forrest Stephan (CG Supervisor)
SANDI: Hello and welcome to Around the Verse, our weekly look at the development of Star Citizen. I’m Sandi Gardiner and while Chris Roberts visits the Frankfurt studio I’ve been joined today by CG Supervisor, Forrest Stephan. Thanks for stopping by Forrest.
FORREST: Thanks for having me, it’s great to be here.
SANDI: In today’s episode, we’ll share how the mega maps feature eliminates load screens between levels which means more time for gameplay and less time waiting. Very important stuff.
FORREST: Very important, but first let’s kick it off with Eric Davis in our Los Angeles Studio Update. Take it away Eric
- Eric Kieron Davis (Senior Producer)
Hey all I’m Eric Kieron Davis, Senior Producer here in Los Angeles. We’ve had quite a busy month since we last talked so let’s just dig right in.
To start off our ship team has been working on the Drake Buccaneer. Art has created a custom dual weapon mount, all LODs have been generated, the Tech Content team has implemented UV2s and damage, Tech Design is making their “flight balance” pass, which will get it ready for “flight with sound”, VFX is making solid progress as well.
The Drake Buccaneer will be a great addition to the Drake lineup and we can’t wait until you’re in the cockpit.
The Ship team has also made a lot of progress on the newly revamped RSI Aurora. The white box phase is now complete, which includes a proxy laying out the space, establishing the animation positions, laying out the screens, and making sure the characters could hold the controls.
We’ve started the final geometry on the cockpit in an effort to improve the inside of the ship. Now that Tech Design has implemented all the art updates into the ship’s new archetype the RSI Aurora is heading into grey box.
It’s been awesome to see all these different pieces come together and breathe a whole new life into an already great design. We’re looking forward to finishing up and getting it back in the air.
There are a few other ships making their way through design as well as a slew of quality of life bugs/fixes for the upcoming 2.6.2 release but we’re not quite ready to reveal those just yet.
In addition to ship production, the tech design group completed design for multifunction displays or MFD screens which control power, heat, coolers, shields, weapons, countermeasures, and missiles in preparations for Item 2.0 functionality. These designer prototypes are meant to help us understand what’s needed and see how everything will interact with each other. Once these designs have been approved, the amazing UI team will create an interface to take advantage of that functionality that Engineering is implementing in the backend.
Once the system’s in place a ship that is staffed by knowledgeable crew will be able to operate their ship beyond the default system settings and min/max the various ship systems to suit, not only your playstyle, but potentially save your life during a devastating attack.
This month QA aided LA Development checking a variety of fixes for 2.6.2 while also providing support to Austin QA with PTU and Live sanity checks, smoke tests, sweeps and deployments, and helping new hires get up to speed with the game. As for feature work, the team swept ship destruction VFXs, Item System 2.0, and implementation of recent loadout changes, and tested multiple iterations of new targeting and ESP code.
For a quick reminder on quality assurance terms: A “sanity check” basically ensures the game loads which is now automated but still can take an hour and another 30-60 minutes to investigate any errors that arise. A “smoke test” checks the basic functionality but this takes six to eight people roughly a day if there aren’t any major issues. And a “full sweep” means checking everything you possibly can, a process which requires a much larger team and can take over a week. As you’d expect full sweeps are mostly arduous, rigorous, and intense but also incredibly important.
Over on the narrative team they’ve been hard at work at some additional 3.0 missions. They’ve also started much-needed documentation for posters and props to help populate the world of Star Citizen. They’ve also made a lot of progress on Xi’An history and society documentation by creating an equivalent time capsule approach for the Xi’An history from birth to present day.
Also, those that saw the 3Lateral head test portion of GDC a few weeks ago, we can now talk about how the team has been doing breakdowns of ethno groups in the Star Citizen universe, utilizing the power behind that technology as our character customization is rapidly coming together.
Now the engineering team has begun work on the new shop entity that uses data core components. It will allow shops to easily be streamed in and object containers (which will be finished in sprint). The plan is to make shops more dynamic and reactive to the economy by retrieving their inventory from the backend.
The engineering team also added a new attribute to vehicle XMLs that will allow designers to specify the interior grid type of the vehicle: small, medium and large. This is a pretty big optimization that will reduce memory storage as all ships previously defaulted to medium size.
Now last time we discussed the development of the new light group entity that was equipped with a state machine to serve as the ultimate light switch. Now the implementation of the core state switching functionality is complete. The next step is to start using the light group in our vehicles and environments, and replace all instances of old layer switching method of light management. This new light group entity has allowed us to reduce the number of lights we’ve been using which has dramatically impacted performance. For example, on the Drake Caterpillar we were able to reduce from hundreds, almost thousands, of entities down to 90 or less with no visual impact. And that’s just the beginning. In the upcoming weeks, we’ll continue to evolve the Light Group with additional features based on feedback from other departments.
We’ve also been developing a framework in IFCS, or Intelligent Flight Control System, for the autopilot to handle situations like a takeoff and landing sequence. This also applies to AI control. They’ll be providing AI developers with a set of tools for controlling the ship like a “move to” or “change to”, etc. This will improve stability and predictability of ship motion under optimal conditions.
There was also a large update to our room system and atmospheric containers with the addition of several new features as well as better debugging tools and several bug fixes. So far the room system has only been implemented in a few locations but these changes will allow us to fully implement rooms and atmospheres throughout the various locations and ships in the game.
At the moment, all the airlocks you enter and exit are scripted events; they don’t factor in atmosphere of any kind. With this new system, we’ll be able to replace this set up with an actual room and atmosphere that allows for a dynamic experience.
In addition to the room system changes, they’ve added a feature to allow designers and artists to set wear and dirt parameters for loadouts. This functionality comes in two levels: overall as well as individual values for specific items. Wear and dirt values are used by the render node to set shader parameters that make items look older, dusty, scuffed up, and burnt out. You’ve seen an example of this on the module surface outpost seen in the last week’s Studio Update. This task also used loadout editor side work where the team added UI support to edit wear and dirt.
We’ve recently also started working on a pretty massive task called the entity owner manager. To give you a little background this is a core feature required to take our gameplay from a multiplayer game to a persistent online experience. This system will be responsible for managing ownership and lifetimes of all the entities in the game and will work in conjunction with the backend persistent systems to indicate dynamic changes to the world that need to be tracked and persisted across sessions. The entity owner manager will also need to work with various game and engine systems including debris, salvage, criminality, streaming, missions, cargo, shop and much more to help create the persistent experience across clients and servers.
In other news, the team has been working on scanning subcomponents which require us to do some slight refactoring of object databank. Now the databank can support the storage of child entities which will be the subcomponents on ships, players, etc.
In doing this we also improved the thread safety of accessing data within the databank which allows us to move some calculations onto other threads which will help improve performance. This work is focusing on two big elements, the ping component and angle of focus.
The ping component is the method in which a player or a pilot will send out a wave to see if there are objects out there of note within their scan range. This could also be a ship, an asteroid or even signal traces that mark whether a player entered or exited quantum travel. Other players can detect these traces which could have some pretty heavy game implications. For example, if you’re an outlaw it could allow you to track potential prey.
Angle of focus allows players to adjust the angle with which they’re scanning. A smaller angle will provide more range but only contacts within the angle can be detected. We’re currently refactoring the underlying radar query logic to use zone queries rather than a huge iteration of registered radar objects which will make the scanning system much more efficient.
Now if you remember from our last update, our tech content team supports and implements every pipeline within Star Citizen and Squadron 42. One of the main focuses for this team is performance improvements, for instance we’ve changed our mesh vertex and position formats which massively improve streaming of these meshes as well as reduces the build size.
They’ve also been improving the Python integration within our editor which allows for faster development of Python tools usable by every departments across the company. They can now script any sandbox process they want, for example, placing asteroids, generating modular outposts, etc. All of which saves tremendous amount of development time on otherwise tedious and time consuming tasks.
You also may have noticed the player’s helmets were disappearing once they got to a certain distance away from you. As discussed in the character customization featurette not too long ago, we’ve now converted all helmets to a .skin format. The conversion was important to allow a unified LOD ratio across the character skins meaning no more helmetless people running around the ‘Verse. So, don’t be afraid as the oxygen system comes online we would hate to be the reason you lose that FPS battle on the dark side of the moon.
To ensure this is easier in the future, tech content has also created tools that rig skins and exports automatically. This dramatically reduces dev time from potentially an entire day down to just a few minutes. Now that helmets are optimized heads were next on the agenda. We’ve successfully converted all heads to use the human skin shader developed by our graphics team. Since we do 44 different areas of blended wrinkles and blended diffuse our texture cost was quite high at about 100 megs per head.
With this change, we were able to save roughly 90% of the original texture memory cross without a discernable visual impact. This means we can have a lot more characters in the scene without melting your graphics card.
With the implementation of the female character progressing rapidly, we’ve transferred thousands of animations from male to female to complete her motion set and provide a data for animation to start iterating on. This will also allow us to focus on refinement and subtleties without compromising on what she’ll be able to do while exploring the universe. There’s quite a bit more to do but we’re making leaps forward every day.
Another character animation tool the tech content team has completed is this track and report the number of various wildlines each character will have in the universe. With over 1255 pages of script for Squadron 42 which includes all storylines as well as wildlines, we needed a tool to continuously generate reports on how many we’ve completed and what we have left to solve. Once the various lines are all in the system we’ll be able to pull those lines based on player action and situation and randomize the potential wildline response so the NPCs aren’t repeating the same line all the time.
To help our cinematics team focus on content need for Squadron 42, a tool was written to allow for visibility of scenes before they even hit the engine. This allows for fast exporting of animations and preview renders which would then automatically uploaded to Shotgun which makes it much easier and faster to review the many hours of cinematics for Squadron 42.
The character team has been blasting through the concept phase, the high poly phase and on to the in-game mesh of the heavy outlaw. Next it’s going to go into rigging and implementation. We’ve also sent the light, medium and heavy female marine armor as well as the under suit to rigging and implementation. Once we had that male base suit done we utilized a wrap technique with adjustments to save development time and we’re sure getting everything together as quickly as possible. Another suit that has moved through the high poly phase is the female explorer suit. So, she’ll be exploring the universe in no time.
On the Squadron 42 character front, both the EVA deck crew and the marine BDU have gone through high poly and are on to the in game mesh and texturing phase, which means it should be in rigging and implementation in no time.
In a category of things we can’t talk about, we’ve continued developing the Vanduul as well as medium and heavy versions of the OMC outlaw faction and lastly the mechanized Titan suit is in R+D along with other alien concept sculpts and a whole lot more we can’t reveal just yet but stay tuned for updates in the coming weeks. Well, that does it here for Los Angeles, thank you so much for your support, we’ll see you again soon.
Back in the Studio
SANDI: As you may have seen on our production schedules, our developers have been working on a new system called mega map. Understandably, some of you may not know what that means.
FORREST: It is a tough concept to grab. In the simplest terms, mega map means to eliminate the loading screens. So, it basically streamlines the Object Containers while loading in and out the different areas and the different game modes.
SANDI: The goal of mega maps is to allow players to travel through the universe without interruption or lag time. To better explain how mega map does this let’s take a look.
Rob Johnson (Lead Gameplay Programmer)
Clive Johnson (Lead Network Programmer)
ROB: The mega map is a new feature that we’re putting into the game to cut a lot of the frustrations with load times out for people, since you eliminate load screens altogether.
The issues that drove us to this technology come from the unprecedented scale of this universe we’re creating. What this means is we couldn’t load it into one map without crippling memory and performance, so we divided it up and put segments into object containers which we could load as needed.
The problem with that was that it meant players would need to wait for a series of load screens as they moved about in the game. The mega map was our solution.
We load the mega map as we would a standard map. The mega map itself is empty, but once the mega map is loaded, we actually start to fill the mega map with content of various game modes, fire and object containers. So, we would load the mega map which is empty. Load the front end, which is a set of object containers. Load the front-end game rules which tells the game how to work in that game mode. The user would then pick a new game mode to play.
At that point we throw away all the object containers. We throw away the game mode; load in the Free Fly game mode and the Dying Star object containers, but we do that via streaming rather than a complete level load, so we are able to shave the vast majority of the load time down to a few seconds rather than long enough to warrant a load screen.
As you can see, even with mega maps switched on there is still a load stall. It’s only a few seconds compared to the 30 seconds it takes to load without the mega maps feature, but it is still something we’re working to eliminate by making the feature operate asynchronously.
Gameplay wise that’s great for players if they want to be in the front end changing some settings. They can go to a hangar. They can put some items in their hangar, look at their ships then immediately go back to the front end, no load screens, pick a game mode, race mode. They can dive straight into race mode, play around with one ship, decide they don’t like that ship, come back to the front end, switch to a new ship (still no load screens) rather than having a process where they’re setting on the front end and they have to think carefully where they want to go, because they know the load screen coming up, go there, do some stuff and then load screen again.
So, by adding this new feature we’re putting into the game the first application of a lot of the object container streaming which will be a fundamental part of the P.U. experience moving forward as the P.U. becomes essentially like its own mega map with a bunch of sets of object containers that will stream in and out as you move through that map.
The thing that makes it tricky in terms of game-play programming is with the new flow we’re now not destroying and recreating the player between game modes, so with the new setup it potentially makes it easier to persist. Some of the player’s attributes between these game modes, because the fact that we’re not destroying them and recreating them.
So, one of the more interesting bugs that the new mega map flow has produced was QA finding that they could place down a liquor cabinet in their hangar, take a few swigs from a bottle, get slightly blurry vision wise then decide that they didn’t want to be in the hangar anymore. They want to go to go fly their ship in free flight. However, with this new flow the player is not being destroyed and recreated, so unfortunately for you, the player, you now find yourself in the ship with blurry vision trying to fly through space which is probably not the best thing for a player to be doing. So, something we’ll obviously be looking to fix, but a nice illustration of the kind of interesting challenges that we face in fixing up this new flow.
CLIVE: Mega map for multiplayer is a little bit more complicated. It builds on top of the single player implementation. The tech is the same up to a point. The additional challenge is that each level in our multiplayer game lives in its own server to handle the tens of thousands of players who might visit it at any one time.
A multiplayer match and it comes to an end and you want to change to another multiplayer game mode and map then you’re going to have to unload the map that you’re into, Dying Star, go out to the front and make your selections to what you want to do, and then load into the next map, say Broken Moon doing Pirate Swarm or whatever.
Because you’re going from connecting to a server back to the front end, we’re going to drop the connection, but we’ve got to keep the mega map in memory, empty out all its contents, put all the front-end pieces in, let the player make a selection, and then go and connect to another server while keeping a map in memory at the same time, and then stream in all the new pieces for the new map.
It’s a bit like trying to unplug your computer and then re-plugging it without losing power. And that’s not the way we’ve been doing things before. It’s been very much, get to the end of a match, you drop the connections to the server, you clear everything out, it’s kind of like a hard reset of a system, load in the front end, make your selection, into that hard reset of the system, connect to the next server.
So, we’re just keeping the map in memory but switching connections and servers, switching between single player/multiplayer game modes at the same time, without doing this reset, which is a bit of a challenge.
The way the engine is being built, it’s kind of the assumption that once a system starts up it’ll either be in single player mode or it’ll be in multiplayer mode and it’ll always stay that way until the system shuts down again. Now we’re changing these things dynamically all the time, so that can create a log of bugs. It’s kind of been a process of trying it out, find out what it breaks, fixing it, trying it again, find out what it breaks, fixing it, and we just keep doing that over and over.
Taking a system like Crusader, extending it, you might have an object container for each of the stations, each of the comm arrays. There will be an object container that contains references to the object containers for where all these other things are and they’ll be just sort of left there in a very lightweight form. Then as you head toward, say, Port Olisar the object container for Port Olisar will get loaded in and expanded. That may contain other object containers that contain the interior or different decks or whatever, and they’ll get loaded in on demand.
You have a skeleton structure that’s defined by an object container and then you can fill in the various parts and collapse them down again, load out another part. Then it will scale it going down to let’s say a room as an object container. Assemble them together to make a deck, assemble them together to make a space station, that’s an object container, interior and exterior possibly could be different object containers. That’s linked to an object container in space that says where that space station is, and that will be parented by a sort of root system object container that says where all the different space stations are in that system, different planets and so on. It kind of scales out that way.
So far it’s only been done for the Star Marine maps and Arena Commander maps. When we bring this technology over to PU it’ll have to be done through Crusader and the other systems will come online. It’s a lot of work that we need to do but the technology is kind of at the point where we can start seeing the benefits of it now.
Star Citizen is a question of scale really, isn’t it? It’s taken a standard game and made it much bigger than anything else that’s currently out there. The only way that you’re going to be able to do that is by focusing on what the player needs to know and tailoring that experience for each player even though they’re all connected to the same server. So, you’re always looking for opportunities to not do something. Avoid that little bit of work. Well, on the computer side of things anyway.
Back in the Studio
SANDI: Thanks, guys for that insight on mega maps. Cutting down on wait times is really important to improving gameplay.
FORREST: Absolutely. I also look forward to seeing the multiplayer mega maps rolled out in Star Citizen.
SANDI: Yah! And then many players will be able to traverse the universe at the same time.
Now before we wrap up today’s show we want to express our gratitude to all of our subscribers.
FORREST: Yeah shows like this one would not be possible without your support which is why we are rolling out new subscriber perks. Due to popular requests from our current subscribers we’ve got a third edition of Jump Point in the works and we’re also making the free flight of the month a permanent edition for all of the subscribers. More details on the Subscriber Perk, so take a look.
- Sandi Gardiner (VP of Marketing)
- Alexis Lesnick (Subscription Manager)
SANDI: Hey everyone I’m Sandi Gardiner.
ALEXIS: And I’m Alexis. We wanted to take this chance to thank all of our subscribers, both Centurions and Imperators for your ongoing support.
SANDI: We look forward to continuing the journey with you and we’ve updated your subscriber perks.
ALEXIS: If you’re new to the Star Citizen community, Star Citizen’s subscription programs were created to provide an added level of community interaction and off you some unique perks. As a subscriber, Centurion, or Imperator you get access to Jump Point.
SANDI: Jump Point is Star Citizen’s monthly magazine featuring interviews with the dev team, in-depth looks at the process of building game assets along with new fiction and lore pieces.
There’s also the vault which is updated weekly with all sorts of ship concepts, environments, and characters.
ALEXIS: Subscribers allow us to create all of our video content. Shows like: Around the Verse, Bugsmashers, Loremaker’s Guide to the Galaxy, Happy Hour, and Citizens of the Stars. As well as more in depth events like 10 for the Chairman and the Subscribers’ Town Hall.
SANDI: We like to put you behind the scenes here, hear from the creators themselves about the development of Star Citizen. Centurions and Imperators get exclusive access to submit questions for Chris and the rest of the dev team to be answered during 10 for the Chairman or Town Hall videos.
ALEXIS: You also get access to the subscriber forums where you can interact with other subscribers and myself, as well as participate in subscriber only polls and Q&A threads.
SANDI: A new perk for all subscribers is our ship of the month club.
ALEXIS: That’s where we unlock a ship for subscribers to test fly. So if you’re dueling it out in Arena Commander or exploring the space around Crusader, you can try out a new ship every month. Imperators will also have access to test flight all available ships and variants when new patches go live for a duration of one week.
SANDI: Subscribers get a variety of other extras including early access to event tickets and discounts on physical merchandise as well as subscriber exclusive merchandise.
ALEXIS: And for the collector in you, there’s a free hanger decoration every month. These have ranged from models of ships, glowing algae plants, and even an ancient underwater creature skull for your in-game hangar.
SANDI: Imperator subscribers get a little extra. Double the flair, double the discount coupon, plus your ship of the month roster is expanded too. You can get access to some of the limited alien ships like the Vanduul, Xi’An, and Banu ships as they become available.
ALEXIS: So again, thanks to all of our subscribers.
SANDI: …And we will see you…
BOTH: In the ‘Verse
Back in the Studio
FORREST: In addition to the new subscriber perks, all active subscribers or anyone becomes a subscriber before April 17th will receive an awesome piece of flair, a Big Benny’s Vending machine.
SANDI: That’s a great addition to any hanger and if you’re interested in learning more about our subscriber program, click on the link in the description below.
FORREST: And that’s all for today’s show. Again, thank you to all of our subscribers as well as our backers. None of this would be possible without you so, so much thanks for everything.
SANDI: Also, please join us tomorrow at 12 Pacific for Star Citizen Happy Hour for a special game development episode. Jared Huckaby, Tyler Nolin, and Tyler Witkin will be joined by Technical Designer, Calix Reneau.
FORREST: After the excitement of last week’s basketball half court reveal in the U.K. studio update. Calix will try his hand at creating a first pass game mechanic that might make it possible to shoot hoops in the game. Of course, this isn’t a mechanic scheduled to go in game, but it will be a fun behind the scenes look at digital scripting, all the same.
SANDI: Wow, sounds like a must-see episode. Thanks for watching and we’ll see you.
BOTH: Around the Verse!