Alpha 3.18 & 3.19 Post Mortem
Undefined Undefined NoneContent
English
Alpha 3.18 & 3.19
Post Mortem
Persistent Entity Streaming
What Went Well
The development of Persistent Entity Streaming (PES) involved a diverse strike team of programmers with specialized skills from multiple areas across the Core Tech group and Turbulent. This collaboration was crucial in successfully building this complex system. The strike team followed aligned sprints and goals facilitated by senior engineers and producers that were supported by regular meetings. This resulted in effective communication and minimized miscommunication or technical misunderstandings.
A high-code-quality bar was maintained by the strike team, who ensured it underwent thorough design, discussion, and multiple reviews before being integrated into the mainline codebase.
The initial deployment to the Public Test Universe (PTU) and testing with the PTU community went well, setting a positive foundation for further improvements. However, this led to issues (discussed below).
Finally, PES’ system architecture and API, which are based on durable queues, proved they can recover from the worst kind of problems safely and will always tend towards recovery.
What Didn't Go Well
The research-and-development aspects of PES posed challenges, requiring the engineers to invent ways around unforeseen problems. Due to the foundational nature of PES, integrating it into the Star Citizen game code resulted in significant changes that disrupted the game at a very low level, and some game teams were unprepared for the integration effort required to bring the game systems back to parity or to convert and leverage the new persistence layer for existing features.
Issues with the changes introduced by PES only became apparent during large-scale use and under heavy player load, which caused delays in identifying and resolving the problems. And features not thought to use persistence at all became affected by trivial delays (like tram systems, spawn queues, and others).
We also underestimated the multiplication factor between the PTU and Live operations; the group had estimated a 10x increase in backend activity but were faced with a 20x+ increase in requests, stream message sizes, and overall activity, which caused service outages across the board during the initial launch.
Regarding vehicles, PES heavily modified the way they are entitled and created in-game. This gives a better user experience (where you can choose where a ship ends up being created) but also significantly reduced the size of the inventory/global database for ships that are never used.
Major issues were also discovered at scale with a third-party database engine that PES leverages for its functionality. These issues gave birth to very unstable request/response cycles as well as heavy queuing. These issues also caused ripple effects where one database server entering a deadlock condition would cause the entire shard cluster (instead of a single shard) to stop processing requests for a period. This was a major cause of the instability throughout Alpha 3.18.x until the team had identified and programmed a workaround to alleviate the effects. Additionally, multiple locking problems at scale were discovered in the global database system (same engine) that would cause a periodic stop of all requests to the inventory systems. The team had to investigate and report to our vendors to determine workarounds and ultimately fixes that would prevent the database engine from locking.
In the engine, several shards reached previously unknown hard limits of the maximum number of allocated entities, forcing the teams to seed/create new shards and cycle them out, diluting the effect of persistence on those shards.
Several bugs were uncovered (in those unstable times) with error handling in parts of the login flow that bricked some accounts in different ways related to character creation. Server-crash handling was discovered to take a much longer amount of time due to a new process that kicks in during the post-mortem analysis. This affected the shard post-mortem and delayed players getting stowed back to the global inventory, which could result in a player character being “stuck” in a shard.
What We’ll Do Better/Future Plans
Going forward, we’ll finalize and use the new Cloud Test Launcher to adequately stress test the game shards at scale. This tool will simulate player behaviors and allow QA and the engineers to connect multiple modified game clients to the shard. By utilizing cloud computing resources, effective stress testing can be conducted, which will help identify and address issues relating to heavily loaded servers before moving to Live.
The team responsible for PES has now moved onto Static Server Meshing and are embracing a transformation approach to the new project. Unlike PES, this foundational technology can be integrated into the codebase gradually, avoiding a disruptive "Big Bang" approach. Parts of the Server Meshing tech are already available to the game team for testing compatibility with their game features. Combined with the Cloud Test Launcher, this approach aims to facilitate a smoother integration process for Static Server Meshing.
By implementing these measures, we aim to enhance our testing capabilities and mitigate integration challenges, ensuring smoother delivery of foundational technologies while minimizing disruption to the game.
Rivers
What Went Well
The inclusion of rivers marked a significant milestone in our quest to create more realistic and immersive planets. We were quite happy with the improvements to river canyons we were able to achieve between Alpha 3.18 and 3.19 due to improvements in our asset pipeline. And the support from the Planet Tech team to address technical issues during this process was remarkable.
What Didn’t Go Well
The procedural river placement tool was not in as good of a state as we had hoped when we started using it. As a consequence, a considerable amount of manual effort was required to meticulously place and verify the resulting rivers to ensure their optimal quality. Moreover, this limitation also led to a decrease in the number of rivers we were able to generate.
What We’ll Do Better/Future Plans
The numerous issues that were successfully identified and addressed during this initial run of rivers have already made a significant impact toward ensuring a smoother experience for next time. Although there is still considerable work ahead before we can consistently create planetary landscapes with rivers that look and feel like the real deal, we have made substantial progress and are now much closer to achieving our goal than ever before.
Sand Caves
What Went Well
We were very happy with the results of this initial push to develop an improved pipeline to produce individual rooms for all cave archetypes and to also define the visual identity of our sand caves. That we were able to release a first set of smaller cave systems out of that prototyping phase thanks to the concerted effort from multiple departments was the icing on the cake for us.
What Didn’t Go Well
With neither the tools for procedurally assembling locations nor automatically placing them on planets ready for use, we had to build and place every cave manually, which was the primary constraint on the number of caves we could place on planets in the Stanton system.
Unfortunately, these caves had to initially be released without missions, making them into locations the player actively needed to seek out to experience.
What We’ll Do Better/Future Plans
We are currently in the final stages of refining the new visuals for rock caves, which will serve as the next archetype. We are looking forward to utilizing the Location Tool to construct a wider variety of cave systems.
Additionally, we will be working towards support for bigger connections, rooms, and entrances, which is a key requirement before we can replace the old caves.
PTV Racetrack
What Went Well
It was created very quickly; we went into it with the idea that it was a simple location with a short timeframe and minimal impact on other teams. However, we achieved a lot more in three weeks than we were initially expecting, with a good modular kit for kart-style racetracks, and the addition of good dressing, theming, and lighting. It was really good to see how the community, especially the racing community, was excited when the track was initially shown to the public. We have since seen organized races on the track. We also got code support for upgrades to the respawning vehicle entity so if people were to crash, break, or abandon the Greycat PTV, it would respawn back at the starting area of the track. We can also set the values of things like time to respawn.
What Didn’t Go Well
Despite finishing the track before Alpha 3.17 was released, it had yet to have a QA pass and be bug-fixed, so we decided to hold it back until Alpha 3.18. Little did we know Alpha 3.18 was going to be delayed so much, so the track, even though complete, made it into the public’s hands a long time after we had hoped.
What We’ll Do Better/Future Plans
We will certainly develop more modular tracks in the future (and have another in the works), but it is on the back burner for the moment. We will try and support other similar-sized ground vehicles like the Greycat STV in the future as well (initial tests have been positive). We will also work with the Mission team to look into adding a racetrack-style mission to the tracks, which will allow the tracking of race times, checkpoints, and laps, and enable the mission to give rewards to players.
Security Post Kareah
What Went Well
We could never have imagined the level of support we received from the Art team, which really rejuvenated the location.
The player-triggered sandbox activity was well received, and analytics showed that hacking CrimeStats at Kareah is still very popular, which was a concern for us as we were taking a risk removing the other hacking locations.
What Didn't Go Well
The mission still has rough edges that need ironing out, which is in progress. Also, additional analytics needs on sandbox activities were identified to be able to further understand player participation.
What We’ll Do Better/Future Plans
We’ll continue to iterate on the sandbox activity and location based on the feedback we’ve received and add further analytics to better understand participation.
Jumptown
What Went Well
The changes to the location were very well received, player participation was consistently very high, and the support we received from Art was well beyond what we expected.
What Didn’t Go Well
The implementation of PES led to performance issues around the location after a lot of ships were destroyed. We also wanted to redrop the locations with RASTAR. However, we were unable to at the time due to it breaking the shops.
What We’ll Do Better/Future Plans
For the next run of Global Events, we’re planning to redrop the locations on different planets to give different gameplay. For example, in thick atmosphere, higher gravity planets, and forests.
Time Trials
What Went Well
The new racing content and time trial modes were well received by the racing community, helped by the Content teams who produced many more tracks than we could have hoped for.
In the backend, the analytics we added were fantastic and allowed us to make very in-depth analyses of each track, which helped determine where they should go on the difficulty ranking and what the target times should be.
What Didn’t Go Well
Poor server performance meant that a sophisticated new system of checkpoint tracking had to be created, though the markers still do not update as responsively as we would like.
Analytics also show that relatively few players actually unlock the second track.
Infiltrate Missions - Orison
What Went Well
The new FPS environments were well-received and a refreshing change after only having underground facilities for years. The ability to assault the locations on foot or in ships was great too.
What Didn’t Go Well
We had to turn the missions off for Alpha 3.19 because we were aiming to release Siege of Orison, but we were not able to achieve this or the new platform clusters (where we were to relocate them) in time.
What We’ll Do Better/Future Plans
We have relocated the missions to the new platform clusters and will be releasing them when possible.
Prison Activities
What Went Well
The Prison Escape mission is surprisingly well-played and offers a new way for players to clear their CrimeStats. Inside the prison, loot on the AI and new selling terminals were well received; players felt the new AI made the prison feel more alive and it gave them another way to earn merits.
What Didn’t Go Well
The Ursa Rover continues to spawn underground, selling items at the prison kiosk still isn’t reliable, and excessive AI are being spawned due to a spawn closet issue.
What We’ll Do Better/Future Plans
For the next release, we’ll fix any bugs we can, including the Ursa spawning issue.
Drake Vulture
What Went Well
Adding the long-awaited “starter” of the Salvage career alongside its gameplay loop was a great milestone for the Vehicle team. While the vehicle was started some time ago, we had held on to it to ensure it released strongly with the gameplay loop rather than without, and this allowed the team to squeeze in some more features to the ship to make sure it hit all the current standards.
What Didn't Go Well
A few complaints surrounding the traversal of the ship due to the gameplay mechanics were somewhat a product of the Salvage mechanic evolving over time to require more manual input than initially expected during the vehicle’s concept in 2018.
What We’ll Do Better/Future Plans
Releasing vehicles alongside their gameplay loops rather than earlier in the project (see Starfarer and Reclaimer) is something we’ve been striving to do in recent times, and we’ll continue aiming to do this.
RSI Scorpius Antares
What Went Well
The Antares was designed alongside the base Scorpius as an optional variant to put into production in the future, with the tail section of the ship outlined as the part that could be geometry-swapped. However, during development, it was clear the needs of the EMP and quantum drive required slightly more power than planned and the team reacted well to adjust both the base and Antares to allow the component layout to suit both.
What Didn't Go Well
There were a few technical issues that we weren’t able to solve that reduced the ability for the second player to have more control over pilot features and a more enhanced MFD setup.
What We’ll Do Better/Future Plans
With Master Modes and new MFDs coming in the future, we should see the copilot get more gameplay features rather than being half passenger, half button-presser.
Salvage & Cargo - Vehicle Gameplay
What Went Well
We were able to support both Feature teams' introduction two key features to the PU, with Salvage requiring a lot of time be spent on the art assets and Cargo requiring a pass across all ships by Design.
What Didn't Go Well
Unfortunately, the scope of the work for Salvage was drastically underestimated, as we thought the existing UV2 damage system all ships used would be suitable out of the box. However, we very quickly realized we’d have to do an entire pass on every ship to up the quality, as you were looking at the visuals much closer than the damage system.
In addition, the gameplay mechanic was built around the idea that you’d be able to 100% scrape the entire hull. However, this wasn’t a consideration in the UV2 damage setup, so some areas were inaccessible, causing frustration to early testers who couldn’t “100%” a ship.
What We’ll Do Better/Future Plans
We’re now more closely integrated with the teams working on big features like this so issues can be found and investigated before development properly starts, rather than being looped in once the prototype has been completed.
Hull Scraping
What Went Well
The long-awaited first iteration of Salvage gameplay finally arrived with Alpha 3.18, which enables players to scrape off hull material and either trade it or use it for field repairs. The core gameplay loop was generally well received and provided a great contrast to other activities.
We also expanded the harvestable system with ship-wrecks and salvageable metal pieces, and introduced the first miniature version of Crafting by allowing players to create a few select items using RMC.
Releasing Hull Scraping alongside the Drake Vulture meant that the ship could come out with a proper gameplay system, and the Aegis Reclaimer finally has appropriate gameplay available to it.
What Didn’t Go Well
A lot of features and systems Hull Scraping was relying on were still in active development when we were building the core gameplay system. This meant the feature was handed off to the EUPU team with a fairly compressed timeline for release.
We addressed the way players would find salvageable objects in the universe way too late in the process, and the balance work for salvageable-object distribution was not properly mapped out.
Not all vehicles could be upgraded to the new Damage Map, meaning some vehicles still won’t work correctly with Hull Scraping.
What We’ll Do Better/Future Plans
We’ve changed our approach to how early we get other teams involved, meaning that downstream teams get involved as early as the prototyping stage. We’ve also introduced additional milestones where downstream and content teams can review and approve the progress we’ve made before we move on to the next stage.
Alpha 3.19
Salvage Contracts
What Went Well
We’re very proud of what we achieved; initially, we had only expected to release with Hull Scraping, but were able to get cargo and the brand-new detachable-components feature included. The mission was well received by backers too.
What Didn't Go Well
We didn’t choose the best ships for the mission, as only some have detachable internal components and gold-standard hulls for scraping (which we only found out after the fact). And, due to developer illness, the first release saw a very rough pass of cargo spawning, meaning there was no time to properly balance or verify that all items could be sold.
The Economy team had to change the value of ship weapons very late into development. This was necessary to balance the problematic insurance issue, which needs a further rebalance. The change meant some backers were disappointed having gotten used to higher rewards.
What We’ll Do Better/Future Plans
For the next release, we’ll choose more appropriate ships with detachable internal components.
New Player Experience
What Went Well
We received a lot of positive feedback from new players that the New Player Experience has helped them learn the game. The visual upgrades to Area 18 have greatly improved navigation, alongside new control and contextual hints.
Throughout the development of NPE, we’ve been able to make many improvements to our mission system, such as the introduction of mission persistence, which allows us to resume a mission at the last active objective if a player loses connection or experiences a client crash.
What Didn’t Go Well
The mission is largely modular but not entirely so, which means more work is needed to bring it to other locations. We didn’t have sufficient time or support to teach the player inventory management or interacting with shops.
In terms of the production itself, New Player Experience was a cross-team initiative and as such, was complicated to coordinate. Production support for New Player Experience changed a few times as it wasn’t owned by a dedicated team.
Additionally, we didn’t have sufficient support to remedy the visual issues with the existing HUD elements clashing with the new Control and Contextual Hints.
What We'll Do Better/Future Plans
We’ve started work on modularizing the remaining parts of the New Player Experience to reduce maintenance and allow us to bring it to multiple locations. We will also introduce additional components to NPE, such as inventory management, shopping and more.
RSI Lynx
What Went Well
The Lynx started off as a very simplistic adjustment of the Ursa but, as we progressed, we felt it deserved more. So, it ended up with virtually all-new geometry and materials, which paid off as the vehicle now looks the part and sits well with the Constellation Phoenix.
We also managed to cram a huge amount of interactive content within the vehicle, including animated chairs, TVs, lockers, and fridges.
What Didn't Go Well
Increasing the scope of work for the vehicle (primarily redoing the entire cockpit area) resulted in the Vehicle team working longer than expected, leaving less time for other teams, such as VFX and Audio, to do their work.
What We’ll Do Better/Future Plans
Next time, we’ll ensure scope adjustments are discussed with all teams and that they’re not unnecessarily waiting for all aspects to be delivered to start their pass.
Mirai Fury & Fury MX
What Went Well
Despite its size, the Fury series is one of the most complex vehicles we’ve ever put in the game, requiring complex animations and state machines all compressed into a very small spaceframe. It was also delivered ahead of schedule, as we were so excited by the vehicle we actually started production before the concept pass was officially complete.
Vehicle Features made a pass on the gimballed thrusters to make them work as we had envisioned. This means the Khartu-al and San’tok.yai will benefit from this in the future.
The MX’s blast shield was our first proper foray into integrating custom Building Blocks UI into the vehicle pipeline rather than reusing other assets, such as door control panels.
What Didn't Go Well
Some of the tech we needed for the thruster rotations took a few attempts to iron out, and we accidentally caused other issues with thrusters on other ships, but all was solved before release.
The MX was originally intended to have generic missile racks but it was clear early on they needed to be bespoke to prevent them from launching into the body or wings when changed for alternatives. This sadly reduces player customization but ultimately makes it more reliable in use.
What We’ll Do Better/Future Plans
We’re pretty happy with how the Fury and Fury MX turned out and no specific things occurred with their development that need adjustment in the future.
Tractor Beam - Item Attach/Detach
What Went Well
Finally, players are able to loot vehicles for components and weapons, greatly expanding the Salvage gameplay loop. This feature also provides additional gameplay opportunities to other features, such as allowing players to swap out mining heads and modules, and provides a strong foundation for the Vehicle Tractor Beam feature.
Internally, the Vehicle Content team were very responsive to addressing content issues with existing components and weapons.
What Didn’t Go Well
This feature wasn’t originally scheduled for Alpha 3.19, so we had a compressed timeline to work with. The QATR for this feature also revealed a lot of issues with content that couldn’t all be resolved in time for release.
What We’ll Do Better/Future Plans
We’ve started requesting downstream support much earlier in the process so that necessary content changes can be done in anticipation of the feature getting ready, as opposed to doing the handover toward the tail end of development.
Mining Rebalance
What Went Well
The community reception has been fantastic and we’re very happy with how the release panned out; long-standing metas and balance issues have been resolved and mining is now a much more nuanced gameplay loop that allows for multiple strategies.
Changes to tractor beams greatly benefited the Mining gameplay loop by enabling the ability to swap out mining heads, modules, and pods. We also identified a better process to balance gameplay loops holistically.
What Didn’t Go Well
There were some issues that we couldn’t properly resolve until after the release, such as mineable rocks always exploding, and the redistribution and rebalance of shop prices required quite a bit of back and forth between various teams before we got it properly implemented.
A lot of issues and edge cases with pricing and distribution were revealed during testing that needed constant fixing and readjustment.
What We’ll Do Better/Future Plans
We want to continue to improve our communication around mining with the community and keep listening to critical feedback to make mining the best it can be.
We’ll also put more trust in the data we gather to help inform future design decisions around mining gameplay.
Alpha 3.18's LaunchAs many of our players experienced, we launched Alpha 3.18 on March 10 of this year, and alongside a bevy of high-profile new features like Salvage, the Vulture patch flyable ship, the surprise Scorpius Antares, new rivers, and new missions, the biggest headliner of the patch was our delivery of Persistent Entity Streaming (PES), which completely rewrote how we save state in the game and ushered in the beginning of the promise of a truly persistent universe where a player’s actions could remain in the game for others to interact with and create a lived-in environment where you could literally leave your mark in the PU. And, just as importantly, PES, was the necessary final stepping stone to delivering Static Server Meshing.
Many who follow Star Citizen appreciated how consequential and important our delivery of Alpha 3.18 was for us and the game itself. Many teams at CIG spent most of the second half of last year finishing out Persistent Entity Streaming, as we deployed it to our Public Test Universe servers for testing in December 2022, and then spent the next 3 months attempting to harden and improve it for launching to our Live Star Citizen service as quickly as possible.
However, when the moment of truth came and Alpha 3.18 shipped to Live, the shock to the system was beyond what we had projected. While it’s true that we expected PES to create a rough experience initially as we ironed out the issues that could only expose themselves at massive scale (and we warned as much), to say that we were surprised by the depth of chaos from the PES launch would be an understatement.
The anticipation for PES and 3.18 was nothing short of unprecedented for us. When the patch first dropped on March 10, we experienced our highest peaks ever for logins per minute and per hour, and had our highest number of attempted logins in a day for the first few days of launch. We say “attempted logins” because as you all know, the service was so overwhelmed by the traffic and teething pains of PES that many players could not get into the game, as various issues stalled users throughout the login funnel. Some were stuck in queues, some couldn’t get their characters to load, some were stuck at an infinite loading screen. As you can read more about in Benoit Beausojour’s (our Chief Technical Officer) account below on PES, we underestimated the multiplicative forces of going to Live and now creating and persisting every entity players created through their actions, creating a load on our service that was beyond our initial forecasts. And it took weeks if not months to expose, diagnose, create fixes, test them, and deploy them to restore the service, all while the game was still running on Live.
We learned a lot from the launch of PES, and while we are still recovering, and regret the compromised service in the first days and weeks of the rollout, it has definitely taught us a valuable lesson to value and preserve the integrity of the service more than we had in the past. That’s why as we begin to roll out the Replication Layer split and crash recovery – two things now enabled by PES – we will do so gradually, and as we begin to deliver Server Meshing, we will create dedicated testing channels to harden those new technologies further and implement standards and thresholds before we “graduate” them to PTU and then Live. You’ll start to see the ramifications of that later in the year and hear more from us later about our new approach to deploying potentially disruptive and game-changing new tech to the game service, but it comes down to us truly committing to preserving the experience for the hundreds of thousands, if not millions, who now play Star Citizen as a live service game, albeit an alpha still in development.
Post Mortem
Persistent Entity Streaming
What Went Well
The development of Persistent Entity Streaming (PES) involved a diverse strike team of programmers with specialized skills from multiple areas across the Core Tech group and Turbulent. This collaboration was crucial in successfully building this complex system. The strike team followed aligned sprints and goals facilitated by senior engineers and producers that were supported by regular meetings. This resulted in effective communication and minimized miscommunication or technical misunderstandings.
A high-code-quality bar was maintained by the strike team, who ensured it underwent thorough design, discussion, and multiple reviews before being integrated into the mainline codebase.
The initial deployment to the Public Test Universe (PTU) and testing with the PTU community went well, setting a positive foundation for further improvements. However, this led to issues (discussed below).
Finally, PES’ system architecture and API, which are based on durable queues, proved they can recover from the worst kind of problems safely and will always tend towards recovery.
What Didn't Go Well
The research-and-development aspects of PES posed challenges, requiring the engineers to invent ways around unforeseen problems. Due to the foundational nature of PES, integrating it into the Star Citizen game code resulted in significant changes that disrupted the game at a very low level, and some game teams were unprepared for the integration effort required to bring the game systems back to parity or to convert and leverage the new persistence layer for existing features.
Issues with the changes introduced by PES only became apparent during large-scale use and under heavy player load, which caused delays in identifying and resolving the problems. And features not thought to use persistence at all became affected by trivial delays (like tram systems, spawn queues, and others).
We also underestimated the multiplication factor between the PTU and Live operations; the group had estimated a 10x increase in backend activity but were faced with a 20x+ increase in requests, stream message sizes, and overall activity, which caused service outages across the board during the initial launch.
Regarding vehicles, PES heavily modified the way they are entitled and created in-game. This gives a better user experience (where you can choose where a ship ends up being created) but also significantly reduced the size of the inventory/global database for ships that are never used.
Major issues were also discovered at scale with a third-party database engine that PES leverages for its functionality. These issues gave birth to very unstable request/response cycles as well as heavy queuing. These issues also caused ripple effects where one database server entering a deadlock condition would cause the entire shard cluster (instead of a single shard) to stop processing requests for a period. This was a major cause of the instability throughout Alpha 3.18.x until the team had identified and programmed a workaround to alleviate the effects. Additionally, multiple locking problems at scale were discovered in the global database system (same engine) that would cause a periodic stop of all requests to the inventory systems. The team had to investigate and report to our vendors to determine workarounds and ultimately fixes that would prevent the database engine from locking.
In the engine, several shards reached previously unknown hard limits of the maximum number of allocated entities, forcing the teams to seed/create new shards and cycle them out, diluting the effect of persistence on those shards.
Several bugs were uncovered (in those unstable times) with error handling in parts of the login flow that bricked some accounts in different ways related to character creation. Server-crash handling was discovered to take a much longer amount of time due to a new process that kicks in during the post-mortem analysis. This affected the shard post-mortem and delayed players getting stowed back to the global inventory, which could result in a player character being “stuck” in a shard.
What We’ll Do Better/Future Plans
Going forward, we’ll finalize and use the new Cloud Test Launcher to adequately stress test the game shards at scale. This tool will simulate player behaviors and allow QA and the engineers to connect multiple modified game clients to the shard. By utilizing cloud computing resources, effective stress testing can be conducted, which will help identify and address issues relating to heavily loaded servers before moving to Live.
The team responsible for PES has now moved onto Static Server Meshing and are embracing a transformation approach to the new project. Unlike PES, this foundational technology can be integrated into the codebase gradually, avoiding a disruptive "Big Bang" approach. Parts of the Server Meshing tech are already available to the game team for testing compatibility with their game features. Combined with the Cloud Test Launcher, this approach aims to facilitate a smoother integration process for Static Server Meshing.
By implementing these measures, we aim to enhance our testing capabilities and mitigate integration challenges, ensuring smoother delivery of foundational technologies while minimizing disruption to the game.
Rivers
What Went Well
The inclusion of rivers marked a significant milestone in our quest to create more realistic and immersive planets. We were quite happy with the improvements to river canyons we were able to achieve between Alpha 3.18 and 3.19 due to improvements in our asset pipeline. And the support from the Planet Tech team to address technical issues during this process was remarkable.
What Didn’t Go Well
The procedural river placement tool was not in as good of a state as we had hoped when we started using it. As a consequence, a considerable amount of manual effort was required to meticulously place and verify the resulting rivers to ensure their optimal quality. Moreover, this limitation also led to a decrease in the number of rivers we were able to generate.
What We’ll Do Better/Future Plans
The numerous issues that were successfully identified and addressed during this initial run of rivers have already made a significant impact toward ensuring a smoother experience for next time. Although there is still considerable work ahead before we can consistently create planetary landscapes with rivers that look and feel like the real deal, we have made substantial progress and are now much closer to achieving our goal than ever before.
Sand Caves
What Went Well
We were very happy with the results of this initial push to develop an improved pipeline to produce individual rooms for all cave archetypes and to also define the visual identity of our sand caves. That we were able to release a first set of smaller cave systems out of that prototyping phase thanks to the concerted effort from multiple departments was the icing on the cake for us.
What Didn’t Go Well
With neither the tools for procedurally assembling locations nor automatically placing them on planets ready for use, we had to build and place every cave manually, which was the primary constraint on the number of caves we could place on planets in the Stanton system.
Unfortunately, these caves had to initially be released without missions, making them into locations the player actively needed to seek out to experience.
What We’ll Do Better/Future Plans
We are currently in the final stages of refining the new visuals for rock caves, which will serve as the next archetype. We are looking forward to utilizing the Location Tool to construct a wider variety of cave systems.
Additionally, we will be working towards support for bigger connections, rooms, and entrances, which is a key requirement before we can replace the old caves.
PTV Racetrack
What Went Well
It was created very quickly; we went into it with the idea that it was a simple location with a short timeframe and minimal impact on other teams. However, we achieved a lot more in three weeks than we were initially expecting, with a good modular kit for kart-style racetracks, and the addition of good dressing, theming, and lighting. It was really good to see how the community, especially the racing community, was excited when the track was initially shown to the public. We have since seen organized races on the track. We also got code support for upgrades to the respawning vehicle entity so if people were to crash, break, or abandon the Greycat PTV, it would respawn back at the starting area of the track. We can also set the values of things like time to respawn.
What Didn’t Go Well
Despite finishing the track before Alpha 3.17 was released, it had yet to have a QA pass and be bug-fixed, so we decided to hold it back until Alpha 3.18. Little did we know Alpha 3.18 was going to be delayed so much, so the track, even though complete, made it into the public’s hands a long time after we had hoped.
What We’ll Do Better/Future Plans
We will certainly develop more modular tracks in the future (and have another in the works), but it is on the back burner for the moment. We will try and support other similar-sized ground vehicles like the Greycat STV in the future as well (initial tests have been positive). We will also work with the Mission team to look into adding a racetrack-style mission to the tracks, which will allow the tracking of race times, checkpoints, and laps, and enable the mission to give rewards to players.
Security Post Kareah
What Went Well
We could never have imagined the level of support we received from the Art team, which really rejuvenated the location.
The player-triggered sandbox activity was well received, and analytics showed that hacking CrimeStats at Kareah is still very popular, which was a concern for us as we were taking a risk removing the other hacking locations.
What Didn't Go Well
The mission still has rough edges that need ironing out, which is in progress. Also, additional analytics needs on sandbox activities were identified to be able to further understand player participation.
What We’ll Do Better/Future Plans
We’ll continue to iterate on the sandbox activity and location based on the feedback we’ve received and add further analytics to better understand participation.
Jumptown
What Went Well
The changes to the location were very well received, player participation was consistently very high, and the support we received from Art was well beyond what we expected.
What Didn’t Go Well
The implementation of PES led to performance issues around the location after a lot of ships were destroyed. We also wanted to redrop the locations with RASTAR. However, we were unable to at the time due to it breaking the shops.
What We’ll Do Better/Future Plans
For the next run of Global Events, we’re planning to redrop the locations on different planets to give different gameplay. For example, in thick atmosphere, higher gravity planets, and forests.
Time Trials
What Went Well
The new racing content and time trial modes were well received by the racing community, helped by the Content teams who produced many more tracks than we could have hoped for.
In the backend, the analytics we added were fantastic and allowed us to make very in-depth analyses of each track, which helped determine where they should go on the difficulty ranking and what the target times should be.
What Didn’t Go Well
Poor server performance meant that a sophisticated new system of checkpoint tracking had to be created, though the markers still do not update as responsively as we would like.
Analytics also show that relatively few players actually unlock the second track.
Infiltrate Missions - Orison
What Went Well
The new FPS environments were well-received and a refreshing change after only having underground facilities for years. The ability to assault the locations on foot or in ships was great too.
What Didn’t Go Well
We had to turn the missions off for Alpha 3.19 because we were aiming to release Siege of Orison, but we were not able to achieve this or the new platform clusters (where we were to relocate them) in time.
What We’ll Do Better/Future Plans
We have relocated the missions to the new platform clusters and will be releasing them when possible.
Prison Activities
What Went Well
The Prison Escape mission is surprisingly well-played and offers a new way for players to clear their CrimeStats. Inside the prison, loot on the AI and new selling terminals were well received; players felt the new AI made the prison feel more alive and it gave them another way to earn merits.
What Didn’t Go Well
The Ursa Rover continues to spawn underground, selling items at the prison kiosk still isn’t reliable, and excessive AI are being spawned due to a spawn closet issue.
What We’ll Do Better/Future Plans
For the next release, we’ll fix any bugs we can, including the Ursa spawning issue.
Drake Vulture
What Went Well
Adding the long-awaited “starter” of the Salvage career alongside its gameplay loop was a great milestone for the Vehicle team. While the vehicle was started some time ago, we had held on to it to ensure it released strongly with the gameplay loop rather than without, and this allowed the team to squeeze in some more features to the ship to make sure it hit all the current standards.
What Didn't Go Well
A few complaints surrounding the traversal of the ship due to the gameplay mechanics were somewhat a product of the Salvage mechanic evolving over time to require more manual input than initially expected during the vehicle’s concept in 2018.
What We’ll Do Better/Future Plans
Releasing vehicles alongside their gameplay loops rather than earlier in the project (see Starfarer and Reclaimer) is something we’ve been striving to do in recent times, and we’ll continue aiming to do this.
RSI Scorpius Antares
What Went Well
The Antares was designed alongside the base Scorpius as an optional variant to put into production in the future, with the tail section of the ship outlined as the part that could be geometry-swapped. However, during development, it was clear the needs of the EMP and quantum drive required slightly more power than planned and the team reacted well to adjust both the base and Antares to allow the component layout to suit both.
What Didn't Go Well
There were a few technical issues that we weren’t able to solve that reduced the ability for the second player to have more control over pilot features and a more enhanced MFD setup.
What We’ll Do Better/Future Plans
With Master Modes and new MFDs coming in the future, we should see the copilot get more gameplay features rather than being half passenger, half button-presser.
Salvage & Cargo - Vehicle Gameplay
What Went Well
We were able to support both Feature teams' introduction two key features to the PU, with Salvage requiring a lot of time be spent on the art assets and Cargo requiring a pass across all ships by Design.
What Didn't Go Well
Unfortunately, the scope of the work for Salvage was drastically underestimated, as we thought the existing UV2 damage system all ships used would be suitable out of the box. However, we very quickly realized we’d have to do an entire pass on every ship to up the quality, as you were looking at the visuals much closer than the damage system.
In addition, the gameplay mechanic was built around the idea that you’d be able to 100% scrape the entire hull. However, this wasn’t a consideration in the UV2 damage setup, so some areas were inaccessible, causing frustration to early testers who couldn’t “100%” a ship.
What We’ll Do Better/Future Plans
We’re now more closely integrated with the teams working on big features like this so issues can be found and investigated before development properly starts, rather than being looped in once the prototype has been completed.
Hull Scraping
What Went Well
The long-awaited first iteration of Salvage gameplay finally arrived with Alpha 3.18, which enables players to scrape off hull material and either trade it or use it for field repairs. The core gameplay loop was generally well received and provided a great contrast to other activities.
We also expanded the harvestable system with ship-wrecks and salvageable metal pieces, and introduced the first miniature version of Crafting by allowing players to create a few select items using RMC.
Releasing Hull Scraping alongside the Drake Vulture meant that the ship could come out with a proper gameplay system, and the Aegis Reclaimer finally has appropriate gameplay available to it.
What Didn’t Go Well
A lot of features and systems Hull Scraping was relying on were still in active development when we were building the core gameplay system. This meant the feature was handed off to the EUPU team with a fairly compressed timeline for release.
We addressed the way players would find salvageable objects in the universe way too late in the process, and the balance work for salvageable-object distribution was not properly mapped out.
Not all vehicles could be upgraded to the new Damage Map, meaning some vehicles still won’t work correctly with Hull Scraping.
What We’ll Do Better/Future Plans
We’ve changed our approach to how early we get other teams involved, meaning that downstream teams get involved as early as the prototyping stage. We’ve also introduced additional milestones where downstream and content teams can review and approve the progress we’ve made before we move on to the next stage.
Alpha 3.19
Salvage Contracts
What Went Well
We’re very proud of what we achieved; initially, we had only expected to release with Hull Scraping, but were able to get cargo and the brand-new detachable-components feature included. The mission was well received by backers too.
What Didn't Go Well
We didn’t choose the best ships for the mission, as only some have detachable internal components and gold-standard hulls for scraping (which we only found out after the fact). And, due to developer illness, the first release saw a very rough pass of cargo spawning, meaning there was no time to properly balance or verify that all items could be sold.
The Economy team had to change the value of ship weapons very late into development. This was necessary to balance the problematic insurance issue, which needs a further rebalance. The change meant some backers were disappointed having gotten used to higher rewards.
What We’ll Do Better/Future Plans
For the next release, we’ll choose more appropriate ships with detachable internal components.
New Player Experience
What Went Well
We received a lot of positive feedback from new players that the New Player Experience has helped them learn the game. The visual upgrades to Area 18 have greatly improved navigation, alongside new control and contextual hints.
Throughout the development of NPE, we’ve been able to make many improvements to our mission system, such as the introduction of mission persistence, which allows us to resume a mission at the last active objective if a player loses connection or experiences a client crash.
What Didn’t Go Well
The mission is largely modular but not entirely so, which means more work is needed to bring it to other locations. We didn’t have sufficient time or support to teach the player inventory management or interacting with shops.
In terms of the production itself, New Player Experience was a cross-team initiative and as such, was complicated to coordinate. Production support for New Player Experience changed a few times as it wasn’t owned by a dedicated team.
Additionally, we didn’t have sufficient support to remedy the visual issues with the existing HUD elements clashing with the new Control and Contextual Hints.
What We'll Do Better/Future Plans
We’ve started work on modularizing the remaining parts of the New Player Experience to reduce maintenance and allow us to bring it to multiple locations. We will also introduce additional components to NPE, such as inventory management, shopping and more.
RSI Lynx
What Went Well
The Lynx started off as a very simplistic adjustment of the Ursa but, as we progressed, we felt it deserved more. So, it ended up with virtually all-new geometry and materials, which paid off as the vehicle now looks the part and sits well with the Constellation Phoenix.
We also managed to cram a huge amount of interactive content within the vehicle, including animated chairs, TVs, lockers, and fridges.
What Didn't Go Well
Increasing the scope of work for the vehicle (primarily redoing the entire cockpit area) resulted in the Vehicle team working longer than expected, leaving less time for other teams, such as VFX and Audio, to do their work.
What We’ll Do Better/Future Plans
Next time, we’ll ensure scope adjustments are discussed with all teams and that they’re not unnecessarily waiting for all aspects to be delivered to start their pass.
Mirai Fury & Fury MX
What Went Well
Despite its size, the Fury series is one of the most complex vehicles we’ve ever put in the game, requiring complex animations and state machines all compressed into a very small spaceframe. It was also delivered ahead of schedule, as we were so excited by the vehicle we actually started production before the concept pass was officially complete.
Vehicle Features made a pass on the gimballed thrusters to make them work as we had envisioned. This means the Khartu-al and San’tok.yai will benefit from this in the future.
The MX’s blast shield was our first proper foray into integrating custom Building Blocks UI into the vehicle pipeline rather than reusing other assets, such as door control panels.
What Didn't Go Well
Some of the tech we needed for the thruster rotations took a few attempts to iron out, and we accidentally caused other issues with thrusters on other ships, but all was solved before release.
The MX was originally intended to have generic missile racks but it was clear early on they needed to be bespoke to prevent them from launching into the body or wings when changed for alternatives. This sadly reduces player customization but ultimately makes it more reliable in use.
What We’ll Do Better/Future Plans
We’re pretty happy with how the Fury and Fury MX turned out and no specific things occurred with their development that need adjustment in the future.
Tractor Beam - Item Attach/Detach
What Went Well
Finally, players are able to loot vehicles for components and weapons, greatly expanding the Salvage gameplay loop. This feature also provides additional gameplay opportunities to other features, such as allowing players to swap out mining heads and modules, and provides a strong foundation for the Vehicle Tractor Beam feature.
Internally, the Vehicle Content team were very responsive to addressing content issues with existing components and weapons.
What Didn’t Go Well
This feature wasn’t originally scheduled for Alpha 3.19, so we had a compressed timeline to work with. The QATR for this feature also revealed a lot of issues with content that couldn’t all be resolved in time for release.
What We’ll Do Better/Future Plans
We’ve started requesting downstream support much earlier in the process so that necessary content changes can be done in anticipation of the feature getting ready, as opposed to doing the handover toward the tail end of development.
Mining Rebalance
What Went Well
The community reception has been fantastic and we’re very happy with how the release panned out; long-standing metas and balance issues have been resolved and mining is now a much more nuanced gameplay loop that allows for multiple strategies.
Changes to tractor beams greatly benefited the Mining gameplay loop by enabling the ability to swap out mining heads, modules, and pods. We also identified a better process to balance gameplay loops holistically.
What Didn’t Go Well
There were some issues that we couldn’t properly resolve until after the release, such as mineable rocks always exploding, and the redistribution and rebalance of shop prices required quite a bit of back and forth between various teams before we got it properly implemented.
A lot of issues and edge cases with pricing and distribution were revealed during testing that needed constant fixing and readjustment.
What We’ll Do Better/Future Plans
We want to continue to improve our communication around mining with the community and keep listening to critical feedback to make mining the best it can be.
We’ll also put more trust in the data we gather to help inform future design decisions around mining gameplay.
Alpha 3.18's LaunchAs many of our players experienced, we launched Alpha 3.18 on March 10 of this year, and alongside a bevy of high-profile new features like Salvage, the Vulture patch flyable ship, the surprise Scorpius Antares, new rivers, and new missions, the biggest headliner of the patch was our delivery of Persistent Entity Streaming (PES), which completely rewrote how we save state in the game and ushered in the beginning of the promise of a truly persistent universe where a player’s actions could remain in the game for others to interact with and create a lived-in environment where you could literally leave your mark in the PU. And, just as importantly, PES, was the necessary final stepping stone to delivering Static Server Meshing.
Many who follow Star Citizen appreciated how consequential and important our delivery of Alpha 3.18 was for us and the game itself. Many teams at CIG spent most of the second half of last year finishing out Persistent Entity Streaming, as we deployed it to our Public Test Universe servers for testing in December 2022, and then spent the next 3 months attempting to harden and improve it for launching to our Live Star Citizen service as quickly as possible.
However, when the moment of truth came and Alpha 3.18 shipped to Live, the shock to the system was beyond what we had projected. While it’s true that we expected PES to create a rough experience initially as we ironed out the issues that could only expose themselves at massive scale (and we warned as much), to say that we were surprised by the depth of chaos from the PES launch would be an understatement.
The anticipation for PES and 3.18 was nothing short of unprecedented for us. When the patch first dropped on March 10, we experienced our highest peaks ever for logins per minute and per hour, and had our highest number of attempted logins in a day for the first few days of launch. We say “attempted logins” because as you all know, the service was so overwhelmed by the traffic and teething pains of PES that many players could not get into the game, as various issues stalled users throughout the login funnel. Some were stuck in queues, some couldn’t get their characters to load, some were stuck at an infinite loading screen. As you can read more about in Benoit Beausojour’s (our Chief Technical Officer) account below on PES, we underestimated the multiplicative forces of going to Live and now creating and persisting every entity players created through their actions, creating a load on our service that was beyond our initial forecasts. And it took weeks if not months to expose, diagnose, create fixes, test them, and deploy them to restore the service, all while the game was still running on Live.
We learned a lot from the launch of PES, and while we are still recovering, and regret the compromised service in the first days and weeks of the rollout, it has definitely taught us a valuable lesson to value and preserve the integrity of the service more than we had in the past. That’s why as we begin to roll out the Replication Layer split and crash recovery – two things now enabled by PES – we will do so gradually, and as we begin to deliver Server Meshing, we will create dedicated testing channels to harden those new technologies further and implement standards and thresholds before we “graduate” them to PTU and then Live. You’ll start to see the ramifications of that later in the year and hear more from us later about our new approach to deploying potentially disruptive and game-changing new tech to the game service, but it comes down to us truly committing to preserving the experience for the hundreds of thousands, if not millions, who now play Star Citizen as a live service game, albeit an alpha still in development.
German
Persistentes Streaming von Entitäten
Was gut gelaufen ist
An der Entwicklung von Persistent Entity Streaming (PES) war ein bunt gemischtes Team von Programmierern mit Spezialkenntnissen aus verschiedenen Bereichen der Core Tech Group und Turbulent beteiligt. Diese Zusammenarbeit war entscheidend für den erfolgreichen Aufbau dieses komplexen Systems. Das Strike-Team arbeitete nach abgestimmten Sprints und Zielen, die von leitenden Ingenieuren und Produzenten vorgegeben und durch regelmäßige Treffen unterstützt wurden. Dies führte zu einer effektiven Kommunikation und minimierte Fehlkommunikation oder technische Missverständnisse.
Das Strike-Team sorgte für eine hohe Code-Qualität und stellte sicher, dass das System gründlich entworfen, diskutiert und mehrfach überprüft wurde, bevor es in die Haupt-Codebasis integriert wurde.
Der erste Einsatz im Public Test Universe (PTU) und die Tests mit der PTU-Community verliefen gut und bildeten eine gute Grundlage für weitere Verbesserungen. Dies führte jedoch zu Problemen (siehe unten).
Schließlich haben die Systemarchitektur und die API der PES, die auf langlebigen Warteschlangen basieren, bewiesen, dass sie sich von den schlimmsten Problemen sicher erholen können und immer zur Wiederherstellung tendieren werden.
Was nicht gut gelaufen ist
Die Forschungs- und Entwicklungsaspekte der PES stellten die Ingenieure vor Herausforderungen, denn sie mussten Wege finden, um unvorhergesehene Probleme zu umgehen. Aufgrund der grundlegenden Natur von PES führte die Integration in den Star Citizen Spielcode zu erheblichen Änderungen, die das Spiel auf einer sehr niedrigen Ebene störten, und einige Spielteams waren nicht auf den Integrationsaufwand vorbereitet, der erforderlich war, um die Spielsysteme wieder auf den gleichen Stand zu bringen oder die neue Persistenzschicht zu konvertieren und für bestehende Funktionen zu nutzen.
Probleme mit den von PES eingeführten Änderungen wurden erst bei umfangreichem Einsatz und unter hoher Spielerbelastung deutlich, was zu Verzögerungen bei der Identifizierung und Lösung der Probleme führte. Und Funktionen, von denen man gar nicht dachte, dass sie Persistenz nutzen, wurden durch triviale Verzögerungen beeinträchtigt (wie Straßenbahnsysteme, Spawn-Warteschlangen und andere).
Wir haben auch den Multiplikationsfaktor zwischen dem PTU- und dem Live-Betrieb unterschätzt; die Gruppe hatte mit einem 10-fachen Anstieg der Backend-Aktivitäten gerechnet, sah sich aber mit einem 20-fachen Anstieg der Anfragen, der Stream-Nachrichtengrößen und der Gesamtaktivität konfrontiert, was in der Anfangsphase zu Serviceausfällen auf breiter Front führte.
Bei den Fahrzeugen hat PES die Art und Weise, wie sie im Spiel berechtigt und erstellt werden, stark verändert. Dadurch wird die Benutzerfreundlichkeit verbessert (du kannst wählen, wo ein Schiff erstellt wird), aber auch die Größe des Inventars/der globalen Datenbank für Schiffe, die nie benutzt werden, erheblich reduziert.
Außerdem wurden große Probleme mit einer Datenbank-Engine eines Drittanbieters entdeckt, die PES für seine Funktionen nutzt. Diese Probleme führten zu sehr instabilen Anfrage-/Antwort-Zyklen und zu langen Warteschlangen. Diese Probleme führten auch dazu, dass ein Datenbankserver, der in einen Deadlockzustand geriet, dazu führte, dass der gesamte Shard-Cluster (statt eines einzelnen Shards) für eine gewisse Zeit keine Anfragen mehr bearbeiten konnte. Dies war eine der Hauptursachen für die Instabilität von Alpha 3.18.x, bis das Team einen Workaround gefunden und programmiert hatte, um die Auswirkungen zu lindern. Außerdem wurden im globalen Datenbanksystem (dieselbe Engine) mehrere Sperrprobleme entdeckt, die dazu führten, dass alle Anfragen an die Inventarsysteme regelmäßig gestoppt wurden. Das Team musste das Problem untersuchen und unseren Anbietern Bericht erstatten, um Abhilfemaßnahmen und schließlich Korrekturen zu finden, die das Sperren der Datenbank-Engine verhindern.
In der Engine erreichten mehrere Shards bisher unbekannte Grenzen für die maximale Anzahl der zugewiesenen Entitäten, so dass die Teams gezwungen waren, neue Shards zu seeden/erstellen und sie zu verteilen, wodurch die Wirkung der Persistenz auf diesen Shards verwässert wurde.
Mehrere Fehler wurden (in diesen instabilen Zeiten) bei der Fehlerbehandlung in Teilen des Anmeldevorgangs aufgedeckt, die einige Konten auf unterschiedliche Weise im Zusammenhang mit der Charaktererstellung zum Absturz brachten. Es wurde festgestellt, dass die Behandlung von Serverabstürzen aufgrund eines neuen Prozesses, der während der Post-Mortem-Analyse einsetzt, viel mehr Zeit in Anspruch nimmt. Dies wirkte sich auf die Post-Mortem-Analyse des Shards aus und verzögerte die Rückführung von Spielern in das globale Inventar, was dazu führen konnte, dass ein Spielercharakter in einem Shard "feststeckte".
Was wir besser machen werden/Zukunftspläne
In Zukunft werden wir den neuen Cloud Test Launcher fertigstellen und einsetzen, um die Spiel-Scherben im großen Maßstab angemessen zu testen. Dieses Tool wird das Spielerverhalten simulieren und es der QA und den Ingenieuren ermöglichen, mehrere modifizierte Spielclients mit dem Shard zu verbinden. Durch die Nutzung von Cloud-Computing-Ressourcen können effektive Stresstests durchgeführt werden, die dabei helfen, Probleme im Zusammenhang mit stark belasteten Servern zu erkennen und zu beheben, bevor sie in den Live-Betrieb übergehen.
Das Team, das für PES verantwortlich ist, hat sich nun dem Static Server Meshing zugewandt und verfolgt bei dem neuen Projekt einen Transformationsansatz. Im Gegensatz zu PES kann diese grundlegende Technologie schrittweise in die Codebasis integriert werden, so dass ein störender "Big Bang"-Ansatz vermieden wird. Teile der Server Meshing-Technologie stehen dem Spielteam bereits zur Verfügung, um die Kompatibilität mit ihren Spielfunktionen zu testen. In Kombination mit dem Cloud Test Launcher zielt dieser Ansatz darauf ab, einen reibungsloseren Integrationsprozess für Static Server Meshing zu ermöglichen.
Mit diesen Maßnahmen wollen wir unsere Testmöglichkeiten verbessern und Integrationsprobleme abmildern, um eine reibungslosere Bereitstellung grundlegender Technologien zu gewährleisten und gleichzeitig die Unterbrechung des Spiels zu minimieren.
Flüsse
Was gut gelaufen ist
Die Einbeziehung von Flüssen war ein wichtiger Meilenstein in unserem Bestreben, realistischere und immersivere Planeten zu schaffen. Wir waren sehr zufrieden mit den Verbesserungen bei den Flussschluchten, die wir zwischen Alpha 3.18 und 3.19 dank der Verbesserungen in unserer Asset-Pipeline erreichen konnten. Und die Unterstützung des Planet Tech-Teams bei der Lösung technischer Probleme während dieses Prozesses war bemerkenswert.
Was nicht gut gelaufen ist
Das Tool zum Platzieren von Flüssen war nicht so gut, wie wir es uns erhofft hatten, als wir es einsetzten. Daher war ein erheblicher manueller Aufwand erforderlich, um die Flüsse sorgfältig zu platzieren und zu überprüfen, um ihre optimale Qualität zu gewährleisten. Außerdem führte diese Einschränkung dazu, dass die Anzahl der Flüsse, die wir erstellen konnten, sank.
Was wir besser machen werden/Zukunftspläne
Die zahlreichen Probleme, die wir während dieser ersten Runde von Flüssen erfolgreich identifiziert und behoben haben, haben bereits einen erheblichen Einfluss darauf, dass das nächste Mal ein reibungsloseres Erlebnis gewährleistet ist. Auch wenn noch viel Arbeit vor uns liegt, bis wir durchgängig planetarische Landschaften mit Flüssen erstellen können, die wie echte Flüsse aussehen und sich auch so anfühlen, haben wir große Fortschritte gemacht und sind unserem Ziel jetzt viel näher als je zuvor.
Sandhöhlen
Was gut gelaufen ist
Wir waren sehr zufrieden mit den Ergebnissen dieser ersten Phase, in der es darum ging, eine verbesserte Pipeline zu entwickeln, um individuelle Räume für alle Höhlenarchetypen zu produzieren und auch die visuelle Identität unserer Sandhöhlen zu definieren. Die Tatsache, dass wir dank der gemeinsamen Anstrengungen mehrerer Abteilungen nach dieser Prototyping-Phase ein erstes Set kleinerer Höhlensysteme veröffentlichen konnten, war für uns das Sahnehäubchen auf dem Kuchen.
Was nicht gut gelaufen ist
Da wir weder die Werkzeuge für den prozeduralen Aufbau von Orten noch für die automatische Platzierung auf Planeten zur Verfügung hatten, mussten wir jede Höhle von Hand bauen und platzieren, was die Anzahl der Höhlen, die wir auf Planeten im Stanton-System platzieren konnten, stark einschränkte.
Leider mussten diese Höhlen anfangs ohne Missionen freigeschaltet werden, was sie zu Orten machte, die der Spieler aktiv aufsuchen musste, um sie zu erleben.
Was wir besser machen werden/Zukunftspläne
Wir sind gerade dabei, die neue Grafik für Felshöhlen zu verfeinern, die als nächster Archetyp dienen wird. Wir freuen uns darauf, das Location Tool zu nutzen, um eine größere Vielfalt an Höhlensystemen zu erstellen.
Außerdem werden wir daran arbeiten, größere Verbindungen, Räume und Eingänge zu unterstützen, was eine wichtige Voraussetzung dafür ist, dass wir die alten Höhlen ersetzen können.
PTV-Rennbahn
Was gut gelaufen ist
Wir sind mit der Vorstellung an die Sache herangegangen, dass es sich um einen einfachen Ort mit einem kurzen Zeitrahmen und minimalen Auswirkungen auf andere Teams handelt. In drei Wochen haben wir jedoch viel mehr erreicht, als wir anfangs erwartet hatten. Wir haben einen guten Baukasten für Kart-Rennstrecken zusammengestellt und ihn mit einer guten Aufmachung, Thematisierung und Beleuchtung versehen. Es war wirklich schön zu sehen, wie begeistert die Gemeinde, vor allem die Renngemeinde, war, als die Strecke zum ersten Mal der Öffentlichkeit gezeigt wurde. Seitdem haben wir organisierte Rennen auf der Strecke gesehen. Wir haben auch Code-Unterstützung für Upgrades für die Respawning Vehicle Entity erhalten, so dass das Greycat PTV bei einem Unfall, einer Panne oder beim Verlassen der Strecke wieder im Startbereich landet. Wir können auch Werte wie die Zeit bis zum Respawn einstellen.
Was nicht gut gelaufen ist
Obwohl wir den Track vor der Veröffentlichung von Alpha 3.17 fertiggestellt hatten, musste er noch durch die QA gehen und Fehler behoben werden, also beschlossen wir, ihn bis Alpha 3.18 zurückzuhalten. Wir wussten nicht, dass sich die Alpha 3.18 so sehr verzögern würde, so dass der Track, obwohl er fertiggestellt war, erst lange nach unseren Hoffnungen veröffentlicht werden konnte.
Was wir besser machen werden/Zukunftspläne
Wir werden in Zukunft sicherlich noch mehr modulare Ketten entwickeln (und haben eine weitere in Arbeit), aber das ist im Moment eher auf Eis gelegt. Wir werden versuchen, in Zukunft auch andere Bodenfahrzeuge ähnlicher Größe wie das Greycat STV zu unterstützen (erste Tests sind positiv verlaufen). Wir werden auch mit dem Missionsteam zusammenarbeiten, um zu prüfen, ob wir eine Mission im Stil einer Rennstrecke einbauen können, die es ermöglicht, Rennzeiten, Kontrollpunkte und Runden zu erfassen und den Spielern Belohnungen zukommen zu lassen.
Sicherheitsposten Kareah
Was gut gelaufen ist
Wir hätten uns nie vorstellen können, wie viel Unterstützung wir vom Art-Team erhalten haben, das den Standort wirklich verjüngt hat.
Die von den Spielern ausgelöste Sandbox-Aktivität wurde gut angenommen und die Analysen zeigten, dass das Hacken von CrimeStats in Kareah immer noch sehr beliebt ist, was uns Sorgen bereitete, da wir das Risiko eingingen, die anderen Hacking-Standorte zu entfernen.
Was nicht gut gelaufen ist
Die Mission hat immer noch Ecken und Kanten, die ausgebügelt werden müssen, was derzeit geschieht. Außerdem wurden zusätzliche Analysen zu den Sandkastenaktivitäten benötigt, um die Beteiligung der Spieler/innen besser zu verstehen.
Was wir besser machen werden/Zukunftspläne
Wir werden die Sandbox-Aktivitäten und den Standort auf der Grundlage des Feedbacks, das wir erhalten haben, weiter verbessern und weitere Analysen hinzufügen, um die Teilnahme besser zu verstehen.
Jumptown
Was gut gelaufen ist
Die Änderungen am Standort wurden sehr gut aufgenommen, die Beteiligung der Spieler/innen war durchweg sehr hoch und die Unterstützung, die wir von Art erhielten, übertraf unsere Erwartungen bei weitem.
Was nicht gut gelaufen ist
Die Implementierung von PES führte zu Leistungsproblemen rund um den Ort, nachdem viele Schiffe zerstört worden waren. Außerdem wollten wir die Orte mit RASTAR neu ausrichten. Das war uns jedoch nicht möglich, da die Läden dadurch kaputt gingen.
Was wir besser machen werden/Zukunftspläne
Für die nächste Runde der Global Events planen wir, die Orte auf verschiedenen Planeten neu zu platzieren, um ein anderes Gameplay zu ermöglichen. Zum Beispiel in dicker Atmosphäre, auf Planeten mit höherer Schwerkraft und in Wäldern.
Time Trials
Was gut gelaufen ist
Die neuen Renninhalte und Zeitfahrmodi wurden von der Renngemeinschaft gut aufgenommen. Dazu beigetragen haben die Content-Teams, die viel mehr Strecken produziert haben, als wir uns erhofft hatten.
Im Backend waren die Analysen, die wir hinzugefügt haben, fantastisch und ermöglichten uns sehr detaillierte Analysen jeder Strecke, die uns dabei halfen, zu bestimmen, wo sie auf der Schwierigkeitsrangliste stehen sollten und wie die Zielzeiten aussehen sollten.
Was nicht gut gelaufen ist
Die schlechte Serverleistung führte dazu, dass ein ausgeklügeltes neues System zur Verfolgung von Kontrollpunkten entwickelt werden musste, obwohl die Markierungen immer noch nicht so schnell aktualisiert werden, wie wir es gerne hätten.
Die Analysen zeigen auch, dass relativ wenige Spieler/innen den zweiten Track tatsächlich freischalten.
Missionen infiltrieren - Orison
Was gut gelaufen ist
Die neuen FPS-Umgebungen wurden gut angenommen und waren eine erfrischende Abwechslung, nachdem es jahrelang nur unterirdische Anlagen gab. Die Möglichkeit, die Orte zu Fuß oder mit Schiffen anzugreifen, war ebenfalls großartig.
Was nicht gut gelaufen ist
Wir mussten die Missionen für die Alpha 3.19 abschalten, weil wir die Belagerung von Orison veröffentlichen wollten, aber wir konnten dies oder die neuen Plattform-Cluster (in die wir sie verlegen wollten) nicht rechtzeitig erreichen.
Was wir besser machen werden/Zukunftspläne
Wir haben die Missionen zu den neuen Plattform-Clustern verlegt und werden sie veröffentlichen, sobald es möglich ist.
Aktivitäten im Gefängnis
Was gut gelaufen ist
Die Mission "Gefängnisausbruch" wird überraschend gut gespielt und bietet den Spielern eine neue Möglichkeit, ihre Verbrechensstatistiken zu verbessern. Innerhalb des Gefängnisses wurden die Beute der KI und die neuen Verkaufsterminals gut angenommen. Die Spieler/innen fanden, dass die neue KI das Gefängnis lebendiger machte und ihnen eine weitere Möglichkeit bot, Verdienste zu verdienen.
Was nicht gut gelaufen ist
Der Ursa Rover spawnt weiterhin im Untergrund, der Verkauf von Gegenständen am Gefängniskiosk ist immer noch unzuverlässig und aufgrund eines Spawn-Schrank-Problems wird zu viel KI gespawnt.
Was wir besser machen werden/Zukunftspläne
In der nächsten Version werden wir alle Fehler beheben, die wir können, einschließlich des Ursa-Spawning-Problems.
Drachengeier
Was gut gelaufen ist
Das Hinzufügen des lang erwarteten "Starters" der Bergungskarriere zusammen mit der Gameplay-Schleife war ein großer Meilenstein für das Fahrzeugteam. Das Fahrzeug wurde zwar schon vor einiger Zeit gestartet, aber wir haben daran festgehalten, um sicherzustellen, dass es zusammen mit dem Gameplay-Loop und nicht ohne diesen veröffentlicht wird, was es dem Team ermöglichte, weitere Funktionen in das Schiff zu integrieren, um sicherzustellen, dass es alle aktuellen Standards erfüllt.
Was nicht gut gelaufen ist
Einige Beschwerden über die Fortbewegung des Schiffes aufgrund der Spielmechanik sind darauf zurückzuführen, dass sich die Bergungsmechanik im Laufe der Zeit weiterentwickelt hat und mehr manuelle Eingaben erfordert, als ursprünglich bei der Konzeption des Fahrzeugs im Jahr 2018 erwartet.
Was wir besser machen werden/Zukunftspläne
Wir haben uns in letzter Zeit bemüht, Fahrzeuge parallel zu den Spielschleifen zu veröffentlichen und nicht schon zu einem früheren Zeitpunkt im Projekt (siehe Starfarer und Reclaimer), und das werden wir auch weiterhin tun.
RSI Scorpius Antares
Was gut gelaufen ist
Die Antares wurde neben der Basis-Scorpius als optionale Variante für eine spätere Produktion entworfen, wobei das Heck des Schiffes als der Teil vorgesehen war, dessen Geometrie ausgetauscht werden konnte. Während der Entwicklung stellte sich jedoch heraus, dass der EMP- und der Quantenantrieb etwas mehr Leistung benötigten als geplant, und das Team reagierte gut darauf, indem es sowohl die Basis als auch die Antares so anpasste, dass die Komponentenanordnung für beide geeignet war.
Was nicht gut gelaufen ist
Es gab ein paar technische Probleme, die wir nicht lösen konnten und die die Möglichkeiten des zweiten Spielers einschränkten, mehr Kontrolle über die Pilotenfunktionen und ein verbessertes MFD-Setup zu haben.
Was wir besser machen werden/Zukunftspläne
Mit den Master-Modi und den neuen MFDs, die in Zukunft kommen werden, sollte der Kopilot mehr Gameplay-Funktionen bekommen, anstatt halb Passagier, halb Knopfdrücker zu sein.
Bergung & Fracht - Fahrzeug-Gameplay
Was gut gelaufen ist
Wir waren in der Lage, die beiden Feature-Teams bei der Einführung von zwei wichtigen Features in das PU zu unterstützen, wobei Salvage viel Zeit für die Art-Assets benötigte und Cargo einen Durchgang für alle Schiffe durch das Design erforderte.
Was nicht gut gelaufen ist
Leider haben wir den Umfang der Arbeit für Salvage drastisch unterschätzt, da wir dachten, dass das bestehende UV2-Schadenssystem, das alle Schiffe verwenden, von vornherein geeignet wäre. Wir haben aber sehr schnell gemerkt, dass wir einen kompletten Durchgang für jedes Schiff brauchen, um die Qualität zu verbessern, da man sich die Grafik viel genauer ansieht als das Schadenssystem.
Außerdem war die Spielmechanik darauf ausgelegt, dass du den gesamten Rumpf zu 100 % abkratzen kannst. Das war jedoch beim UV2-Schadenssystem nicht der Fall, so dass einige Bereiche nicht zugänglich waren, was bei den ersten Testern, die ein Schiff nicht zu 100 % kratzen konnten, zu Frustration führte.
Was wir besser machen werden/Zukunftspläne
Wir sind jetzt enger in die Teams integriert, die an großen Funktionen wie dieser arbeiten. So können Probleme gefunden und untersucht werden, bevor die Entwicklung richtig beginnt, anstatt erst nach Fertigstellung des Prototyps eingebunden zu werden.
Rumpfschaben
Was gut gelaufen ist
Mit der Alpha 3.18 kam endlich die lang erwartete erste Version des Bergungsspiels, bei dem die Spieler/innen Rumpfmaterial abkratzen und es entweder tauschen oder für Reparaturen vor Ort verwenden können. Der zentrale Spielablauf wurde allgemein gut aufgenommen und bot einen tollen Kontrast zu anderen Aktivitäten.
Außerdem haben wir das Erntesystem um Schiffswracks und bergbare Metallteile erweitert und die erste Miniaturversion von Crafting eingeführt, bei der die Spieler/innen einige ausgewählte Gegenstände mit RMC herstellen können.
Die Veröffentlichung von Hull Scraping zusammen mit dem Drake Vulture bedeutete, dass das Schiff mit einem richtigen Gameplay-System herauskommen konnte, und der Aegis Reclaimer hat endlich ein angemessenes Gameplay zur Verfügung.
Was nicht gut gelaufen ist
Viele Funktionen und Systeme, auf die sich Hull Scraping stützte, befanden sich noch in der Entwicklung, als wir das Kernsystem für das Gameplay erstellten. Das bedeutete, dass das Feature an das EUPU-Team übergeben wurde und der Zeitplan für die Veröffentlichung ziemlich eng war.
Wir haben uns viel zu spät mit der Art und Weise befasst, wie die Spieler/innen wiederverwertbare Objekte im Universum finden würden, und die Balance für die Verteilung der wiederverwertbaren Objekte war nicht richtig ausgearbeitet worden.
Nicht alle Fahrzeuge konnten auf die neue Schadenskarte aufgerüstet werden, was bedeutet, dass einige Fahrzeuge immer noch nicht richtig mit Hull Scraping funktionieren.
Was wir besser machen werden/Zukunftspläne
Wir haben unseren Ansatz geändert, wie früh wir andere Teams einbeziehen. Das bedeutet, dass nachgelagerte Teams bereits in der Prototyping-Phase einbezogen werden. Außerdem haben wir zusätzliche Meilensteine eingeführt, an denen nachgelagerte und inhaltliche Teams unsere Fortschritte überprüfen und genehmigen können, bevor wir zur nächsten Phase übergehen.
Alpha 3.19
Bergungsverträge
Was gut gelaufen ist
Wir sind sehr stolz auf das, was wir erreicht haben. Ursprünglich wollten wir die Mission nur mit Hull Scraping veröffentlichen, aber wir haben es geschafft, die Fracht und das brandneue Feature der abnehmbaren Komponenten zu integrieren. Auch bei den Geldgebern kam die Mission gut an.
Was nicht gut gelaufen ist
Wir haben nicht die besten Schiffe für die Mission ausgewählt, denn nur einige haben abnehmbare interne Komponenten und Goldstandard-Rümpfe zum Verschrotten (was wir erst im Nachhinein herausgefunden haben). Und aufgrund einer Krankheit der Entwickler wurde das Spawnen von Fracht in der ersten Version nur sehr grob durchgeführt, so dass keine Zeit blieb, um das Balancing richtig zu gestalten oder zu überprüfen, ob alle Gegenstände verkauft werden können.
Das Wirtschaftsteam musste den Wert von Schiffswaffen erst sehr spät in der Entwicklung ändern. Dies war notwendig, um das problematische Versicherungsproblem auszubalancieren, das noch einmal überarbeitet werden muss. Die Änderung führte dazu, dass einige Backer enttäuscht waren, weil sie sich an höhere Belohnungen gewöhnt hatten.
Was wir besser machen werden/Zukunftspläne
Für die nächste Version werden wir geeignetere Schiffe mit abnehmbaren internen Komponenten auswählen.
Neue Spielerfahrung
Was gut gelaufen ist
Wir haben viel positives Feedback von neuen Spielern erhalten, dass das neue Spielerlebnis ihnen geholfen hat, das Spiel zu lernen. Die visuellen Verbesserungen in Gebiet 18 haben die Navigation stark verbessert, zusammen mit neuen Steuerungs- und Kontexthinweisen.
Während der Entwicklung von NPE konnten wir viele Verbesserungen an unserem Missionssystem vornehmen, wie zum Beispiel die Einführung der Missionspersistenz, die es uns ermöglicht, eine Mission am letzten aktiven Ziel fortzusetzen, wenn ein Spieler die Verbindung verliert oder der Client abstürzt.
Was nicht gut gelaufen ist
Die Mission ist weitgehend modular, aber nicht vollständig, was bedeutet, dass mehr Arbeit nötig ist, um sie an andere Orte zu bringen. Wir hatten nicht genug Zeit oder Unterstützung, um dem Spieler die Lagerverwaltung oder die Interaktion mit Geschäften beizubringen.
Was die Produktion selbst angeht, so war New Player Experience eine teamübergreifende Initiative und als solche kompliziert zu koordinieren. Die Produktionsunterstützung für "New Player Experience" wechselte ein paar Mal, da sie nicht von einem eigenen Team betreut wurde.
Außerdem hatten wir nicht genügend Unterstützung, um die visuellen Probleme mit den bestehenden HUD-Elementen zu beheben, die mit den neuen Steuerungs- und Kontexthinweisen kollidierten.
Was wir besser machen werden/Zukunftspläne
Wir haben damit begonnen, die verbleibenden Teile der New Player Experience zu modularisieren, um den Wartungsaufwand zu verringern und sie an mehreren Standorten einsetzen zu können. Außerdem werden wir zusätzliche Komponenten in die NPE einführen, wie z. B. die Bestandsverwaltung, das Einkaufen und mehr.
RSI Lynx
Was gut gelaufen ist
Der Lynx war anfangs eine sehr einfache Anpassung des Ursa, aber im Laufe der Zeit hatten wir das Gefühl, dass er mehr verdient hat. Das hat sich ausgezahlt, denn das Fahrzeug sieht jetzt richtig gut aus und passt gut zum Constellation Phoenix.
Wir haben es auch geschafft, eine große Menge an interaktiven Inhalten in das Fahrzeug einzubauen, darunter animierte Stühle, Fernseher, Spinde und Kühlschränke.
Was nicht gut gelaufen ist
Die Ausweitung des Arbeitsumfangs für das Fahrzeug (vor allem die Neugestaltung des gesamten Cockpits) führte dazu, dass das Fahrzeugteam länger arbeitete als erwartet, wodurch anderen Teams wie VFX und Audio weniger Zeit für ihre Arbeit blieb.
Was wir besser machen werden/Zukunftspläne
Beim nächsten Mal werden wir sicherstellen, dass die Anpassungen des Umfangs mit allen Teams besprochen werden und dass sie nicht unnötig warten, bis alle Aspekte geliefert sind, um mit ihrem Durchgang zu beginnen.
Mirai Fury & Fury MX
Was gut gelaufen ist
Trotz ihrer Größe ist die Fury-Serie eines der komplexesten Fahrzeuge, die wir je ins Spiel gebracht haben. Sie erfordert komplexe Animationen und Zustandsautomaten, die alle auf einen sehr kleinen Raum komprimiert sind. Wir waren so begeistert von dem Fahrzeug, dass wir schon mit der Produktion begannen, bevor der Concept Pass offiziell fertig war.
Vehicle Features hat die kardanischen Triebwerke überarbeitet, damit sie so funktionieren, wie wir es uns vorgestellt haben. Das bedeutet, dass der Khartu-al und der San'tok.yai in Zukunft davon profitieren werden.
Der Schutzschild des MX war unser erster richtiger Versuch, benutzerdefinierte Building Blocks UI in die Fahrzeugpipeline zu integrieren, anstatt andere Assets wie Türbedienfelder wiederzuverwenden.
Was nicht gut gelaufen ist
Es hat ein paar Versuche gebraucht, um die Technik für die Schubdüsenrotation auszubügeln, und wir haben versehentlich andere Probleme mit Schubdüsen auf anderen Schiffen verursacht, aber alles wurde vor der Veröffentlichung gelöst.
Ursprünglich sollte die MX über generische Raketenständer verfügen, aber es war schon früh klar, dass sie maßgeschneidert sein mussten, um zu verhindern, dass sie in den Rumpf oder die Flügel geschossen werden, wenn sie gegen Alternativen ausgetauscht werden. Das schränkt die Anpassungsmöglichkeiten der Spieler leider ein, macht sie aber letztlich zuverlässiger.
Was wir besser machen werden/Zukunftspläne
Wir sind ziemlich zufrieden damit, wie sich die Fury und die Fury MX entwickelt haben, und es sind keine besonderen Dinge bei ihrer Entwicklung aufgetreten, die in Zukunft angepasst werden müssen.
Traktorstrahl - Gegenstand anbringen/abnehmen
Was gut gelaufen ist
Endlich können die Spieler/innen Fahrzeuge nach Bauteilen und Waffen plündern, was den Bergungsspielkreislauf erheblich erweitert. Diese Funktion bietet auch zusätzliche Spielmöglichkeiten für andere Funktionen, wie z. B. das Austauschen von Minenköpfen und Modulen, und bildet eine solide Grundlage für die Fahrzeug-Traktorstrahl-Funktion.
Intern hat das Fahrzeuginhaltsteam sehr schnell reagiert, um inhaltliche Probleme mit bestehenden Komponenten und Waffen zu lösen.
Was nicht gut gelaufen ist
Diese Funktion war ursprünglich nicht für die Alpha 3.19 geplant, so dass wir mit einem engen Zeitplan arbeiten mussten. Der QATR für diese Funktion enthüllte auch eine Menge inhaltlicher Probleme, die nicht alle rechtzeitig zur Veröffentlichung gelöst werden konnten.
Was wir besser machen werden/Zukunftspläne
Wir haben damit begonnen, die nachgelagerte Unterstützung viel früher im Prozess anzufordern, damit die notwendigen inhaltlichen Änderungen schon vor der Fertigstellung des Features vorgenommen werden können, anstatt die Übergabe erst gegen Ende der Entwicklung zu machen.
Bergbau Rebalance
Was gut gelaufen ist
Die Community hat uns fantastisch aufgenommen und wir sind sehr zufrieden damit, wie sich die Veröffentlichung entwickelt hat. Lange bestehende Metas und Balanceprobleme wurden gelöst und der Bergbau ist jetzt ein viel nuancierterer Spielablauf, der verschiedene Strategien zulässt.
Die Änderungen an den Traktorstrahlen haben sich sehr positiv auf das Mining Gameplay ausgewirkt, da sie es ermöglichen, Mining Heads, Module und Pods auszutauschen. Außerdem haben wir einen besseren Prozess gefunden, um Spielabläufe ganzheitlich zu balancieren.
Was nicht gut gelaufen ist
Es gab einige Probleme, die wir erst nach der Veröffentlichung richtig lösen konnten, z. B. dass abbaubare Steine immer explodierten, und die Neuverteilung und Anpassung der Ladenpreise erforderte ein ziemliches Hin und Her zwischen verschiedenen Teams, bevor wir sie richtig umgesetzt hatten.
Während des Testens wurden viele Probleme mit der Preisgestaltung und der Verteilung aufgedeckt, die ständig behoben und nachjustiert werden mussten.
Was wir besser machen werden/Zukunftspläne
Wir wollen unsere Kommunikation mit der Community rund um den Bergbau weiter verbessern und weiterhin auf kritisches Feedback hören, um den Bergbau so gut wie möglich zu machen.
Außerdem werden wir den Daten, die wir sammeln, mehr Vertrauen schenken, um zukünftige Designentscheidungen rund um das Mining Gameplay zu treffen.
Was gut gelaufen ist
An der Entwicklung von Persistent Entity Streaming (PES) war ein bunt gemischtes Team von Programmierern mit Spezialkenntnissen aus verschiedenen Bereichen der Core Tech Group und Turbulent beteiligt. Diese Zusammenarbeit war entscheidend für den erfolgreichen Aufbau dieses komplexen Systems. Das Strike-Team arbeitete nach abgestimmten Sprints und Zielen, die von leitenden Ingenieuren und Produzenten vorgegeben und durch regelmäßige Treffen unterstützt wurden. Dies führte zu einer effektiven Kommunikation und minimierte Fehlkommunikation oder technische Missverständnisse.
Das Strike-Team sorgte für eine hohe Code-Qualität und stellte sicher, dass das System gründlich entworfen, diskutiert und mehrfach überprüft wurde, bevor es in die Haupt-Codebasis integriert wurde.
Der erste Einsatz im Public Test Universe (PTU) und die Tests mit der PTU-Community verliefen gut und bildeten eine gute Grundlage für weitere Verbesserungen. Dies führte jedoch zu Problemen (siehe unten).
Schließlich haben die Systemarchitektur und die API der PES, die auf langlebigen Warteschlangen basieren, bewiesen, dass sie sich von den schlimmsten Problemen sicher erholen können und immer zur Wiederherstellung tendieren werden.
Was nicht gut gelaufen ist
Die Forschungs- und Entwicklungsaspekte der PES stellten die Ingenieure vor Herausforderungen, denn sie mussten Wege finden, um unvorhergesehene Probleme zu umgehen. Aufgrund der grundlegenden Natur von PES führte die Integration in den Star Citizen Spielcode zu erheblichen Änderungen, die das Spiel auf einer sehr niedrigen Ebene störten, und einige Spielteams waren nicht auf den Integrationsaufwand vorbereitet, der erforderlich war, um die Spielsysteme wieder auf den gleichen Stand zu bringen oder die neue Persistenzschicht zu konvertieren und für bestehende Funktionen zu nutzen.
Probleme mit den von PES eingeführten Änderungen wurden erst bei umfangreichem Einsatz und unter hoher Spielerbelastung deutlich, was zu Verzögerungen bei der Identifizierung und Lösung der Probleme führte. Und Funktionen, von denen man gar nicht dachte, dass sie Persistenz nutzen, wurden durch triviale Verzögerungen beeinträchtigt (wie Straßenbahnsysteme, Spawn-Warteschlangen und andere).
Wir haben auch den Multiplikationsfaktor zwischen dem PTU- und dem Live-Betrieb unterschätzt; die Gruppe hatte mit einem 10-fachen Anstieg der Backend-Aktivitäten gerechnet, sah sich aber mit einem 20-fachen Anstieg der Anfragen, der Stream-Nachrichtengrößen und der Gesamtaktivität konfrontiert, was in der Anfangsphase zu Serviceausfällen auf breiter Front führte.
Bei den Fahrzeugen hat PES die Art und Weise, wie sie im Spiel berechtigt und erstellt werden, stark verändert. Dadurch wird die Benutzerfreundlichkeit verbessert (du kannst wählen, wo ein Schiff erstellt wird), aber auch die Größe des Inventars/der globalen Datenbank für Schiffe, die nie benutzt werden, erheblich reduziert.
Außerdem wurden große Probleme mit einer Datenbank-Engine eines Drittanbieters entdeckt, die PES für seine Funktionen nutzt. Diese Probleme führten zu sehr instabilen Anfrage-/Antwort-Zyklen und zu langen Warteschlangen. Diese Probleme führten auch dazu, dass ein Datenbankserver, der in einen Deadlockzustand geriet, dazu führte, dass der gesamte Shard-Cluster (statt eines einzelnen Shards) für eine gewisse Zeit keine Anfragen mehr bearbeiten konnte. Dies war eine der Hauptursachen für die Instabilität von Alpha 3.18.x, bis das Team einen Workaround gefunden und programmiert hatte, um die Auswirkungen zu lindern. Außerdem wurden im globalen Datenbanksystem (dieselbe Engine) mehrere Sperrprobleme entdeckt, die dazu führten, dass alle Anfragen an die Inventarsysteme regelmäßig gestoppt wurden. Das Team musste das Problem untersuchen und unseren Anbietern Bericht erstatten, um Abhilfemaßnahmen und schließlich Korrekturen zu finden, die das Sperren der Datenbank-Engine verhindern.
In der Engine erreichten mehrere Shards bisher unbekannte Grenzen für die maximale Anzahl der zugewiesenen Entitäten, so dass die Teams gezwungen waren, neue Shards zu seeden/erstellen und sie zu verteilen, wodurch die Wirkung der Persistenz auf diesen Shards verwässert wurde.
Mehrere Fehler wurden (in diesen instabilen Zeiten) bei der Fehlerbehandlung in Teilen des Anmeldevorgangs aufgedeckt, die einige Konten auf unterschiedliche Weise im Zusammenhang mit der Charaktererstellung zum Absturz brachten. Es wurde festgestellt, dass die Behandlung von Serverabstürzen aufgrund eines neuen Prozesses, der während der Post-Mortem-Analyse einsetzt, viel mehr Zeit in Anspruch nimmt. Dies wirkte sich auf die Post-Mortem-Analyse des Shards aus und verzögerte die Rückführung von Spielern in das globale Inventar, was dazu führen konnte, dass ein Spielercharakter in einem Shard "feststeckte".
Was wir besser machen werden/Zukunftspläne
In Zukunft werden wir den neuen Cloud Test Launcher fertigstellen und einsetzen, um die Spiel-Scherben im großen Maßstab angemessen zu testen. Dieses Tool wird das Spielerverhalten simulieren und es der QA und den Ingenieuren ermöglichen, mehrere modifizierte Spielclients mit dem Shard zu verbinden. Durch die Nutzung von Cloud-Computing-Ressourcen können effektive Stresstests durchgeführt werden, die dabei helfen, Probleme im Zusammenhang mit stark belasteten Servern zu erkennen und zu beheben, bevor sie in den Live-Betrieb übergehen.
Das Team, das für PES verantwortlich ist, hat sich nun dem Static Server Meshing zugewandt und verfolgt bei dem neuen Projekt einen Transformationsansatz. Im Gegensatz zu PES kann diese grundlegende Technologie schrittweise in die Codebasis integriert werden, so dass ein störender "Big Bang"-Ansatz vermieden wird. Teile der Server Meshing-Technologie stehen dem Spielteam bereits zur Verfügung, um die Kompatibilität mit ihren Spielfunktionen zu testen. In Kombination mit dem Cloud Test Launcher zielt dieser Ansatz darauf ab, einen reibungsloseren Integrationsprozess für Static Server Meshing zu ermöglichen.
Mit diesen Maßnahmen wollen wir unsere Testmöglichkeiten verbessern und Integrationsprobleme abmildern, um eine reibungslosere Bereitstellung grundlegender Technologien zu gewährleisten und gleichzeitig die Unterbrechung des Spiels zu minimieren.
Flüsse
Was gut gelaufen ist
Die Einbeziehung von Flüssen war ein wichtiger Meilenstein in unserem Bestreben, realistischere und immersivere Planeten zu schaffen. Wir waren sehr zufrieden mit den Verbesserungen bei den Flussschluchten, die wir zwischen Alpha 3.18 und 3.19 dank der Verbesserungen in unserer Asset-Pipeline erreichen konnten. Und die Unterstützung des Planet Tech-Teams bei der Lösung technischer Probleme während dieses Prozesses war bemerkenswert.
Was nicht gut gelaufen ist
Das Tool zum Platzieren von Flüssen war nicht so gut, wie wir es uns erhofft hatten, als wir es einsetzten. Daher war ein erheblicher manueller Aufwand erforderlich, um die Flüsse sorgfältig zu platzieren und zu überprüfen, um ihre optimale Qualität zu gewährleisten. Außerdem führte diese Einschränkung dazu, dass die Anzahl der Flüsse, die wir erstellen konnten, sank.
Was wir besser machen werden/Zukunftspläne
Die zahlreichen Probleme, die wir während dieser ersten Runde von Flüssen erfolgreich identifiziert und behoben haben, haben bereits einen erheblichen Einfluss darauf, dass das nächste Mal ein reibungsloseres Erlebnis gewährleistet ist. Auch wenn noch viel Arbeit vor uns liegt, bis wir durchgängig planetarische Landschaften mit Flüssen erstellen können, die wie echte Flüsse aussehen und sich auch so anfühlen, haben wir große Fortschritte gemacht und sind unserem Ziel jetzt viel näher als je zuvor.
Sandhöhlen
Was gut gelaufen ist
Wir waren sehr zufrieden mit den Ergebnissen dieser ersten Phase, in der es darum ging, eine verbesserte Pipeline zu entwickeln, um individuelle Räume für alle Höhlenarchetypen zu produzieren und auch die visuelle Identität unserer Sandhöhlen zu definieren. Die Tatsache, dass wir dank der gemeinsamen Anstrengungen mehrerer Abteilungen nach dieser Prototyping-Phase ein erstes Set kleinerer Höhlensysteme veröffentlichen konnten, war für uns das Sahnehäubchen auf dem Kuchen.
Was nicht gut gelaufen ist
Da wir weder die Werkzeuge für den prozeduralen Aufbau von Orten noch für die automatische Platzierung auf Planeten zur Verfügung hatten, mussten wir jede Höhle von Hand bauen und platzieren, was die Anzahl der Höhlen, die wir auf Planeten im Stanton-System platzieren konnten, stark einschränkte.
Leider mussten diese Höhlen anfangs ohne Missionen freigeschaltet werden, was sie zu Orten machte, die der Spieler aktiv aufsuchen musste, um sie zu erleben.
Was wir besser machen werden/Zukunftspläne
Wir sind gerade dabei, die neue Grafik für Felshöhlen zu verfeinern, die als nächster Archetyp dienen wird. Wir freuen uns darauf, das Location Tool zu nutzen, um eine größere Vielfalt an Höhlensystemen zu erstellen.
Außerdem werden wir daran arbeiten, größere Verbindungen, Räume und Eingänge zu unterstützen, was eine wichtige Voraussetzung dafür ist, dass wir die alten Höhlen ersetzen können.
PTV-Rennbahn
Was gut gelaufen ist
Wir sind mit der Vorstellung an die Sache herangegangen, dass es sich um einen einfachen Ort mit einem kurzen Zeitrahmen und minimalen Auswirkungen auf andere Teams handelt. In drei Wochen haben wir jedoch viel mehr erreicht, als wir anfangs erwartet hatten. Wir haben einen guten Baukasten für Kart-Rennstrecken zusammengestellt und ihn mit einer guten Aufmachung, Thematisierung und Beleuchtung versehen. Es war wirklich schön zu sehen, wie begeistert die Gemeinde, vor allem die Renngemeinde, war, als die Strecke zum ersten Mal der Öffentlichkeit gezeigt wurde. Seitdem haben wir organisierte Rennen auf der Strecke gesehen. Wir haben auch Code-Unterstützung für Upgrades für die Respawning Vehicle Entity erhalten, so dass das Greycat PTV bei einem Unfall, einer Panne oder beim Verlassen der Strecke wieder im Startbereich landet. Wir können auch Werte wie die Zeit bis zum Respawn einstellen.
Was nicht gut gelaufen ist
Obwohl wir den Track vor der Veröffentlichung von Alpha 3.17 fertiggestellt hatten, musste er noch durch die QA gehen und Fehler behoben werden, also beschlossen wir, ihn bis Alpha 3.18 zurückzuhalten. Wir wussten nicht, dass sich die Alpha 3.18 so sehr verzögern würde, so dass der Track, obwohl er fertiggestellt war, erst lange nach unseren Hoffnungen veröffentlicht werden konnte.
Was wir besser machen werden/Zukunftspläne
Wir werden in Zukunft sicherlich noch mehr modulare Ketten entwickeln (und haben eine weitere in Arbeit), aber das ist im Moment eher auf Eis gelegt. Wir werden versuchen, in Zukunft auch andere Bodenfahrzeuge ähnlicher Größe wie das Greycat STV zu unterstützen (erste Tests sind positiv verlaufen). Wir werden auch mit dem Missionsteam zusammenarbeiten, um zu prüfen, ob wir eine Mission im Stil einer Rennstrecke einbauen können, die es ermöglicht, Rennzeiten, Kontrollpunkte und Runden zu erfassen und den Spielern Belohnungen zukommen zu lassen.
Sicherheitsposten Kareah
Was gut gelaufen ist
Wir hätten uns nie vorstellen können, wie viel Unterstützung wir vom Art-Team erhalten haben, das den Standort wirklich verjüngt hat.
Die von den Spielern ausgelöste Sandbox-Aktivität wurde gut angenommen und die Analysen zeigten, dass das Hacken von CrimeStats in Kareah immer noch sehr beliebt ist, was uns Sorgen bereitete, da wir das Risiko eingingen, die anderen Hacking-Standorte zu entfernen.
Was nicht gut gelaufen ist
Die Mission hat immer noch Ecken und Kanten, die ausgebügelt werden müssen, was derzeit geschieht. Außerdem wurden zusätzliche Analysen zu den Sandkastenaktivitäten benötigt, um die Beteiligung der Spieler/innen besser zu verstehen.
Was wir besser machen werden/Zukunftspläne
Wir werden die Sandbox-Aktivitäten und den Standort auf der Grundlage des Feedbacks, das wir erhalten haben, weiter verbessern und weitere Analysen hinzufügen, um die Teilnahme besser zu verstehen.
Jumptown
Was gut gelaufen ist
Die Änderungen am Standort wurden sehr gut aufgenommen, die Beteiligung der Spieler/innen war durchweg sehr hoch und die Unterstützung, die wir von Art erhielten, übertraf unsere Erwartungen bei weitem.
Was nicht gut gelaufen ist
Die Implementierung von PES führte zu Leistungsproblemen rund um den Ort, nachdem viele Schiffe zerstört worden waren. Außerdem wollten wir die Orte mit RASTAR neu ausrichten. Das war uns jedoch nicht möglich, da die Läden dadurch kaputt gingen.
Was wir besser machen werden/Zukunftspläne
Für die nächste Runde der Global Events planen wir, die Orte auf verschiedenen Planeten neu zu platzieren, um ein anderes Gameplay zu ermöglichen. Zum Beispiel in dicker Atmosphäre, auf Planeten mit höherer Schwerkraft und in Wäldern.
Time Trials
Was gut gelaufen ist
Die neuen Renninhalte und Zeitfahrmodi wurden von der Renngemeinschaft gut aufgenommen. Dazu beigetragen haben die Content-Teams, die viel mehr Strecken produziert haben, als wir uns erhofft hatten.
Im Backend waren die Analysen, die wir hinzugefügt haben, fantastisch und ermöglichten uns sehr detaillierte Analysen jeder Strecke, die uns dabei halfen, zu bestimmen, wo sie auf der Schwierigkeitsrangliste stehen sollten und wie die Zielzeiten aussehen sollten.
Was nicht gut gelaufen ist
Die schlechte Serverleistung führte dazu, dass ein ausgeklügeltes neues System zur Verfolgung von Kontrollpunkten entwickelt werden musste, obwohl die Markierungen immer noch nicht so schnell aktualisiert werden, wie wir es gerne hätten.
Die Analysen zeigen auch, dass relativ wenige Spieler/innen den zweiten Track tatsächlich freischalten.
Missionen infiltrieren - Orison
Was gut gelaufen ist
Die neuen FPS-Umgebungen wurden gut angenommen und waren eine erfrischende Abwechslung, nachdem es jahrelang nur unterirdische Anlagen gab. Die Möglichkeit, die Orte zu Fuß oder mit Schiffen anzugreifen, war ebenfalls großartig.
Was nicht gut gelaufen ist
Wir mussten die Missionen für die Alpha 3.19 abschalten, weil wir die Belagerung von Orison veröffentlichen wollten, aber wir konnten dies oder die neuen Plattform-Cluster (in die wir sie verlegen wollten) nicht rechtzeitig erreichen.
Was wir besser machen werden/Zukunftspläne
Wir haben die Missionen zu den neuen Plattform-Clustern verlegt und werden sie veröffentlichen, sobald es möglich ist.
Aktivitäten im Gefängnis
Was gut gelaufen ist
Die Mission "Gefängnisausbruch" wird überraschend gut gespielt und bietet den Spielern eine neue Möglichkeit, ihre Verbrechensstatistiken zu verbessern. Innerhalb des Gefängnisses wurden die Beute der KI und die neuen Verkaufsterminals gut angenommen. Die Spieler/innen fanden, dass die neue KI das Gefängnis lebendiger machte und ihnen eine weitere Möglichkeit bot, Verdienste zu verdienen.
Was nicht gut gelaufen ist
Der Ursa Rover spawnt weiterhin im Untergrund, der Verkauf von Gegenständen am Gefängniskiosk ist immer noch unzuverlässig und aufgrund eines Spawn-Schrank-Problems wird zu viel KI gespawnt.
Was wir besser machen werden/Zukunftspläne
In der nächsten Version werden wir alle Fehler beheben, die wir können, einschließlich des Ursa-Spawning-Problems.
Drachengeier
Was gut gelaufen ist
Das Hinzufügen des lang erwarteten "Starters" der Bergungskarriere zusammen mit der Gameplay-Schleife war ein großer Meilenstein für das Fahrzeugteam. Das Fahrzeug wurde zwar schon vor einiger Zeit gestartet, aber wir haben daran festgehalten, um sicherzustellen, dass es zusammen mit dem Gameplay-Loop und nicht ohne diesen veröffentlicht wird, was es dem Team ermöglichte, weitere Funktionen in das Schiff zu integrieren, um sicherzustellen, dass es alle aktuellen Standards erfüllt.
Was nicht gut gelaufen ist
Einige Beschwerden über die Fortbewegung des Schiffes aufgrund der Spielmechanik sind darauf zurückzuführen, dass sich die Bergungsmechanik im Laufe der Zeit weiterentwickelt hat und mehr manuelle Eingaben erfordert, als ursprünglich bei der Konzeption des Fahrzeugs im Jahr 2018 erwartet.
Was wir besser machen werden/Zukunftspläne
Wir haben uns in letzter Zeit bemüht, Fahrzeuge parallel zu den Spielschleifen zu veröffentlichen und nicht schon zu einem früheren Zeitpunkt im Projekt (siehe Starfarer und Reclaimer), und das werden wir auch weiterhin tun.
RSI Scorpius Antares
Was gut gelaufen ist
Die Antares wurde neben der Basis-Scorpius als optionale Variante für eine spätere Produktion entworfen, wobei das Heck des Schiffes als der Teil vorgesehen war, dessen Geometrie ausgetauscht werden konnte. Während der Entwicklung stellte sich jedoch heraus, dass der EMP- und der Quantenantrieb etwas mehr Leistung benötigten als geplant, und das Team reagierte gut darauf, indem es sowohl die Basis als auch die Antares so anpasste, dass die Komponentenanordnung für beide geeignet war.
Was nicht gut gelaufen ist
Es gab ein paar technische Probleme, die wir nicht lösen konnten und die die Möglichkeiten des zweiten Spielers einschränkten, mehr Kontrolle über die Pilotenfunktionen und ein verbessertes MFD-Setup zu haben.
Was wir besser machen werden/Zukunftspläne
Mit den Master-Modi und den neuen MFDs, die in Zukunft kommen werden, sollte der Kopilot mehr Gameplay-Funktionen bekommen, anstatt halb Passagier, halb Knopfdrücker zu sein.
Bergung & Fracht - Fahrzeug-Gameplay
Was gut gelaufen ist
Wir waren in der Lage, die beiden Feature-Teams bei der Einführung von zwei wichtigen Features in das PU zu unterstützen, wobei Salvage viel Zeit für die Art-Assets benötigte und Cargo einen Durchgang für alle Schiffe durch das Design erforderte.
Was nicht gut gelaufen ist
Leider haben wir den Umfang der Arbeit für Salvage drastisch unterschätzt, da wir dachten, dass das bestehende UV2-Schadenssystem, das alle Schiffe verwenden, von vornherein geeignet wäre. Wir haben aber sehr schnell gemerkt, dass wir einen kompletten Durchgang für jedes Schiff brauchen, um die Qualität zu verbessern, da man sich die Grafik viel genauer ansieht als das Schadenssystem.
Außerdem war die Spielmechanik darauf ausgelegt, dass du den gesamten Rumpf zu 100 % abkratzen kannst. Das war jedoch beim UV2-Schadenssystem nicht der Fall, so dass einige Bereiche nicht zugänglich waren, was bei den ersten Testern, die ein Schiff nicht zu 100 % kratzen konnten, zu Frustration führte.
Was wir besser machen werden/Zukunftspläne
Wir sind jetzt enger in die Teams integriert, die an großen Funktionen wie dieser arbeiten. So können Probleme gefunden und untersucht werden, bevor die Entwicklung richtig beginnt, anstatt erst nach Fertigstellung des Prototyps eingebunden zu werden.
Rumpfschaben
Was gut gelaufen ist
Mit der Alpha 3.18 kam endlich die lang erwartete erste Version des Bergungsspiels, bei dem die Spieler/innen Rumpfmaterial abkratzen und es entweder tauschen oder für Reparaturen vor Ort verwenden können. Der zentrale Spielablauf wurde allgemein gut aufgenommen und bot einen tollen Kontrast zu anderen Aktivitäten.
Außerdem haben wir das Erntesystem um Schiffswracks und bergbare Metallteile erweitert und die erste Miniaturversion von Crafting eingeführt, bei der die Spieler/innen einige ausgewählte Gegenstände mit RMC herstellen können.
Die Veröffentlichung von Hull Scraping zusammen mit dem Drake Vulture bedeutete, dass das Schiff mit einem richtigen Gameplay-System herauskommen konnte, und der Aegis Reclaimer hat endlich ein angemessenes Gameplay zur Verfügung.
Was nicht gut gelaufen ist
Viele Funktionen und Systeme, auf die sich Hull Scraping stützte, befanden sich noch in der Entwicklung, als wir das Kernsystem für das Gameplay erstellten. Das bedeutete, dass das Feature an das EUPU-Team übergeben wurde und der Zeitplan für die Veröffentlichung ziemlich eng war.
Wir haben uns viel zu spät mit der Art und Weise befasst, wie die Spieler/innen wiederverwertbare Objekte im Universum finden würden, und die Balance für die Verteilung der wiederverwertbaren Objekte war nicht richtig ausgearbeitet worden.
Nicht alle Fahrzeuge konnten auf die neue Schadenskarte aufgerüstet werden, was bedeutet, dass einige Fahrzeuge immer noch nicht richtig mit Hull Scraping funktionieren.
Was wir besser machen werden/Zukunftspläne
Wir haben unseren Ansatz geändert, wie früh wir andere Teams einbeziehen. Das bedeutet, dass nachgelagerte Teams bereits in der Prototyping-Phase einbezogen werden. Außerdem haben wir zusätzliche Meilensteine eingeführt, an denen nachgelagerte und inhaltliche Teams unsere Fortschritte überprüfen und genehmigen können, bevor wir zur nächsten Phase übergehen.
Alpha 3.19
Bergungsverträge
Was gut gelaufen ist
Wir sind sehr stolz auf das, was wir erreicht haben. Ursprünglich wollten wir die Mission nur mit Hull Scraping veröffentlichen, aber wir haben es geschafft, die Fracht und das brandneue Feature der abnehmbaren Komponenten zu integrieren. Auch bei den Geldgebern kam die Mission gut an.
Was nicht gut gelaufen ist
Wir haben nicht die besten Schiffe für die Mission ausgewählt, denn nur einige haben abnehmbare interne Komponenten und Goldstandard-Rümpfe zum Verschrotten (was wir erst im Nachhinein herausgefunden haben). Und aufgrund einer Krankheit der Entwickler wurde das Spawnen von Fracht in der ersten Version nur sehr grob durchgeführt, so dass keine Zeit blieb, um das Balancing richtig zu gestalten oder zu überprüfen, ob alle Gegenstände verkauft werden können.
Das Wirtschaftsteam musste den Wert von Schiffswaffen erst sehr spät in der Entwicklung ändern. Dies war notwendig, um das problematische Versicherungsproblem auszubalancieren, das noch einmal überarbeitet werden muss. Die Änderung führte dazu, dass einige Backer enttäuscht waren, weil sie sich an höhere Belohnungen gewöhnt hatten.
Was wir besser machen werden/Zukunftspläne
Für die nächste Version werden wir geeignetere Schiffe mit abnehmbaren internen Komponenten auswählen.
Neue Spielerfahrung
Was gut gelaufen ist
Wir haben viel positives Feedback von neuen Spielern erhalten, dass das neue Spielerlebnis ihnen geholfen hat, das Spiel zu lernen. Die visuellen Verbesserungen in Gebiet 18 haben die Navigation stark verbessert, zusammen mit neuen Steuerungs- und Kontexthinweisen.
Während der Entwicklung von NPE konnten wir viele Verbesserungen an unserem Missionssystem vornehmen, wie zum Beispiel die Einführung der Missionspersistenz, die es uns ermöglicht, eine Mission am letzten aktiven Ziel fortzusetzen, wenn ein Spieler die Verbindung verliert oder der Client abstürzt.
Was nicht gut gelaufen ist
Die Mission ist weitgehend modular, aber nicht vollständig, was bedeutet, dass mehr Arbeit nötig ist, um sie an andere Orte zu bringen. Wir hatten nicht genug Zeit oder Unterstützung, um dem Spieler die Lagerverwaltung oder die Interaktion mit Geschäften beizubringen.
Was die Produktion selbst angeht, so war New Player Experience eine teamübergreifende Initiative und als solche kompliziert zu koordinieren. Die Produktionsunterstützung für "New Player Experience" wechselte ein paar Mal, da sie nicht von einem eigenen Team betreut wurde.
Außerdem hatten wir nicht genügend Unterstützung, um die visuellen Probleme mit den bestehenden HUD-Elementen zu beheben, die mit den neuen Steuerungs- und Kontexthinweisen kollidierten.
Was wir besser machen werden/Zukunftspläne
Wir haben damit begonnen, die verbleibenden Teile der New Player Experience zu modularisieren, um den Wartungsaufwand zu verringern und sie an mehreren Standorten einsetzen zu können. Außerdem werden wir zusätzliche Komponenten in die NPE einführen, wie z. B. die Bestandsverwaltung, das Einkaufen und mehr.
RSI Lynx
Was gut gelaufen ist
Der Lynx war anfangs eine sehr einfache Anpassung des Ursa, aber im Laufe der Zeit hatten wir das Gefühl, dass er mehr verdient hat. Das hat sich ausgezahlt, denn das Fahrzeug sieht jetzt richtig gut aus und passt gut zum Constellation Phoenix.
Wir haben es auch geschafft, eine große Menge an interaktiven Inhalten in das Fahrzeug einzubauen, darunter animierte Stühle, Fernseher, Spinde und Kühlschränke.
Was nicht gut gelaufen ist
Die Ausweitung des Arbeitsumfangs für das Fahrzeug (vor allem die Neugestaltung des gesamten Cockpits) führte dazu, dass das Fahrzeugteam länger arbeitete als erwartet, wodurch anderen Teams wie VFX und Audio weniger Zeit für ihre Arbeit blieb.
Was wir besser machen werden/Zukunftspläne
Beim nächsten Mal werden wir sicherstellen, dass die Anpassungen des Umfangs mit allen Teams besprochen werden und dass sie nicht unnötig warten, bis alle Aspekte geliefert sind, um mit ihrem Durchgang zu beginnen.
Mirai Fury & Fury MX
Was gut gelaufen ist
Trotz ihrer Größe ist die Fury-Serie eines der komplexesten Fahrzeuge, die wir je ins Spiel gebracht haben. Sie erfordert komplexe Animationen und Zustandsautomaten, die alle auf einen sehr kleinen Raum komprimiert sind. Wir waren so begeistert von dem Fahrzeug, dass wir schon mit der Produktion begannen, bevor der Concept Pass offiziell fertig war.
Vehicle Features hat die kardanischen Triebwerke überarbeitet, damit sie so funktionieren, wie wir es uns vorgestellt haben. Das bedeutet, dass der Khartu-al und der San'tok.yai in Zukunft davon profitieren werden.
Der Schutzschild des MX war unser erster richtiger Versuch, benutzerdefinierte Building Blocks UI in die Fahrzeugpipeline zu integrieren, anstatt andere Assets wie Türbedienfelder wiederzuverwenden.
Was nicht gut gelaufen ist
Es hat ein paar Versuche gebraucht, um die Technik für die Schubdüsenrotation auszubügeln, und wir haben versehentlich andere Probleme mit Schubdüsen auf anderen Schiffen verursacht, aber alles wurde vor der Veröffentlichung gelöst.
Ursprünglich sollte die MX über generische Raketenständer verfügen, aber es war schon früh klar, dass sie maßgeschneidert sein mussten, um zu verhindern, dass sie in den Rumpf oder die Flügel geschossen werden, wenn sie gegen Alternativen ausgetauscht werden. Das schränkt die Anpassungsmöglichkeiten der Spieler leider ein, macht sie aber letztlich zuverlässiger.
Was wir besser machen werden/Zukunftspläne
Wir sind ziemlich zufrieden damit, wie sich die Fury und die Fury MX entwickelt haben, und es sind keine besonderen Dinge bei ihrer Entwicklung aufgetreten, die in Zukunft angepasst werden müssen.
Traktorstrahl - Gegenstand anbringen/abnehmen
Was gut gelaufen ist
Endlich können die Spieler/innen Fahrzeuge nach Bauteilen und Waffen plündern, was den Bergungsspielkreislauf erheblich erweitert. Diese Funktion bietet auch zusätzliche Spielmöglichkeiten für andere Funktionen, wie z. B. das Austauschen von Minenköpfen und Modulen, und bildet eine solide Grundlage für die Fahrzeug-Traktorstrahl-Funktion.
Intern hat das Fahrzeuginhaltsteam sehr schnell reagiert, um inhaltliche Probleme mit bestehenden Komponenten und Waffen zu lösen.
Was nicht gut gelaufen ist
Diese Funktion war ursprünglich nicht für die Alpha 3.19 geplant, so dass wir mit einem engen Zeitplan arbeiten mussten. Der QATR für diese Funktion enthüllte auch eine Menge inhaltlicher Probleme, die nicht alle rechtzeitig zur Veröffentlichung gelöst werden konnten.
Was wir besser machen werden/Zukunftspläne
Wir haben damit begonnen, die nachgelagerte Unterstützung viel früher im Prozess anzufordern, damit die notwendigen inhaltlichen Änderungen schon vor der Fertigstellung des Features vorgenommen werden können, anstatt die Übergabe erst gegen Ende der Entwicklung zu machen.
Bergbau Rebalance
Was gut gelaufen ist
Die Community hat uns fantastisch aufgenommen und wir sind sehr zufrieden damit, wie sich die Veröffentlichung entwickelt hat. Lange bestehende Metas und Balanceprobleme wurden gelöst und der Bergbau ist jetzt ein viel nuancierterer Spielablauf, der verschiedene Strategien zulässt.
Die Änderungen an den Traktorstrahlen haben sich sehr positiv auf das Mining Gameplay ausgewirkt, da sie es ermöglichen, Mining Heads, Module und Pods auszutauschen. Außerdem haben wir einen besseren Prozess gefunden, um Spielabläufe ganzheitlich zu balancieren.
Was nicht gut gelaufen ist
Es gab einige Probleme, die wir erst nach der Veröffentlichung richtig lösen konnten, z. B. dass abbaubare Steine immer explodierten, und die Neuverteilung und Anpassung der Ladenpreise erforderte ein ziemliches Hin und Her zwischen verschiedenen Teams, bevor wir sie richtig umgesetzt hatten.
Während des Testens wurden viele Probleme mit der Preisgestaltung und der Verteilung aufgedeckt, die ständig behoben und nachjustiert werden mussten.
Was wir besser machen werden/Zukunftspläne
Wir wollen unsere Kommunikation mit der Community rund um den Bergbau weiter verbessern und weiterhin auf kritisches Feedback hören, um den Bergbau so gut wie möglich zu machen.
Außerdem werden wir den Daten, die wir sammeln, mehr Vertrauen schenken, um zukünftige Designentscheidungen rund um das Mining Gameplay zu treffen.
Chinese
Alpha 3.18 & 3.19
Post Mortem
Persistent Entity Streaming
What Went Well
The development of Persistent Entity Streaming (PES) involved a diverse strike team of programmers with specialized skills from multiple areas across the Core Tech group and Turbulent. This collaboration was crucial in successfully building this complex system. The strike team followed aligned sprints and goals facilitated by senior engineers and producers that were supported by regular meetings. This resulted in effective communication and minimized miscommunication or technical misunderstandings.
A high-code-quality bar was maintained by the strike team, who ensured it underwent thorough design, discussion, and multiple reviews before being integrated into the mainline codebase.
The initial deployment to the Public Test Universe (PTU) and testing with the PTU community went well, setting a positive foundation for further improvements. However, this led to issues (discussed below).
Finally, PES’ system architecture and API, which are based on durable queues, proved they can recover from the worst kind of problems safely and will always tend towards recovery.
What Didn't Go Well
The research-and-development aspects of PES posed challenges, requiring the engineers to invent ways around unforeseen problems. Due to the foundational nature of PES, integrating it into the Star Citizen game code resulted in significant changes that disrupted the game at a very low level, and some game teams were unprepared for the integration effort required to bring the game systems back to parity or to convert and leverage the new persistence layer for existing features.
Issues with the changes introduced by PES only became apparent during large-scale use and under heavy player load, which caused delays in identifying and resolving the problems. And features not thought to use persistence at all became affected by trivial delays (like tram systems, spawn queues, and others).
We also underestimated the multiplication factor between the PTU and Live operations; the group had estimated a 10x increase in backend activity but were faced with a 20x+ increase in requests, stream message sizes, and overall activity, which caused service outages across the board during the initial launch.
Regarding vehicles, PES heavily modified the way they are entitled and created in-game. This gives a better user experience (where you can choose where a ship ends up being created) but also significantly reduced the size of the inventory/global database for ships that are never used.
Major issues were also discovered at scale with a third-party database engine that PES leverages for its functionality. These issues gave birth to very unstable request/response cycles as well as heavy queuing. These issues also caused ripple effects where one database server entering a deadlock condition would cause the entire shard cluster (instead of a single shard) to stop processing requests for a period. This was a major cause of the instability throughout Alpha 3.18.x until the team had identified and programmed a workaround to alleviate the effects. Additionally, multiple locking problems at scale were discovered in the global database system (same engine) that would cause a periodic stop of all requests to the inventory systems. The team had to investigate and report to our vendors to determine workarounds and ultimately fixes that would prevent the database engine from locking.
In the engine, several shards reached previously unknown hard limits of the maximum number of allocated entities, forcing the teams to seed/create new shards and cycle them out, diluting the effect of persistence on those shards.
Several bugs were uncovered (in those unstable times) with error handling in parts of the login flow that bricked some accounts in different ways related to character creation. Server-crash handling was discovered to take a much longer amount of time due to a new process that kicks in during the post-mortem analysis. This affected the shard post-mortem and delayed players getting stowed back to the global inventory, which could result in a player character being “stuck” in a shard.
What We’ll Do Better/Future Plans
Going forward, we’ll finalize and use the new Cloud Test Launcher to adequately stress test the game shards at scale. This tool will simulate player behaviors and allow QA and the engineers to connect multiple modified game clients to the shard. By utilizing cloud computing resources, effective stress testing can be conducted, which will help identify and address issues relating to heavily loaded servers before moving to Live.
The team responsible for PES has now moved onto Static Server Meshing and are embracing a transformation approach to the new project. Unlike PES, this foundational technology can be integrated into the codebase gradually, avoiding a disruptive "Big Bang" approach. Parts of the Server Meshing tech are already available to the game team for testing compatibility with their game features. Combined with the Cloud Test Launcher, this approach aims to facilitate a smoother integration process for Static Server Meshing.
By implementing these measures, we aim to enhance our testing capabilities and mitigate integration challenges, ensuring smoother delivery of foundational technologies while minimizing disruption to the game.
Rivers
What Went Well
The inclusion of rivers marked a significant milestone in our quest to create more realistic and immersive planets. We were quite happy with the improvements to river canyons we were able to achieve between Alpha 3.18 and 3.19 due to improvements in our asset pipeline. And the support from the Planet Tech team to address technical issues during this process was remarkable.
What Didn’t Go Well
The procedural river placement tool was not in as good of a state as we had hoped when we started using it. As a consequence, a considerable amount of manual effort was required to meticulously place and verify the resulting rivers to ensure their optimal quality. Moreover, this limitation also led to a decrease in the number of rivers we were able to generate.
What We’ll Do Better/Future Plans
The numerous issues that were successfully identified and addressed during this initial run of rivers have already made a significant impact toward ensuring a smoother experience for next time. Although there is still considerable work ahead before we can consistently create planetary landscapes with rivers that look and feel like the real deal, we have made substantial progress and are now much closer to achieving our goal than ever before.
Sand Caves
What Went Well
We were very happy with the results of this initial push to develop an improved pipeline to produce individual rooms for all cave archetypes and to also define the visual identity of our sand caves. That we were able to release a first set of smaller cave systems out of that prototyping phase thanks to the concerted effort from multiple departments was the icing on the cake for us.
What Didn’t Go Well
With neither the tools for procedurally assembling locations nor automatically placing them on planets ready for use, we had to build and place every cave manually, which was the primary constraint on the number of caves we could place on planets in the Stanton system.
Unfortunately, these caves had to initially be released without missions, making them into locations the player actively needed to seek out to experience.
What We’ll Do Better/Future Plans
We are currently in the final stages of refining the new visuals for rock caves, which will serve as the next archetype. We are looking forward to utilizing the Location Tool to construct a wider variety of cave systems.
Additionally, we will be working towards support for bigger connections, rooms, and entrances, which is a key requirement before we can replace the old caves.
PTV Racetrack
What Went Well
It was created very quickly; we went into it with the idea that it was a simple location with a short timeframe and minimal impact on other teams. However, we achieved a lot more in three weeks than we were initially expecting, with a good modular kit for kart-style racetracks, and the addition of good dressing, theming, and lighting. It was really good to see how the community, especially the racing community, was excited when the track was initially shown to the public. We have since seen organized races on the track. We also got code support for upgrades to the respawning vehicle entity so if people were to crash, break, or abandon the Greycat PTV, it would respawn back at the starting area of the track. We can also set the values of things like time to respawn.
What Didn’t Go Well
Despite finishing the track before Alpha 3.17 was released, it had yet to have a QA pass and be bug-fixed, so we decided to hold it back until Alpha 3.18. Little did we know Alpha 3.18 was going to be delayed so much, so the track, even though complete, made it into the public’s hands a long time after we had hoped.
What We’ll Do Better/Future Plans
We will certainly develop more modular tracks in the future (and have another in the works), but it is on the back burner for the moment. We will try and support other similar-sized ground vehicles like the Greycat STV in the future as well (initial tests have been positive). We will also work with the Mission team to look into adding a racetrack-style mission to the tracks, which will allow the tracking of race times, checkpoints, and laps, and enable the mission to give rewards to players.
Security Post Kareah
What Went Well
We could never have imagined the level of support we received from the Art team, which really rejuvenated the location.
The player-triggered sandbox activity was well received, and analytics showed that hacking CrimeStats at Kareah is still very popular, which was a concern for us as we were taking a risk removing the other hacking locations.
What Didn't Go Well
The mission still has rough edges that need ironing out, which is in progress. Also, additional analytics needs on sandbox activities were identified to be able to further understand player participation.
What We’ll Do Better/Future Plans
We’ll continue to iterate on the sandbox activity and location based on the feedback we’ve received and add further analytics to better understand participation.
Jumptown
What Went Well
The changes to the location were very well received, player participation was consistently very high, and the support we received from Art was well beyond what we expected.
What Didn’t Go Well
The implementation of PES led to performance issues around the location after a lot of ships were destroyed. We also wanted to redrop the locations with RASTAR. However, we were unable to at the time due to it breaking the shops.
What We’ll Do Better/Future Plans
For the next run of Global Events, we’re planning to redrop the locations on different planets to give different gameplay. For example, in thick atmosphere, higher gravity planets, and forests.
Time Trials
What Went Well
The new racing content and time trial modes were well received by the racing community, helped by the Content teams who produced many more tracks than we could have hoped for.
In the backend, the analytics we added were fantastic and allowed us to make very in-depth analyses of each track, which helped determine where they should go on the difficulty ranking and what the target times should be.
What Didn’t Go Well
Poor server performance meant that a sophisticated new system of checkpoint tracking had to be created, though the markers still do not update as responsively as we would like.
Analytics also show that relatively few players actually unlock the second track.
Infiltrate Missions - Orison
What Went Well
The new FPS environments were well-received and a refreshing change after only having underground facilities for years. The ability to assault the locations on foot or in ships was great too.
What Didn’t Go Well
We had to turn the missions off for Alpha 3.19 because we were aiming to release Siege of Orison, but we were not able to achieve this or the new platform clusters (where we were to relocate them) in time.
What We’ll Do Better/Future Plans
We have relocated the missions to the new platform clusters and will be releasing them when possible.
Prison Activities
What Went Well
The Prison Escape mission is surprisingly well-played and offers a new way for players to clear their CrimeStats. Inside the prison, loot on the AI and new selling terminals were well received; players felt the new AI made the prison feel more alive and it gave them another way to earn merits.
What Didn’t Go Well
The Ursa Rover continues to spawn underground, selling items at the prison kiosk still isn’t reliable, and excessive AI are being spawned due to a spawn closet issue.
What We’ll Do Better/Future Plans
For the next release, we’ll fix any bugs we can, including the Ursa spawning issue.
Drake Vulture
What Went Well
Adding the long-awaited “starter” of the Salvage career alongside its gameplay loop was a great milestone for the Vehicle team. While the vehicle was started some time ago, we had held on to it to ensure it released strongly with the gameplay loop rather than without, and this allowed the team to squeeze in some more features to the ship to make sure it hit all the current standards.
What Didn't Go Well
A few complaints surrounding the traversal of the ship due to the gameplay mechanics were somewhat a product of the Salvage mechanic evolving over time to require more manual input than initially expected during the vehicle’s concept in 2018.
What We’ll Do Better/Future Plans
Releasing vehicles alongside their gameplay loops rather than earlier in the project (see Starfarer and Reclaimer) is something we’ve been striving to do in recent times, and we’ll continue aiming to do this.
RSI Scorpius Antares
What Went Well
The Antares was designed alongside the base Scorpius as an optional variant to put into production in the future, with the tail section of the ship outlined as the part that could be geometry-swapped. However, during development, it was clear the needs of the EMP and quantum drive required slightly more power than planned and the team reacted well to adjust both the base and Antares to allow the component layout to suit both.
What Didn't Go Well
There were a few technical issues that we weren’t able to solve that reduced the ability for the second player to have more control over pilot features and a more enhanced MFD setup.
What We’ll Do Better/Future Plans
With Master Modes and new MFDs coming in the future, we should see the copilot get more gameplay features rather than being half passenger, half button-presser.
Salvage & Cargo - Vehicle Gameplay
What Went Well
We were able to support both Feature teams' introduction two key features to the PU, with Salvage requiring a lot of time be spent on the art assets and Cargo requiring a pass across all ships by Design.
What Didn't Go Well
Unfortunately, the scope of the work for Salvage was drastically underestimated, as we thought the existing UV2 damage system all ships used would be suitable out of the box. However, we very quickly realized we’d have to do an entire pass on every ship to up the quality, as you were looking at the visuals much closer than the damage system.
In addition, the gameplay mechanic was built around the idea that you’d be able to 100% scrape the entire hull. However, this wasn’t a consideration in the UV2 damage setup, so some areas were inaccessible, causing frustration to early testers who couldn’t “100%” a ship.
What We’ll Do Better/Future Plans
We’re now more closely integrated with the teams working on big features like this so issues can be found and investigated before development properly starts, rather than being looped in once the prototype has been completed.
Hull Scraping
What Went Well
The long-awaited first iteration of Salvage gameplay finally arrived with Alpha 3.18, which enables players to scrape off hull material and either trade it or use it for field repairs. The core gameplay loop was generally well received and provided a great contrast to other activities.
We also expanded the harvestable system with ship-wrecks and salvageable metal pieces, and introduced the first miniature version of Crafting by allowing players to create a few select items using RMC.
Releasing Hull Scraping alongside the Drake Vulture meant that the ship could come out with a proper gameplay system, and the Aegis Reclaimer finally has appropriate gameplay available to it.
What Didn’t Go Well
A lot of features and systems Hull Scraping was relying on were still in active development when we were building the core gameplay system. This meant the feature was handed off to the EUPU team with a fairly compressed timeline for release.
We addressed the way players would find salvageable objects in the universe way too late in the process, and the balance work for salvageable-object distribution was not properly mapped out.
Not all vehicles could be upgraded to the new Damage Map, meaning some vehicles still won’t work correctly with Hull Scraping.
What We’ll Do Better/Future Plans
We’ve changed our approach to how early we get other teams involved, meaning that downstream teams get involved as early as the prototyping stage. We’ve also introduced additional milestones where downstream and content teams can review and approve the progress we’ve made before we move on to the next stage.
Alpha 3.19
Salvage Contracts
What Went Well
We’re very proud of what we achieved; initially, we had only expected to release with Hull Scraping, but were able to get cargo and the brand-new detachable-components feature included. The mission was well received by backers too.
What Didn't Go Well
We didn’t choose the best ships for the mission, as only some have detachable internal components and gold-standard hulls for scraping (which we only found out after the fact). And, due to developer illness, the first release saw a very rough pass of cargo spawning, meaning there was no time to properly balance or verify that all items could be sold.
The Economy team had to change the value of ship weapons very late into development. This was necessary to balance the problematic insurance issue, which needs a further rebalance. The change meant some backers were disappointed having gotten used to higher rewards.
What We’ll Do Better/Future Plans
For the next release, we’ll choose more appropriate ships with detachable internal components.
New Player Experience
What Went Well
We received a lot of positive feedback from new players that the New Player Experience has helped them learn the game. The visual upgrades to Area 18 have greatly improved navigation, alongside new control and contextual hints.
Throughout the development of NPE, we’ve been able to make many improvements to our mission system, such as the introduction of mission persistence, which allows us to resume a mission at the last active objective if a player loses connection or experiences a client crash.
What Didn’t Go Well
The mission is largely modular but not entirely so, which means more work is needed to bring it to other locations. We didn’t have sufficient time or support to teach the player inventory management or interacting with shops.
In terms of the production itself, New Player Experience was a cross-team initiative and as such, was complicated to coordinate. Production support for New Player Experience changed a few times as it wasn’t owned by a dedicated team.
Additionally, we didn’t have sufficient support to remedy the visual issues with the existing HUD elements clashing with the new Control and Contextual Hints.
What We'll Do Better/Future Plans
We’ve started work on modularizing the remaining parts of the New Player Experience to reduce maintenance and allow us to bring it to multiple locations. We will also introduce additional components to NPE, such as inventory management, shopping and more.
RSI Lynx
What Went Well
The Lynx started off as a very simplistic adjustment of the Ursa but, as we progressed, we felt it deserved more. So, it ended up with virtually all-new geometry and materials, which paid off as the vehicle now looks the part and sits well with the Constellation Phoenix.
We also managed to cram a huge amount of interactive content within the vehicle, including animated chairs, TVs, lockers, and fridges.
What Didn't Go Well
Increasing the scope of work for the vehicle (primarily redoing the entire cockpit area) resulted in the Vehicle team working longer than expected, leaving less time for other teams, such as VFX and Audio, to do their work.
What We’ll Do Better/Future Plans
Next time, we’ll ensure scope adjustments are discussed with all teams and that they’re not unnecessarily waiting for all aspects to be delivered to start their pass.
Mirai Fury & Fury MX
What Went Well
Despite its size, the Fury series is one of the most complex vehicles we’ve ever put in the game, requiring complex animations and state machines all compressed into a very small spaceframe. It was also delivered ahead of schedule, as we were so excited by the vehicle we actually started production before the concept pass was officially complete.
Vehicle Features made a pass on the gimballed thrusters to make them work as we had envisioned. This means the Khartu-al and San’tok.yai will benefit from this in the future.
The MX’s blast shield was our first proper foray into integrating custom Building Blocks UI into the vehicle pipeline rather than reusing other assets, such as door control panels.
What Didn't Go Well
Some of the tech we needed for the thruster rotations took a few attempts to iron out, and we accidentally caused other issues with thrusters on other ships, but all was solved before release.
The MX was originally intended to have generic missile racks but it was clear early on they needed to be bespoke to prevent them from launching into the body or wings when changed for alternatives. This sadly reduces player customization but ultimately makes it more reliable in use.
What We’ll Do Better/Future Plans
We’re pretty happy with how the Fury and Fury MX turned out and no specific things occurred with their development that need adjustment in the future.
Tractor Beam - Item Attach/Detach
What Went Well
Finally, players are able to loot vehicles for components and weapons, greatly expanding the Salvage gameplay loop. This feature also provides additional gameplay opportunities to other features, such as allowing players to swap out mining heads and modules, and provides a strong foundation for the Vehicle Tractor Beam feature.
Internally, the Vehicle Content team were very responsive to addressing content issues with existing components and weapons.
What Didn’t Go Well
This feature wasn’t originally scheduled for Alpha 3.19, so we had a compressed timeline to work with. The QATR for this feature also revealed a lot of issues with content that couldn’t all be resolved in time for release.
What We’ll Do Better/Future Plans
We’ve started requesting downstream support much earlier in the process so that necessary content changes can be done in anticipation of the feature getting ready, as opposed to doing the handover toward the tail end of development.
Mining Rebalance
What Went Well
The community reception has been fantastic and we’re very happy with how the release panned out; long-standing metas and balance issues have been resolved and mining is now a much more nuanced gameplay loop that allows for multiple strategies.
Changes to tractor beams greatly benefited the Mining gameplay loop by enabling the ability to swap out mining heads, modules, and pods. We also identified a better process to balance gameplay loops holistically.
What Didn’t Go Well
There were some issues that we couldn’t properly resolve until after the release, such as mineable rocks always exploding, and the redistribution and rebalance of shop prices required quite a bit of back and forth between various teams before we got it properly implemented.
A lot of issues and edge cases with pricing and distribution were revealed during testing that needed constant fixing and readjustment.
What We’ll Do Better/Future Plans
We want to continue to improve our communication around mining with the community and keep listening to critical feedback to make mining the best it can be.
We’ll also put more trust in the data we gather to help inform future design decisions around mining gameplay.
Alpha 3.18's LaunchAs many of our players experienced, we launched Alpha 3.18 on March 10 of this year, and alongside a bevy of high-profile new features like Salvage, the Vulture patch flyable ship, the surprise Scorpius Antares, new rivers, and new missions, the biggest headliner of the patch was our delivery of Persistent Entity Streaming (PES), which completely rewrote how we save state in the game and ushered in the beginning of the promise of a truly persistent universe where a player’s actions could remain in the game for others to interact with and create a lived-in environment where you could literally leave your mark in the PU. And, just as importantly, PES, was the necessary final stepping stone to delivering Static Server Meshing.
Many who follow Star Citizen appreciated how consequential and important our delivery of Alpha 3.18 was for us and the game itself. Many teams at CIG spent most of the second half of last year finishing out Persistent Entity Streaming, as we deployed it to our Public Test Universe servers for testing in December 2022, and then spent the next 3 months attempting to harden and improve it for launching to our Live Star Citizen service as quickly as possible.
However, when the moment of truth came and Alpha 3.18 shipped to Live, the shock to the system was beyond what we had projected. While it’s true that we expected PES to create a rough experience initially as we ironed out the issues that could only expose themselves at massive scale (and we warned as much), to say that we were surprised by the depth of chaos from the PES launch would be an understatement.
The anticipation for PES and 3.18 was nothing short of unprecedented for us. When the patch first dropped on March 10, we experienced our highest peaks ever for logins per minute and per hour, and had our highest number of attempted logins in a day for the first few days of launch. We say “attempted logins” because as you all know, the service was so overwhelmed by the traffic and teething pains of PES that many players could not get into the game, as various issues stalled users throughout the login funnel. Some were stuck in queues, some couldn’t get their characters to load, some were stuck at an infinite loading screen. As you can read more about in Benoit Beausojour’s (our Chief Technical Officer) account below on PES, we underestimated the multiplicative forces of going to Live and now creating and persisting every entity players created through their actions, creating a load on our service that was beyond our initial forecasts. And it took weeks if not months to expose, diagnose, create fixes, test them, and deploy them to restore the service, all while the game was still running on Live.
We learned a lot from the launch of PES, and while we are still recovering, and regret the compromised service in the first days and weeks of the rollout, it has definitely taught us a valuable lesson to value and preserve the integrity of the service more than we had in the past. That’s why as we begin to roll out the Replication Layer split and crash recovery – two things now enabled by PES – we will do so gradually, and as we begin to deliver Server Meshing, we will create dedicated testing channels to harden those new technologies further and implement standards and thresholds before we “graduate” them to PTU and then Live. You’ll start to see the ramifications of that later in the year and hear more from us later about our new approach to deploying potentially disruptive and game-changing new tech to the game service, but it comes down to us truly committing to preserving the experience for the hundreds of thousands, if not millions, who now play Star Citizen as a live service game, albeit an alpha still in development.
Post Mortem
Persistent Entity Streaming
What Went Well
The development of Persistent Entity Streaming (PES) involved a diverse strike team of programmers with specialized skills from multiple areas across the Core Tech group and Turbulent. This collaboration was crucial in successfully building this complex system. The strike team followed aligned sprints and goals facilitated by senior engineers and producers that were supported by regular meetings. This resulted in effective communication and minimized miscommunication or technical misunderstandings.
A high-code-quality bar was maintained by the strike team, who ensured it underwent thorough design, discussion, and multiple reviews before being integrated into the mainline codebase.
The initial deployment to the Public Test Universe (PTU) and testing with the PTU community went well, setting a positive foundation for further improvements. However, this led to issues (discussed below).
Finally, PES’ system architecture and API, which are based on durable queues, proved they can recover from the worst kind of problems safely and will always tend towards recovery.
What Didn't Go Well
The research-and-development aspects of PES posed challenges, requiring the engineers to invent ways around unforeseen problems. Due to the foundational nature of PES, integrating it into the Star Citizen game code resulted in significant changes that disrupted the game at a very low level, and some game teams were unprepared for the integration effort required to bring the game systems back to parity or to convert and leverage the new persistence layer for existing features.
Issues with the changes introduced by PES only became apparent during large-scale use and under heavy player load, which caused delays in identifying and resolving the problems. And features not thought to use persistence at all became affected by trivial delays (like tram systems, spawn queues, and others).
We also underestimated the multiplication factor between the PTU and Live operations; the group had estimated a 10x increase in backend activity but were faced with a 20x+ increase in requests, stream message sizes, and overall activity, which caused service outages across the board during the initial launch.
Regarding vehicles, PES heavily modified the way they are entitled and created in-game. This gives a better user experience (where you can choose where a ship ends up being created) but also significantly reduced the size of the inventory/global database for ships that are never used.
Major issues were also discovered at scale with a third-party database engine that PES leverages for its functionality. These issues gave birth to very unstable request/response cycles as well as heavy queuing. These issues also caused ripple effects where one database server entering a deadlock condition would cause the entire shard cluster (instead of a single shard) to stop processing requests for a period. This was a major cause of the instability throughout Alpha 3.18.x until the team had identified and programmed a workaround to alleviate the effects. Additionally, multiple locking problems at scale were discovered in the global database system (same engine) that would cause a periodic stop of all requests to the inventory systems. The team had to investigate and report to our vendors to determine workarounds and ultimately fixes that would prevent the database engine from locking.
In the engine, several shards reached previously unknown hard limits of the maximum number of allocated entities, forcing the teams to seed/create new shards and cycle them out, diluting the effect of persistence on those shards.
Several bugs were uncovered (in those unstable times) with error handling in parts of the login flow that bricked some accounts in different ways related to character creation. Server-crash handling was discovered to take a much longer amount of time due to a new process that kicks in during the post-mortem analysis. This affected the shard post-mortem and delayed players getting stowed back to the global inventory, which could result in a player character being “stuck” in a shard.
What We’ll Do Better/Future Plans
Going forward, we’ll finalize and use the new Cloud Test Launcher to adequately stress test the game shards at scale. This tool will simulate player behaviors and allow QA and the engineers to connect multiple modified game clients to the shard. By utilizing cloud computing resources, effective stress testing can be conducted, which will help identify and address issues relating to heavily loaded servers before moving to Live.
The team responsible for PES has now moved onto Static Server Meshing and are embracing a transformation approach to the new project. Unlike PES, this foundational technology can be integrated into the codebase gradually, avoiding a disruptive "Big Bang" approach. Parts of the Server Meshing tech are already available to the game team for testing compatibility with their game features. Combined with the Cloud Test Launcher, this approach aims to facilitate a smoother integration process for Static Server Meshing.
By implementing these measures, we aim to enhance our testing capabilities and mitigate integration challenges, ensuring smoother delivery of foundational technologies while minimizing disruption to the game.
Rivers
What Went Well
The inclusion of rivers marked a significant milestone in our quest to create more realistic and immersive planets. We were quite happy with the improvements to river canyons we were able to achieve between Alpha 3.18 and 3.19 due to improvements in our asset pipeline. And the support from the Planet Tech team to address technical issues during this process was remarkable.
What Didn’t Go Well
The procedural river placement tool was not in as good of a state as we had hoped when we started using it. As a consequence, a considerable amount of manual effort was required to meticulously place and verify the resulting rivers to ensure their optimal quality. Moreover, this limitation also led to a decrease in the number of rivers we were able to generate.
What We’ll Do Better/Future Plans
The numerous issues that were successfully identified and addressed during this initial run of rivers have already made a significant impact toward ensuring a smoother experience for next time. Although there is still considerable work ahead before we can consistently create planetary landscapes with rivers that look and feel like the real deal, we have made substantial progress and are now much closer to achieving our goal than ever before.
Sand Caves
What Went Well
We were very happy with the results of this initial push to develop an improved pipeline to produce individual rooms for all cave archetypes and to also define the visual identity of our sand caves. That we were able to release a first set of smaller cave systems out of that prototyping phase thanks to the concerted effort from multiple departments was the icing on the cake for us.
What Didn’t Go Well
With neither the tools for procedurally assembling locations nor automatically placing them on planets ready for use, we had to build and place every cave manually, which was the primary constraint on the number of caves we could place on planets in the Stanton system.
Unfortunately, these caves had to initially be released without missions, making them into locations the player actively needed to seek out to experience.
What We’ll Do Better/Future Plans
We are currently in the final stages of refining the new visuals for rock caves, which will serve as the next archetype. We are looking forward to utilizing the Location Tool to construct a wider variety of cave systems.
Additionally, we will be working towards support for bigger connections, rooms, and entrances, which is a key requirement before we can replace the old caves.
PTV Racetrack
What Went Well
It was created very quickly; we went into it with the idea that it was a simple location with a short timeframe and minimal impact on other teams. However, we achieved a lot more in three weeks than we were initially expecting, with a good modular kit for kart-style racetracks, and the addition of good dressing, theming, and lighting. It was really good to see how the community, especially the racing community, was excited when the track was initially shown to the public. We have since seen organized races on the track. We also got code support for upgrades to the respawning vehicle entity so if people were to crash, break, or abandon the Greycat PTV, it would respawn back at the starting area of the track. We can also set the values of things like time to respawn.
What Didn’t Go Well
Despite finishing the track before Alpha 3.17 was released, it had yet to have a QA pass and be bug-fixed, so we decided to hold it back until Alpha 3.18. Little did we know Alpha 3.18 was going to be delayed so much, so the track, even though complete, made it into the public’s hands a long time after we had hoped.
What We’ll Do Better/Future Plans
We will certainly develop more modular tracks in the future (and have another in the works), but it is on the back burner for the moment. We will try and support other similar-sized ground vehicles like the Greycat STV in the future as well (initial tests have been positive). We will also work with the Mission team to look into adding a racetrack-style mission to the tracks, which will allow the tracking of race times, checkpoints, and laps, and enable the mission to give rewards to players.
Security Post Kareah
What Went Well
We could never have imagined the level of support we received from the Art team, which really rejuvenated the location.
The player-triggered sandbox activity was well received, and analytics showed that hacking CrimeStats at Kareah is still very popular, which was a concern for us as we were taking a risk removing the other hacking locations.
What Didn't Go Well
The mission still has rough edges that need ironing out, which is in progress. Also, additional analytics needs on sandbox activities were identified to be able to further understand player participation.
What We’ll Do Better/Future Plans
We’ll continue to iterate on the sandbox activity and location based on the feedback we’ve received and add further analytics to better understand participation.
Jumptown
What Went Well
The changes to the location were very well received, player participation was consistently very high, and the support we received from Art was well beyond what we expected.
What Didn’t Go Well
The implementation of PES led to performance issues around the location after a lot of ships were destroyed. We also wanted to redrop the locations with RASTAR. However, we were unable to at the time due to it breaking the shops.
What We’ll Do Better/Future Plans
For the next run of Global Events, we’re planning to redrop the locations on different planets to give different gameplay. For example, in thick atmosphere, higher gravity planets, and forests.
Time Trials
What Went Well
The new racing content and time trial modes were well received by the racing community, helped by the Content teams who produced many more tracks than we could have hoped for.
In the backend, the analytics we added were fantastic and allowed us to make very in-depth analyses of each track, which helped determine where they should go on the difficulty ranking and what the target times should be.
What Didn’t Go Well
Poor server performance meant that a sophisticated new system of checkpoint tracking had to be created, though the markers still do not update as responsively as we would like.
Analytics also show that relatively few players actually unlock the second track.
Infiltrate Missions - Orison
What Went Well
The new FPS environments were well-received and a refreshing change after only having underground facilities for years. The ability to assault the locations on foot or in ships was great too.
What Didn’t Go Well
We had to turn the missions off for Alpha 3.19 because we were aiming to release Siege of Orison, but we were not able to achieve this or the new platform clusters (where we were to relocate them) in time.
What We’ll Do Better/Future Plans
We have relocated the missions to the new platform clusters and will be releasing them when possible.
Prison Activities
What Went Well
The Prison Escape mission is surprisingly well-played and offers a new way for players to clear their CrimeStats. Inside the prison, loot on the AI and new selling terminals were well received; players felt the new AI made the prison feel more alive and it gave them another way to earn merits.
What Didn’t Go Well
The Ursa Rover continues to spawn underground, selling items at the prison kiosk still isn’t reliable, and excessive AI are being spawned due to a spawn closet issue.
What We’ll Do Better/Future Plans
For the next release, we’ll fix any bugs we can, including the Ursa spawning issue.
Drake Vulture
What Went Well
Adding the long-awaited “starter” of the Salvage career alongside its gameplay loop was a great milestone for the Vehicle team. While the vehicle was started some time ago, we had held on to it to ensure it released strongly with the gameplay loop rather than without, and this allowed the team to squeeze in some more features to the ship to make sure it hit all the current standards.
What Didn't Go Well
A few complaints surrounding the traversal of the ship due to the gameplay mechanics were somewhat a product of the Salvage mechanic evolving over time to require more manual input than initially expected during the vehicle’s concept in 2018.
What We’ll Do Better/Future Plans
Releasing vehicles alongside their gameplay loops rather than earlier in the project (see Starfarer and Reclaimer) is something we’ve been striving to do in recent times, and we’ll continue aiming to do this.
RSI Scorpius Antares
What Went Well
The Antares was designed alongside the base Scorpius as an optional variant to put into production in the future, with the tail section of the ship outlined as the part that could be geometry-swapped. However, during development, it was clear the needs of the EMP and quantum drive required slightly more power than planned and the team reacted well to adjust both the base and Antares to allow the component layout to suit both.
What Didn't Go Well
There were a few technical issues that we weren’t able to solve that reduced the ability for the second player to have more control over pilot features and a more enhanced MFD setup.
What We’ll Do Better/Future Plans
With Master Modes and new MFDs coming in the future, we should see the copilot get more gameplay features rather than being half passenger, half button-presser.
Salvage & Cargo - Vehicle Gameplay
What Went Well
We were able to support both Feature teams' introduction two key features to the PU, with Salvage requiring a lot of time be spent on the art assets and Cargo requiring a pass across all ships by Design.
What Didn't Go Well
Unfortunately, the scope of the work for Salvage was drastically underestimated, as we thought the existing UV2 damage system all ships used would be suitable out of the box. However, we very quickly realized we’d have to do an entire pass on every ship to up the quality, as you were looking at the visuals much closer than the damage system.
In addition, the gameplay mechanic was built around the idea that you’d be able to 100% scrape the entire hull. However, this wasn’t a consideration in the UV2 damage setup, so some areas were inaccessible, causing frustration to early testers who couldn’t “100%” a ship.
What We’ll Do Better/Future Plans
We’re now more closely integrated with the teams working on big features like this so issues can be found and investigated before development properly starts, rather than being looped in once the prototype has been completed.
Hull Scraping
What Went Well
The long-awaited first iteration of Salvage gameplay finally arrived with Alpha 3.18, which enables players to scrape off hull material and either trade it or use it for field repairs. The core gameplay loop was generally well received and provided a great contrast to other activities.
We also expanded the harvestable system with ship-wrecks and salvageable metal pieces, and introduced the first miniature version of Crafting by allowing players to create a few select items using RMC.
Releasing Hull Scraping alongside the Drake Vulture meant that the ship could come out with a proper gameplay system, and the Aegis Reclaimer finally has appropriate gameplay available to it.
What Didn’t Go Well
A lot of features and systems Hull Scraping was relying on were still in active development when we were building the core gameplay system. This meant the feature was handed off to the EUPU team with a fairly compressed timeline for release.
We addressed the way players would find salvageable objects in the universe way too late in the process, and the balance work for salvageable-object distribution was not properly mapped out.
Not all vehicles could be upgraded to the new Damage Map, meaning some vehicles still won’t work correctly with Hull Scraping.
What We’ll Do Better/Future Plans
We’ve changed our approach to how early we get other teams involved, meaning that downstream teams get involved as early as the prototyping stage. We’ve also introduced additional milestones where downstream and content teams can review and approve the progress we’ve made before we move on to the next stage.
Alpha 3.19
Salvage Contracts
What Went Well
We’re very proud of what we achieved; initially, we had only expected to release with Hull Scraping, but were able to get cargo and the brand-new detachable-components feature included. The mission was well received by backers too.
What Didn't Go Well
We didn’t choose the best ships for the mission, as only some have detachable internal components and gold-standard hulls for scraping (which we only found out after the fact). And, due to developer illness, the first release saw a very rough pass of cargo spawning, meaning there was no time to properly balance or verify that all items could be sold.
The Economy team had to change the value of ship weapons very late into development. This was necessary to balance the problematic insurance issue, which needs a further rebalance. The change meant some backers were disappointed having gotten used to higher rewards.
What We’ll Do Better/Future Plans
For the next release, we’ll choose more appropriate ships with detachable internal components.
New Player Experience
What Went Well
We received a lot of positive feedback from new players that the New Player Experience has helped them learn the game. The visual upgrades to Area 18 have greatly improved navigation, alongside new control and contextual hints.
Throughout the development of NPE, we’ve been able to make many improvements to our mission system, such as the introduction of mission persistence, which allows us to resume a mission at the last active objective if a player loses connection or experiences a client crash.
What Didn’t Go Well
The mission is largely modular but not entirely so, which means more work is needed to bring it to other locations. We didn’t have sufficient time or support to teach the player inventory management or interacting with shops.
In terms of the production itself, New Player Experience was a cross-team initiative and as such, was complicated to coordinate. Production support for New Player Experience changed a few times as it wasn’t owned by a dedicated team.
Additionally, we didn’t have sufficient support to remedy the visual issues with the existing HUD elements clashing with the new Control and Contextual Hints.
What We'll Do Better/Future Plans
We’ve started work on modularizing the remaining parts of the New Player Experience to reduce maintenance and allow us to bring it to multiple locations. We will also introduce additional components to NPE, such as inventory management, shopping and more.
RSI Lynx
What Went Well
The Lynx started off as a very simplistic adjustment of the Ursa but, as we progressed, we felt it deserved more. So, it ended up with virtually all-new geometry and materials, which paid off as the vehicle now looks the part and sits well with the Constellation Phoenix.
We also managed to cram a huge amount of interactive content within the vehicle, including animated chairs, TVs, lockers, and fridges.
What Didn't Go Well
Increasing the scope of work for the vehicle (primarily redoing the entire cockpit area) resulted in the Vehicle team working longer than expected, leaving less time for other teams, such as VFX and Audio, to do their work.
What We’ll Do Better/Future Plans
Next time, we’ll ensure scope adjustments are discussed with all teams and that they’re not unnecessarily waiting for all aspects to be delivered to start their pass.
Mirai Fury & Fury MX
What Went Well
Despite its size, the Fury series is one of the most complex vehicles we’ve ever put in the game, requiring complex animations and state machines all compressed into a very small spaceframe. It was also delivered ahead of schedule, as we were so excited by the vehicle we actually started production before the concept pass was officially complete.
Vehicle Features made a pass on the gimballed thrusters to make them work as we had envisioned. This means the Khartu-al and San’tok.yai will benefit from this in the future.
The MX’s blast shield was our first proper foray into integrating custom Building Blocks UI into the vehicle pipeline rather than reusing other assets, such as door control panels.
What Didn't Go Well
Some of the tech we needed for the thruster rotations took a few attempts to iron out, and we accidentally caused other issues with thrusters on other ships, but all was solved before release.
The MX was originally intended to have generic missile racks but it was clear early on they needed to be bespoke to prevent them from launching into the body or wings when changed for alternatives. This sadly reduces player customization but ultimately makes it more reliable in use.
What We’ll Do Better/Future Plans
We’re pretty happy with how the Fury and Fury MX turned out and no specific things occurred with their development that need adjustment in the future.
Tractor Beam - Item Attach/Detach
What Went Well
Finally, players are able to loot vehicles for components and weapons, greatly expanding the Salvage gameplay loop. This feature also provides additional gameplay opportunities to other features, such as allowing players to swap out mining heads and modules, and provides a strong foundation for the Vehicle Tractor Beam feature.
Internally, the Vehicle Content team were very responsive to addressing content issues with existing components and weapons.
What Didn’t Go Well
This feature wasn’t originally scheduled for Alpha 3.19, so we had a compressed timeline to work with. The QATR for this feature also revealed a lot of issues with content that couldn’t all be resolved in time for release.
What We’ll Do Better/Future Plans
We’ve started requesting downstream support much earlier in the process so that necessary content changes can be done in anticipation of the feature getting ready, as opposed to doing the handover toward the tail end of development.
Mining Rebalance
What Went Well
The community reception has been fantastic and we’re very happy with how the release panned out; long-standing metas and balance issues have been resolved and mining is now a much more nuanced gameplay loop that allows for multiple strategies.
Changes to tractor beams greatly benefited the Mining gameplay loop by enabling the ability to swap out mining heads, modules, and pods. We also identified a better process to balance gameplay loops holistically.
What Didn’t Go Well
There were some issues that we couldn’t properly resolve until after the release, such as mineable rocks always exploding, and the redistribution and rebalance of shop prices required quite a bit of back and forth between various teams before we got it properly implemented.
A lot of issues and edge cases with pricing and distribution were revealed during testing that needed constant fixing and readjustment.
What We’ll Do Better/Future Plans
We want to continue to improve our communication around mining with the community and keep listening to critical feedback to make mining the best it can be.
We’ll also put more trust in the data we gather to help inform future design decisions around mining gameplay.
Alpha 3.18's LaunchAs many of our players experienced, we launched Alpha 3.18 on March 10 of this year, and alongside a bevy of high-profile new features like Salvage, the Vulture patch flyable ship, the surprise Scorpius Antares, new rivers, and new missions, the biggest headliner of the patch was our delivery of Persistent Entity Streaming (PES), which completely rewrote how we save state in the game and ushered in the beginning of the promise of a truly persistent universe where a player’s actions could remain in the game for others to interact with and create a lived-in environment where you could literally leave your mark in the PU. And, just as importantly, PES, was the necessary final stepping stone to delivering Static Server Meshing.
Many who follow Star Citizen appreciated how consequential and important our delivery of Alpha 3.18 was for us and the game itself. Many teams at CIG spent most of the second half of last year finishing out Persistent Entity Streaming, as we deployed it to our Public Test Universe servers for testing in December 2022, and then spent the next 3 months attempting to harden and improve it for launching to our Live Star Citizen service as quickly as possible.
However, when the moment of truth came and Alpha 3.18 shipped to Live, the shock to the system was beyond what we had projected. While it’s true that we expected PES to create a rough experience initially as we ironed out the issues that could only expose themselves at massive scale (and we warned as much), to say that we were surprised by the depth of chaos from the PES launch would be an understatement.
The anticipation for PES and 3.18 was nothing short of unprecedented for us. When the patch first dropped on March 10, we experienced our highest peaks ever for logins per minute and per hour, and had our highest number of attempted logins in a day for the first few days of launch. We say “attempted logins” because as you all know, the service was so overwhelmed by the traffic and teething pains of PES that many players could not get into the game, as various issues stalled users throughout the login funnel. Some were stuck in queues, some couldn’t get their characters to load, some were stuck at an infinite loading screen. As you can read more about in Benoit Beausojour’s (our Chief Technical Officer) account below on PES, we underestimated the multiplicative forces of going to Live and now creating and persisting every entity players created through their actions, creating a load on our service that was beyond our initial forecasts. And it took weeks if not months to expose, diagnose, create fixes, test them, and deploy them to restore the service, all while the game was still running on Live.
We learned a lot from the launch of PES, and while we are still recovering, and regret the compromised service in the first days and weeks of the rollout, it has definitely taught us a valuable lesson to value and preserve the integrity of the service more than we had in the past. That’s why as we begin to roll out the Replication Layer split and crash recovery – two things now enabled by PES – we will do so gradually, and as we begin to deliver Server Meshing, we will create dedicated testing channels to harden those new technologies further and implement standards and thresholds before we “graduate” them to PTU and then Live. You’ll start to see the ramifications of that later in the year and hear more from us later about our new approach to deploying potentially disruptive and game-changing new tech to the game service, but it comes down to us truly committing to preserving the experience for the hundreds of thousands, if not millions, who now play Star Citizen as a live service game, albeit an alpha still in development.
Links
No links available.
Images
3
image/jpeg
image/webp
Metadata
- CIG ID
- 19471
- Channel
- Undefined
- Category
- Undefined
- Series
- None
- Comments
- 0
- Published
- 2 years ago (2023-09-12T18:00:00+00:00)