FOUNDRY 42: DE



ENVIRONMENT ART The Environment Art Team recently wrapped up polishing the existing moons in the persistent universe. Cellin, Yela, Daymar and Delamar all received a visual update that will further enrich the experience at each location for the 3.1 release. With the update of the existing locations completed, the team is shifting focus to Hurston. Hurston will benefit massively from new planet tech updates, and further additions to the planet tech are on the roadmap for the coming weeks. The numerous updates will help make Hurston a unique experience, pushing biomes further than what players have seen so far on the existing moons. The team is also close to wrapping up the whitebox stage of the Lorville landing zone. Layout and locations have been approved by all departments involved, and the team is preparing to start full production to bring the city to its next stage.







ENGINE The Engine Team regularly works on both long-term items as well as low level bugs and performance, and this month was no exception. They refined the auto performance capture code and tools used to track heavy stalls on both client and server. The tools automatically take performance captures if the frame rate falls below a given threshold for a specified amount of time. They then analyze the captures and optimize code, content, and level set up if necessary.



They made further progress on the performance telemetry system that will submit data so the team can analyze what typically happens on servers and clients, what actions cause performance slowdowns, etc. The data should allow them to tweak the game and improve the overall player experience. They also continued to work on reducing the initial startup time of the game. They found a lot of inefficient data parsing meant that the game would launch slowly, especially during the first startup on HDD s after the computer had been booted up.



The Engine Team worked on optimizations of the physics terrain mesh generation, and optimized data layout and SSE instructions to improve computation speed. They reworked API for component updates to provide more flexibility and opportunity for further code optimizations, batching of updates, etc. The team handled rendering improvements for the vegetation shader. Good progress was made on skin rendering improvements, which included work on rendering eyes, teeth and tongues. An investigation into pushing the quality and fidelity of facial animations was kicked off. Plus, they continued code size and build time investigations. It’s an ongoing effort to uncover the reasons for increased code size and compile times to see what can be reduced. This is an ongoing task and the findings will be applied globally.



TECH ART The Tech Art Team built a new tool called cigXfer. It helps artists transfer skin data on various meshes, as well as on LOD meshes, without any assistance from a tech artist. This significantly speeds up the art update process, enabling artists to be more self-sufficient. They also implemented a large amount of animations that will be used for Squadron 42 cinematics.



They collaborated with the Weapons Team to complete the previsualization rig and game entity for the Kastak Arms Scalpel sniper rifle. Work was done on a run time physic simulation for a portion of the handle of the combat knife. Research and development was done to refine the alignment of the camera with the sight of a weapon while leaning. They developed content with an additional bone titled “ADS_align” to help achieve the desired results. They are currently testing the new approach on the Klaus & Werner Gallant rifle, and once verified it will be replicated to additional weapons.



The team worked with Art and Tech Design to produce Centurion and Imperator weapon skins for the Gemini LH86 pistol, Kastak Arms Devastator shotgun, and Klaus & Werner Arrowhead sniper rifle. They also continued R&D and implementation of the tools required for the next iteration of the Character Customizer. They primarily focused on consolidating how hundreds of head and head attachment assets (i.e. hair, beards or helmets) are being authored in Maya and then exported into the engine. Since every attachment is supposed to work with every possible head shape, even procedurally generated ones, they had to ensure the head topology remained 100% consistent during export.



LEVEL DESIGN The PU Level Design Team had several locations to design, and tech needed for future content building to work on. Lorville, a flagship landing zones, received quite a bit of attention, and is being used as a test bed for numerous systems and Common Elements. These systems include Security, Smuggling, Transit, Air Traffic Control, Hangars, etc. The Common Elements work in tandem with these systems and serve as their representation in the game world: for example, a Security Office and guards for Security, Customs for Smuggling, Train Stations for Transit, and a Spaceport for the Air Traffic Controller and Hangars. To connect everything there needs to be transitional spaces, arrival areas, and terminals to make it feel believable, while being diligent about not inflating the playable space too much. Here are some examples of these transitional spaces:





















They also continued work on the Procedural Tool for generating interior spaces. This tool is essential for Level Design to efficiently deliver the amount of content needed for generic locations like Rest Stops, Refineries, Cargo Depots etc. The tool is still in progress and will require more iterations and additions before it’s ready, which is a natural part of the R&D process. Here are examples of two generated layouts seen top down as a comparison:





CINEMATICS The Cinematics Team supported Squadron 42 level design efforts that previously had a lower priority. For these chapters, they blocked out and completed quick previs animation exports where level sections are still in the whitebox phase. For locations that are further along, like the Idris (Stanton) and the Bengal carrier, they did performance capture animation exports aligned to geometry and a defined scene root for all actors in the scene. This is an ongoing effort, as each chapter has a huge number of narrative scenes ranging from comms calls, conversations, walk & talk greetings, NPC chatter, and more complex scenes with multiple key characters in full-on filmic cinematics. In addition to the previs exports, they also focused on a handful of scenes featuring Gillian Anderson as Captain Rachel Maclaren. With the Vanduul Kingship bridge almost finished, they did a first camera pass on the cinematic Vanduul character sequences required for the story. This work coincides with a concentrated push for the Vanduul across different departments. Currently, Tech Animation is working on the Vanduul face rig, Character Art and Animation tackling costumes, key poses & silhouettes, and the Weapons Team focusing on Vanduul weaponry.



An important part of cinematics work is to regularly sync with ship and environment artists. The teams discuss issues with the default metrics dictated for mechanisms like doors, displays, chairs and the existing geometry, or address problems that arise when performance capture deviates slightly from metrics or meshes. Most of these metrics were in place for the main shoot, but occasional tweaks or updates must be made to either meshes or the animation. It always requires the teams to carefully weigh what requires the least amount of rework and impact. Cinematics also supported Graphics Engineering to upgrade the human skin shading. They built a test lighting setup that mimicked reference photographs and replicated a PCAP head-camera setup in the engine. Results of this R&D and shading work will be seen in the coming months.



LIGHTING The DE Lighting Team supported the 3.1 patch. Their recent focus was finalizing a new lighting pass on the Echo 11, as changes to the lighting tools and technology have left the Star Marine maps visually out of sync. They’ve also helped the planet team with minor tweaks and polish to the atmospheres and color grading for Crusader’s three moons and Delamar. In addition, they assisted with several 3.1 goals, such as the new mobiGlas PMA /VMA character and item rendering, the Character Customizer, and general optimizations.



VFX

The DE VFX Team worked with UK programmers to further improve various tools, such as curl noise. This is a 3D noise field that perturbs the particles as they travel through the field, which creates some very unique and volumetric looking effects. They’ve also been fleshing out the Vanduul tech style, experimenting with the curl noise in combination with vector fields to create a visual style that sets the Vanduul apart.



WEAPONS

The DE Weapons Team finished the first art pass for the Kastak Arms Scalpel sniper rifle, and completed the Centurion and Imperator subscriber flair skins for a few weapons.



SYSTEM DESIGN The DE System Design Team moved forward with the mining system. Their first goal is to get mining functional for planet/moon surfaces, so the Prospector will be fully operational. They will move on to additional mining types once that is completed. Mining is still being prototyped but the current results are promising from a gameplay and visual perspective. They are currently able to shatter mineable rocks, and are working on the harvesting functionality that will transfer resources from those smaller pieces into the Prospector’s mining containers. Once completed, they will integrate mining with other systems like radar and scanning, which will be used to find mineable deposits and analyze their contents.



Progress was made on FPS Combat AI. After solving low cover, they implemented high cover for Human AI, and focused on making the timings and transitions as snappy as possible. Now, they are slowly moving into more complex behaviors like flanking, which allows the AI to work better as a team and force the player to think tactically and constantly adapt to what the AI is doing. They also considered what elements from human combat could be used by alien races, and experimented with ways to make them feel unique, so players must deal with aliens differently than their human counterparts.



The first batch of the reworked ship AI is now in 3.1, though some additional functionality is still outstanding. The system is being built so players can choose how to train and specialize their hired NPC s. FPS AI will use the same system in the future to achieve similar goals. On the non-combatant side of AI, they experimented with creating small story vignettes for locations, focusing on Lorville. This should infuse the location with more life and grant the AI more storytelling ability than walking around and sitting on benches. The hope is for players to experience what the lives of the population in a location are like, sympathize with them, and potentially choose sides. To achieve that, the non-combatants need to become more lively and complex.



Towards the end of the month, the team worked closely with Level Designers and Artists on the procedural location tool. They focused on the functionality needed for the tool to create nice environments and connect gameplay systems, like rooms, oxygen, gravity, security and generated AI populations. The tool must do it in a way that once the location is generated, there will be only minor adjustments before it can be released. The goal with this system is to ensure the team can output quality content at lightning speeds with a minimal amount of menial work. That way the team can quickly fill an entire universe, while keeping it feeling specific, depending on the location.



BUILD ENGINEERING The DE Build Engineers added a sanity check for the RC to TryBuilder. While engineers work, they may change the Resource Compiler (RC), which can sometimes lead to failed builds. With so many unique asset types, it becomes difficult for an engineer to ensure that nothing is going to break. Additionally, engineers may touch a cpp file without even being aware that it may affect the RC. To alleviate this, they isolated a minimal subset of assets and now have them compiled whenever any code in the main branch changes. Each code change that goes into p4 is checked and the whole process is quick, essentially compiling one sample of every type of assets in the Engine. Now, before starting the process of creating a new a build, the team can check the state of RC. If it’s red (as in, the process described above is failing) they know there’s an issue to address. They also added some powerful dedicated hardware to the TryBuild cluster for profiling speed improvements in compilation. This has brought compilation times down significantly, which shifted focus back to optimizing other steps whose build-times now contribute a proportionally significant amount towards the entire build time.





QA

PTU

AI

FPS

The above illustrates a Perforce-state caching mechanism and smart querying method for comparing local workspace to the relevant global branch the code is being built on. This simplified state-caching mechanism is used to determine if any further version-control communication is necessary. Initial optimizations removed 30 seconds from any build regardless of the machine’s state. In further precise situations, where the slave is confirmed up-to-date, it skips syncing entirely. That saves an additional 30 seconds minimum, yielding build results that can potentially be as low as 15 seconds total. In addition to adding dedicated hardware and eliminating time-costing checks from bootstrap steps for code validation, the team is now looking at binary caching mechanisms so the code-building machines can simply retrieve the compilation results that have already been processed.For the DE QA team, most of March centered around Subsumption testing with a new version available to test each week. As new features are implemented into the Subsumption Tool, the team maintains and revamps the existing documentation and checklists to ensure QA covers all necessary test cases for Subsumption testing. DE QA also supported the in-house development team with various requests from simple tests to verify if issues devs have encountered are due to their local files or an actual issue within the current build, to the more complex tests that require custom binaries and comparing differences between builds. One recent request involved testing changes that could potentially affect prefabs within the Engine. Extensive prefab testing was performed using custom binaries and test cases to intentionally attempt to break the prefab system. When an issue was discovered, this was brought to the Engine Team’s attention, and they proceeded to fix the issue and return new binaries to continue the testing. Similarly, the team focused on numerous physics test requests for changes that could potentially break other functionality within the client. These changes contained stability improvements to address various physics crashes that were plaguing Evocati in the. While they normally work in the Game-Dev stream, most of the testing was focused on 3.1 as the live release date closed in.Focus was primarily devoted to stabilizing the dogfight behavior. Flight AI is a young system, and the team is working on the skill characterization of the pilot’s abilities to balance the overall combat experience. A pass was made on the target chase velocities and attack ranges, two important factors to render the combat dynamics less prone to collide with obstacles or escape the assigned boundaries. The AI team also worked on improving player interaction with combat AI. This comes in the form of new behaviors, internally tweakable parameters (like accuracy and missile usage) for designers, and adding wildlines for PU pilots. For AICombat, they are currently implementing flanking behavior. Further work was done to update the logic for bullet rain, and improve flinch reactions when an AI’s cover gets compromised and they need to leave quickly or target and shoot. In addition, the team addressed bugs and optimized the code for the 3.1 release.