Alpha 3.11 Postmortem
Undefined Undefined NoneContent
English
Alpha 3.11 Postmortem
On October 8, 2020, we launched Alpha 3.11 High Impact, which introduced a number of new features and changes, including cargo decks, force reactions, and the first stage of the wider Armistice Zone removal. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. Vehicle Team
The Vehicle Pillar had a much lighter quarter with Alpha 3.11 compared to the bumper delivery in Alpha 3.10, but what we delivered hopefully had a big impact on the gameplay experience.
Origin 100 Series
The Vehicle Content Team delivered the Origin 100 Series in Alpha 3.11, comprising of the 100i, 125a, and 135c. The 100 Series adds an alternative starter ship to the game as well as a light fighter and light cargo hauler. These are fantastic little ships for new players to start their Star Citizen journey with and provide the ability to tackle a wide range of missions and explore the far reaches of the ‘verse. Missiles & Countermeasures
The missile and countermeasure gameplay had been in various states over the years and was never truly enjoyable from the aggressor or defender side. We’re aiming to ultimately fix that with Missile Operator Mode, but until that is delivered, we decided to spend the time implementing fixes and iterations to the gameplay to provide a taste of what that feature will deliver. The main issues with the missiles prior to Alpha 3.11 were as follows: Countermeasures would act only on IR missiles (flares) and EM missiles (chaff)
Only flares worked (sometimes and highly server-dependant)
There were no countermeasures available to spoof CS missiles
Firing missiles was extremely easy, defending against missiles was extremely hard
First, we investigated why only flares would work and chaff wouldn’t. The issue was a combination of incorrect setup data in some ships, incorrect data in some countermeasures and missiles, and a now-redundant workaround originally created for a specific SQ42 level that had knock-ons game-wide.
Once we fixed those issues, we recognized that the signature system has two distinct ways of modifying signals – either creating a strong signal or dampening all signals around. We decided to embrace that difference instead of requiring pilots to play “whack-a-mole” by choosing the “right” countermeasure for the “right” missile type whilst under the stress of having a few seconds to decide before impact. With that in mind, we did some playtests with the following changes: Flares would act on all missile types
Chaff would be turned into a noise field, dampening all signatures around the field
Right away, the first gameplay tests proved that this was a much more engaging way to defend against missiles. We then went ahead and updated the HUD elements of the missile warning system, re-added a countermeasure widget, and updated the keybinds to allow direct launching for each countermeasure type. The UI and VFX teams then jumped in and beautified everything, replacing the effects and also fixing a couple of VFX related bugs (like countermeasures being invisible in the PU).
One future addition that we couldn’t do in time for Alpha 3.11 was to change the names of “flares” and “chaff”. Both names are very common for flight sim communities, but we still want to rename them to make it clear that Star Citizen uses different concepts for defending against missiles. This will require us to record new VO lines to update ship computer voices. Each vehicle is only allowed four locks at a time
Only one missile can launch per rack at a time
Only one missile type (IR/EM/CS) can launch at a time
Missiles lose lock outside of their locking angle
Once we had these measures in, the missile experience notably improved in early testing. The spamming of missiles was significantly reduced, and the meta shifted towards ships getting very close to each other and firing missiles at distances where the defender would not even get a missile warning before impact. As a result of this undesirable change, we introduced minimum and maximum lock ranges. This notably stretched the missile gameplay out of gun range, allowing missile-focussed ships to loiter at the edge of combat as designed while dedicated gunfighters would get in closer. This also allowed us to increase the locking angle of smaller missiles so that ships like the Constellation (that do not fire missiles forward but slightly off-angle) were viable to use missiles again.
A lot of these changes (especially to the missiles) are temporary to give a better experience until Missile Operator Mode is ready, which will change the behaviour again and/or remove certain aspects when it is implemented. Final Thoughts
The overall goal we want to achieve in the missile gameplay loop is to make both employing missiles and defending against missiles deeper and more rewarding, with its own “slot” in the combat environment. Missiles are not supposed to be an alternative to guns but tactical weapons, and the use of them should be a conscious decision with consequences. We also want to give special missile boats, like the Talon Shrike or Freelancer MIS, an edge when it comes to employing ordnance for the same reason. Those ships will excel in offensive missile gameplay though have obvious drawbacks in other categories. So, there will be more iterations on countermeasures and missile gameplay in the next couple of releases. For the time being though, we’re quite happy the missile experience stepped away from the frustrations of previous releases.
John Crewe
Vehicle Director
Technology
Canvas Decal System
For Alpha 3.11, the Graphics Team delivered underlying rendering tech to help power the ‘canvas decal’ system, which leverages the Building Blocks system to create decal textures at runtime. These decals can be used for signposting, on clothing, or even the signage on vehicles. The advantage of the decals being created at runtime is that we can use game data such as the player’s name or even have the content translated to the language the game is being played in.
To make this feature scalable for wider use in the PU, the system is tightly coupled with the texture streaming system, such that the dynamic textures are ‘streamed in’ using the same logic as standard textures, which ensures we always maintain a fixed memory budget. This streaming logic ensures we can automatically run the same feature set on low-spec machines by carefully load-balancing texture resolutions on the fly, but also allows us to push the texture resolution as high as possible on more powerful machines. Integrating the canvas decals into texture streaming resulted in several crashes in the PTU that were very difficult to track down and took a lot of time to resolve. As a result, we wrote some documentation to help future programmers understand the complexities of the texture streaming system, which will be especially important as we plan to generalize the code and use it for mesh streaming too. Planet Tech
On the planet-tech side, we added several features, including improvements to planet tools. This includes new painting brushes, revamped UI, and merged ground layer and object presets to make it even faster to paint planets. Utilising the new planetary painting tools, the Environment Art Team went through all planets and moons in the Stanton System and repainted the ground surfaces and object presets. This also futureproofs us and allows us to take advantage of new tech in existing locations. On a per-object basis, we are now able to support HW tessellation displacement on geology distributed across terrain to give it a more detailed and organic appearance. There were also several ocean and water related improvements, including ground cover buoyancy, which we will continue to expand upon in the future, as there wasn’t enough time during this release cycle to introduce larger floating objects.
A lot of time in the past few months was dedicated towards continued research and development of the atmosphere and cloud renderer, including the planet atmosphere unified raymarcher. We will go into more detail once the system becomes available. For now, let’s just say we worked on various algorithms to allow raymarching at lower-than-screen resolution and denoise and upsample the results to full resolution to improve the performance of costly raymarching operations. These are combined with reprojection techniques and the bundling of raymarch requests for pixels to be updated each frame to further improve performance. Additionally, our existing multiscatter solution now supports a significantly higher number of scattering orders, which will be important for very dense atmospheres. BTW, we’re now in the very early days of volumetric cloud rendering R&D…
Almost a byproduct of this work, we made various improvements to the existing atmosphere rendering technology. First and foremost several long-standing artifacts, such as false color rendering in twilight near the atmosphere top along with very prominent halos around the silhouette of a planet’s dark side, have been addressed. The generation of lookup tables now uses a better-suited method to generate sample locations for numerical integration over (hemi)spheres. That and other numerical precision improvements led to more accurate results in those tables at reduced computational overhead. We didn’t stop there, however, and implemented additional visual improvements for you to hopefully enjoy soon. One of them includes evaluating how much of the sun’s disc is visible when computing how much sunlight reaches point x in-atmosphere. This evaluation is fully integrated into the entire atmosphere lighting system and impacts direct and indirect lighting. Moreover, we added support for an absorption layer. Among other things, this allows us to add an ozone layer to Earth-like planets that emphasizes the blueness of the sky and enables better shading in twilight (removing yellow tint). We now also incorporate IRL extraterrestrial sun radiometry data when running the light simulation instead of assuming a “pure white” light source as well as an approximate conversion from spectral radiance (the result of the atmosphere lighting simulation) to luminance (used to light the scene in a traditional sense). Lastly, we improved the evaluation of sun radiance received by points outside the planet’s atmosphere. It now casts twilight due to atmospheric scattering and the impact of the sun’s angular radius onto objects in a planet’s penumbra region. This should add a nice touch to capital ships or moons orbiting planets. Engine
On the engine side, several improvements were made. We updated our compiler toolchain to VS 2019, which will allow for faster compile and link times. Moreover, we’ve added support for Intel SPMD Program Compiler (ISPC). This will allow us to write target-agnostic SSE optimized code (think HLSL) for heavy duty CPU compute jobs and will fully utilize CPU capabilities on each individual machine that the code runs on. Several code paths in physics, the 3D engine, and the zone system are in the process of being ported. And, we have another compiler optimization in store for you. AVX code generation support for clients was previously enabled and should hit the public servers in the coming Alpha 3.12 release.
Regarding server and client memory usage, we spent a good deal of time further refining our tracking tools to ensure we have good visibility on where we spend memory. We’re now also able to properly track memory usage in third-party libraries that either don’t allow us to reroute memory allocation through our system or haven’t been updated yet to do so. We still plan to get a bit more visibility on client-side video memory allocations on the driver level (below the level we can currently track as an application using the GPU). As a result of these improvements, ongoing investigations, and tracking, a few critical memory leaks were fixed for release.
Throughout Alpha 3.11 production, the Core Engine Team was mostly focused on features for later releases, like the Gen12 Renderer. However, a very large bug was fixed, which caused all our objects on clients to unload way earlier than we intended. Objects on clients should now stay streamed for noticeably larger distances. Audio
For audio tech, we updated the Wwise version to 2019.2.4, which fixed several issues. As part of this endeavour we reworked memory management within the audio system, going from a group of memory pools to a single pool. This allows us to deal more easily with the many different situations that Star Citizen presents by allocating memory where it is needed, when it is needed. We spent a lot of time revisiting our voice budgets to improve the overall experience and to allow players to hear more of what’s going on in the game. Weapon fire support, particularly at long distance, was improved and several issues with audio fire rates and weapon volumes were fixed. Canvas Slicing
This quarter the UI-Tech team has been working on a system called the Canvas Slicer. This is a sub-system of Building Blocks which will allow the UI designers to place slices of 2D UI in 3D space. Normally, when we draw 2D UI, it gets rendered to a texture and then that texture is applied to geometry such as a monitor panel or data-pad. With the Canvas Slicer, we create the geometry at any position in 3D-space at runtime and draw the 2D UI directly onto it. This means we will be able to produce interesting layered UI, such as holographic ship HUDs and helmet displays. Tooltips
We have also started designing our tooltips system for Building Blocks. On the surface, this looked like a simple system to implement but the requirements to ensure it is super flexible have meant we’ve got quite a lot to think about before we start implementation.
Marco Corbetta
VP of Technology
Core Gameplay
External Inventory
External Inventory is the first iteration of our grid-based inventory interface that allows players to manage their FPS commodities between their backpack, chest, and leg pockets. As it says in the name, the External Inventory also allows players to directly interact with other storage containers in the world and drag and drop items between them. In Alpha 3.11, this is only enabled for the Greycat ROC storage compartment so players can manage their FPS mineables. But, in the future and once we realise true item storage (underpinned by iCache), this will allow players to store items in compartments, crates, and other such external inventories.
While on the face of it, a new inventory UI and being able to drag and drop items between storage containers may sound simple, we had to overcome several creative and technical challenges. The main creative challenges revolved around having an interface that felt tactile and accessible to use without just feeling like a standard 2D interface that you see in most RPGs. This wasn’t because those inventories are bad, more that we didn’t want players performing inventory Tetris to manage their items; we wanted players to freely move items between storage containers without having to worry about where they dropped the item or if another item was in the way. We were able to achieve the first iteration of this using our Building Blocks technology, which stores the items as a list rather than a 2D grid. This means items fluidly move around your cursor as you drag objects between containers. We still want to further improve on the overall feel, but the team is happy with the initial outing.
While Building Blocks allowed us to deliver on the creative aspects of the design, it also provided the main technical challenge. As the technology is still being developed, it means it doesn’t always support things that you need to deliver a feature. In the case of External Inventory, we wanted the UI to feel diegetic and 3D even though it is not. This meant we wanted all the icons to be holographic, like they were being displayed in AR directly in front of your eyes. Unfortunately, our 3D icons could only support a limited shader which meant we lost a lot of material detail from the items being displayed. At this point we could have delayed the feature, but the team and I felt it was important for us to go live and get as much feedback as we could between now and a true physical inventory. We will definitely be upgrading that shader in an upcoming patch. Force Reactions
At its core, Force Reactions is a system developed to simulate what a character would do when impacted by a force, whether that is a strong gust of wind or a bullet penetrating their shoulder. It can be split into three levels of impacts: Low impact: twitches, flinches, and leans
Medium impact: staggers
High impact: knockdowns
In Alpha 3.10, we delivered the first iteration of low-impact reactions with the procedural twitches in FPS combat and leaning during sustained winds. In Alpha 3.11, we added more ‘feels’ to the twitches with additional camera and weapon reactions and our first iteration of knockdowns, with the intention for staggers to come later.
The biggest challenge for this system was that it needed to be truly systemic as forces can come from a lot of different places, not just bullets. For this, we broke down the forces into three main categories: Direct forces: anything that physically impacts the character, like a box or bullet
Indirect forces: the force you receive when your ship gets rammed or from a gust of wind
Sustained forces: where a force is constantly applied, such a g-force or wind
This meant we could compartmentalise different forces with different scales and allow the designers to balance the character’s reaction accordingly, as the forces of being hit by a box compared to the acceleration of a ship in space to 1000m/s are vastly different. While low-impact reactions do not take away any player control, we were very cognizant of the fact that knockdowns would. We spent a lot of time making sure the knockdown animations were very reactive to player control as soon as their character hit the ground. We also implemented a skill-based system that meant if you tried to ADS before touching the floor you would trigger a faster recovery animation, meaning you could get back into the action quicker.
Force Reactions in Alpha 3.11 was our second delivery and will be by no means our last. We are actively working on medium-impact reactions and will be constantly reviewing and tweaking the balance going forward, especially in FPS combat.
Throwing T1
Throwing grenades or other objects has always been a bit inconsistent and is even more disappointing when you think you have that perfect multi-kill opportunity for the grenade to just whimper a few feet from you. So, the first thing we wanted to achieve with T1 was to make throwing much more reliable, so that the object you throw (whether a grenade or other object) goes where you expect it to go. The second biggest objective, which is a critical pre-requisite for the physical inventory, was for the throw system to be able to interact and co-exist with the carriable system.
In Alpha 3.10, if you picked up a grenade from the floor and then tried to throw it, there was no way for you to pull the pin. Also, if you pressed the ‘Throw Grenade’ hotkey, you would drop the grenade in your hand and pull a new one from your suit. Obviously, this is not the intended behaviour and was a major reason why we changed throwing to come from an equipped state (i.e. holding the grenade in your hand) rather than directly from your suit. This system will also allow us to deliver gadgets and deployables in the future.
As part of T1, we also added a UI ‘throw arc’ that allows you to see the trajectory of the grenade. While currently this is enabled for all helmets, it will only be accessible from combat helmets once we start to define different armor archetypes in the ‘verse.
Behring Grenade Launcher & Behring BR2 Shotgun
Ever since I have been directing weapons, we have been trying to make sure that every weapon we add to the game has a unique purpose or playstyle that it suits. Currently, we already have several live shotguns that are deadly when up-close-and-personal but ineffective beyond that. With Behring being a manufacturer that we have identified as being middle of the road when it comes to damage, fire rate, and accuracy, we felt the BR2 was our first opportunity to push the range out for a shotgun to provide a bit more oomph in mid-quarter combat without it dominating at close-quarters. While we were happy with the BR2, we are not necessarily happy with shotguns as an overall class as they are outgunned by SMGs and outranged by assault rifles. We will be doing an update to all the shotguns in an upcoming patch to give them greater identity.
The Behring grenade launcher on the other hand presented entirely different problems. A 40mm grenade in real life has a kill radius of about 5m with a casualty radius of about 15m. These are big numbers when you look at our interior spaces and, considering that you can fire several of these over a short space of time, you are left with a pretty powerful weapon. On the one hand we wanted to deliver a weapon that felt heavy and designed to rain down destruction, but on the other hand we didn’t want to massively wreck the balance of FPS combat.
With that aim, we made sure the numbers were slightly less than that of a normal frag grenade for both kill and injury radius. But if I’m being totally honest, I would say the grenade launcher is slightly too powerful in the current game. The main reason is that players have access to an infinite amount of ammo using the PMA, so we had to choose between releasing the weapon as intended or massively nerfing it until the physical inventory comes online. As a team we felt it was more representative of an experience to release the weapon as it’s supposed to work and wait for the other systems, such as physical inventory and physical damage, to balance out its sheer power. Then, players will have to consider how much space they allocate to ammunition and physical damage will cause weapons and armor to lose integrity when they are hit. This means if someone gets blown up by an explosion, a lot of their equipment will be damaged, which lowers the overall value. I have also seen the feedback regarding arming distance and it’s something that we will be working on.
Final Thoughts
If I look back across all the features that the Core Gameplay Pillar delivered for Alpha 3.11, I am happy with the results. However, this doesn’t mean everything went well or if I had that time again, I would do everything the same.
The main thing I think I would change would be how we implemented Force Reactions in the ships. Rather than treat it the same as all the other forces in the game (wind, bullets, etc) – which on the face of it makes sense – I would have designed it specifically around the gravity generator inside the ships. Currently we take the force that is applied to the ship and then directly apply it to the actor through filters depending on the force so that they react accordingly. Instead, I would have rather had the gravity itself react to the force, which would then cause the actor to react. While there would be no difference to the player, I think it would have been a cleaner implementation and be easier to extend the system in the future. For example, when we add gravity generator items, etc.
In the last two quarters we have also delivered two features (Body Dragging and Knockdowns) that would have really benefited from driven ragdoll. Unfortunately, that feature is not being delivered by someone on my teams, so I wouldn’t have necessarily been able to change anything. But looking back, I would have raised more visibility on the benefits of trying to push that feature forward. That is obviously a challenge with working on a 600-person team that is spread across multiple continents and has different priorities across multiple projects. Everyone is trying to deliver the best features/content/tech that they can to the highest possible quality and sometimes the stars don’t align when it comes to priorities. In this case, it is purely on my shoulders due to a lack of communication. As developers, we don’t always get it right when we’re in the thick of things, but hopefully this gives some insight into our processes and how we are always giving it 100% to try and create the best experiences for you to enjoy.
Richard Tyrer
Core Gameplay Director
Environments
Cargo Decks
For this release we were able to introduce the next step in adding complexity to our space stations. The idea for the major stations located around planets is that they would be more than just rest stops; they would have their own facilities dedicated to other services, like cargo.
For the exterior, we introduced new addon components that describe the infrastructure and large racks of containers implying the capacity of the location (which right now is purely visual, in the future we would like to include more interactive elements).
Inside, we wanted to expand the traversal routes. For this, we introduced the idea of a station having a main transit network that connects the various elements of the station together – commercial decks, cargo decks, etc.
For the interior of the cargo deck, there were a few elements we wanted to include. Firstly, for the hub area we wanted to describe a themed logistical experience for the player. This includes a section of a shipping warehouse that, in the future, will be a sandbox for mission content. For the main shopping space, we wanted to incorporate a few elements into one larger shop. Now we can see the cargo drop-off and pickup counter located within a mini logistic sorting office, the ship rental space is located off to the side, and the guild and supplies area is in the corner. Overall, this gives a more diverse experience for the player rather than separating all these elements into separate stores..
Planet Content
For this quarter we were able to keep momentum in updating the planets and moons in the Stanton System with the latest tools and tech we’re using to build out the Pyro System. The start of this was doing a global repainting pass to all planets and moons. Fundamentally, this painting process drives a lot of the latest features in how we’re unifying objects, so to get this into the game we needed to bite the bullet and do the first pass over everything. In the last patch, we introduced the new heightmaps, and now the new painting pass will take advantage of all this new data.
The second element we were able to introduce was a global improvement to all our geology packs. We now have the ability to specify terrain colour pickup for assets which will enable them to procedurally match the colour of the terrain or bedrock. Also, we were able to add asset tessellation and displacement on a per-object basis, which means we can assign heightmaps to assets that drive the displacement parameters. In a nutshell, this means when the player gets close to an asset it should be considerably higher in geometry resolution, giving a complex silhouette read.
Lastly, we replaced all of our terrain shaders with scanned data. This is something we’ve been looking into for some time as the quality of the results was extremely high, but with some of the latest tech, we were able to implement it into our pipeline. We recreated over 70 base shaders by combining and mixing the scanned data together to get the results we wanted. In the future, we have ambitions to set up dedicated scanning equipment to process our own data, which we’ll gather from field trips. We want to ensure we can create a diverse and wonderful palette for future Star Citizen locations.
Final Thoughts
We were able to introduce a lot of new tech in this release, as well as start to show the second round of polish updates on the planet surfaces. Also, with the introduction of scanned data for our surfaces, we saw a substantial jump in quality. However, some of the global painting passes were not as detailed and involved as we would have liked. This is mainly due to time restraints in the quarter. Some of the geology surfacing with the new libraries could be more appropriate to the biome/region also.
For cargo decks, we should have foreseen the disconnect between the interior and exterior when separating out the commercial decks. To improve the experience and help give context to the player we would like this transit network to be physicalized in the future. This will provide visibility out from the transit cab to the exterior of the station as it moves towards its destination.
Ian Leyland
Star Citizen Art Director
Design
Armistice Zones
The Armistice Zone relaxations are the first step in removing all arbitrary restrictions from the game, as and when we have the capability to properly defend and police the various areas of the game. This was possible at the rest stops because as well as reusing the existing size-4 turrets and size-6 sentries, we created an all-new size-10 turret. Together, these are capable of dealing with any ship planned to be in the game. And rather than impose yet another arbitrary restriction, we made the defenses fully destructible, though their respawn time is very swift at 5 minutes. This respawn system will be developed further in the future to likely rely on repair.
In concert with the defenses, we added the first iteration of a security response system which, while still quite simplistic, adds up the CrimeStats of all players in the area (known internally as “heat”) and spawns security ships of increasing numbers and strength in response. The system responds quickly to increases in an area’s heat by spawning in new ships and despawning out weaker ships they replace. The system responds slower to the killing of its members (should the heat not be raised by this) and slower still to decreases in heat. We will develop this system further in the future to also take into account the ships that players are using and the aggression shown.
We will roll this out across other locations like outposts, though Grim HEX will need a more complex solution as the defenses there should only respond to crimes committed in its jurisdiction and not in others. Olisar will remain an aberration as it is a legacy location that cannot support an Armistice Zone of the radius required.
The Live Team had to be extremely vigilant and quick to react to issues given the short time that Alpha 3.11 was running in the PTU. One example of an issue we noticed was players stealing the sentries by swallowing them in the cargo bay of their 890 Jumps and flying off with them. We rectified this by self-destructing sentries taken away from the area and respawning them. Another example is that while the security response was capable of quickly spawning ships on local severs, on a live server it was not. To try and improve this we reduced the thresholds that the system responded to in order to reduce the number of spawns requested.
We have seen videos of many players teaming up to overrun a rest stop and hold it for a long time despite the defenses and security response. Because of this, the moment the Idris became available, we added it to the top level of the response system, so we’re hopeful that those players would struggle to replicate this in the not too distant future.
Final Thoughts
Moving forward, we also plan to relax the arbitrary limitations found in interiors, again starting at the rest stops. We are already well underway with a spawn closet system that will allow us to spawn the guards necessary to police the area. As well as this, we are working on a security network that will know whether players have the right to be in certain areas and enable cameras, turrets, and guards to respond to trespassers, those with CrimeStats, or those in the process of committing crimes.
Luke Pressley
Lead Designer
See you in the ‘Verse!
We believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we’re committed to transparent development and will continue to provide quarterly patch postmortems going forward.
On October 8, 2020, we launched Alpha 3.11 High Impact, which introduced a number of new features and changes, including cargo decks, force reactions, and the first stage of the wider Armistice Zone removal. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. Vehicle Team
The Vehicle Pillar had a much lighter quarter with Alpha 3.11 compared to the bumper delivery in Alpha 3.10, but what we delivered hopefully had a big impact on the gameplay experience.
Origin 100 Series
The Vehicle Content Team delivered the Origin 100 Series in Alpha 3.11, comprising of the 100i, 125a, and 135c. The 100 Series adds an alternative starter ship to the game as well as a light fighter and light cargo hauler. These are fantastic little ships for new players to start their Star Citizen journey with and provide the ability to tackle a wide range of missions and explore the far reaches of the ‘verse. Missiles & Countermeasures
The missile and countermeasure gameplay had been in various states over the years and was never truly enjoyable from the aggressor or defender side. We’re aiming to ultimately fix that with Missile Operator Mode, but until that is delivered, we decided to spend the time implementing fixes and iterations to the gameplay to provide a taste of what that feature will deliver. The main issues with the missiles prior to Alpha 3.11 were as follows: Countermeasures would act only on IR missiles (flares) and EM missiles (chaff)
Only flares worked (sometimes and highly server-dependant)
There were no countermeasures available to spoof CS missiles
Firing missiles was extremely easy, defending against missiles was extremely hard
First, we investigated why only flares would work and chaff wouldn’t. The issue was a combination of incorrect setup data in some ships, incorrect data in some countermeasures and missiles, and a now-redundant workaround originally created for a specific SQ42 level that had knock-ons game-wide.
Once we fixed those issues, we recognized that the signature system has two distinct ways of modifying signals – either creating a strong signal or dampening all signals around. We decided to embrace that difference instead of requiring pilots to play “whack-a-mole” by choosing the “right” countermeasure for the “right” missile type whilst under the stress of having a few seconds to decide before impact. With that in mind, we did some playtests with the following changes: Flares would act on all missile types
Chaff would be turned into a noise field, dampening all signatures around the field
Right away, the first gameplay tests proved that this was a much more engaging way to defend against missiles. We then went ahead and updated the HUD elements of the missile warning system, re-added a countermeasure widget, and updated the keybinds to allow direct launching for each countermeasure type. The UI and VFX teams then jumped in and beautified everything, replacing the effects and also fixing a couple of VFX related bugs (like countermeasures being invisible in the PU).
One future addition that we couldn’t do in time for Alpha 3.11 was to change the names of “flares” and “chaff”. Both names are very common for flight sim communities, but we still want to rename them to make it clear that Star Citizen uses different concepts for defending against missiles. This will require us to record new VO lines to update ship computer voices. Each vehicle is only allowed four locks at a time
Only one missile can launch per rack at a time
Only one missile type (IR/EM/CS) can launch at a time
Missiles lose lock outside of their locking angle
Once we had these measures in, the missile experience notably improved in early testing. The spamming of missiles was significantly reduced, and the meta shifted towards ships getting very close to each other and firing missiles at distances where the defender would not even get a missile warning before impact. As a result of this undesirable change, we introduced minimum and maximum lock ranges. This notably stretched the missile gameplay out of gun range, allowing missile-focussed ships to loiter at the edge of combat as designed while dedicated gunfighters would get in closer. This also allowed us to increase the locking angle of smaller missiles so that ships like the Constellation (that do not fire missiles forward but slightly off-angle) were viable to use missiles again.
A lot of these changes (especially to the missiles) are temporary to give a better experience until Missile Operator Mode is ready, which will change the behaviour again and/or remove certain aspects when it is implemented. Final Thoughts
The overall goal we want to achieve in the missile gameplay loop is to make both employing missiles and defending against missiles deeper and more rewarding, with its own “slot” in the combat environment. Missiles are not supposed to be an alternative to guns but tactical weapons, and the use of them should be a conscious decision with consequences. We also want to give special missile boats, like the Talon Shrike or Freelancer MIS, an edge when it comes to employing ordnance for the same reason. Those ships will excel in offensive missile gameplay though have obvious drawbacks in other categories. So, there will be more iterations on countermeasures and missile gameplay in the next couple of releases. For the time being though, we’re quite happy the missile experience stepped away from the frustrations of previous releases.
John Crewe
Vehicle Director
Technology
Canvas Decal System
For Alpha 3.11, the Graphics Team delivered underlying rendering tech to help power the ‘canvas decal’ system, which leverages the Building Blocks system to create decal textures at runtime. These decals can be used for signposting, on clothing, or even the signage on vehicles. The advantage of the decals being created at runtime is that we can use game data such as the player’s name or even have the content translated to the language the game is being played in.
To make this feature scalable for wider use in the PU, the system is tightly coupled with the texture streaming system, such that the dynamic textures are ‘streamed in’ using the same logic as standard textures, which ensures we always maintain a fixed memory budget. This streaming logic ensures we can automatically run the same feature set on low-spec machines by carefully load-balancing texture resolutions on the fly, but also allows us to push the texture resolution as high as possible on more powerful machines. Integrating the canvas decals into texture streaming resulted in several crashes in the PTU that were very difficult to track down and took a lot of time to resolve. As a result, we wrote some documentation to help future programmers understand the complexities of the texture streaming system, which will be especially important as we plan to generalize the code and use it for mesh streaming too. Planet Tech
On the planet-tech side, we added several features, including improvements to planet tools. This includes new painting brushes, revamped UI, and merged ground layer and object presets to make it even faster to paint planets. Utilising the new planetary painting tools, the Environment Art Team went through all planets and moons in the Stanton System and repainted the ground surfaces and object presets. This also futureproofs us and allows us to take advantage of new tech in existing locations. On a per-object basis, we are now able to support HW tessellation displacement on geology distributed across terrain to give it a more detailed and organic appearance. There were also several ocean and water related improvements, including ground cover buoyancy, which we will continue to expand upon in the future, as there wasn’t enough time during this release cycle to introduce larger floating objects.
A lot of time in the past few months was dedicated towards continued research and development of the atmosphere and cloud renderer, including the planet atmosphere unified raymarcher. We will go into more detail once the system becomes available. For now, let’s just say we worked on various algorithms to allow raymarching at lower-than-screen resolution and denoise and upsample the results to full resolution to improve the performance of costly raymarching operations. These are combined with reprojection techniques and the bundling of raymarch requests for pixels to be updated each frame to further improve performance. Additionally, our existing multiscatter solution now supports a significantly higher number of scattering orders, which will be important for very dense atmospheres. BTW, we’re now in the very early days of volumetric cloud rendering R&D…
Almost a byproduct of this work, we made various improvements to the existing atmosphere rendering technology. First and foremost several long-standing artifacts, such as false color rendering in twilight near the atmosphere top along with very prominent halos around the silhouette of a planet’s dark side, have been addressed. The generation of lookup tables now uses a better-suited method to generate sample locations for numerical integration over (hemi)spheres. That and other numerical precision improvements led to more accurate results in those tables at reduced computational overhead. We didn’t stop there, however, and implemented additional visual improvements for you to hopefully enjoy soon. One of them includes evaluating how much of the sun’s disc is visible when computing how much sunlight reaches point x in-atmosphere. This evaluation is fully integrated into the entire atmosphere lighting system and impacts direct and indirect lighting. Moreover, we added support for an absorption layer. Among other things, this allows us to add an ozone layer to Earth-like planets that emphasizes the blueness of the sky and enables better shading in twilight (removing yellow tint). We now also incorporate IRL extraterrestrial sun radiometry data when running the light simulation instead of assuming a “pure white” light source as well as an approximate conversion from spectral radiance (the result of the atmosphere lighting simulation) to luminance (used to light the scene in a traditional sense). Lastly, we improved the evaluation of sun radiance received by points outside the planet’s atmosphere. It now casts twilight due to atmospheric scattering and the impact of the sun’s angular radius onto objects in a planet’s penumbra region. This should add a nice touch to capital ships or moons orbiting planets. Engine
On the engine side, several improvements were made. We updated our compiler toolchain to VS 2019, which will allow for faster compile and link times. Moreover, we’ve added support for Intel SPMD Program Compiler (ISPC). This will allow us to write target-agnostic SSE optimized code (think HLSL) for heavy duty CPU compute jobs and will fully utilize CPU capabilities on each individual machine that the code runs on. Several code paths in physics, the 3D engine, and the zone system are in the process of being ported. And, we have another compiler optimization in store for you. AVX code generation support for clients was previously enabled and should hit the public servers in the coming Alpha 3.12 release.
Regarding server and client memory usage, we spent a good deal of time further refining our tracking tools to ensure we have good visibility on where we spend memory. We’re now also able to properly track memory usage in third-party libraries that either don’t allow us to reroute memory allocation through our system or haven’t been updated yet to do so. We still plan to get a bit more visibility on client-side video memory allocations on the driver level (below the level we can currently track as an application using the GPU). As a result of these improvements, ongoing investigations, and tracking, a few critical memory leaks were fixed for release.
Throughout Alpha 3.11 production, the Core Engine Team was mostly focused on features for later releases, like the Gen12 Renderer. However, a very large bug was fixed, which caused all our objects on clients to unload way earlier than we intended. Objects on clients should now stay streamed for noticeably larger distances. Audio
For audio tech, we updated the Wwise version to 2019.2.4, which fixed several issues. As part of this endeavour we reworked memory management within the audio system, going from a group of memory pools to a single pool. This allows us to deal more easily with the many different situations that Star Citizen presents by allocating memory where it is needed, when it is needed. We spent a lot of time revisiting our voice budgets to improve the overall experience and to allow players to hear more of what’s going on in the game. Weapon fire support, particularly at long distance, was improved and several issues with audio fire rates and weapon volumes were fixed. Canvas Slicing
This quarter the UI-Tech team has been working on a system called the Canvas Slicer. This is a sub-system of Building Blocks which will allow the UI designers to place slices of 2D UI in 3D space. Normally, when we draw 2D UI, it gets rendered to a texture and then that texture is applied to geometry such as a monitor panel or data-pad. With the Canvas Slicer, we create the geometry at any position in 3D-space at runtime and draw the 2D UI directly onto it. This means we will be able to produce interesting layered UI, such as holographic ship HUDs and helmet displays. Tooltips
We have also started designing our tooltips system for Building Blocks. On the surface, this looked like a simple system to implement but the requirements to ensure it is super flexible have meant we’ve got quite a lot to think about before we start implementation.
Marco Corbetta
VP of Technology
Core Gameplay
External Inventory
External Inventory is the first iteration of our grid-based inventory interface that allows players to manage their FPS commodities between their backpack, chest, and leg pockets. As it says in the name, the External Inventory also allows players to directly interact with other storage containers in the world and drag and drop items between them. In Alpha 3.11, this is only enabled for the Greycat ROC storage compartment so players can manage their FPS mineables. But, in the future and once we realise true item storage (underpinned by iCache), this will allow players to store items in compartments, crates, and other such external inventories.
While on the face of it, a new inventory UI and being able to drag and drop items between storage containers may sound simple, we had to overcome several creative and technical challenges. The main creative challenges revolved around having an interface that felt tactile and accessible to use without just feeling like a standard 2D interface that you see in most RPGs. This wasn’t because those inventories are bad, more that we didn’t want players performing inventory Tetris to manage their items; we wanted players to freely move items between storage containers without having to worry about where they dropped the item or if another item was in the way. We were able to achieve the first iteration of this using our Building Blocks technology, which stores the items as a list rather than a 2D grid. This means items fluidly move around your cursor as you drag objects between containers. We still want to further improve on the overall feel, but the team is happy with the initial outing.
While Building Blocks allowed us to deliver on the creative aspects of the design, it also provided the main technical challenge. As the technology is still being developed, it means it doesn’t always support things that you need to deliver a feature. In the case of External Inventory, we wanted the UI to feel diegetic and 3D even though it is not. This meant we wanted all the icons to be holographic, like they were being displayed in AR directly in front of your eyes. Unfortunately, our 3D icons could only support a limited shader which meant we lost a lot of material detail from the items being displayed. At this point we could have delayed the feature, but the team and I felt it was important for us to go live and get as much feedback as we could between now and a true physical inventory. We will definitely be upgrading that shader in an upcoming patch. Force Reactions
At its core, Force Reactions is a system developed to simulate what a character would do when impacted by a force, whether that is a strong gust of wind or a bullet penetrating their shoulder. It can be split into three levels of impacts: Low impact: twitches, flinches, and leans
Medium impact: staggers
High impact: knockdowns
In Alpha 3.10, we delivered the first iteration of low-impact reactions with the procedural twitches in FPS combat and leaning during sustained winds. In Alpha 3.11, we added more ‘feels’ to the twitches with additional camera and weapon reactions and our first iteration of knockdowns, with the intention for staggers to come later.
The biggest challenge for this system was that it needed to be truly systemic as forces can come from a lot of different places, not just bullets. For this, we broke down the forces into three main categories: Direct forces: anything that physically impacts the character, like a box or bullet
Indirect forces: the force you receive when your ship gets rammed or from a gust of wind
Sustained forces: where a force is constantly applied, such a g-force or wind
This meant we could compartmentalise different forces with different scales and allow the designers to balance the character’s reaction accordingly, as the forces of being hit by a box compared to the acceleration of a ship in space to 1000m/s are vastly different. While low-impact reactions do not take away any player control, we were very cognizant of the fact that knockdowns would. We spent a lot of time making sure the knockdown animations were very reactive to player control as soon as their character hit the ground. We also implemented a skill-based system that meant if you tried to ADS before touching the floor you would trigger a faster recovery animation, meaning you could get back into the action quicker.
Force Reactions in Alpha 3.11 was our second delivery and will be by no means our last. We are actively working on medium-impact reactions and will be constantly reviewing and tweaking the balance going forward, especially in FPS combat.
Throwing T1
Throwing grenades or other objects has always been a bit inconsistent and is even more disappointing when you think you have that perfect multi-kill opportunity for the grenade to just whimper a few feet from you. So, the first thing we wanted to achieve with T1 was to make throwing much more reliable, so that the object you throw (whether a grenade or other object) goes where you expect it to go. The second biggest objective, which is a critical pre-requisite for the physical inventory, was for the throw system to be able to interact and co-exist with the carriable system.
In Alpha 3.10, if you picked up a grenade from the floor and then tried to throw it, there was no way for you to pull the pin. Also, if you pressed the ‘Throw Grenade’ hotkey, you would drop the grenade in your hand and pull a new one from your suit. Obviously, this is not the intended behaviour and was a major reason why we changed throwing to come from an equipped state (i.e. holding the grenade in your hand) rather than directly from your suit. This system will also allow us to deliver gadgets and deployables in the future.
As part of T1, we also added a UI ‘throw arc’ that allows you to see the trajectory of the grenade. While currently this is enabled for all helmets, it will only be accessible from combat helmets once we start to define different armor archetypes in the ‘verse.
Behring Grenade Launcher & Behring BR2 Shotgun
Ever since I have been directing weapons, we have been trying to make sure that every weapon we add to the game has a unique purpose or playstyle that it suits. Currently, we already have several live shotguns that are deadly when up-close-and-personal but ineffective beyond that. With Behring being a manufacturer that we have identified as being middle of the road when it comes to damage, fire rate, and accuracy, we felt the BR2 was our first opportunity to push the range out for a shotgun to provide a bit more oomph in mid-quarter combat without it dominating at close-quarters. While we were happy with the BR2, we are not necessarily happy with shotguns as an overall class as they are outgunned by SMGs and outranged by assault rifles. We will be doing an update to all the shotguns in an upcoming patch to give them greater identity.
The Behring grenade launcher on the other hand presented entirely different problems. A 40mm grenade in real life has a kill radius of about 5m with a casualty radius of about 15m. These are big numbers when you look at our interior spaces and, considering that you can fire several of these over a short space of time, you are left with a pretty powerful weapon. On the one hand we wanted to deliver a weapon that felt heavy and designed to rain down destruction, but on the other hand we didn’t want to massively wreck the balance of FPS combat.
With that aim, we made sure the numbers were slightly less than that of a normal frag grenade for both kill and injury radius. But if I’m being totally honest, I would say the grenade launcher is slightly too powerful in the current game. The main reason is that players have access to an infinite amount of ammo using the PMA, so we had to choose between releasing the weapon as intended or massively nerfing it until the physical inventory comes online. As a team we felt it was more representative of an experience to release the weapon as it’s supposed to work and wait for the other systems, such as physical inventory and physical damage, to balance out its sheer power. Then, players will have to consider how much space they allocate to ammunition and physical damage will cause weapons and armor to lose integrity when they are hit. This means if someone gets blown up by an explosion, a lot of their equipment will be damaged, which lowers the overall value. I have also seen the feedback regarding arming distance and it’s something that we will be working on.
Final Thoughts
If I look back across all the features that the Core Gameplay Pillar delivered for Alpha 3.11, I am happy with the results. However, this doesn’t mean everything went well or if I had that time again, I would do everything the same.
The main thing I think I would change would be how we implemented Force Reactions in the ships. Rather than treat it the same as all the other forces in the game (wind, bullets, etc) – which on the face of it makes sense – I would have designed it specifically around the gravity generator inside the ships. Currently we take the force that is applied to the ship and then directly apply it to the actor through filters depending on the force so that they react accordingly. Instead, I would have rather had the gravity itself react to the force, which would then cause the actor to react. While there would be no difference to the player, I think it would have been a cleaner implementation and be easier to extend the system in the future. For example, when we add gravity generator items, etc.
In the last two quarters we have also delivered two features (Body Dragging and Knockdowns) that would have really benefited from driven ragdoll. Unfortunately, that feature is not being delivered by someone on my teams, so I wouldn’t have necessarily been able to change anything. But looking back, I would have raised more visibility on the benefits of trying to push that feature forward. That is obviously a challenge with working on a 600-person team that is spread across multiple continents and has different priorities across multiple projects. Everyone is trying to deliver the best features/content/tech that they can to the highest possible quality and sometimes the stars don’t align when it comes to priorities. In this case, it is purely on my shoulders due to a lack of communication. As developers, we don’t always get it right when we’re in the thick of things, but hopefully this gives some insight into our processes and how we are always giving it 100% to try and create the best experiences for you to enjoy.
Richard Tyrer
Core Gameplay Director
Environments
Cargo Decks
For this release we were able to introduce the next step in adding complexity to our space stations. The idea for the major stations located around planets is that they would be more than just rest stops; they would have their own facilities dedicated to other services, like cargo.
For the exterior, we introduced new addon components that describe the infrastructure and large racks of containers implying the capacity of the location (which right now is purely visual, in the future we would like to include more interactive elements).
Inside, we wanted to expand the traversal routes. For this, we introduced the idea of a station having a main transit network that connects the various elements of the station together – commercial decks, cargo decks, etc.
For the interior of the cargo deck, there were a few elements we wanted to include. Firstly, for the hub area we wanted to describe a themed logistical experience for the player. This includes a section of a shipping warehouse that, in the future, will be a sandbox for mission content. For the main shopping space, we wanted to incorporate a few elements into one larger shop. Now we can see the cargo drop-off and pickup counter located within a mini logistic sorting office, the ship rental space is located off to the side, and the guild and supplies area is in the corner. Overall, this gives a more diverse experience for the player rather than separating all these elements into separate stores..
Planet Content
For this quarter we were able to keep momentum in updating the planets and moons in the Stanton System with the latest tools and tech we’re using to build out the Pyro System. The start of this was doing a global repainting pass to all planets and moons. Fundamentally, this painting process drives a lot of the latest features in how we’re unifying objects, so to get this into the game we needed to bite the bullet and do the first pass over everything. In the last patch, we introduced the new heightmaps, and now the new painting pass will take advantage of all this new data.
The second element we were able to introduce was a global improvement to all our geology packs. We now have the ability to specify terrain colour pickup for assets which will enable them to procedurally match the colour of the terrain or bedrock. Also, we were able to add asset tessellation and displacement on a per-object basis, which means we can assign heightmaps to assets that drive the displacement parameters. In a nutshell, this means when the player gets close to an asset it should be considerably higher in geometry resolution, giving a complex silhouette read.
Lastly, we replaced all of our terrain shaders with scanned data. This is something we’ve been looking into for some time as the quality of the results was extremely high, but with some of the latest tech, we were able to implement it into our pipeline. We recreated over 70 base shaders by combining and mixing the scanned data together to get the results we wanted. In the future, we have ambitions to set up dedicated scanning equipment to process our own data, which we’ll gather from field trips. We want to ensure we can create a diverse and wonderful palette for future Star Citizen locations.
Final Thoughts
We were able to introduce a lot of new tech in this release, as well as start to show the second round of polish updates on the planet surfaces. Also, with the introduction of scanned data for our surfaces, we saw a substantial jump in quality. However, some of the global painting passes were not as detailed and involved as we would have liked. This is mainly due to time restraints in the quarter. Some of the geology surfacing with the new libraries could be more appropriate to the biome/region also.
For cargo decks, we should have foreseen the disconnect between the interior and exterior when separating out the commercial decks. To improve the experience and help give context to the player we would like this transit network to be physicalized in the future. This will provide visibility out from the transit cab to the exterior of the station as it moves towards its destination.
Ian Leyland
Star Citizen Art Director
Design
Armistice Zones
The Armistice Zone relaxations are the first step in removing all arbitrary restrictions from the game, as and when we have the capability to properly defend and police the various areas of the game. This was possible at the rest stops because as well as reusing the existing size-4 turrets and size-6 sentries, we created an all-new size-10 turret. Together, these are capable of dealing with any ship planned to be in the game. And rather than impose yet another arbitrary restriction, we made the defenses fully destructible, though their respawn time is very swift at 5 minutes. This respawn system will be developed further in the future to likely rely on repair.
In concert with the defenses, we added the first iteration of a security response system which, while still quite simplistic, adds up the CrimeStats of all players in the area (known internally as “heat”) and spawns security ships of increasing numbers and strength in response. The system responds quickly to increases in an area’s heat by spawning in new ships and despawning out weaker ships they replace. The system responds slower to the killing of its members (should the heat not be raised by this) and slower still to decreases in heat. We will develop this system further in the future to also take into account the ships that players are using and the aggression shown.
We will roll this out across other locations like outposts, though Grim HEX will need a more complex solution as the defenses there should only respond to crimes committed in its jurisdiction and not in others. Olisar will remain an aberration as it is a legacy location that cannot support an Armistice Zone of the radius required.
The Live Team had to be extremely vigilant and quick to react to issues given the short time that Alpha 3.11 was running in the PTU. One example of an issue we noticed was players stealing the sentries by swallowing them in the cargo bay of their 890 Jumps and flying off with them. We rectified this by self-destructing sentries taken away from the area and respawning them. Another example is that while the security response was capable of quickly spawning ships on local severs, on a live server it was not. To try and improve this we reduced the thresholds that the system responded to in order to reduce the number of spawns requested.
We have seen videos of many players teaming up to overrun a rest stop and hold it for a long time despite the defenses and security response. Because of this, the moment the Idris became available, we added it to the top level of the response system, so we’re hopeful that those players would struggle to replicate this in the not too distant future.
Final Thoughts
Moving forward, we also plan to relax the arbitrary limitations found in interiors, again starting at the rest stops. We are already well underway with a spawn closet system that will allow us to spawn the guards necessary to police the area. As well as this, we are working on a security network that will know whether players have the right to be in certain areas and enable cameras, turrets, and guards to respond to trespassers, those with CrimeStats, or those in the process of committing crimes.
Luke Pressley
Lead Designer
See you in the ‘Verse!
We believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we’re committed to transparent development and will continue to provide quarterly patch postmortems going forward.
German
Alpha 3.11 Obduktion
Am 8. Oktober 2020 starteten wir Alpha 3.11 High Impact, das eine Reihe von neuen Features und Änderungen einführte, darunter Frachtdecks, Kraftreaktionen und die erste Stufe der umfassenderen Entfernung der Waffenstillstandszone. Im Folgenden findet ihr eine Obduktion der Senior-Entwickler selbst, die detailliert beschreibt, was geliefert wurde und was sie darüber dachten, wie es gelaufen ist.
Fahrzeug-Team
Die Fahrzeugsäule hatte mit Alpha 3.11 ein viel leichteres Viertel im Vergleich zur Stoßstangenlieferung in Alpha 3.10, aber was wir geliefert haben, hatte hoffentlich einen großen Einfluss auf das Spielerlebnis.
Herkunft 100er Serie
Das Team für Fahrzeuginhalte lieferte die Origin 100 Serie in Alpha 3.11, bestehend aus 100i, 125a und 135c. Die 100er Serie fügt dem Spiel ein alternatives Startschiff sowie einen leichten Jäger und leichten Frachtschlepper hinzu. Dies sind fantastische kleine Schiffe für neue Spieler, mit denen sie ihre Reise als Sternenbürger beginnen können. Sie bieten die Möglichkeit, eine Vielzahl von Missionen zu bewältigen und die Weiten des 'Verses' zu erforschen. Raketen & Gegenmaßnahmen
Das Raketen- und Gegenmaßnahmen-Gameplay war im Laufe der Jahre in verschiedenen Zuständen gewesen und war weder auf der Seite des Angreifers noch auf der Seite des Verteidigers wirklich unterhaltsam. Unser Ziel ist es, dies mit dem Raketenoperator-Modus endgültig zu beheben, aber bis es soweit ist, haben wir beschlossen, die Zeit damit zu verbringen, Korrekturen und Iterationen im Gameplay zu implementieren, um einen Vorgeschmack darauf zu geben, was dieses Feature liefern wird. Die Hauptprobleme mit den Raketen vor Alpha 3.11 waren die folgenden:
Gegenmaßnahmen würden nur auf IR-Raketen (Flares) und EM-Raketen (Chaff) wirken Nur Flares funktionierten (manchmal und stark Server-abhängig) Es gab keine Gegenmaßnahmen für Spoof-CS-Raketen Es war extrem einfach, Raketen abzufeuern, und die Verteidigung gegen Raketen war extrem schwierig
Zuerst untersuchten wir, warum nur Fackeln funktionieren würden und Spreu nicht. Das Problem war eine Kombination aus falschen Setup-Daten bei einigen Schiffen, falschen Daten bei einigen Gegenmaßnahmen und Raketen und einem jetzt redundanten Workaround, der ursprünglich für einen bestimmten SQ42-Level erstellt wurde und das ganze Spiel über angeklopft hat.
Nachdem wir diese Probleme behoben hatten, erkannten wir, dass das Signatursystem zwei verschiedene Möglichkeiten hat, Signale zu modifizieren - entweder ein starkes Signal zu erzeugen oder alle Signale in der Umgebung zu dämpfen. Wir entschieden uns, diesen Unterschied zu nutzen, anstatt von den Piloten zu verlangen, "Maulwurfwaffen" zu spielen, indem wir die "richtige" Gegenmaßnahme für den "richtigen" Raketentyp wählten, während wir unter dem Stress standen, einige Sekunden vor dem Einschlag entscheiden zu müssen. Mit diesem Gedanken im Hinterkopf haben wir einige Spieltests mit den folgenden Änderungen durchgeführt: Fackeln würden auf alle Raketentypen wirken Chaff würde in ein Lärmfeld verwandelt werden, das alle Signaturen um das Feld herum dämpft
Sofort bewiesen die ersten Gameplay-Tests, dass dies eine viel ansprechendere Art der Raketenabwehr ist. Wir haben dann die HUD-Elemente des Raketenwarnsystems aktualisiert, ein Widget für Gegenmaßnahmen hinzugefügt und die Keybinds aktualisiert, um einen direkten Start für jede Art von Gegenmaßnahme zu ermöglichen. Die UI- und VFX-Teams sind dann eingesprungen und haben alles verschönert, die Effekte ersetzt und auch ein paar Fehler im Zusammenhang mit VFX behoben (z.B. dass Gegenmaßnahmen im PU unsichtbar sind).
Ein zukünftiger Zusatz, den wir nicht rechtzeitig für Alpha 3.11 machen konnten, war die Änderung der Namen von "Flares" und "Spreu". Beide Namen sind für Flugsimulationsgemeinschaften sehr gebräuchlich, aber wir wollen sie trotzdem umbenennen, um deutlich zu machen, dass Star Citizen unterschiedliche Konzepte zur Verteidigung gegen Raketen verwendet. Dies wird uns dazu zwingen, neue VO-Zeilen aufzunehmen, um die Schiffscomputerstimmen zu aktualisieren. Jedes Fahrzeug darf nur vier Schlösser gleichzeitig haben Nur eine Rakete kann pro Gestell gleichzeitig starten Nur ein Raketentyp (IR/EM/CS) kann gleichzeitig starten Raketen verlieren außerhalb ihres Verriegelungswinkels
Nachdem wir diese Maßnahmen eingeführt hatten, verbesserte sich das Raketenerlebnis in den ersten Tests deutlich. Das Spamming der Raketen wurde deutlich reduziert und die Meta verlagerte sich in Richtung Schiffe, die sehr nahe aneinander herankommen und Raketen auf Entfernungen abfeuern, bei denen der Verteidiger nicht einmal eine Raketenwarnung vor dem Einschlag erhalten würde. Als Ergebnis dieser unerwünschten Änderung führten wir minimale und maximale Zielreichweiten ein. Dadurch wurde das Raketen-Gameplay deutlich über die Reichweite der Geschütze hinaus ausgedehnt, so dass raketenfokussierte Schiffe wie geplant am Rand des Kampfes herumlungern konnten, während engagierte Kämpfer näher an sie herankamen. Dies ermöglichte es uns auch, den Verriegelungswinkel kleinerer Raketen zu erhöhen, so dass Schiffe wie die Constellation (die Raketen nicht nach vorne, sondern leicht aus dem Winkel feuern) wieder Raketen einsetzen konnten.
Viele dieser Änderungen (besonders an den Raketen) sind vorübergehend, um ein besseres Erlebnis zu bieten, bis der Raketenoperator-Modus bereit ist, der das Verhalten wieder ändert und/oder bestimmte Aspekte entfernt, wenn er implementiert wird. Abschließende Gedanken
Das übergeordnete Ziel, das wir im Raketenspiel erreichen wollen, ist es, sowohl den Einsatz von Raketen als auch die Verteidigung gegen Raketen tiefer und lohnender zu machen, mit einem eigenen "Slot" in der Kampfumgebung. Raketen sollen keine Alternative zu Gewehren sein, sondern taktische Waffen, und der Einsatz von Raketen soll eine bewusste Entscheidung mit Konsequenzen sein. Aus dem gleichen Grund wollen wir auch speziellen Raketenbooten, wie der Talonwürger oder dem Freelancer MIS, einen Vorteil verschaffen, wenn es darum geht, Munition einzusetzen. Diese Schiffe werden sich im offensiven Raketen-Gameplay auszeichnen, haben aber in anderen Kategorien offensichtliche Nachteile. Daher wird es in den nächsten paar Versionen mehr Iterationen zu Gegenmaßnahmen und Raketenspiel geben. Im Moment sind wir jedoch sehr froh, dass die Raketenerfahrung die Frustrationen der vorherigen Versionen hinter sich gelassen hat.
John Crewe
Fahrzeug-Direktor
Technik
Leinwand-Aufkleber-System
Für Alpha 3.11 lieferte das Grafikteam die zugrundeliegende Rendering-Technologie, um das 'Canvas Decal'-System zu unterstützen, das das Building Blocks-System nutzt, um Decal-Texturen zur Laufzeit zu erstellen. Diese Abziehbilder können für die Beschilderung, auf der Kleidung oder sogar für die Beschilderung von Fahrzeugen verwendet werden. Der Vorteil der Abziehbilder, die zur Laufzeit erstellt werden, ist, dass wir Spieldaten wie den Namen des Spielers verwenden oder sogar den Inhalt in die Sprache übersetzen lassen können, in der das Spiel gespielt wird.
Um dieses Feature für eine breitere Verwendung in der PU skalierbar zu machen, ist das System eng mit dem Textur-Streaming-System gekoppelt, so dass die dynamischen Texturen mit der gleichen Logik wie Standardtexturen 'hereingestreamt' werden, was sicherstellt, dass wir immer ein festes Speicherbudget haben. Diese Streaminglogik stellt sicher, dass wir die gleichen Funktionen automatisch auch auf Maschinen mit niedriger Spezifikation ausführen können, indem die Texturauflösungen während des Streamens sorgfältig ausbalanciert werden, erlaubt es uns aber auch, die Texturauflösung auf leistungsstärkeren Maschinen so hoch wie möglich zu pushen. Die Integration der Canvas-Aufkleber in das Textur-Streaming führte zu mehreren Abstürzen in der PTU, die sehr schwer aufzuspüren waren und viel Zeit benötigten, um sie zu lösen. Infolgedessen haben wir einige Dokumentationen geschrieben, um zukünftigen Programmierern zu helfen, die Komplexität des Textur-Streaming-Systems zu verstehen, was besonders wichtig sein wird, da wir planen, den Code zu verallgemeinern und ihn auch für das Mesh-Streaming zu verwenden. Planeten-Technologie
Auf der Seite der Planetentechnologie haben wir einige Features hinzugefügt, einschließlich Verbesserungen an den Planetenwerkzeugen. Dazu gehören neue Malpinsel, eine überarbeitete Benutzeroberfläche und kombinierte Bodenebenen- und Objektvoreinstellungen, um das Malen von Planeten noch schneller zu machen. Mit den neuen Malwerkzeugen für Planeten ging das Umweltkunst-Team durch alle Planeten und Monde im Stanton-System und malte die Bodenflächen und Objektvoreinstellungen neu. Dies macht uns auch zukunftssicher und erlaubt uns, die Vorteile der neuen Technologie an bestehenden Orten zu nutzen. Auf einer Pro-Objekt-Basis sind wir nun in der Lage, die Verschiebung der HW-Tessellation auf der über das Gelände verteilten Geologie zu unterstützen, um ihr ein detaillierteres und organischeres Aussehen zu geben. Es gab auch einige Verbesserungen im Zusammenhang mit Ozeanen und Wasser, einschließlich des Auftriebs der Bodendecke, die wir in Zukunft weiter ausbauen werden, da während dieses Release-Zyklus nicht genug Zeit war, um größere schwimmende Objekte einzuführen.
In den letzten Monaten wurde viel Zeit für die weitere Erforschung und Entwicklung der Atmosphäre und des Wolkenrenderers, einschließlich des vereinheitlichten Raymarchers für die Planetenatmosphäre, aufgewendet. Wir werden mehr ins Detail gehen, sobald das System verfügbar ist. Für den Moment sagen wir einfach, dass wir an verschiedenen Algorithmen gearbeitet haben, um das Raymarchen bei einer Auflösung unter dem Bildschirm zu ermöglichen und das Rauschen und Upsampling der Ergebnisse auf die volle Auflösung zu reduzieren, um die Leistung der kostspieligen Raymarching-Vorgänge zu verbessern. Diese werden mit Reprojektionstechniken und der Bündelung von Raymarching-Anfragen für Pixel, die bei jedem Frame aktualisiert werden sollen, kombiniert, um die Leistung weiter zu verbessern. Zusätzlich unterstützt unsere bestehende Multiscatter-Lösung nun eine deutlich höhere Anzahl an Streuaufträgen, was für sehr dichte Atmosphären wichtig sein wird. Übrigens befinden wir uns jetzt in den allerersten Tagen der volumetrischen Wolken-Rendering-Forschung...
Fast als Nebenprodukt dieser Arbeit haben wir verschiedene Verbesserungen an der bestehenden Atmosphären-Rendering-Technologie vorgenommen. Zuallererst wurden einige seit langem bestehende Artefakte, wie z.B. die Falschfarbenwiedergabe in der Dämmerung in der Nähe der Atmosphärenoberseite zusammen mit sehr markanten Halos um die Silhouette der dunklen Seite eines Planeten, angesprochen. Die Generierung von Nachschlagetabellen verwendet nun eine besser geeignete Methode, um Beispielstandorte für die numerische Integration über (Hemi-)Sphären zu generieren. Dies und andere Verbesserungen der numerischen Präzision führten zu genaueren Ergebnissen in diesen Tabellen bei reduziertem Rechenaufwand. Doch damit nicht genug, wir haben noch weitere visuelle Verbesserungen implementiert, die ihr hoffentlich bald genießen werdet. Eine davon ist die Auswertung, wie viel von der Sonnenscheibe sichtbar ist, wenn man berechnet, wie viel Sonnenlicht den Punkt x in der Atmosphäre erreicht. Diese Auswertung ist vollständig in das gesamte Beleuchtungssystem der Atmosphäre integriert und wirkt sich auf die direkte und indirekte Beleuchtung aus. Außerdem haben wir Unterstützung für eine Absorptionsschicht hinzugefügt. Dies erlaubt uns unter anderem, den erdähnlichen Planeten eine Ozonschicht hinzuzufügen, die die Bläue des Himmels betont und eine bessere Schattierung in der Dämmerung ermöglicht (Entfernung der gelben Tönung). Wir beziehen nun auch IRL-Radiometriedaten der extraterrestrischen Sonne mit ein, wenn wir die Lichtsimulation durchführen, anstatt von einer "rein weißen" Lichtquelle auszugehen, sowie eine ungefähre Umrechnung von spektraler Strahldichte (das Ergebnis der Atmosphärenbeleuchtungssimulation) in Leuchtdichte (die im traditionellen Sinne zur Beleuchtung der Szene verwendet wird). Schließlich haben wir die Auswertung der Sonnenstrahlung verbessert, die von Punkten außerhalb der Atmosphäre des Planeten empfangen wird. Sie wirft nun Dämmerungslicht aufgrund der atmosphärischen Streuung und dem Aufprall des Winkelradius der Sonne auf Objekte in der Halbschattenregion eines Planeten. Dies sollte einen netten Touch für Großkampfschiffe oder Monde, die Planeten umkreisen, hinzufügen. Triebwerk
Auf der Motorseite wurden einige Verbesserungen vorgenommen. Wir haben unsere Compiler-Toolchain auf VS 2019 aktualisiert, was schnellere Kompilier- und Linkzeiten ermöglichen wird. Außerdem haben wir Unterstützung für den Intel SPMD Program Compiler (ISPC) hinzugefügt. Dies wird es uns ermöglichen, zielgerichteten, SSE-optimierten Code (man denke an HLSL) für Hochleistungs-CPU-Compute-Jobs zu schreiben und die CPU-Fähigkeiten auf jeder einzelnen Maschine, auf der der Code läuft, voll auszunutzen. Mehrere Codepfade in der Physik, der 3D-Engine und dem Zonensystem sind dabei, portiert zu werden. Und, wir haben noch eine weitere Compiler-Optimierung für euch auf Lager. Die Unterstützung für die AVX-Codegenerierung für Clients wurde bereits aktiviert und sollte in der kommenden Alpha 3.12-Version auf die öffentlichen Server kommen.
Was die Speicherauslastung der Server und Clients betrifft, haben wir viel Zeit damit verbracht, unsere Tracking-Tools weiter zu verfeinern, um sicherzustellen, dass wir eine gute Übersicht darüber haben, wo wir Speicher verbrauchen. Wir sind jetzt auch in der Lage, die Speichernutzung in Bibliotheken von Drittanbietern korrekt zu verfolgen, die es uns entweder nicht erlauben, die Speicherzuweisung durch unser System umzuleiten, oder die noch nicht aktualisiert wurden, um dies zu tun. Wir planen immer noch, etwas mehr Sichtbarkeit bei der clientseitigen Video-Speicherzuweisung auf der Treiberebene zu erhalten (unterhalb der Ebene, die wir derzeit als Anwendung mit der GPU verfolgen können). Als Ergebnis dieser Verbesserungen, der laufenden Untersuchungen und des Trackings wurden einige kritische Speicherlecks zur Veröffentlichung behoben.
Während der gesamten Alpha 3.11 Produktion konzentrierte sich das Core Engine Team hauptsächlich auf Features für spätere Versionen, wie den Gen12 Renderer. Allerdings wurde ein sehr großer Fehler behoben, der dazu führte, dass alle unsere Objekte auf den Clients viel früher als geplant entladen wurden. Objekte auf den Clients sollten nun für deutlich größere Entfernungen gestreamt bleiben. Audio
Für die Audiotechnik haben wir die Wise-Version auf 2019.2.4 aktualisiert, wodurch mehrere Probleme behoben wurden. Als Teil dieses Unterfangens haben wir die Speicherverwaltung innerhalb des Audiosystems überarbeitet, indem wir von einer Gruppe von Speicherpools zu einem einzigen Pool übergegangen sind. Dadurch können wir mit den vielen verschiedenen Situationen, die der Sternenbürger präsentiert, leichter umgehen, indem wir Speicher dort zuweisen, wo er gebraucht wird, wenn er gebraucht wird. Wir haben viel Zeit damit verbracht, unsere Voice-Budgets zu überdenken, um das Gesamterlebnis zu verbessern und den Spielern zu ermöglichen, mehr von dem zu hören, was im Spiel vor sich geht. Die Unterstützung für Waffenfeuer, insbesondere auf große Entfernungen, wurde verbessert und mehrere Probleme mit der Audio-Feuerrate und der Waffenlautstärke wurden behoben. Leinwand-Slicing
Dieses Quartal hat das UI-Tech Team an einem System gearbeitet, das Canvas Slicer genannt wird. Dabei handelt es sich um ein Untersystem von Building Blocks, das es den UI-Designern ermöglichen wird, Scheiben von 2D-UI in 3D-Raum zu platzieren. Normalerweise, wenn wir ein 2D UI zeichnen, wird es zu einer Textur gerendert und dann wird diese Textur auf eine Geometrie, wie z.B. ein Monitor Panel oder ein Data-Pad, angewendet. Mit dem Canvas Slicer erstellen wir die Geometrie an einer beliebigen Position im 3D-Raum zur Laufzeit und zeichnen die 2D-UI direkt darauf. Das bedeutet, dass wir in der Lage sein werden, interessante UI-Layer zu erzeugen, wie z.B. holografische Schiffs HUDs und Helmdisplays. Tooltipps
Wir haben auch begonnen, unser Tooltips-System für Building Blocks zu entwerfen. Oberflächlich gesehen sah es nach einem einfach zu implementierenden System aus, aber die Anforderungen, um sicherzustellen, dass es superflexibel ist, haben dazu geführt, dass wir über eine ganze Menge nachdenken müssen, bevor wir mit der Implementierung beginnen.
Marco Corbetta
VP der Technologie
Kern-Gameplay
Externes Inventar
Externes Inventar ist die erste Iteration unseres gitterbasierten Inventarinterfaces, mit dem Spieler ihre FPS-Waren zwischen Rucksack-, Brust- und Beintaschen verwalten können. Wie der Name schon sagt, können Spieler mit dem Externen Inventar auch direkt mit anderen Lagerbehältern in der Welt interagieren und Gegenstände zwischen ihnen hin- und herziehen. In Alpha 3.11 ist dies nur für das Greycat ROC-Lagerfach aktiviert, damit Spieler ihre FPS-Minengüter verwalten können. Aber in der Zukunft und sobald wir eine echte Item-Lagerung (unterstützt durch iCache) realisieren, wird dies Spielern erlauben, Gegenstände in Fächern, Kisten und anderen solchen externen Inventaren zu lagern.
Auch wenn eine neue Inventar-UI und die Möglichkeit, Gegenstände per Drag & Drop zwischen den Lagercontainern hin- und herzuziehen, auf den ersten Blick einfach klingen mag, mussten wir einige kreative und technische Herausforderungen meistern. Die wichtigsten kreativen Herausforderungen drehten sich darum, ein Interface zu haben, das sich taktil und zugänglich anfühlt, ohne sich einfach nur wie ein Standard 2D Interface anzufühlen, das man in den meisten RPGs sieht. Das lag nicht daran, dass diese Inventare schlecht sind, vielmehr wollten wir nicht, dass Spieler, die Inventar-Tetris durchführen, ihre Gegenstände verwalten; wir wollten, dass die Spieler Gegenstände frei zwischen den Lagercontainern bewegen können, ohne sich Gedanken darüber machen zu müssen, wo sie den Gegenstand fallen lassen oder ob ein anderer Gegenstand im Weg ist. Die erste Iteration davon konnten wir mit unserer Building Blocks-Technologie erreichen, die die Gegenstände als Liste und nicht als 2D-Raster speichert. Das bedeutet, dass sich die Gegenstände fließend um deinen Cursor bewegen, wenn du Objekte zwischen den Containern hin- und herziehst. Wir wollen das Gesamtgefühl noch weiter verbessern, aber das Team ist mit der ersten Iteration zufrieden.
Mit Building Blocks konnten wir zwar die kreativen Aspekte des Designs umsetzen, aber es stellte auch die größte technische Herausforderung dar. Da sich die Technologie noch in der Entwicklung befindet, bedeutet das, dass sie nicht immer die Dinge unterstützt, die man braucht, um ein Feature zu liefern. Im Fall von External Inventory wollten wir, dass sich die Benutzeroberfläche diegetisch und 3D anfühlt, auch wenn sie es nicht ist. Das bedeutete, dass wir wollten, dass alle Icons holografisch sind, so wie sie in AR direkt vor deinen Augen angezeigt werden. Leider konnten unsere 3D-Symbole nur einen begrenzten Shader unterstützen, was bedeutete, dass wir viele materielle Details der angezeigten Gegenstände verloren haben. Zu diesem Zeitpunkt hätten wir das Feature verzögern können, aber das Team und ich hielten es für wichtig, dass wir live gehen und so viel Feedback wie möglich erhalten, bis wir ein echtes Inventar haben. Wir werden diesen Shader in einem kommenden Patch definitiv aufrüsten. Reaktionen erzwingen
Im Kern ist Force Reactions ein System, das entwickelt wurde, um zu simulieren, was ein Charakter tun würde, wenn er von einer Kraft getroffen wird, sei es ein starker Windstoß oder eine Kugel, die in seine Schulter eindringt. Es kann in drei Stufen von Aufprallen unterteilt werden:
Geringer Aufprall: zuckt, zuckt zusammen und neigt sich, mittlerer Aufprall: taumelt, hoher Aufprall: niederschlägt.
In Alpha 3.10 lieferten wir die erste Iteration von Low-Impact-Reaktionen mit den prozeduralen Zuckungen im FPS-Kampf und Schräglage bei anhaltendem Wind. In Alpha 3.11 fügten wir den Zuckungen mehr "Gefühl" hinzu, mit zusätzlichen Kamera- und Waffenreaktionen und unserer ersten Iteration von Knockdowns, mit der Absicht, dass die Torkel später kommen.
Die größte Herausforderung für dieses System war, dass es wirklich systemisch sein musste, da Kräfte von vielen verschiedenen Orten kommen können, nicht nur von Kugeln. Dafür haben wir die Kräfte in drei Hauptkategorien eingeteilt: Direkte Kräfte: alles, was physisch auf den Charakter einwirkt, wie eine Schachtel oder eine Kugel Indirekte Kräfte: die Kraft, die du erhältst, wenn dein Schiff gerammt wird oder von einer Windböe Nachhaltige Kräfte: wo eine Kraft ständig angewendet wird, wie eine G-Kraft oder Wind
Das bedeutete, dass wir verschiedene Kräfte mit unterschiedlichen Maßstäben aufteilen konnten und es den Designern erlaubten, die Reaktion des Charakters entsprechend auszugleichen, da die Kräfte, wenn man von einer Kiste getroffen wird, verglichen mit der Beschleunigung eines Schiffes im Weltraum auf 1000m/s sehr unterschiedlich sind. Auch wenn die Reaktionen der Spieler bei geringerem Aufprall nicht die Kontrolle über den Spieler verlieren, waren wir uns der Tatsache bewusst, dass ein Knockdown das tun würde. Wir haben viel Zeit damit verbracht, sicherzustellen, dass die Knockdown-Animationen sehr reaktiv auf die Spielersteuerung reagieren, sobald ihr Charakter auf dem Boden aufschlägt. Wir implementierten auch ein fähigkeitsbasiertes System, das bedeutete, dass wenn man versuchte, ADS auszulösen, bevor man den Boden berührte, eine schnellere Genesungsanimation auslöste, was bedeutete, dass man schneller wieder in die Action einsteigen konnte.
Force Reactions in Alpha 3.11 war unsere zweite Lieferung und wird keineswegs unsere letzte sein. Wir arbeiten aktiv an Reaktionen mit mittlerer Wirkung und werden die Balance in Zukunft ständig überprüfen und optimieren, insbesondere im FPS-Kampf.
Wurf T1
Das Werfen von Granaten oder anderen Gegenständen war schon immer ein wenig inkonsequent und ist umso enttäuschender, wenn man denkt, dass man die perfekte Multi-Kill-Gelegenheit hat, bei der die Granate nur ein paar Meter von einem entfernt wimmert. Also, das erste, was wir mit T1 erreichen wollten, war, das Werfen viel zuverlässiger zu machen, so dass das Objekt, das man wirft (egal ob Granate oder anderes Objekt) dorthin kommt, wo man es erwartet. Das zweitgrößte Ziel, das eine entscheidende Voraussetzung für das physische Inventar ist, war, dass das Wurfsystem mit dem tragbaren System interagieren und koexistieren kann.
Wenn man in Alpha 3.10 eine Granate vom Boden aufhob und dann versuchte, sie zu werfen, gab es für dich keine Möglichkeit, den Stift zu ziehen. Außerdem, wenn du den Hotkey 'Granate werfen' gedrückt hast, hast du die Granate in deine Hand fallen lassen und eine neue aus deinem Anzug gezogen. Offensichtlich ist dies nicht das beabsichtigte Verhalten und war einer der Hauptgründe, warum wir das Werfen geändert haben, um aus einem ausgerüsteten Zustand zu kommen (d.h. die Granate in der Hand zu halten) und nicht direkt aus deinem Anzug. Dieses System wird es uns auch erlauben, in Zukunft Gadgets und Deployables zu liefern.
Als Teil von T1 haben wir auch einen UI-'Wurfbogen' hinzugefügt, der es euch erlaubt, die Flugbahn der Granate zu sehen. Derzeit ist dies zwar für alle Helme aktiviert, wird aber erst von Kampfhelmen aus zugänglich sein, wenn wir anfangen, verschiedene Rüstungsarchetypen im 'Vers' zu definieren.
Behring Granatwerfer & Behring BR2 Schrotflinte
Seitdem ich Waffen dirigiere, versuchen wir sicherzustellen, dass jede Waffe, die wir dem Spiel hinzufügen, einen einzigartigen Zweck oder Spielstil hat, der zu ihr passt. Momentan haben wir bereits mehrere lebende Schrotflinten, die aus nächster Nähe tödlich sind, aber darüber hinaus ineffektiv. Da Behring ein Hersteller ist, den wir in Bezug auf Schaden, Feuerrate und Genauigkeit als Mitte der Straße identifiziert haben, war die BR2 unsere erste Gelegenheit, die Reichweite für eine Schrotflinte zu vergrößern, um im Nahkampf etwas mehr Schwung zu geben, ohne dass sie im Nahkampf dominiert. Während wir mit dem BR2 zufrieden waren, sind wir mit Schrotflinten als Gesamtklasse nicht unbedingt zufrieden, da sie von SMGs unterlegen sind und von Sturmgewehren überrannt werden. Wir werden in einem kommenden Patch ein Update für alle Schrotflinten machen, um ihnen mehr Identität zu geben.
Der Behring-Granatwerfer hingegen warf ganz andere Probleme auf. Eine 40mm-Granate im echten Leben hat einen Tötungsradius von etwa 5m mit einem Verletztenradius von etwa 15m. Das sind große Zahlen, wenn man sich unsere Innenräume ansieht, und wenn man bedenkt, dass man mehrere davon in kurzer Zeit abfeuern kann, bleibt einem eine ziemlich mächtige Waffe. Auf der einen Seite wollten wir eine Waffe liefern, die sich schwer anfühlt und dafür ausgelegt ist, Zerstörung herabregnen zu lassen, aber auf der anderen Seite wollten wir die Balance des FPS-Kampfes nicht massiv stören.
Mit diesem Ziel haben wir dafür gesorgt, dass die Zahlen sowohl für den Tötungs- als auch für den Verletzungsradius etwas unter denen einer normalen Splittergranate liegen. Aber wenn ich ganz ehrlich bin, würde ich sagen, dass der Granatwerfer im aktuellen Spiel etwas zu mächtig ist. Der Hauptgrund dafür ist, dass die Spieler mit dem PMA Zugang zu einer unendlichen Menge an Munition haben, also mussten wir uns entscheiden, ob wir die Waffe wie beabsichtigt loslassen oder sie massiv nerfen, bis das physische Inventar online ist. Als Team waren wir der Meinung, dass es eher eine Erfahrung war, die Waffe freizugeben, da sie funktionieren sollte, und darauf zu warten, dass die anderen Systeme, wie das Inventar und der physische Schaden, ihre schiere Kraft ausgleichen. Dann müssen sich die Spieler überlegen, wie viel Platz sie für Munition und physischen Schaden einplanen, damit Waffen und Rüstung ihre Integrität verlieren, wenn sie getroffen werden. Das heißt, wenn jemand durch eine Explosion in die Luft gejagt wird, wird ein Großteil seiner Ausrüstung beschädigt, was den Gesamtwert senkt. Ich habe auch die Rückmeldungen bezüglich der Bewaffnungsdistanz gesehen und daran werden wir arbeiten.
Abschließende Gedanken
Wenn ich auf all die Features zurückblicke, die die Core Gameplay Pillar für Alpha 3.11 geliefert hat, bin ich mit den Ergebnissen zufrieden. Das heißt aber nicht, dass alles gut gelaufen ist, oder wenn ich diese Zeit noch einmal hätte, würde ich alles genauso machen.
Das Wichtigste, was ich denke, dass ich ändern würde, wäre, wie wir Force Reactions in den Schiffen implementiert haben. Anstatt sie gleich zu behandeln wie alle anderen Kräfte im Spiel (Wind, Kugeln, etc.) - was auf den ersten Blick Sinn macht - hätte ich sie speziell um den Gravitationsgenerator in den Schiffen herum entworfen. Momentan nehmen wir die Kraft, die auf das Schiff einwirkt und wenden sie dann über Filter je nach Kraft direkt auf den Akteur an, damit dieser entsprechend reagiert. Stattdessen hätte ich lieber die Gravitation selbst auf die Kraft reagieren lassen, die dann den Akteur zu einer Reaktion veranlassen würde. Während es für den Spieler keinen Unterschied gäbe, denke ich, dass es eine sauberere Implementierung gewesen wäre und das System in Zukunft einfacher zu erweitern wäre. Zum Beispiel, wenn wir Gegenstände des Gravitationsgenerators hinzufügen, etc.
In den letzten zwei Quartalen haben wir auch zwei Features (Body Dragging und Knockdowns) geliefert, die von einer getriebenen Ragdoll wirklich profitiert hätten. Leider wird dieses Feature nicht von jemandem aus meinen Teams geliefert, also hätte ich nicht unbedingt etwas daran ändern können. Aber wenn ich zurückblicke, hätte ich mehr Aufmerksamkeit auf die Vorteile gelenkt, wenn ich versucht hätte, dieses Feature voranzutreiben. Das ist natürlich eine Herausforderung, wenn man in einem 600-köpfigen Team arbeitet, das über mehrere Kontinente verteilt ist und in mehreren Projekten unterschiedliche Prioritäten hat. Jeder versucht, die besten Features/Inhalte/Techniken in höchstmöglicher Qualität zu liefern, und manchmal stimmen die Sterne nicht überein, wenn es um die Prioritäten geht. In diesem Fall liegt es aufgrund mangelnder Kommunikation rein auf meinen Schultern. Als Entwickler kriegen wir es nicht immer richtig hin, wenn wir mitten im Geschehen sind, aber hoffentlich gibt uns das einen Einblick in unsere Prozesse und wie wir immer 100%ig geben, um zu versuchen, die besten Erlebnisse zu schaffen, die du genießen kannst.
Richard Tyrer
Haupt-Gameplay-Regisseur
Umgebungen
Frachtdecks
Für diese Veröffentlichung konnten wir den nächsten Schritt einführen, um die Komplexität unserer Raumstationen zu erhöhen. Die Idee für die großen Stationen, die sich um Planeten herum befinden, ist, dass sie mehr als nur Raststätten sein würden; sie würden ihre eigenen Einrichtungen haben, die anderen Diensten gewidmet sind, wie zum Beispiel der Fracht.
Für das Äußere haben wir neue Addon-Komponenten eingeführt, die die Infrastruktur und die großen Containerregale beschreiben, die die Kapazität des Ortes implizieren (die im Moment noch rein visuell ist, in Zukunft würden wir gerne mehr interaktive Elemente einbauen).
Im Inneren wollten wir die Traversalrouten erweitern. Dazu haben wir die Idee einer Station mit einem Haupttransitnetz eingeführt, das die verschiedenen Elemente der Station miteinander verbindet - Handelsdecks, Frachtdecks, etc.
Für das Innere des Frachtdecks wollten wir ein paar Elemente einbauen. Erstens wollten wir für den Hub-Bereich eine thematische logistische Erfahrung für den Spieler beschreiben. Dazu gehört ein Bereich eines Versandlagers, der in Zukunft eine Sandkiste für Missionsinhalte sein wird. Für den Haupteinkaufsbereich wollten wir ein paar Elemente in einen größeren Shop integrieren. Jetzt sehen wir den Ladungsabgabe- und Abholschalter, der sich in einem Mini-Logistiksortierraum befindet, den Schiffsverleihraum an der Seite und den Gilden- und Vorratsraum in der Ecke. Insgesamt bietet dies dem Spieler eine abwechslungsreichere Erfahrung, anstatt all diese Elemente in separate Läden zu trennen.
Inhalt des Planeten
In diesem Quartal konnten wir die Planeten und Monde im Stanton-System mit den neuesten Tools und Technologien, die wir für den Aufbau des Pyro-Systems verwenden, auf den neuesten Stand bringen. Der Anfang davon war die Durchführung eines globalen Neumalungspasses für alle Planeten und Monde. Im Grunde treibt dieser Malprozess eine Menge der neuesten Features an, wie wir Objekte vereinigen, also mussten wir, um das ins Spiel zu bekommen, in den sauren Apfel beißen und den ersten Pass über alles machen. Im letzten Patch haben wir die neuen Höhenkarten eingeführt, und jetzt wird der neue Maldurchgang all diese neuen Daten nutzen.
Das zweite Element, das wir einführen konnten, war eine globale Verbesserung all unserer Geologie-Packs. Wir haben jetzt die Möglichkeit, die Geländefarbaufnahme für Assets zu spezifizieren, was es ihnen ermöglicht, die Farbe des Geländes oder des Untergrunds prozedural anzupassen. Außerdem konnten wir die Mosaikierung und die Verschiebung von Objekten auf Objektbasis hinzufügen, was bedeutet, dass wir den Objekten, die die Verschiebungsparameter steuern, Höhenkarten zuweisen können. Kurz gesagt bedeutet das, wenn der Spieler in die Nähe eines Assets kommt, sollte die Auflösung der Geometrie wesentlich höher sein, so dass eine komplexe Silhouette gelesen werden kann.
Zuletzt haben wir alle unsere Terrain-Shader durch gescannte Daten ersetzt. Das ist etwas, mit dem wir uns schon seit einiger Zeit beschäftigt haben, da die Qualität der Ergebnisse extrem hoch war, aber mit der neuesten Technologie konnten wir es in unsere Pipeline implementieren. Wir haben über 70 Basis-Shader neu erstellt, indem wir die gescannten Daten miteinander kombiniert und gemischt haben, um die Ergebnisse zu erhalten, die wir wollten. Für die Zukunft haben wir Ambitionen, eine dedizierte Scan-Ausrüstung einzurichten, um unsere eigenen Daten zu verarbeiten, die wir bei unseren Exkursionen sammeln werden. Wir wollen sicherstellen, dass wir eine vielfältige und wunderbare Palette für zukünftige Star-Citizen-Standorte erstellen können.
Abschließende Gedanken
Wir waren in der Lage, eine Menge neuer Tech in dieser Veröffentlichung einzuführen, sowie die zweite Runde der polnischen Updates auf den Planetenoberflächen zu zeigen. Außerdem haben wir mit der Einführung der gescannten Daten für unsere Oberflächen einen erheblichen Qualitätssprung gesehen. Allerdings waren einige der globalen Maldurchgänge nicht so detailliert und aufwändig, wie wir es uns gewünscht hätten. Das liegt hauptsächlich an den Zeitbeschränkungen im Quartal. Ein Teil der Geologie, die mit den neuen Bibliotheken an die Oberfläche kommt, könnte auch für die Biome/Region besser geeignet sein.
Bei den Frachtdecks hätten wir die Trennung zwischen Innen- und Außenbereich bei der Trennung der kommerziellen Decks vorhersehen müssen. Um die Erfahrung zu verbessern und dem Spieler einen Kontext zu geben, würden wir uns wünschen, dass dieses Transitnetzwerk in Zukunft physisiert wird. Dadurch wird die Sicht aus der Transitkabine auf die Außenseite der Station, während sie sich ihrem Ziel nähert, gewährleistet.
Ian Leyland
Star-Bürger Art Director
Gestaltung
Waffenstillstands-Zonen
Die Entspannungen der Waffenstillstandszone sind der erste Schritt, um alle willkürlichen Beschränkungen aus dem Spiel zu entfernen, sobald wir in der Lage sind, die verschiedenen Bereiche des Spiels richtig zu verteidigen und zu überwachen. Dies war an den Raststätten möglich, weil wir nicht nur die bestehenden Türme der Größe 4 und Wachposten der Größe 6 wiederverwenden, sondern auch einen völlig neuen Turm der Größe 10 geschaffen haben. Zusammen sind diese in der Lage, mit jedem Schiff fertig zu werden, das im Spiel geplant ist. Und anstatt noch eine weitere willkürliche Beschränkung aufzuerlegen, haben wir die Verteidigungsanlagen vollständig zerstörbar gemacht, obwohl ihre Respawn-Zeit mit 5 Minuten sehr schnell ist. Dieses Respawn-System wird in Zukunft weiter entwickelt werden, um wahrscheinlich auf Reparaturen angewiesen zu sein.
Zusammen mit der Verteidigung haben wir die erste Iteration eines Sicherheitsreaktionssystems hinzugefügt, das, obwohl es noch recht simpel ist, die CrimeStats aller Spieler in der Gegend addiert (intern als "Heat" bekannt) und als Reaktion darauf Sicherheitsschiffe von steigender Anzahl und Stärke hervorbringt. Das System reagiert schnell auf den Anstieg der Hitze in einem Gebiet, indem es neue Schiffe laicht und schwächere Schiffe, die sie ersetzen, despawnen lässt. Das System reagiert langsamer auf die Tötung seiner Mitglieder (sollte die Hitze dadurch nicht erhöht werden) und noch langsamer auf eine Abnahme es in der Hitze. Wir werden dieses System in Zukunft weiterentwickeln, um auch die Schiffe, die die Spieler benutzen, und die gezeigte Aggression zu berücksichtigen.
Wir werden es auch auf andere Orte wie Außenposten ausrollen, obwohl Grim HEX eine komplexere Lösung benötigt, da die dortigen Verteidigungsanlagen nur auf Verbrechen reagieren sollen, die in ihrem Zuständigkeitsbereich begangen wurden und nicht in anderen. Olisar wird eine Anomalie bleiben, da es ein veralteter Standort ist, der keine Waffenstillstandszone mit dem erforderlichen Radius unterstützen kann.
Das Live-Team musste extrem wachsam sein und schnell auf Probleme reagieren, angesichts der kurzen Zeit, die Alpha 3.11 in der PTU lief. Ein Beispiel für ein Problem, das uns auffiel, waren Spieler, die die Wachen stahlen, indem sie sie in der Ladebucht ihrer 890 Sprünge verschluckten und mit ihnen davonflogen. Wir berichtigten dies, indem wir selbstzerstörende Wachen aus dem Gebiet weggebracht und sie wiederbelebt haben. Ein anderes Beispiel ist, dass die Sicherheitsreaktion zwar in der Lage war, schnell Schiffe auf lokalen Severn zu respawnen, auf einem Live-Server jedoch nicht. Um dies zu verbessern, haben wir die Schwellenwerte, auf die das System reagierte, reduziert, um die Anzahl der angeforderten Spawns zu reduzieren.
Wir haben Videos von vielen Spielern gesehen, die sich zusammentun, um einen Rastplatz zu überrennen und ihn trotz der Abwehr- und Sicherheitsmaßnahmen lange Zeit zu halten. Aus diesem Grund haben wir den Idris in dem Moment, als er verfügbar wurde, der obersten Ebene des Antwortsystems hinzugefügt, so dass wir hoffen, dass diese Spieler in nicht allzu ferner Zukunft Schwierigkeiten haben werden, ihn zu replizieren.
Abschließende Gedanken
In Zukunft planen wir auch, die willkürlichen Begrenzungen in den Innenräumen zu lockern, wieder beginnend an den Raststätten. Wir sind bereits auf dem besten Wege, ein Spawn-Schranksystem zu entwickeln, das es uns erlaubt, die Wachen zu spawnen, die notwendig sind, um das Gebiet zu überwachen. Außerdem arbeiten wir an einem Sicherheitsnetzwerk, das wissen wird, ob Spieler das Recht haben, sich in bestimmten Bereichen aufzuhalten, und das es den Spielern ermöglicht, Kameras, Türmchen und Wachen zu aktivieren, um auf Eindringlinge, die mit CrimeStats ausgestattet sind oder die gerade dabei sind, Verbrechen zu begehen, zu reagieren.
Lukas Pressley
Chefdesigner
Wir sehen uns im 'Vers'!
Wir glauben, dass es sehr wertvoll ist, auf dieser Ebene Einblick in unseren Entwicklungsprozess zu geben, besonders wenn man die Gedankengänge, Reflexionen und Lektionen direkt von unseren Senior-Entwicklern lesen kann. Wie bereits beim letzten Mal erwähnt, haben wir uns zu einer transparenten Entwicklung verpflichtet und werden auch in Zukunft vierteljährliche Patch-Postmortems zur Verfügung stellen.
Am 8. Oktober 2020 starteten wir Alpha 3.11 High Impact, das eine Reihe von neuen Features und Änderungen einführte, darunter Frachtdecks, Kraftreaktionen und die erste Stufe der umfassenderen Entfernung der Waffenstillstandszone. Im Folgenden findet ihr eine Obduktion der Senior-Entwickler selbst, die detailliert beschreibt, was geliefert wurde und was sie darüber dachten, wie es gelaufen ist.
Fahrzeug-Team
Die Fahrzeugsäule hatte mit Alpha 3.11 ein viel leichteres Viertel im Vergleich zur Stoßstangenlieferung in Alpha 3.10, aber was wir geliefert haben, hatte hoffentlich einen großen Einfluss auf das Spielerlebnis.
Herkunft 100er Serie
Das Team für Fahrzeuginhalte lieferte die Origin 100 Serie in Alpha 3.11, bestehend aus 100i, 125a und 135c. Die 100er Serie fügt dem Spiel ein alternatives Startschiff sowie einen leichten Jäger und leichten Frachtschlepper hinzu. Dies sind fantastische kleine Schiffe für neue Spieler, mit denen sie ihre Reise als Sternenbürger beginnen können. Sie bieten die Möglichkeit, eine Vielzahl von Missionen zu bewältigen und die Weiten des 'Verses' zu erforschen. Raketen & Gegenmaßnahmen
Das Raketen- und Gegenmaßnahmen-Gameplay war im Laufe der Jahre in verschiedenen Zuständen gewesen und war weder auf der Seite des Angreifers noch auf der Seite des Verteidigers wirklich unterhaltsam. Unser Ziel ist es, dies mit dem Raketenoperator-Modus endgültig zu beheben, aber bis es soweit ist, haben wir beschlossen, die Zeit damit zu verbringen, Korrekturen und Iterationen im Gameplay zu implementieren, um einen Vorgeschmack darauf zu geben, was dieses Feature liefern wird. Die Hauptprobleme mit den Raketen vor Alpha 3.11 waren die folgenden:
Gegenmaßnahmen würden nur auf IR-Raketen (Flares) und EM-Raketen (Chaff) wirken Nur Flares funktionierten (manchmal und stark Server-abhängig) Es gab keine Gegenmaßnahmen für Spoof-CS-Raketen Es war extrem einfach, Raketen abzufeuern, und die Verteidigung gegen Raketen war extrem schwierig
Zuerst untersuchten wir, warum nur Fackeln funktionieren würden und Spreu nicht. Das Problem war eine Kombination aus falschen Setup-Daten bei einigen Schiffen, falschen Daten bei einigen Gegenmaßnahmen und Raketen und einem jetzt redundanten Workaround, der ursprünglich für einen bestimmten SQ42-Level erstellt wurde und das ganze Spiel über angeklopft hat.
Nachdem wir diese Probleme behoben hatten, erkannten wir, dass das Signatursystem zwei verschiedene Möglichkeiten hat, Signale zu modifizieren - entweder ein starkes Signal zu erzeugen oder alle Signale in der Umgebung zu dämpfen. Wir entschieden uns, diesen Unterschied zu nutzen, anstatt von den Piloten zu verlangen, "Maulwurfwaffen" zu spielen, indem wir die "richtige" Gegenmaßnahme für den "richtigen" Raketentyp wählten, während wir unter dem Stress standen, einige Sekunden vor dem Einschlag entscheiden zu müssen. Mit diesem Gedanken im Hinterkopf haben wir einige Spieltests mit den folgenden Änderungen durchgeführt: Fackeln würden auf alle Raketentypen wirken Chaff würde in ein Lärmfeld verwandelt werden, das alle Signaturen um das Feld herum dämpft
Sofort bewiesen die ersten Gameplay-Tests, dass dies eine viel ansprechendere Art der Raketenabwehr ist. Wir haben dann die HUD-Elemente des Raketenwarnsystems aktualisiert, ein Widget für Gegenmaßnahmen hinzugefügt und die Keybinds aktualisiert, um einen direkten Start für jede Art von Gegenmaßnahme zu ermöglichen. Die UI- und VFX-Teams sind dann eingesprungen und haben alles verschönert, die Effekte ersetzt und auch ein paar Fehler im Zusammenhang mit VFX behoben (z.B. dass Gegenmaßnahmen im PU unsichtbar sind).
Ein zukünftiger Zusatz, den wir nicht rechtzeitig für Alpha 3.11 machen konnten, war die Änderung der Namen von "Flares" und "Spreu". Beide Namen sind für Flugsimulationsgemeinschaften sehr gebräuchlich, aber wir wollen sie trotzdem umbenennen, um deutlich zu machen, dass Star Citizen unterschiedliche Konzepte zur Verteidigung gegen Raketen verwendet. Dies wird uns dazu zwingen, neue VO-Zeilen aufzunehmen, um die Schiffscomputerstimmen zu aktualisieren. Jedes Fahrzeug darf nur vier Schlösser gleichzeitig haben Nur eine Rakete kann pro Gestell gleichzeitig starten Nur ein Raketentyp (IR/EM/CS) kann gleichzeitig starten Raketen verlieren außerhalb ihres Verriegelungswinkels
Nachdem wir diese Maßnahmen eingeführt hatten, verbesserte sich das Raketenerlebnis in den ersten Tests deutlich. Das Spamming der Raketen wurde deutlich reduziert und die Meta verlagerte sich in Richtung Schiffe, die sehr nahe aneinander herankommen und Raketen auf Entfernungen abfeuern, bei denen der Verteidiger nicht einmal eine Raketenwarnung vor dem Einschlag erhalten würde. Als Ergebnis dieser unerwünschten Änderung führten wir minimale und maximale Zielreichweiten ein. Dadurch wurde das Raketen-Gameplay deutlich über die Reichweite der Geschütze hinaus ausgedehnt, so dass raketenfokussierte Schiffe wie geplant am Rand des Kampfes herumlungern konnten, während engagierte Kämpfer näher an sie herankamen. Dies ermöglichte es uns auch, den Verriegelungswinkel kleinerer Raketen zu erhöhen, so dass Schiffe wie die Constellation (die Raketen nicht nach vorne, sondern leicht aus dem Winkel feuern) wieder Raketen einsetzen konnten.
Viele dieser Änderungen (besonders an den Raketen) sind vorübergehend, um ein besseres Erlebnis zu bieten, bis der Raketenoperator-Modus bereit ist, der das Verhalten wieder ändert und/oder bestimmte Aspekte entfernt, wenn er implementiert wird. Abschließende Gedanken
Das übergeordnete Ziel, das wir im Raketenspiel erreichen wollen, ist es, sowohl den Einsatz von Raketen als auch die Verteidigung gegen Raketen tiefer und lohnender zu machen, mit einem eigenen "Slot" in der Kampfumgebung. Raketen sollen keine Alternative zu Gewehren sein, sondern taktische Waffen, und der Einsatz von Raketen soll eine bewusste Entscheidung mit Konsequenzen sein. Aus dem gleichen Grund wollen wir auch speziellen Raketenbooten, wie der Talonwürger oder dem Freelancer MIS, einen Vorteil verschaffen, wenn es darum geht, Munition einzusetzen. Diese Schiffe werden sich im offensiven Raketen-Gameplay auszeichnen, haben aber in anderen Kategorien offensichtliche Nachteile. Daher wird es in den nächsten paar Versionen mehr Iterationen zu Gegenmaßnahmen und Raketenspiel geben. Im Moment sind wir jedoch sehr froh, dass die Raketenerfahrung die Frustrationen der vorherigen Versionen hinter sich gelassen hat.
John Crewe
Fahrzeug-Direktor
Technik
Leinwand-Aufkleber-System
Für Alpha 3.11 lieferte das Grafikteam die zugrundeliegende Rendering-Technologie, um das 'Canvas Decal'-System zu unterstützen, das das Building Blocks-System nutzt, um Decal-Texturen zur Laufzeit zu erstellen. Diese Abziehbilder können für die Beschilderung, auf der Kleidung oder sogar für die Beschilderung von Fahrzeugen verwendet werden. Der Vorteil der Abziehbilder, die zur Laufzeit erstellt werden, ist, dass wir Spieldaten wie den Namen des Spielers verwenden oder sogar den Inhalt in die Sprache übersetzen lassen können, in der das Spiel gespielt wird.
Um dieses Feature für eine breitere Verwendung in der PU skalierbar zu machen, ist das System eng mit dem Textur-Streaming-System gekoppelt, so dass die dynamischen Texturen mit der gleichen Logik wie Standardtexturen 'hereingestreamt' werden, was sicherstellt, dass wir immer ein festes Speicherbudget haben. Diese Streaminglogik stellt sicher, dass wir die gleichen Funktionen automatisch auch auf Maschinen mit niedriger Spezifikation ausführen können, indem die Texturauflösungen während des Streamens sorgfältig ausbalanciert werden, erlaubt es uns aber auch, die Texturauflösung auf leistungsstärkeren Maschinen so hoch wie möglich zu pushen. Die Integration der Canvas-Aufkleber in das Textur-Streaming führte zu mehreren Abstürzen in der PTU, die sehr schwer aufzuspüren waren und viel Zeit benötigten, um sie zu lösen. Infolgedessen haben wir einige Dokumentationen geschrieben, um zukünftigen Programmierern zu helfen, die Komplexität des Textur-Streaming-Systems zu verstehen, was besonders wichtig sein wird, da wir planen, den Code zu verallgemeinern und ihn auch für das Mesh-Streaming zu verwenden. Planeten-Technologie
Auf der Seite der Planetentechnologie haben wir einige Features hinzugefügt, einschließlich Verbesserungen an den Planetenwerkzeugen. Dazu gehören neue Malpinsel, eine überarbeitete Benutzeroberfläche und kombinierte Bodenebenen- und Objektvoreinstellungen, um das Malen von Planeten noch schneller zu machen. Mit den neuen Malwerkzeugen für Planeten ging das Umweltkunst-Team durch alle Planeten und Monde im Stanton-System und malte die Bodenflächen und Objektvoreinstellungen neu. Dies macht uns auch zukunftssicher und erlaubt uns, die Vorteile der neuen Technologie an bestehenden Orten zu nutzen. Auf einer Pro-Objekt-Basis sind wir nun in der Lage, die Verschiebung der HW-Tessellation auf der über das Gelände verteilten Geologie zu unterstützen, um ihr ein detaillierteres und organischeres Aussehen zu geben. Es gab auch einige Verbesserungen im Zusammenhang mit Ozeanen und Wasser, einschließlich des Auftriebs der Bodendecke, die wir in Zukunft weiter ausbauen werden, da während dieses Release-Zyklus nicht genug Zeit war, um größere schwimmende Objekte einzuführen.
In den letzten Monaten wurde viel Zeit für die weitere Erforschung und Entwicklung der Atmosphäre und des Wolkenrenderers, einschließlich des vereinheitlichten Raymarchers für die Planetenatmosphäre, aufgewendet. Wir werden mehr ins Detail gehen, sobald das System verfügbar ist. Für den Moment sagen wir einfach, dass wir an verschiedenen Algorithmen gearbeitet haben, um das Raymarchen bei einer Auflösung unter dem Bildschirm zu ermöglichen und das Rauschen und Upsampling der Ergebnisse auf die volle Auflösung zu reduzieren, um die Leistung der kostspieligen Raymarching-Vorgänge zu verbessern. Diese werden mit Reprojektionstechniken und der Bündelung von Raymarching-Anfragen für Pixel, die bei jedem Frame aktualisiert werden sollen, kombiniert, um die Leistung weiter zu verbessern. Zusätzlich unterstützt unsere bestehende Multiscatter-Lösung nun eine deutlich höhere Anzahl an Streuaufträgen, was für sehr dichte Atmosphären wichtig sein wird. Übrigens befinden wir uns jetzt in den allerersten Tagen der volumetrischen Wolken-Rendering-Forschung...
Fast als Nebenprodukt dieser Arbeit haben wir verschiedene Verbesserungen an der bestehenden Atmosphären-Rendering-Technologie vorgenommen. Zuallererst wurden einige seit langem bestehende Artefakte, wie z.B. die Falschfarbenwiedergabe in der Dämmerung in der Nähe der Atmosphärenoberseite zusammen mit sehr markanten Halos um die Silhouette der dunklen Seite eines Planeten, angesprochen. Die Generierung von Nachschlagetabellen verwendet nun eine besser geeignete Methode, um Beispielstandorte für die numerische Integration über (Hemi-)Sphären zu generieren. Dies und andere Verbesserungen der numerischen Präzision führten zu genaueren Ergebnissen in diesen Tabellen bei reduziertem Rechenaufwand. Doch damit nicht genug, wir haben noch weitere visuelle Verbesserungen implementiert, die ihr hoffentlich bald genießen werdet. Eine davon ist die Auswertung, wie viel von der Sonnenscheibe sichtbar ist, wenn man berechnet, wie viel Sonnenlicht den Punkt x in der Atmosphäre erreicht. Diese Auswertung ist vollständig in das gesamte Beleuchtungssystem der Atmosphäre integriert und wirkt sich auf die direkte und indirekte Beleuchtung aus. Außerdem haben wir Unterstützung für eine Absorptionsschicht hinzugefügt. Dies erlaubt uns unter anderem, den erdähnlichen Planeten eine Ozonschicht hinzuzufügen, die die Bläue des Himmels betont und eine bessere Schattierung in der Dämmerung ermöglicht (Entfernung der gelben Tönung). Wir beziehen nun auch IRL-Radiometriedaten der extraterrestrischen Sonne mit ein, wenn wir die Lichtsimulation durchführen, anstatt von einer "rein weißen" Lichtquelle auszugehen, sowie eine ungefähre Umrechnung von spektraler Strahldichte (das Ergebnis der Atmosphärenbeleuchtungssimulation) in Leuchtdichte (die im traditionellen Sinne zur Beleuchtung der Szene verwendet wird). Schließlich haben wir die Auswertung der Sonnenstrahlung verbessert, die von Punkten außerhalb der Atmosphäre des Planeten empfangen wird. Sie wirft nun Dämmerungslicht aufgrund der atmosphärischen Streuung und dem Aufprall des Winkelradius der Sonne auf Objekte in der Halbschattenregion eines Planeten. Dies sollte einen netten Touch für Großkampfschiffe oder Monde, die Planeten umkreisen, hinzufügen. Triebwerk
Auf der Motorseite wurden einige Verbesserungen vorgenommen. Wir haben unsere Compiler-Toolchain auf VS 2019 aktualisiert, was schnellere Kompilier- und Linkzeiten ermöglichen wird. Außerdem haben wir Unterstützung für den Intel SPMD Program Compiler (ISPC) hinzugefügt. Dies wird es uns ermöglichen, zielgerichteten, SSE-optimierten Code (man denke an HLSL) für Hochleistungs-CPU-Compute-Jobs zu schreiben und die CPU-Fähigkeiten auf jeder einzelnen Maschine, auf der der Code läuft, voll auszunutzen. Mehrere Codepfade in der Physik, der 3D-Engine und dem Zonensystem sind dabei, portiert zu werden. Und, wir haben noch eine weitere Compiler-Optimierung für euch auf Lager. Die Unterstützung für die AVX-Codegenerierung für Clients wurde bereits aktiviert und sollte in der kommenden Alpha 3.12-Version auf die öffentlichen Server kommen.
Was die Speicherauslastung der Server und Clients betrifft, haben wir viel Zeit damit verbracht, unsere Tracking-Tools weiter zu verfeinern, um sicherzustellen, dass wir eine gute Übersicht darüber haben, wo wir Speicher verbrauchen. Wir sind jetzt auch in der Lage, die Speichernutzung in Bibliotheken von Drittanbietern korrekt zu verfolgen, die es uns entweder nicht erlauben, die Speicherzuweisung durch unser System umzuleiten, oder die noch nicht aktualisiert wurden, um dies zu tun. Wir planen immer noch, etwas mehr Sichtbarkeit bei der clientseitigen Video-Speicherzuweisung auf der Treiberebene zu erhalten (unterhalb der Ebene, die wir derzeit als Anwendung mit der GPU verfolgen können). Als Ergebnis dieser Verbesserungen, der laufenden Untersuchungen und des Trackings wurden einige kritische Speicherlecks zur Veröffentlichung behoben.
Während der gesamten Alpha 3.11 Produktion konzentrierte sich das Core Engine Team hauptsächlich auf Features für spätere Versionen, wie den Gen12 Renderer. Allerdings wurde ein sehr großer Fehler behoben, der dazu führte, dass alle unsere Objekte auf den Clients viel früher als geplant entladen wurden. Objekte auf den Clients sollten nun für deutlich größere Entfernungen gestreamt bleiben. Audio
Für die Audiotechnik haben wir die Wise-Version auf 2019.2.4 aktualisiert, wodurch mehrere Probleme behoben wurden. Als Teil dieses Unterfangens haben wir die Speicherverwaltung innerhalb des Audiosystems überarbeitet, indem wir von einer Gruppe von Speicherpools zu einem einzigen Pool übergegangen sind. Dadurch können wir mit den vielen verschiedenen Situationen, die der Sternenbürger präsentiert, leichter umgehen, indem wir Speicher dort zuweisen, wo er gebraucht wird, wenn er gebraucht wird. Wir haben viel Zeit damit verbracht, unsere Voice-Budgets zu überdenken, um das Gesamterlebnis zu verbessern und den Spielern zu ermöglichen, mehr von dem zu hören, was im Spiel vor sich geht. Die Unterstützung für Waffenfeuer, insbesondere auf große Entfernungen, wurde verbessert und mehrere Probleme mit der Audio-Feuerrate und der Waffenlautstärke wurden behoben. Leinwand-Slicing
Dieses Quartal hat das UI-Tech Team an einem System gearbeitet, das Canvas Slicer genannt wird. Dabei handelt es sich um ein Untersystem von Building Blocks, das es den UI-Designern ermöglichen wird, Scheiben von 2D-UI in 3D-Raum zu platzieren. Normalerweise, wenn wir ein 2D UI zeichnen, wird es zu einer Textur gerendert und dann wird diese Textur auf eine Geometrie, wie z.B. ein Monitor Panel oder ein Data-Pad, angewendet. Mit dem Canvas Slicer erstellen wir die Geometrie an einer beliebigen Position im 3D-Raum zur Laufzeit und zeichnen die 2D-UI direkt darauf. Das bedeutet, dass wir in der Lage sein werden, interessante UI-Layer zu erzeugen, wie z.B. holografische Schiffs HUDs und Helmdisplays. Tooltipps
Wir haben auch begonnen, unser Tooltips-System für Building Blocks zu entwerfen. Oberflächlich gesehen sah es nach einem einfach zu implementierenden System aus, aber die Anforderungen, um sicherzustellen, dass es superflexibel ist, haben dazu geführt, dass wir über eine ganze Menge nachdenken müssen, bevor wir mit der Implementierung beginnen.
Marco Corbetta
VP der Technologie
Kern-Gameplay
Externes Inventar
Externes Inventar ist die erste Iteration unseres gitterbasierten Inventarinterfaces, mit dem Spieler ihre FPS-Waren zwischen Rucksack-, Brust- und Beintaschen verwalten können. Wie der Name schon sagt, können Spieler mit dem Externen Inventar auch direkt mit anderen Lagerbehältern in der Welt interagieren und Gegenstände zwischen ihnen hin- und herziehen. In Alpha 3.11 ist dies nur für das Greycat ROC-Lagerfach aktiviert, damit Spieler ihre FPS-Minengüter verwalten können. Aber in der Zukunft und sobald wir eine echte Item-Lagerung (unterstützt durch iCache) realisieren, wird dies Spielern erlauben, Gegenstände in Fächern, Kisten und anderen solchen externen Inventaren zu lagern.
Auch wenn eine neue Inventar-UI und die Möglichkeit, Gegenstände per Drag & Drop zwischen den Lagercontainern hin- und herzuziehen, auf den ersten Blick einfach klingen mag, mussten wir einige kreative und technische Herausforderungen meistern. Die wichtigsten kreativen Herausforderungen drehten sich darum, ein Interface zu haben, das sich taktil und zugänglich anfühlt, ohne sich einfach nur wie ein Standard 2D Interface anzufühlen, das man in den meisten RPGs sieht. Das lag nicht daran, dass diese Inventare schlecht sind, vielmehr wollten wir nicht, dass Spieler, die Inventar-Tetris durchführen, ihre Gegenstände verwalten; wir wollten, dass die Spieler Gegenstände frei zwischen den Lagercontainern bewegen können, ohne sich Gedanken darüber machen zu müssen, wo sie den Gegenstand fallen lassen oder ob ein anderer Gegenstand im Weg ist. Die erste Iteration davon konnten wir mit unserer Building Blocks-Technologie erreichen, die die Gegenstände als Liste und nicht als 2D-Raster speichert. Das bedeutet, dass sich die Gegenstände fließend um deinen Cursor bewegen, wenn du Objekte zwischen den Containern hin- und herziehst. Wir wollen das Gesamtgefühl noch weiter verbessern, aber das Team ist mit der ersten Iteration zufrieden.
Mit Building Blocks konnten wir zwar die kreativen Aspekte des Designs umsetzen, aber es stellte auch die größte technische Herausforderung dar. Da sich die Technologie noch in der Entwicklung befindet, bedeutet das, dass sie nicht immer die Dinge unterstützt, die man braucht, um ein Feature zu liefern. Im Fall von External Inventory wollten wir, dass sich die Benutzeroberfläche diegetisch und 3D anfühlt, auch wenn sie es nicht ist. Das bedeutete, dass wir wollten, dass alle Icons holografisch sind, so wie sie in AR direkt vor deinen Augen angezeigt werden. Leider konnten unsere 3D-Symbole nur einen begrenzten Shader unterstützen, was bedeutete, dass wir viele materielle Details der angezeigten Gegenstände verloren haben. Zu diesem Zeitpunkt hätten wir das Feature verzögern können, aber das Team und ich hielten es für wichtig, dass wir live gehen und so viel Feedback wie möglich erhalten, bis wir ein echtes Inventar haben. Wir werden diesen Shader in einem kommenden Patch definitiv aufrüsten. Reaktionen erzwingen
Im Kern ist Force Reactions ein System, das entwickelt wurde, um zu simulieren, was ein Charakter tun würde, wenn er von einer Kraft getroffen wird, sei es ein starker Windstoß oder eine Kugel, die in seine Schulter eindringt. Es kann in drei Stufen von Aufprallen unterteilt werden:
Geringer Aufprall: zuckt, zuckt zusammen und neigt sich, mittlerer Aufprall: taumelt, hoher Aufprall: niederschlägt.
In Alpha 3.10 lieferten wir die erste Iteration von Low-Impact-Reaktionen mit den prozeduralen Zuckungen im FPS-Kampf und Schräglage bei anhaltendem Wind. In Alpha 3.11 fügten wir den Zuckungen mehr "Gefühl" hinzu, mit zusätzlichen Kamera- und Waffenreaktionen und unserer ersten Iteration von Knockdowns, mit der Absicht, dass die Torkel später kommen.
Die größte Herausforderung für dieses System war, dass es wirklich systemisch sein musste, da Kräfte von vielen verschiedenen Orten kommen können, nicht nur von Kugeln. Dafür haben wir die Kräfte in drei Hauptkategorien eingeteilt: Direkte Kräfte: alles, was physisch auf den Charakter einwirkt, wie eine Schachtel oder eine Kugel Indirekte Kräfte: die Kraft, die du erhältst, wenn dein Schiff gerammt wird oder von einer Windböe Nachhaltige Kräfte: wo eine Kraft ständig angewendet wird, wie eine G-Kraft oder Wind
Das bedeutete, dass wir verschiedene Kräfte mit unterschiedlichen Maßstäben aufteilen konnten und es den Designern erlaubten, die Reaktion des Charakters entsprechend auszugleichen, da die Kräfte, wenn man von einer Kiste getroffen wird, verglichen mit der Beschleunigung eines Schiffes im Weltraum auf 1000m/s sehr unterschiedlich sind. Auch wenn die Reaktionen der Spieler bei geringerem Aufprall nicht die Kontrolle über den Spieler verlieren, waren wir uns der Tatsache bewusst, dass ein Knockdown das tun würde. Wir haben viel Zeit damit verbracht, sicherzustellen, dass die Knockdown-Animationen sehr reaktiv auf die Spielersteuerung reagieren, sobald ihr Charakter auf dem Boden aufschlägt. Wir implementierten auch ein fähigkeitsbasiertes System, das bedeutete, dass wenn man versuchte, ADS auszulösen, bevor man den Boden berührte, eine schnellere Genesungsanimation auslöste, was bedeutete, dass man schneller wieder in die Action einsteigen konnte.
Force Reactions in Alpha 3.11 war unsere zweite Lieferung und wird keineswegs unsere letzte sein. Wir arbeiten aktiv an Reaktionen mit mittlerer Wirkung und werden die Balance in Zukunft ständig überprüfen und optimieren, insbesondere im FPS-Kampf.
Wurf T1
Das Werfen von Granaten oder anderen Gegenständen war schon immer ein wenig inkonsequent und ist umso enttäuschender, wenn man denkt, dass man die perfekte Multi-Kill-Gelegenheit hat, bei der die Granate nur ein paar Meter von einem entfernt wimmert. Also, das erste, was wir mit T1 erreichen wollten, war, das Werfen viel zuverlässiger zu machen, so dass das Objekt, das man wirft (egal ob Granate oder anderes Objekt) dorthin kommt, wo man es erwartet. Das zweitgrößte Ziel, das eine entscheidende Voraussetzung für das physische Inventar ist, war, dass das Wurfsystem mit dem tragbaren System interagieren und koexistieren kann.
Wenn man in Alpha 3.10 eine Granate vom Boden aufhob und dann versuchte, sie zu werfen, gab es für dich keine Möglichkeit, den Stift zu ziehen. Außerdem, wenn du den Hotkey 'Granate werfen' gedrückt hast, hast du die Granate in deine Hand fallen lassen und eine neue aus deinem Anzug gezogen. Offensichtlich ist dies nicht das beabsichtigte Verhalten und war einer der Hauptgründe, warum wir das Werfen geändert haben, um aus einem ausgerüsteten Zustand zu kommen (d.h. die Granate in der Hand zu halten) und nicht direkt aus deinem Anzug. Dieses System wird es uns auch erlauben, in Zukunft Gadgets und Deployables zu liefern.
Als Teil von T1 haben wir auch einen UI-'Wurfbogen' hinzugefügt, der es euch erlaubt, die Flugbahn der Granate zu sehen. Derzeit ist dies zwar für alle Helme aktiviert, wird aber erst von Kampfhelmen aus zugänglich sein, wenn wir anfangen, verschiedene Rüstungsarchetypen im 'Vers' zu definieren.
Behring Granatwerfer & Behring BR2 Schrotflinte
Seitdem ich Waffen dirigiere, versuchen wir sicherzustellen, dass jede Waffe, die wir dem Spiel hinzufügen, einen einzigartigen Zweck oder Spielstil hat, der zu ihr passt. Momentan haben wir bereits mehrere lebende Schrotflinten, die aus nächster Nähe tödlich sind, aber darüber hinaus ineffektiv. Da Behring ein Hersteller ist, den wir in Bezug auf Schaden, Feuerrate und Genauigkeit als Mitte der Straße identifiziert haben, war die BR2 unsere erste Gelegenheit, die Reichweite für eine Schrotflinte zu vergrößern, um im Nahkampf etwas mehr Schwung zu geben, ohne dass sie im Nahkampf dominiert. Während wir mit dem BR2 zufrieden waren, sind wir mit Schrotflinten als Gesamtklasse nicht unbedingt zufrieden, da sie von SMGs unterlegen sind und von Sturmgewehren überrannt werden. Wir werden in einem kommenden Patch ein Update für alle Schrotflinten machen, um ihnen mehr Identität zu geben.
Der Behring-Granatwerfer hingegen warf ganz andere Probleme auf. Eine 40mm-Granate im echten Leben hat einen Tötungsradius von etwa 5m mit einem Verletztenradius von etwa 15m. Das sind große Zahlen, wenn man sich unsere Innenräume ansieht, und wenn man bedenkt, dass man mehrere davon in kurzer Zeit abfeuern kann, bleibt einem eine ziemlich mächtige Waffe. Auf der einen Seite wollten wir eine Waffe liefern, die sich schwer anfühlt und dafür ausgelegt ist, Zerstörung herabregnen zu lassen, aber auf der anderen Seite wollten wir die Balance des FPS-Kampfes nicht massiv stören.
Mit diesem Ziel haben wir dafür gesorgt, dass die Zahlen sowohl für den Tötungs- als auch für den Verletzungsradius etwas unter denen einer normalen Splittergranate liegen. Aber wenn ich ganz ehrlich bin, würde ich sagen, dass der Granatwerfer im aktuellen Spiel etwas zu mächtig ist. Der Hauptgrund dafür ist, dass die Spieler mit dem PMA Zugang zu einer unendlichen Menge an Munition haben, also mussten wir uns entscheiden, ob wir die Waffe wie beabsichtigt loslassen oder sie massiv nerfen, bis das physische Inventar online ist. Als Team waren wir der Meinung, dass es eher eine Erfahrung war, die Waffe freizugeben, da sie funktionieren sollte, und darauf zu warten, dass die anderen Systeme, wie das Inventar und der physische Schaden, ihre schiere Kraft ausgleichen. Dann müssen sich die Spieler überlegen, wie viel Platz sie für Munition und physischen Schaden einplanen, damit Waffen und Rüstung ihre Integrität verlieren, wenn sie getroffen werden. Das heißt, wenn jemand durch eine Explosion in die Luft gejagt wird, wird ein Großteil seiner Ausrüstung beschädigt, was den Gesamtwert senkt. Ich habe auch die Rückmeldungen bezüglich der Bewaffnungsdistanz gesehen und daran werden wir arbeiten.
Abschließende Gedanken
Wenn ich auf all die Features zurückblicke, die die Core Gameplay Pillar für Alpha 3.11 geliefert hat, bin ich mit den Ergebnissen zufrieden. Das heißt aber nicht, dass alles gut gelaufen ist, oder wenn ich diese Zeit noch einmal hätte, würde ich alles genauso machen.
Das Wichtigste, was ich denke, dass ich ändern würde, wäre, wie wir Force Reactions in den Schiffen implementiert haben. Anstatt sie gleich zu behandeln wie alle anderen Kräfte im Spiel (Wind, Kugeln, etc.) - was auf den ersten Blick Sinn macht - hätte ich sie speziell um den Gravitationsgenerator in den Schiffen herum entworfen. Momentan nehmen wir die Kraft, die auf das Schiff einwirkt und wenden sie dann über Filter je nach Kraft direkt auf den Akteur an, damit dieser entsprechend reagiert. Stattdessen hätte ich lieber die Gravitation selbst auf die Kraft reagieren lassen, die dann den Akteur zu einer Reaktion veranlassen würde. Während es für den Spieler keinen Unterschied gäbe, denke ich, dass es eine sauberere Implementierung gewesen wäre und das System in Zukunft einfacher zu erweitern wäre. Zum Beispiel, wenn wir Gegenstände des Gravitationsgenerators hinzufügen, etc.
In den letzten zwei Quartalen haben wir auch zwei Features (Body Dragging und Knockdowns) geliefert, die von einer getriebenen Ragdoll wirklich profitiert hätten. Leider wird dieses Feature nicht von jemandem aus meinen Teams geliefert, also hätte ich nicht unbedingt etwas daran ändern können. Aber wenn ich zurückblicke, hätte ich mehr Aufmerksamkeit auf die Vorteile gelenkt, wenn ich versucht hätte, dieses Feature voranzutreiben. Das ist natürlich eine Herausforderung, wenn man in einem 600-köpfigen Team arbeitet, das über mehrere Kontinente verteilt ist und in mehreren Projekten unterschiedliche Prioritäten hat. Jeder versucht, die besten Features/Inhalte/Techniken in höchstmöglicher Qualität zu liefern, und manchmal stimmen die Sterne nicht überein, wenn es um die Prioritäten geht. In diesem Fall liegt es aufgrund mangelnder Kommunikation rein auf meinen Schultern. Als Entwickler kriegen wir es nicht immer richtig hin, wenn wir mitten im Geschehen sind, aber hoffentlich gibt uns das einen Einblick in unsere Prozesse und wie wir immer 100%ig geben, um zu versuchen, die besten Erlebnisse zu schaffen, die du genießen kannst.
Richard Tyrer
Haupt-Gameplay-Regisseur
Umgebungen
Frachtdecks
Für diese Veröffentlichung konnten wir den nächsten Schritt einführen, um die Komplexität unserer Raumstationen zu erhöhen. Die Idee für die großen Stationen, die sich um Planeten herum befinden, ist, dass sie mehr als nur Raststätten sein würden; sie würden ihre eigenen Einrichtungen haben, die anderen Diensten gewidmet sind, wie zum Beispiel der Fracht.
Für das Äußere haben wir neue Addon-Komponenten eingeführt, die die Infrastruktur und die großen Containerregale beschreiben, die die Kapazität des Ortes implizieren (die im Moment noch rein visuell ist, in Zukunft würden wir gerne mehr interaktive Elemente einbauen).
Im Inneren wollten wir die Traversalrouten erweitern. Dazu haben wir die Idee einer Station mit einem Haupttransitnetz eingeführt, das die verschiedenen Elemente der Station miteinander verbindet - Handelsdecks, Frachtdecks, etc.
Für das Innere des Frachtdecks wollten wir ein paar Elemente einbauen. Erstens wollten wir für den Hub-Bereich eine thematische logistische Erfahrung für den Spieler beschreiben. Dazu gehört ein Bereich eines Versandlagers, der in Zukunft eine Sandkiste für Missionsinhalte sein wird. Für den Haupteinkaufsbereich wollten wir ein paar Elemente in einen größeren Shop integrieren. Jetzt sehen wir den Ladungsabgabe- und Abholschalter, der sich in einem Mini-Logistiksortierraum befindet, den Schiffsverleihraum an der Seite und den Gilden- und Vorratsraum in der Ecke. Insgesamt bietet dies dem Spieler eine abwechslungsreichere Erfahrung, anstatt all diese Elemente in separate Läden zu trennen.
Inhalt des Planeten
In diesem Quartal konnten wir die Planeten und Monde im Stanton-System mit den neuesten Tools und Technologien, die wir für den Aufbau des Pyro-Systems verwenden, auf den neuesten Stand bringen. Der Anfang davon war die Durchführung eines globalen Neumalungspasses für alle Planeten und Monde. Im Grunde treibt dieser Malprozess eine Menge der neuesten Features an, wie wir Objekte vereinigen, also mussten wir, um das ins Spiel zu bekommen, in den sauren Apfel beißen und den ersten Pass über alles machen. Im letzten Patch haben wir die neuen Höhenkarten eingeführt, und jetzt wird der neue Maldurchgang all diese neuen Daten nutzen.
Das zweite Element, das wir einführen konnten, war eine globale Verbesserung all unserer Geologie-Packs. Wir haben jetzt die Möglichkeit, die Geländefarbaufnahme für Assets zu spezifizieren, was es ihnen ermöglicht, die Farbe des Geländes oder des Untergrunds prozedural anzupassen. Außerdem konnten wir die Mosaikierung und die Verschiebung von Objekten auf Objektbasis hinzufügen, was bedeutet, dass wir den Objekten, die die Verschiebungsparameter steuern, Höhenkarten zuweisen können. Kurz gesagt bedeutet das, wenn der Spieler in die Nähe eines Assets kommt, sollte die Auflösung der Geometrie wesentlich höher sein, so dass eine komplexe Silhouette gelesen werden kann.
Zuletzt haben wir alle unsere Terrain-Shader durch gescannte Daten ersetzt. Das ist etwas, mit dem wir uns schon seit einiger Zeit beschäftigt haben, da die Qualität der Ergebnisse extrem hoch war, aber mit der neuesten Technologie konnten wir es in unsere Pipeline implementieren. Wir haben über 70 Basis-Shader neu erstellt, indem wir die gescannten Daten miteinander kombiniert und gemischt haben, um die Ergebnisse zu erhalten, die wir wollten. Für die Zukunft haben wir Ambitionen, eine dedizierte Scan-Ausrüstung einzurichten, um unsere eigenen Daten zu verarbeiten, die wir bei unseren Exkursionen sammeln werden. Wir wollen sicherstellen, dass wir eine vielfältige und wunderbare Palette für zukünftige Star-Citizen-Standorte erstellen können.
Abschließende Gedanken
Wir waren in der Lage, eine Menge neuer Tech in dieser Veröffentlichung einzuführen, sowie die zweite Runde der polnischen Updates auf den Planetenoberflächen zu zeigen. Außerdem haben wir mit der Einführung der gescannten Daten für unsere Oberflächen einen erheblichen Qualitätssprung gesehen. Allerdings waren einige der globalen Maldurchgänge nicht so detailliert und aufwändig, wie wir es uns gewünscht hätten. Das liegt hauptsächlich an den Zeitbeschränkungen im Quartal. Ein Teil der Geologie, die mit den neuen Bibliotheken an die Oberfläche kommt, könnte auch für die Biome/Region besser geeignet sein.
Bei den Frachtdecks hätten wir die Trennung zwischen Innen- und Außenbereich bei der Trennung der kommerziellen Decks vorhersehen müssen. Um die Erfahrung zu verbessern und dem Spieler einen Kontext zu geben, würden wir uns wünschen, dass dieses Transitnetzwerk in Zukunft physisiert wird. Dadurch wird die Sicht aus der Transitkabine auf die Außenseite der Station, während sie sich ihrem Ziel nähert, gewährleistet.
Ian Leyland
Star-Bürger Art Director
Gestaltung
Waffenstillstands-Zonen
Die Entspannungen der Waffenstillstandszone sind der erste Schritt, um alle willkürlichen Beschränkungen aus dem Spiel zu entfernen, sobald wir in der Lage sind, die verschiedenen Bereiche des Spiels richtig zu verteidigen und zu überwachen. Dies war an den Raststätten möglich, weil wir nicht nur die bestehenden Türme der Größe 4 und Wachposten der Größe 6 wiederverwenden, sondern auch einen völlig neuen Turm der Größe 10 geschaffen haben. Zusammen sind diese in der Lage, mit jedem Schiff fertig zu werden, das im Spiel geplant ist. Und anstatt noch eine weitere willkürliche Beschränkung aufzuerlegen, haben wir die Verteidigungsanlagen vollständig zerstörbar gemacht, obwohl ihre Respawn-Zeit mit 5 Minuten sehr schnell ist. Dieses Respawn-System wird in Zukunft weiter entwickelt werden, um wahrscheinlich auf Reparaturen angewiesen zu sein.
Zusammen mit der Verteidigung haben wir die erste Iteration eines Sicherheitsreaktionssystems hinzugefügt, das, obwohl es noch recht simpel ist, die CrimeStats aller Spieler in der Gegend addiert (intern als "Heat" bekannt) und als Reaktion darauf Sicherheitsschiffe von steigender Anzahl und Stärke hervorbringt. Das System reagiert schnell auf den Anstieg der Hitze in einem Gebiet, indem es neue Schiffe laicht und schwächere Schiffe, die sie ersetzen, despawnen lässt. Das System reagiert langsamer auf die Tötung seiner Mitglieder (sollte die Hitze dadurch nicht erhöht werden) und noch langsamer auf eine Abnahme es in der Hitze. Wir werden dieses System in Zukunft weiterentwickeln, um auch die Schiffe, die die Spieler benutzen, und die gezeigte Aggression zu berücksichtigen.
Wir werden es auch auf andere Orte wie Außenposten ausrollen, obwohl Grim HEX eine komplexere Lösung benötigt, da die dortigen Verteidigungsanlagen nur auf Verbrechen reagieren sollen, die in ihrem Zuständigkeitsbereich begangen wurden und nicht in anderen. Olisar wird eine Anomalie bleiben, da es ein veralteter Standort ist, der keine Waffenstillstandszone mit dem erforderlichen Radius unterstützen kann.
Das Live-Team musste extrem wachsam sein und schnell auf Probleme reagieren, angesichts der kurzen Zeit, die Alpha 3.11 in der PTU lief. Ein Beispiel für ein Problem, das uns auffiel, waren Spieler, die die Wachen stahlen, indem sie sie in der Ladebucht ihrer 890 Sprünge verschluckten und mit ihnen davonflogen. Wir berichtigten dies, indem wir selbstzerstörende Wachen aus dem Gebiet weggebracht und sie wiederbelebt haben. Ein anderes Beispiel ist, dass die Sicherheitsreaktion zwar in der Lage war, schnell Schiffe auf lokalen Severn zu respawnen, auf einem Live-Server jedoch nicht. Um dies zu verbessern, haben wir die Schwellenwerte, auf die das System reagierte, reduziert, um die Anzahl der angeforderten Spawns zu reduzieren.
Wir haben Videos von vielen Spielern gesehen, die sich zusammentun, um einen Rastplatz zu überrennen und ihn trotz der Abwehr- und Sicherheitsmaßnahmen lange Zeit zu halten. Aus diesem Grund haben wir den Idris in dem Moment, als er verfügbar wurde, der obersten Ebene des Antwortsystems hinzugefügt, so dass wir hoffen, dass diese Spieler in nicht allzu ferner Zukunft Schwierigkeiten haben werden, ihn zu replizieren.
Abschließende Gedanken
In Zukunft planen wir auch, die willkürlichen Begrenzungen in den Innenräumen zu lockern, wieder beginnend an den Raststätten. Wir sind bereits auf dem besten Wege, ein Spawn-Schranksystem zu entwickeln, das es uns erlaubt, die Wachen zu spawnen, die notwendig sind, um das Gebiet zu überwachen. Außerdem arbeiten wir an einem Sicherheitsnetzwerk, das wissen wird, ob Spieler das Recht haben, sich in bestimmten Bereichen aufzuhalten, und das es den Spielern ermöglicht, Kameras, Türmchen und Wachen zu aktivieren, um auf Eindringlinge, die mit CrimeStats ausgestattet sind oder die gerade dabei sind, Verbrechen zu begehen, zu reagieren.
Lukas Pressley
Chefdesigner
Wir sehen uns im 'Vers'!
Wir glauben, dass es sehr wertvoll ist, auf dieser Ebene Einblick in unseren Entwicklungsprozess zu geben, besonders wenn man die Gedankengänge, Reflexionen und Lektionen direkt von unseren Senior-Entwicklern lesen kann. Wie bereits beim letzten Mal erwähnt, haben wir uns zu einer transparenten Entwicklung verpflichtet und werden auch in Zukunft vierteljährliche Patch-Postmortems zur Verfügung stellen.
Chinese
Alpha 3.11 Postmortem
On October 8, 2020, we launched Alpha 3.11 High Impact, which introduced a number of new features and changes, including cargo decks, force reactions, and the first stage of the wider Armistice Zone removal. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. Vehicle Team
The Vehicle Pillar had a much lighter quarter with Alpha 3.11 compared to the bumper delivery in Alpha 3.10, but what we delivered hopefully had a big impact on the gameplay experience.
Origin 100 Series
The Vehicle Content Team delivered the Origin 100 Series in Alpha 3.11, comprising of the 100i, 125a, and 135c. The 100 Series adds an alternative starter ship to the game as well as a light fighter and light cargo hauler. These are fantastic little ships for new players to start their Star Citizen journey with and provide the ability to tackle a wide range of missions and explore the far reaches of the ‘verse. Missiles & Countermeasures
The missile and countermeasure gameplay had been in various states over the years and was never truly enjoyable from the aggressor or defender side. We’re aiming to ultimately fix that with Missile Operator Mode, but until that is delivered, we decided to spend the time implementing fixes and iterations to the gameplay to provide a taste of what that feature will deliver. The main issues with the missiles prior to Alpha 3.11 were as follows: Countermeasures would act only on IR missiles (flares) and EM missiles (chaff)
Only flares worked (sometimes and highly server-dependant)
There were no countermeasures available to spoof CS missiles
Firing missiles was extremely easy, defending against missiles was extremely hard
First, we investigated why only flares would work and chaff wouldn’t. The issue was a combination of incorrect setup data in some ships, incorrect data in some countermeasures and missiles, and a now-redundant workaround originally created for a specific SQ42 level that had knock-ons game-wide.
Once we fixed those issues, we recognized that the signature system has two distinct ways of modifying signals – either creating a strong signal or dampening all signals around. We decided to embrace that difference instead of requiring pilots to play “whack-a-mole” by choosing the “right” countermeasure for the “right” missile type whilst under the stress of having a few seconds to decide before impact. With that in mind, we did some playtests with the following changes: Flares would act on all missile types
Chaff would be turned into a noise field, dampening all signatures around the field
Right away, the first gameplay tests proved that this was a much more engaging way to defend against missiles. We then went ahead and updated the HUD elements of the missile warning system, re-added a countermeasure widget, and updated the keybinds to allow direct launching for each countermeasure type. The UI and VFX teams then jumped in and beautified everything, replacing the effects and also fixing a couple of VFX related bugs (like countermeasures being invisible in the PU).
One future addition that we couldn’t do in time for Alpha 3.11 was to change the names of “flares” and “chaff”. Both names are very common for flight sim communities, but we still want to rename them to make it clear that Star Citizen uses different concepts for defending against missiles. This will require us to record new VO lines to update ship computer voices. Each vehicle is only allowed four locks at a time
Only one missile can launch per rack at a time
Only one missile type (IR/EM/CS) can launch at a time
Missiles lose lock outside of their locking angle
Once we had these measures in, the missile experience notably improved in early testing. The spamming of missiles was significantly reduced, and the meta shifted towards ships getting very close to each other and firing missiles at distances where the defender would not even get a missile warning before impact. As a result of this undesirable change, we introduced minimum and maximum lock ranges. This notably stretched the missile gameplay out of gun range, allowing missile-focussed ships to loiter at the edge of combat as designed while dedicated gunfighters would get in closer. This also allowed us to increase the locking angle of smaller missiles so that ships like the Constellation (that do not fire missiles forward but slightly off-angle) were viable to use missiles again.
A lot of these changes (especially to the missiles) are temporary to give a better experience until Missile Operator Mode is ready, which will change the behaviour again and/or remove certain aspects when it is implemented. Final Thoughts
The overall goal we want to achieve in the missile gameplay loop is to make both employing missiles and defending against missiles deeper and more rewarding, with its own “slot” in the combat environment. Missiles are not supposed to be an alternative to guns but tactical weapons, and the use of them should be a conscious decision with consequences. We also want to give special missile boats, like the Talon Shrike or Freelancer MIS, an edge when it comes to employing ordnance for the same reason. Those ships will excel in offensive missile gameplay though have obvious drawbacks in other categories. So, there will be more iterations on countermeasures and missile gameplay in the next couple of releases. For the time being though, we’re quite happy the missile experience stepped away from the frustrations of previous releases.
John Crewe
Vehicle Director
Technology
Canvas Decal System
For Alpha 3.11, the Graphics Team delivered underlying rendering tech to help power the ‘canvas decal’ system, which leverages the Building Blocks system to create decal textures at runtime. These decals can be used for signposting, on clothing, or even the signage on vehicles. The advantage of the decals being created at runtime is that we can use game data such as the player’s name or even have the content translated to the language the game is being played in.
To make this feature scalable for wider use in the PU, the system is tightly coupled with the texture streaming system, such that the dynamic textures are ‘streamed in’ using the same logic as standard textures, which ensures we always maintain a fixed memory budget. This streaming logic ensures we can automatically run the same feature set on low-spec machines by carefully load-balancing texture resolutions on the fly, but also allows us to push the texture resolution as high as possible on more powerful machines. Integrating the canvas decals into texture streaming resulted in several crashes in the PTU that were very difficult to track down and took a lot of time to resolve. As a result, we wrote some documentation to help future programmers understand the complexities of the texture streaming system, which will be especially important as we plan to generalize the code and use it for mesh streaming too. Planet Tech
On the planet-tech side, we added several features, including improvements to planet tools. This includes new painting brushes, revamped UI, and merged ground layer and object presets to make it even faster to paint planets. Utilising the new planetary painting tools, the Environment Art Team went through all planets and moons in the Stanton System and repainted the ground surfaces and object presets. This also futureproofs us and allows us to take advantage of new tech in existing locations. On a per-object basis, we are now able to support HW tessellation displacement on geology distributed across terrain to give it a more detailed and organic appearance. There were also several ocean and water related improvements, including ground cover buoyancy, which we will continue to expand upon in the future, as there wasn’t enough time during this release cycle to introduce larger floating objects.
A lot of time in the past few months was dedicated towards continued research and development of the atmosphere and cloud renderer, including the planet atmosphere unified raymarcher. We will go into more detail once the system becomes available. For now, let’s just say we worked on various algorithms to allow raymarching at lower-than-screen resolution and denoise and upsample the results to full resolution to improve the performance of costly raymarching operations. These are combined with reprojection techniques and the bundling of raymarch requests for pixels to be updated each frame to further improve performance. Additionally, our existing multiscatter solution now supports a significantly higher number of scattering orders, which will be important for very dense atmospheres. BTW, we’re now in the very early days of volumetric cloud rendering R&D…
Almost a byproduct of this work, we made various improvements to the existing atmosphere rendering technology. First and foremost several long-standing artifacts, such as false color rendering in twilight near the atmosphere top along with very prominent halos around the silhouette of a planet’s dark side, have been addressed. The generation of lookup tables now uses a better-suited method to generate sample locations for numerical integration over (hemi)spheres. That and other numerical precision improvements led to more accurate results in those tables at reduced computational overhead. We didn’t stop there, however, and implemented additional visual improvements for you to hopefully enjoy soon. One of them includes evaluating how much of the sun’s disc is visible when computing how much sunlight reaches point x in-atmosphere. This evaluation is fully integrated into the entire atmosphere lighting system and impacts direct and indirect lighting. Moreover, we added support for an absorption layer. Among other things, this allows us to add an ozone layer to Earth-like planets that emphasizes the blueness of the sky and enables better shading in twilight (removing yellow tint). We now also incorporate IRL extraterrestrial sun radiometry data when running the light simulation instead of assuming a “pure white” light source as well as an approximate conversion from spectral radiance (the result of the atmosphere lighting simulation) to luminance (used to light the scene in a traditional sense). Lastly, we improved the evaluation of sun radiance received by points outside the planet’s atmosphere. It now casts twilight due to atmospheric scattering and the impact of the sun’s angular radius onto objects in a planet’s penumbra region. This should add a nice touch to capital ships or moons orbiting planets. Engine
On the engine side, several improvements were made. We updated our compiler toolchain to VS 2019, which will allow for faster compile and link times. Moreover, we’ve added support for Intel SPMD Program Compiler (ISPC). This will allow us to write target-agnostic SSE optimized code (think HLSL) for heavy duty CPU compute jobs and will fully utilize CPU capabilities on each individual machine that the code runs on. Several code paths in physics, the 3D engine, and the zone system are in the process of being ported. And, we have another compiler optimization in store for you. AVX code generation support for clients was previously enabled and should hit the public servers in the coming Alpha 3.12 release.
Regarding server and client memory usage, we spent a good deal of time further refining our tracking tools to ensure we have good visibility on where we spend memory. We’re now also able to properly track memory usage in third-party libraries that either don’t allow us to reroute memory allocation through our system or haven’t been updated yet to do so. We still plan to get a bit more visibility on client-side video memory allocations on the driver level (below the level we can currently track as an application using the GPU). As a result of these improvements, ongoing investigations, and tracking, a few critical memory leaks were fixed for release.
Throughout Alpha 3.11 production, the Core Engine Team was mostly focused on features for later releases, like the Gen12 Renderer. However, a very large bug was fixed, which caused all our objects on clients to unload way earlier than we intended. Objects on clients should now stay streamed for noticeably larger distances. Audio
For audio tech, we updated the Wwise version to 2019.2.4, which fixed several issues. As part of this endeavour we reworked memory management within the audio system, going from a group of memory pools to a single pool. This allows us to deal more easily with the many different situations that Star Citizen presents by allocating memory where it is needed, when it is needed. We spent a lot of time revisiting our voice budgets to improve the overall experience and to allow players to hear more of what’s going on in the game. Weapon fire support, particularly at long distance, was improved and several issues with audio fire rates and weapon volumes were fixed. Canvas Slicing
This quarter the UI-Tech team has been working on a system called the Canvas Slicer. This is a sub-system of Building Blocks which will allow the UI designers to place slices of 2D UI in 3D space. Normally, when we draw 2D UI, it gets rendered to a texture and then that texture is applied to geometry such as a monitor panel or data-pad. With the Canvas Slicer, we create the geometry at any position in 3D-space at runtime and draw the 2D UI directly onto it. This means we will be able to produce interesting layered UI, such as holographic ship HUDs and helmet displays. Tooltips
We have also started designing our tooltips system for Building Blocks. On the surface, this looked like a simple system to implement but the requirements to ensure it is super flexible have meant we’ve got quite a lot to think about before we start implementation.
Marco Corbetta
VP of Technology
Core Gameplay
External Inventory
External Inventory is the first iteration of our grid-based inventory interface that allows players to manage their FPS commodities between their backpack, chest, and leg pockets. As it says in the name, the External Inventory also allows players to directly interact with other storage containers in the world and drag and drop items between them. In Alpha 3.11, this is only enabled for the Greycat ROC storage compartment so players can manage their FPS mineables. But, in the future and once we realise true item storage (underpinned by iCache), this will allow players to store items in compartments, crates, and other such external inventories.
While on the face of it, a new inventory UI and being able to drag and drop items between storage containers may sound simple, we had to overcome several creative and technical challenges. The main creative challenges revolved around having an interface that felt tactile and accessible to use without just feeling like a standard 2D interface that you see in most RPGs. This wasn’t because those inventories are bad, more that we didn’t want players performing inventory Tetris to manage their items; we wanted players to freely move items between storage containers without having to worry about where they dropped the item or if another item was in the way. We were able to achieve the first iteration of this using our Building Blocks technology, which stores the items as a list rather than a 2D grid. This means items fluidly move around your cursor as you drag objects between containers. We still want to further improve on the overall feel, but the team is happy with the initial outing.
While Building Blocks allowed us to deliver on the creative aspects of the design, it also provided the main technical challenge. As the technology is still being developed, it means it doesn’t always support things that you need to deliver a feature. In the case of External Inventory, we wanted the UI to feel diegetic and 3D even though it is not. This meant we wanted all the icons to be holographic, like they were being displayed in AR directly in front of your eyes. Unfortunately, our 3D icons could only support a limited shader which meant we lost a lot of material detail from the items being displayed. At this point we could have delayed the feature, but the team and I felt it was important for us to go live and get as much feedback as we could between now and a true physical inventory. We will definitely be upgrading that shader in an upcoming patch. Force Reactions
At its core, Force Reactions is a system developed to simulate what a character would do when impacted by a force, whether that is a strong gust of wind or a bullet penetrating their shoulder. It can be split into three levels of impacts: Low impact: twitches, flinches, and leans
Medium impact: staggers
High impact: knockdowns
In Alpha 3.10, we delivered the first iteration of low-impact reactions with the procedural twitches in FPS combat and leaning during sustained winds. In Alpha 3.11, we added more ‘feels’ to the twitches with additional camera and weapon reactions and our first iteration of knockdowns, with the intention for staggers to come later.
The biggest challenge for this system was that it needed to be truly systemic as forces can come from a lot of different places, not just bullets. For this, we broke down the forces into three main categories: Direct forces: anything that physically impacts the character, like a box or bullet
Indirect forces: the force you receive when your ship gets rammed or from a gust of wind
Sustained forces: where a force is constantly applied, such a g-force or wind
This meant we could compartmentalise different forces with different scales and allow the designers to balance the character’s reaction accordingly, as the forces of being hit by a box compared to the acceleration of a ship in space to 1000m/s are vastly different. While low-impact reactions do not take away any player control, we were very cognizant of the fact that knockdowns would. We spent a lot of time making sure the knockdown animations were very reactive to player control as soon as their character hit the ground. We also implemented a skill-based system that meant if you tried to ADS before touching the floor you would trigger a faster recovery animation, meaning you could get back into the action quicker.
Force Reactions in Alpha 3.11 was our second delivery and will be by no means our last. We are actively working on medium-impact reactions and will be constantly reviewing and tweaking the balance going forward, especially in FPS combat.
Throwing T1
Throwing grenades or other objects has always been a bit inconsistent and is even more disappointing when you think you have that perfect multi-kill opportunity for the grenade to just whimper a few feet from you. So, the first thing we wanted to achieve with T1 was to make throwing much more reliable, so that the object you throw (whether a grenade or other object) goes where you expect it to go. The second biggest objective, which is a critical pre-requisite for the physical inventory, was for the throw system to be able to interact and co-exist with the carriable system.
In Alpha 3.10, if you picked up a grenade from the floor and then tried to throw it, there was no way for you to pull the pin. Also, if you pressed the ‘Throw Grenade’ hotkey, you would drop the grenade in your hand and pull a new one from your suit. Obviously, this is not the intended behaviour and was a major reason why we changed throwing to come from an equipped state (i.e. holding the grenade in your hand) rather than directly from your suit. This system will also allow us to deliver gadgets and deployables in the future.
As part of T1, we also added a UI ‘throw arc’ that allows you to see the trajectory of the grenade. While currently this is enabled for all helmets, it will only be accessible from combat helmets once we start to define different armor archetypes in the ‘verse.
Behring Grenade Launcher & Behring BR2 Shotgun
Ever since I have been directing weapons, we have been trying to make sure that every weapon we add to the game has a unique purpose or playstyle that it suits. Currently, we already have several live shotguns that are deadly when up-close-and-personal but ineffective beyond that. With Behring being a manufacturer that we have identified as being middle of the road when it comes to damage, fire rate, and accuracy, we felt the BR2 was our first opportunity to push the range out for a shotgun to provide a bit more oomph in mid-quarter combat without it dominating at close-quarters. While we were happy with the BR2, we are not necessarily happy with shotguns as an overall class as they are outgunned by SMGs and outranged by assault rifles. We will be doing an update to all the shotguns in an upcoming patch to give them greater identity.
The Behring grenade launcher on the other hand presented entirely different problems. A 40mm grenade in real life has a kill radius of about 5m with a casualty radius of about 15m. These are big numbers when you look at our interior spaces and, considering that you can fire several of these over a short space of time, you are left with a pretty powerful weapon. On the one hand we wanted to deliver a weapon that felt heavy and designed to rain down destruction, but on the other hand we didn’t want to massively wreck the balance of FPS combat.
With that aim, we made sure the numbers were slightly less than that of a normal frag grenade for both kill and injury radius. But if I’m being totally honest, I would say the grenade launcher is slightly too powerful in the current game. The main reason is that players have access to an infinite amount of ammo using the PMA, so we had to choose between releasing the weapon as intended or massively nerfing it until the physical inventory comes online. As a team we felt it was more representative of an experience to release the weapon as it’s supposed to work and wait for the other systems, such as physical inventory and physical damage, to balance out its sheer power. Then, players will have to consider how much space they allocate to ammunition and physical damage will cause weapons and armor to lose integrity when they are hit. This means if someone gets blown up by an explosion, a lot of their equipment will be damaged, which lowers the overall value. I have also seen the feedback regarding arming distance and it’s something that we will be working on.
Final Thoughts
If I look back across all the features that the Core Gameplay Pillar delivered for Alpha 3.11, I am happy with the results. However, this doesn’t mean everything went well or if I had that time again, I would do everything the same.
The main thing I think I would change would be how we implemented Force Reactions in the ships. Rather than treat it the same as all the other forces in the game (wind, bullets, etc) – which on the face of it makes sense – I would have designed it specifically around the gravity generator inside the ships. Currently we take the force that is applied to the ship and then directly apply it to the actor through filters depending on the force so that they react accordingly. Instead, I would have rather had the gravity itself react to the force, which would then cause the actor to react. While there would be no difference to the player, I think it would have been a cleaner implementation and be easier to extend the system in the future. For example, when we add gravity generator items, etc.
In the last two quarters we have also delivered two features (Body Dragging and Knockdowns) that would have really benefited from driven ragdoll. Unfortunately, that feature is not being delivered by someone on my teams, so I wouldn’t have necessarily been able to change anything. But looking back, I would have raised more visibility on the benefits of trying to push that feature forward. That is obviously a challenge with working on a 600-person team that is spread across multiple continents and has different priorities across multiple projects. Everyone is trying to deliver the best features/content/tech that they can to the highest possible quality and sometimes the stars don’t align when it comes to priorities. In this case, it is purely on my shoulders due to a lack of communication. As developers, we don’t always get it right when we’re in the thick of things, but hopefully this gives some insight into our processes and how we are always giving it 100% to try and create the best experiences for you to enjoy.
Richard Tyrer
Core Gameplay Director
Environments
Cargo Decks
For this release we were able to introduce the next step in adding complexity to our space stations. The idea for the major stations located around planets is that they would be more than just rest stops; they would have their own facilities dedicated to other services, like cargo.
For the exterior, we introduced new addon components that describe the infrastructure and large racks of containers implying the capacity of the location (which right now is purely visual, in the future we would like to include more interactive elements).
Inside, we wanted to expand the traversal routes. For this, we introduced the idea of a station having a main transit network that connects the various elements of the station together – commercial decks, cargo decks, etc.
For the interior of the cargo deck, there were a few elements we wanted to include. Firstly, for the hub area we wanted to describe a themed logistical experience for the player. This includes a section of a shipping warehouse that, in the future, will be a sandbox for mission content. For the main shopping space, we wanted to incorporate a few elements into one larger shop. Now we can see the cargo drop-off and pickup counter located within a mini logistic sorting office, the ship rental space is located off to the side, and the guild and supplies area is in the corner. Overall, this gives a more diverse experience for the player rather than separating all these elements into separate stores..
Planet Content
For this quarter we were able to keep momentum in updating the planets and moons in the Stanton System with the latest tools and tech we’re using to build out the Pyro System. The start of this was doing a global repainting pass to all planets and moons. Fundamentally, this painting process drives a lot of the latest features in how we’re unifying objects, so to get this into the game we needed to bite the bullet and do the first pass over everything. In the last patch, we introduced the new heightmaps, and now the new painting pass will take advantage of all this new data.
The second element we were able to introduce was a global improvement to all our geology packs. We now have the ability to specify terrain colour pickup for assets which will enable them to procedurally match the colour of the terrain or bedrock. Also, we were able to add asset tessellation and displacement on a per-object basis, which means we can assign heightmaps to assets that drive the displacement parameters. In a nutshell, this means when the player gets close to an asset it should be considerably higher in geometry resolution, giving a complex silhouette read.
Lastly, we replaced all of our terrain shaders with scanned data. This is something we’ve been looking into for some time as the quality of the results was extremely high, but with some of the latest tech, we were able to implement it into our pipeline. We recreated over 70 base shaders by combining and mixing the scanned data together to get the results we wanted. In the future, we have ambitions to set up dedicated scanning equipment to process our own data, which we’ll gather from field trips. We want to ensure we can create a diverse and wonderful palette for future Star Citizen locations.
Final Thoughts
We were able to introduce a lot of new tech in this release, as well as start to show the second round of polish updates on the planet surfaces. Also, with the introduction of scanned data for our surfaces, we saw a substantial jump in quality. However, some of the global painting passes were not as detailed and involved as we would have liked. This is mainly due to time restraints in the quarter. Some of the geology surfacing with the new libraries could be more appropriate to the biome/region also.
For cargo decks, we should have foreseen the disconnect between the interior and exterior when separating out the commercial decks. To improve the experience and help give context to the player we would like this transit network to be physicalized in the future. This will provide visibility out from the transit cab to the exterior of the station as it moves towards its destination.
Ian Leyland
Star Citizen Art Director
Design
Armistice Zones
The Armistice Zone relaxations are the first step in removing all arbitrary restrictions from the game, as and when we have the capability to properly defend and police the various areas of the game. This was possible at the rest stops because as well as reusing the existing size-4 turrets and size-6 sentries, we created an all-new size-10 turret. Together, these are capable of dealing with any ship planned to be in the game. And rather than impose yet another arbitrary restriction, we made the defenses fully destructible, though their respawn time is very swift at 5 minutes. This respawn system will be developed further in the future to likely rely on repair.
In concert with the defenses, we added the first iteration of a security response system which, while still quite simplistic, adds up the CrimeStats of all players in the area (known internally as “heat”) and spawns security ships of increasing numbers and strength in response. The system responds quickly to increases in an area’s heat by spawning in new ships and despawning out weaker ships they replace. The system responds slower to the killing of its members (should the heat not be raised by this) and slower still to decreases in heat. We will develop this system further in the future to also take into account the ships that players are using and the aggression shown.
We will roll this out across other locations like outposts, though Grim HEX will need a more complex solution as the defenses there should only respond to crimes committed in its jurisdiction and not in others. Olisar will remain an aberration as it is a legacy location that cannot support an Armistice Zone of the radius required.
The Live Team had to be extremely vigilant and quick to react to issues given the short time that Alpha 3.11 was running in the PTU. One example of an issue we noticed was players stealing the sentries by swallowing them in the cargo bay of their 890 Jumps and flying off with them. We rectified this by self-destructing sentries taken away from the area and respawning them. Another example is that while the security response was capable of quickly spawning ships on local severs, on a live server it was not. To try and improve this we reduced the thresholds that the system responded to in order to reduce the number of spawns requested.
We have seen videos of many players teaming up to overrun a rest stop and hold it for a long time despite the defenses and security response. Because of this, the moment the Idris became available, we added it to the top level of the response system, so we’re hopeful that those players would struggle to replicate this in the not too distant future.
Final Thoughts
Moving forward, we also plan to relax the arbitrary limitations found in interiors, again starting at the rest stops. We are already well underway with a spawn closet system that will allow us to spawn the guards necessary to police the area. As well as this, we are working on a security network that will know whether players have the right to be in certain areas and enable cameras, turrets, and guards to respond to trespassers, those with CrimeStats, or those in the process of committing crimes.
Luke Pressley
Lead Designer
See you in the ‘Verse!
We believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we’re committed to transparent development and will continue to provide quarterly patch postmortems going forward.
On October 8, 2020, we launched Alpha 3.11 High Impact, which introduced a number of new features and changes, including cargo decks, force reactions, and the first stage of the wider Armistice Zone removal. The following is a postmortem from the senior developers themselves, detailing what was delivered and their thoughts on how it went. Vehicle Team
The Vehicle Pillar had a much lighter quarter with Alpha 3.11 compared to the bumper delivery in Alpha 3.10, but what we delivered hopefully had a big impact on the gameplay experience.
Origin 100 Series
The Vehicle Content Team delivered the Origin 100 Series in Alpha 3.11, comprising of the 100i, 125a, and 135c. The 100 Series adds an alternative starter ship to the game as well as a light fighter and light cargo hauler. These are fantastic little ships for new players to start their Star Citizen journey with and provide the ability to tackle a wide range of missions and explore the far reaches of the ‘verse. Missiles & Countermeasures
The missile and countermeasure gameplay had been in various states over the years and was never truly enjoyable from the aggressor or defender side. We’re aiming to ultimately fix that with Missile Operator Mode, but until that is delivered, we decided to spend the time implementing fixes and iterations to the gameplay to provide a taste of what that feature will deliver. The main issues with the missiles prior to Alpha 3.11 were as follows: Countermeasures would act only on IR missiles (flares) and EM missiles (chaff)
Only flares worked (sometimes and highly server-dependant)
There were no countermeasures available to spoof CS missiles
Firing missiles was extremely easy, defending against missiles was extremely hard
First, we investigated why only flares would work and chaff wouldn’t. The issue was a combination of incorrect setup data in some ships, incorrect data in some countermeasures and missiles, and a now-redundant workaround originally created for a specific SQ42 level that had knock-ons game-wide.
Once we fixed those issues, we recognized that the signature system has two distinct ways of modifying signals – either creating a strong signal or dampening all signals around. We decided to embrace that difference instead of requiring pilots to play “whack-a-mole” by choosing the “right” countermeasure for the “right” missile type whilst under the stress of having a few seconds to decide before impact. With that in mind, we did some playtests with the following changes: Flares would act on all missile types
Chaff would be turned into a noise field, dampening all signatures around the field
Right away, the first gameplay tests proved that this was a much more engaging way to defend against missiles. We then went ahead and updated the HUD elements of the missile warning system, re-added a countermeasure widget, and updated the keybinds to allow direct launching for each countermeasure type. The UI and VFX teams then jumped in and beautified everything, replacing the effects and also fixing a couple of VFX related bugs (like countermeasures being invisible in the PU).
One future addition that we couldn’t do in time for Alpha 3.11 was to change the names of “flares” and “chaff”. Both names are very common for flight sim communities, but we still want to rename them to make it clear that Star Citizen uses different concepts for defending against missiles. This will require us to record new VO lines to update ship computer voices. Each vehicle is only allowed four locks at a time
Only one missile can launch per rack at a time
Only one missile type (IR/EM/CS) can launch at a time
Missiles lose lock outside of their locking angle
Once we had these measures in, the missile experience notably improved in early testing. The spamming of missiles was significantly reduced, and the meta shifted towards ships getting very close to each other and firing missiles at distances where the defender would not even get a missile warning before impact. As a result of this undesirable change, we introduced minimum and maximum lock ranges. This notably stretched the missile gameplay out of gun range, allowing missile-focussed ships to loiter at the edge of combat as designed while dedicated gunfighters would get in closer. This also allowed us to increase the locking angle of smaller missiles so that ships like the Constellation (that do not fire missiles forward but slightly off-angle) were viable to use missiles again.
A lot of these changes (especially to the missiles) are temporary to give a better experience until Missile Operator Mode is ready, which will change the behaviour again and/or remove certain aspects when it is implemented. Final Thoughts
The overall goal we want to achieve in the missile gameplay loop is to make both employing missiles and defending against missiles deeper and more rewarding, with its own “slot” in the combat environment. Missiles are not supposed to be an alternative to guns but tactical weapons, and the use of them should be a conscious decision with consequences. We also want to give special missile boats, like the Talon Shrike or Freelancer MIS, an edge when it comes to employing ordnance for the same reason. Those ships will excel in offensive missile gameplay though have obvious drawbacks in other categories. So, there will be more iterations on countermeasures and missile gameplay in the next couple of releases. For the time being though, we’re quite happy the missile experience stepped away from the frustrations of previous releases.
John Crewe
Vehicle Director
Technology
Canvas Decal System
For Alpha 3.11, the Graphics Team delivered underlying rendering tech to help power the ‘canvas decal’ system, which leverages the Building Blocks system to create decal textures at runtime. These decals can be used for signposting, on clothing, or even the signage on vehicles. The advantage of the decals being created at runtime is that we can use game data such as the player’s name or even have the content translated to the language the game is being played in.
To make this feature scalable for wider use in the PU, the system is tightly coupled with the texture streaming system, such that the dynamic textures are ‘streamed in’ using the same logic as standard textures, which ensures we always maintain a fixed memory budget. This streaming logic ensures we can automatically run the same feature set on low-spec machines by carefully load-balancing texture resolutions on the fly, but also allows us to push the texture resolution as high as possible on more powerful machines. Integrating the canvas decals into texture streaming resulted in several crashes in the PTU that were very difficult to track down and took a lot of time to resolve. As a result, we wrote some documentation to help future programmers understand the complexities of the texture streaming system, which will be especially important as we plan to generalize the code and use it for mesh streaming too. Planet Tech
On the planet-tech side, we added several features, including improvements to planet tools. This includes new painting brushes, revamped UI, and merged ground layer and object presets to make it even faster to paint planets. Utilising the new planetary painting tools, the Environment Art Team went through all planets and moons in the Stanton System and repainted the ground surfaces and object presets. This also futureproofs us and allows us to take advantage of new tech in existing locations. On a per-object basis, we are now able to support HW tessellation displacement on geology distributed across terrain to give it a more detailed and organic appearance. There were also several ocean and water related improvements, including ground cover buoyancy, which we will continue to expand upon in the future, as there wasn’t enough time during this release cycle to introduce larger floating objects.
A lot of time in the past few months was dedicated towards continued research and development of the atmosphere and cloud renderer, including the planet atmosphere unified raymarcher. We will go into more detail once the system becomes available. For now, let’s just say we worked on various algorithms to allow raymarching at lower-than-screen resolution and denoise and upsample the results to full resolution to improve the performance of costly raymarching operations. These are combined with reprojection techniques and the bundling of raymarch requests for pixels to be updated each frame to further improve performance. Additionally, our existing multiscatter solution now supports a significantly higher number of scattering orders, which will be important for very dense atmospheres. BTW, we’re now in the very early days of volumetric cloud rendering R&D…
Almost a byproduct of this work, we made various improvements to the existing atmosphere rendering technology. First and foremost several long-standing artifacts, such as false color rendering in twilight near the atmosphere top along with very prominent halos around the silhouette of a planet’s dark side, have been addressed. The generation of lookup tables now uses a better-suited method to generate sample locations for numerical integration over (hemi)spheres. That and other numerical precision improvements led to more accurate results in those tables at reduced computational overhead. We didn’t stop there, however, and implemented additional visual improvements for you to hopefully enjoy soon. One of them includes evaluating how much of the sun’s disc is visible when computing how much sunlight reaches point x in-atmosphere. This evaluation is fully integrated into the entire atmosphere lighting system and impacts direct and indirect lighting. Moreover, we added support for an absorption layer. Among other things, this allows us to add an ozone layer to Earth-like planets that emphasizes the blueness of the sky and enables better shading in twilight (removing yellow tint). We now also incorporate IRL extraterrestrial sun radiometry data when running the light simulation instead of assuming a “pure white” light source as well as an approximate conversion from spectral radiance (the result of the atmosphere lighting simulation) to luminance (used to light the scene in a traditional sense). Lastly, we improved the evaluation of sun radiance received by points outside the planet’s atmosphere. It now casts twilight due to atmospheric scattering and the impact of the sun’s angular radius onto objects in a planet’s penumbra region. This should add a nice touch to capital ships or moons orbiting planets. Engine
On the engine side, several improvements were made. We updated our compiler toolchain to VS 2019, which will allow for faster compile and link times. Moreover, we’ve added support for Intel SPMD Program Compiler (ISPC). This will allow us to write target-agnostic SSE optimized code (think HLSL) for heavy duty CPU compute jobs and will fully utilize CPU capabilities on each individual machine that the code runs on. Several code paths in physics, the 3D engine, and the zone system are in the process of being ported. And, we have another compiler optimization in store for you. AVX code generation support for clients was previously enabled and should hit the public servers in the coming Alpha 3.12 release.
Regarding server and client memory usage, we spent a good deal of time further refining our tracking tools to ensure we have good visibility on where we spend memory. We’re now also able to properly track memory usage in third-party libraries that either don’t allow us to reroute memory allocation through our system or haven’t been updated yet to do so. We still plan to get a bit more visibility on client-side video memory allocations on the driver level (below the level we can currently track as an application using the GPU). As a result of these improvements, ongoing investigations, and tracking, a few critical memory leaks were fixed for release.
Throughout Alpha 3.11 production, the Core Engine Team was mostly focused on features for later releases, like the Gen12 Renderer. However, a very large bug was fixed, which caused all our objects on clients to unload way earlier than we intended. Objects on clients should now stay streamed for noticeably larger distances. Audio
For audio tech, we updated the Wwise version to 2019.2.4, which fixed several issues. As part of this endeavour we reworked memory management within the audio system, going from a group of memory pools to a single pool. This allows us to deal more easily with the many different situations that Star Citizen presents by allocating memory where it is needed, when it is needed. We spent a lot of time revisiting our voice budgets to improve the overall experience and to allow players to hear more of what’s going on in the game. Weapon fire support, particularly at long distance, was improved and several issues with audio fire rates and weapon volumes were fixed. Canvas Slicing
This quarter the UI-Tech team has been working on a system called the Canvas Slicer. This is a sub-system of Building Blocks which will allow the UI designers to place slices of 2D UI in 3D space. Normally, when we draw 2D UI, it gets rendered to a texture and then that texture is applied to geometry such as a monitor panel or data-pad. With the Canvas Slicer, we create the geometry at any position in 3D-space at runtime and draw the 2D UI directly onto it. This means we will be able to produce interesting layered UI, such as holographic ship HUDs and helmet displays. Tooltips
We have also started designing our tooltips system for Building Blocks. On the surface, this looked like a simple system to implement but the requirements to ensure it is super flexible have meant we’ve got quite a lot to think about before we start implementation.
Marco Corbetta
VP of Technology
Core Gameplay
External Inventory
External Inventory is the first iteration of our grid-based inventory interface that allows players to manage their FPS commodities between their backpack, chest, and leg pockets. As it says in the name, the External Inventory also allows players to directly interact with other storage containers in the world and drag and drop items between them. In Alpha 3.11, this is only enabled for the Greycat ROC storage compartment so players can manage their FPS mineables. But, in the future and once we realise true item storage (underpinned by iCache), this will allow players to store items in compartments, crates, and other such external inventories.
While on the face of it, a new inventory UI and being able to drag and drop items between storage containers may sound simple, we had to overcome several creative and technical challenges. The main creative challenges revolved around having an interface that felt tactile and accessible to use without just feeling like a standard 2D interface that you see in most RPGs. This wasn’t because those inventories are bad, more that we didn’t want players performing inventory Tetris to manage their items; we wanted players to freely move items between storage containers without having to worry about where they dropped the item or if another item was in the way. We were able to achieve the first iteration of this using our Building Blocks technology, which stores the items as a list rather than a 2D grid. This means items fluidly move around your cursor as you drag objects between containers. We still want to further improve on the overall feel, but the team is happy with the initial outing.
While Building Blocks allowed us to deliver on the creative aspects of the design, it also provided the main technical challenge. As the technology is still being developed, it means it doesn’t always support things that you need to deliver a feature. In the case of External Inventory, we wanted the UI to feel diegetic and 3D even though it is not. This meant we wanted all the icons to be holographic, like they were being displayed in AR directly in front of your eyes. Unfortunately, our 3D icons could only support a limited shader which meant we lost a lot of material detail from the items being displayed. At this point we could have delayed the feature, but the team and I felt it was important for us to go live and get as much feedback as we could between now and a true physical inventory. We will definitely be upgrading that shader in an upcoming patch. Force Reactions
At its core, Force Reactions is a system developed to simulate what a character would do when impacted by a force, whether that is a strong gust of wind or a bullet penetrating their shoulder. It can be split into three levels of impacts: Low impact: twitches, flinches, and leans
Medium impact: staggers
High impact: knockdowns
In Alpha 3.10, we delivered the first iteration of low-impact reactions with the procedural twitches in FPS combat and leaning during sustained winds. In Alpha 3.11, we added more ‘feels’ to the twitches with additional camera and weapon reactions and our first iteration of knockdowns, with the intention for staggers to come later.
The biggest challenge for this system was that it needed to be truly systemic as forces can come from a lot of different places, not just bullets. For this, we broke down the forces into three main categories: Direct forces: anything that physically impacts the character, like a box or bullet
Indirect forces: the force you receive when your ship gets rammed or from a gust of wind
Sustained forces: where a force is constantly applied, such a g-force or wind
This meant we could compartmentalise different forces with different scales and allow the designers to balance the character’s reaction accordingly, as the forces of being hit by a box compared to the acceleration of a ship in space to 1000m/s are vastly different. While low-impact reactions do not take away any player control, we were very cognizant of the fact that knockdowns would. We spent a lot of time making sure the knockdown animations were very reactive to player control as soon as their character hit the ground. We also implemented a skill-based system that meant if you tried to ADS before touching the floor you would trigger a faster recovery animation, meaning you could get back into the action quicker.
Force Reactions in Alpha 3.11 was our second delivery and will be by no means our last. We are actively working on medium-impact reactions and will be constantly reviewing and tweaking the balance going forward, especially in FPS combat.
Throwing T1
Throwing grenades or other objects has always been a bit inconsistent and is even more disappointing when you think you have that perfect multi-kill opportunity for the grenade to just whimper a few feet from you. So, the first thing we wanted to achieve with T1 was to make throwing much more reliable, so that the object you throw (whether a grenade or other object) goes where you expect it to go. The second biggest objective, which is a critical pre-requisite for the physical inventory, was for the throw system to be able to interact and co-exist with the carriable system.
In Alpha 3.10, if you picked up a grenade from the floor and then tried to throw it, there was no way for you to pull the pin. Also, if you pressed the ‘Throw Grenade’ hotkey, you would drop the grenade in your hand and pull a new one from your suit. Obviously, this is not the intended behaviour and was a major reason why we changed throwing to come from an equipped state (i.e. holding the grenade in your hand) rather than directly from your suit. This system will also allow us to deliver gadgets and deployables in the future.
As part of T1, we also added a UI ‘throw arc’ that allows you to see the trajectory of the grenade. While currently this is enabled for all helmets, it will only be accessible from combat helmets once we start to define different armor archetypes in the ‘verse.
Behring Grenade Launcher & Behring BR2 Shotgun
Ever since I have been directing weapons, we have been trying to make sure that every weapon we add to the game has a unique purpose or playstyle that it suits. Currently, we already have several live shotguns that are deadly when up-close-and-personal but ineffective beyond that. With Behring being a manufacturer that we have identified as being middle of the road when it comes to damage, fire rate, and accuracy, we felt the BR2 was our first opportunity to push the range out for a shotgun to provide a bit more oomph in mid-quarter combat without it dominating at close-quarters. While we were happy with the BR2, we are not necessarily happy with shotguns as an overall class as they are outgunned by SMGs and outranged by assault rifles. We will be doing an update to all the shotguns in an upcoming patch to give them greater identity.
The Behring grenade launcher on the other hand presented entirely different problems. A 40mm grenade in real life has a kill radius of about 5m with a casualty radius of about 15m. These are big numbers when you look at our interior spaces and, considering that you can fire several of these over a short space of time, you are left with a pretty powerful weapon. On the one hand we wanted to deliver a weapon that felt heavy and designed to rain down destruction, but on the other hand we didn’t want to massively wreck the balance of FPS combat.
With that aim, we made sure the numbers were slightly less than that of a normal frag grenade for both kill and injury radius. But if I’m being totally honest, I would say the grenade launcher is slightly too powerful in the current game. The main reason is that players have access to an infinite amount of ammo using the PMA, so we had to choose between releasing the weapon as intended or massively nerfing it until the physical inventory comes online. As a team we felt it was more representative of an experience to release the weapon as it’s supposed to work and wait for the other systems, such as physical inventory and physical damage, to balance out its sheer power. Then, players will have to consider how much space they allocate to ammunition and physical damage will cause weapons and armor to lose integrity when they are hit. This means if someone gets blown up by an explosion, a lot of their equipment will be damaged, which lowers the overall value. I have also seen the feedback regarding arming distance and it’s something that we will be working on.
Final Thoughts
If I look back across all the features that the Core Gameplay Pillar delivered for Alpha 3.11, I am happy with the results. However, this doesn’t mean everything went well or if I had that time again, I would do everything the same.
The main thing I think I would change would be how we implemented Force Reactions in the ships. Rather than treat it the same as all the other forces in the game (wind, bullets, etc) – which on the face of it makes sense – I would have designed it specifically around the gravity generator inside the ships. Currently we take the force that is applied to the ship and then directly apply it to the actor through filters depending on the force so that they react accordingly. Instead, I would have rather had the gravity itself react to the force, which would then cause the actor to react. While there would be no difference to the player, I think it would have been a cleaner implementation and be easier to extend the system in the future. For example, when we add gravity generator items, etc.
In the last two quarters we have also delivered two features (Body Dragging and Knockdowns) that would have really benefited from driven ragdoll. Unfortunately, that feature is not being delivered by someone on my teams, so I wouldn’t have necessarily been able to change anything. But looking back, I would have raised more visibility on the benefits of trying to push that feature forward. That is obviously a challenge with working on a 600-person team that is spread across multiple continents and has different priorities across multiple projects. Everyone is trying to deliver the best features/content/tech that they can to the highest possible quality and sometimes the stars don’t align when it comes to priorities. In this case, it is purely on my shoulders due to a lack of communication. As developers, we don’t always get it right when we’re in the thick of things, but hopefully this gives some insight into our processes and how we are always giving it 100% to try and create the best experiences for you to enjoy.
Richard Tyrer
Core Gameplay Director
Environments
Cargo Decks
For this release we were able to introduce the next step in adding complexity to our space stations. The idea for the major stations located around planets is that they would be more than just rest stops; they would have their own facilities dedicated to other services, like cargo.
For the exterior, we introduced new addon components that describe the infrastructure and large racks of containers implying the capacity of the location (which right now is purely visual, in the future we would like to include more interactive elements).
Inside, we wanted to expand the traversal routes. For this, we introduced the idea of a station having a main transit network that connects the various elements of the station together – commercial decks, cargo decks, etc.
For the interior of the cargo deck, there were a few elements we wanted to include. Firstly, for the hub area we wanted to describe a themed logistical experience for the player. This includes a section of a shipping warehouse that, in the future, will be a sandbox for mission content. For the main shopping space, we wanted to incorporate a few elements into one larger shop. Now we can see the cargo drop-off and pickup counter located within a mini logistic sorting office, the ship rental space is located off to the side, and the guild and supplies area is in the corner. Overall, this gives a more diverse experience for the player rather than separating all these elements into separate stores..
Planet Content
For this quarter we were able to keep momentum in updating the planets and moons in the Stanton System with the latest tools and tech we’re using to build out the Pyro System. The start of this was doing a global repainting pass to all planets and moons. Fundamentally, this painting process drives a lot of the latest features in how we’re unifying objects, so to get this into the game we needed to bite the bullet and do the first pass over everything. In the last patch, we introduced the new heightmaps, and now the new painting pass will take advantage of all this new data.
The second element we were able to introduce was a global improvement to all our geology packs. We now have the ability to specify terrain colour pickup for assets which will enable them to procedurally match the colour of the terrain or bedrock. Also, we were able to add asset tessellation and displacement on a per-object basis, which means we can assign heightmaps to assets that drive the displacement parameters. In a nutshell, this means when the player gets close to an asset it should be considerably higher in geometry resolution, giving a complex silhouette read.
Lastly, we replaced all of our terrain shaders with scanned data. This is something we’ve been looking into for some time as the quality of the results was extremely high, but with some of the latest tech, we were able to implement it into our pipeline. We recreated over 70 base shaders by combining and mixing the scanned data together to get the results we wanted. In the future, we have ambitions to set up dedicated scanning equipment to process our own data, which we’ll gather from field trips. We want to ensure we can create a diverse and wonderful palette for future Star Citizen locations.
Final Thoughts
We were able to introduce a lot of new tech in this release, as well as start to show the second round of polish updates on the planet surfaces. Also, with the introduction of scanned data for our surfaces, we saw a substantial jump in quality. However, some of the global painting passes were not as detailed and involved as we would have liked. This is mainly due to time restraints in the quarter. Some of the geology surfacing with the new libraries could be more appropriate to the biome/region also.
For cargo decks, we should have foreseen the disconnect between the interior and exterior when separating out the commercial decks. To improve the experience and help give context to the player we would like this transit network to be physicalized in the future. This will provide visibility out from the transit cab to the exterior of the station as it moves towards its destination.
Ian Leyland
Star Citizen Art Director
Design
Armistice Zones
The Armistice Zone relaxations are the first step in removing all arbitrary restrictions from the game, as and when we have the capability to properly defend and police the various areas of the game. This was possible at the rest stops because as well as reusing the existing size-4 turrets and size-6 sentries, we created an all-new size-10 turret. Together, these are capable of dealing with any ship planned to be in the game. And rather than impose yet another arbitrary restriction, we made the defenses fully destructible, though their respawn time is very swift at 5 minutes. This respawn system will be developed further in the future to likely rely on repair.
In concert with the defenses, we added the first iteration of a security response system which, while still quite simplistic, adds up the CrimeStats of all players in the area (known internally as “heat”) and spawns security ships of increasing numbers and strength in response. The system responds quickly to increases in an area’s heat by spawning in new ships and despawning out weaker ships they replace. The system responds slower to the killing of its members (should the heat not be raised by this) and slower still to decreases in heat. We will develop this system further in the future to also take into account the ships that players are using and the aggression shown.
We will roll this out across other locations like outposts, though Grim HEX will need a more complex solution as the defenses there should only respond to crimes committed in its jurisdiction and not in others. Olisar will remain an aberration as it is a legacy location that cannot support an Armistice Zone of the radius required.
The Live Team had to be extremely vigilant and quick to react to issues given the short time that Alpha 3.11 was running in the PTU. One example of an issue we noticed was players stealing the sentries by swallowing them in the cargo bay of their 890 Jumps and flying off with them. We rectified this by self-destructing sentries taken away from the area and respawning them. Another example is that while the security response was capable of quickly spawning ships on local severs, on a live server it was not. To try and improve this we reduced the thresholds that the system responded to in order to reduce the number of spawns requested.
We have seen videos of many players teaming up to overrun a rest stop and hold it for a long time despite the defenses and security response. Because of this, the moment the Idris became available, we added it to the top level of the response system, so we’re hopeful that those players would struggle to replicate this in the not too distant future.
Final Thoughts
Moving forward, we also plan to relax the arbitrary limitations found in interiors, again starting at the rest stops. We are already well underway with a spawn closet system that will allow us to spawn the guards necessary to police the area. As well as this, we are working on a security network that will know whether players have the right to be in certain areas and enable cameras, turrets, and guards to respond to trespassers, those with CrimeStats, or those in the process of committing crimes.
Luke Pressley
Lead Designer
See you in the ‘Verse!
We believe that giving this level of insight into our development process is highly valuable, especially when you can read the thought processes, reflections, and learnings direct from our senior developers. As mentioned last time, we’re committed to transparent development and will continue to provide quarterly patch postmortems going forward.
Links
No links available.
Images
8
Metadata
- CIG ID
- 17887
- Channel
- Undefined
- Category
- Undefined
- Series
- None
- Comments
- 63
- Published
- 5 years ago (2020-11-20T04:00:00+00:00)