Work on Lorville continues with the team looking to modify the arrival area with a few additional shops and features to make it feel more like an active spaceport. The end goal is to have an area that quickly brings the player into the city, but also offers a few select amenities for those who need it.
There will also be a few minor changes to Levski to reflect the content added to Lorville. Although the rework is minor, it will add a few new things and bring Levski closer to its intended purpose and full potential.
Both the Transit System and procedural tech is progressing, and the team is close to adding a new and more stable version of elevators along with moving trains/trams. Level Design also gained a new team member this month, so time was spent onboarding and getting them acquainted with our tools and best practices.
Frankfurt System Design focused mainly on AI improvements. They worked on populating Lorville with an assortment of civilians, engineers, guards, workers, etc. In general, they’ll exhibit similar behaviors as the NPC
s that already exist in PU, but with more depth and flavor to help them better match the lore of the area. A lot of design work went into having the AI interact with one another and respond appropriately to events and stimuli generated by other NPC
s or the player. For guard NPC
s, they worked on designing a patrol system from the ground up. This should allow them to quickly map interest points and connect them with probability paths to define a patrol route that can change dynamically based on rules the designers control, or on game-driven events. At the same time, they are improving the existing simple patrol behaviors and prototyping more features in order to have an initial implementation for future releases before the actual system comes online.
Combat AI had numerous improvements which will hopefully be in players hands in the near future.
For mining, they worked on getting some well-needed improvements to how the instability, resistance, and optimal window size are calculated. They decoupled the window size from instability, so now players can have unstable rocks with a large window and also stable rocks with a very tiny window. This allows the team to better control the difficulty of a rock without having to clamp its values artificially. Work was also completed on the asteroid side of mining and the team’s close to having things working as initially intended. A lot of work has gone into how rocks are spawned in space using the existing procedural asteroids.
The Engine Tools Team worked on general usability improvements and game editor stability. The OCS
and Prefab workflows received enhancements and fixes along with Trackview (the tool used by the Cinematics Team) getting general Data Core properties support. This was needed to get rid of a big chunk of the old Lua scripting dependencies used by game entities and to get one step closer to the implementation of OCS
Polishing and bug fixing are still ongoing for Hurston and its four moons, and preproduction has started on the two moons orbiting Stanton 3 (ArcCorp). Beyond the roadmap, they’ve also started looking at Stanton 4 (MicroTech), which will be a significant challenge for the Art and Tech teams as they’ll be looking at frozen oceans, snowy mountains, frozen vegetation, and other elements that require technology and shaders to be modified and developed. The City or Lorville is entering its final stages as the team completes the outer boundaries of the city and the entry point from the planet’s surface.
The Engine Team completed the first part of the physics command queue refactor. The goal is to allow the move of physics away from dedicated threads and towards our system-wide batch model so that it can scale and perform better with the number of available CPU
They also continued progress on new solutions for cloth/soft body simulations, with several optimizations and improvements, and continued work on moving the skinning computation to GPU
They made load time improvements that addressed some inefficient code, which should reduce load times by up to 20 seconds (depending on PC specs). Lots of work was done on generating height map cascades of planet terrain which will be used for various effects in the future. In tandem, work started on large-scale planetary soft terrain shadows. These will replace the current implementation via traditional shadow maps, improve image quality, and the visibility range of terrain shadows.
The Tech Art Team worked on tools and the pipeline for authoring true next-gen cloth simulation setups for all dynamic attachments such as skirts, trench coats, jackets, and other loose-hanging clothing and equipment. The new softbody solver, which our Engineering department developed, is functioning as it should and will enable us to create all kinds of interesting secondary animation effects such as jiggling, sliding, and collisions. The authoring of such complex and advanced setups is just as important as the solver itself – it needs to be intuitive and provide maximum flexibility to the tech artists, hide the underlying complexity as much as possible, but allow access to it if needed.
While the authoring pipeline is based on Maya, changes to the setups are streamed live to the game engine through our LiveLink plugin and can therefore be previewed in WYSIWYG
fashion, which is extremely important. The general workflow mimics the way Maya’s own cloth simulation setups (nCloth) are authored, thereby allowing Tech Artists and Character FX TDs familiar with the software to become productive and creative as efficiently as possible. The goal of these efforts is to make all the in-game clothing move naturally, look less rigid, and to enhance the PCAP
primary character animation with a layer of physically-based secondary animation wherever possible.
For Tech Animation, they made further progress on the FPS
weapons rework, including updating the rigs and bringing everything into a structure that’s easier to work with. They started working on a batch exporter for weapon animations that will make it much easier to iterate on existing weapons whenever a rig is updated, or new features are added to it. They also updated the AnimEvent lists for both the PU and S42 and removed a long list of old animations that were either no longer needed or moved to an updated location.
A significative part of this month’s activity was spent working on a performance pass concerning two crucial components that heavily impact the behavior of our NPC
s – Subsumption activity updates and NPC
When hundreds of NPC
s are active simultaneously, their activities need to update and respond to events or change in subactivity, depending on the internal or external state of the game. Updates of the Subsumption components are therefore always running each frame, thus creating a sensible performance issue as the number of active NPC
s increases. Most of the time, the update is not truly needed as the NPC
is just waiting for an event of some sort to determine the ‘next’ state of a behavior (e.g. walking on a path and waiting for a ‘destination reached’ event). We can therefore take advantage of that and suspend the updates whenever the running tasks allow it. Internal tests in a heavily crowded scenario confirm that when allowing suspension, the impact of the Subsumption updates is dramatically reduced.
One of the most useful senses belonging to NPC
s is their visual perception. Visibility checks are continuously performed by every NPC
to assess the clearance of their line of sight between them and all other NPC
s or players in their field of view. Visibility checks are raycasts ultimately performed by the physics system. Up to now, we relied on a legacy module of the AI system provided by the Lumberyard system, called VisionMap. In VisionMap, all checks were handled in a centralized place and updated each frame in the main thread (as a synchronous update). The new system handles the visibility checks directly in the individual NPC
vision components and makes good use of the entity component update scheduler (ECUS
) by using multi-threaded updates in a time-sliced fashion.
The team was also busy finishing work for OCS
related to AI systems (Navigation & Cover). The navigation and cover data will not be part of a central manager anymore, instead there will be entity components (inside object containers) that will contain that data. This will help the OCS
since the AI data is kept internally for each object container.
The Weapons Art Team started production on a handful of new Hurston Dynamics ship weapons and a new knife designed for the ‘bad guys’ in-game.
Here’s an image of the ‘Sawtooth’, which is manufactured by Kastak Arms:
This month, DevOps focused on tooling out a test area for the Audio Team’s build processes, so the Audio Team has more autonomy in augmenting and testing their own build tools. The Perforce submission pipeline has been refined to remove redundant MD5 hashing of verified content; previous verification checkpoints relied on a custom MD5 hashing implementation, and these nodes of verification have been updated to check with digests that have been cached by the Perforce server, cutting down submission times for heavy changelists from hours to seconds.
The Cinematic Team’s main priority has been to go through the kick-off and implementation pass phases of a large number of scenes across several S42 levels that are currently being worked on by the Level Design Team. The implementation pass is the first production pass on a scene where the animation is broken up into the different states that are needed for that particular scene to work.
The process goes from a pre-vis of the animation (pretty much the raw PCAP
playing out) to a scene functioning as a conversation with starts, idles, pauses, branching options, and resolves. Iterations by the Level Design Team often change the layout of, for example, an asteroid base or other level environments, so the team needed to come up with an easy way to keep our scenes transportable.
They can now use each scene’s sequence object (the object the scene is defined in) as a root and when they move that sequence object around, the whole scene with its nodes animated within it moves with that root. This way, they can quickly accommodate a room being moved 50m down the corridor and can keep scenes up to date easily. It also helps level design to know they can adjust their level layout without having to request a big rework of a scene just to fit with a particular change.
Work was also completed on the tool side of things to keep the cinematic workflow compatible with the growing tech. An example of this would be the component-based entities that are replacing the old entities. A Tools Engineer wrote a new API
so animators can still animate an entity’s properties via the cinematic timeline tool, Trackview. This is necessary if a cinematic designer wants to change a light’s properties, for example, or wants to dial down sun intensity for a specific shot.
related testing continued into August with changes to test from the AI team. More specifically, a Navigation System refactor to support it. The main change for this refactor is the way navigation mesh data is saved and exported. They focused on testing navigation mesh generation in the Editor, saving levels with Navigation Area objects, and exporting the Object Container levels with Navigation Area objects. They also needed to ensure that all levels that had existing Navigation Areas could still be re-exported and that the AI was still able to move around in the level and pass through doorways, etc. The cover system and usables were also monitored to ensure they were still functional with the newly exported areas.
The team worked together with ATX
QA to test the new 1.003 version of the Subsumption Editor, which contained a lot of necessary fixes needed by the design team for better stabilization. Work continued with the Cinematics Team, with dedicated support for any Track View or Editor issues preventing the team from progressing on their sequences. In some cases, QA created simple test levels to better convey the issues they were encountering.
They also started the process for Automated Feature Tests for the current Feature Teams, with the first meeting to go over the specific setup and requirements at the end of the month with the Ship AI Feature Team. These tests will run for each build and will focus on testing systems that would be deemed risky and prevent usage of that particular build. The goal is to keep on top of features and ensure if they do break a build that the issue is brought to the relevant developer’s attention as quickly as possible. They also continued to provide support for any general Editor specific issues as well as the monthly (sometimes weekly) CIGP
hysics smoke test, where new changes are checked in by the Physics team as part of the refactor of CIGP
Team continued to work on the environmental effects for the new moons as well as working on how the effects function with the new biomes being introduced.
They also continued working on destruction sequences for Squadron 42. This involves bringing the new workflows previously developed in the first quarter of the year into production shots.
Progress is on track to finalize all the new Alpha 3.3 locations. The schedule is closely tied to when environments are finished by the art teams, so the focus this month has been on Lorville habitations, including prototyping a few lighting setups for each of the hab room layouts. They’ve also been finishing work on the security checkpoint common elements, tweaking the atmosphere and colorgrading for the Hurston moons. They also started work on an upcoming underground bunker location.