Star Citizen Live: All About Development

For 3.0 they were very feature-driven, where things kept coming in, and the date kept getting pushed back. With 3.1 and 3.2 they were setting up a certain cadence where they were supposed to be more date-driven. This was working for them for 3.1 to 3.4, however some of the features coming in were still rough, and rougher than they'd like. For 3.5 and 3.6 they didn't release on time, and the features kept coming in later and later. For most of their features, it takes longer than 3 Sprints (3 Sprints = 6 weeks) to get it working - to get it to the quality that they want it to be. Their first iteration of Mining, for example, took that team 6 months to deliver everything that needed to be done. That said, smaller teams, or teams working on smaller features, will be able to do their work within a smaller time frame. As they were getting into the cycle, they found themselves questioning whether the work they were putting out was hitting the mark, and both the teams and the directors were feeling frustrated. As a result they started talking internally about how they could adjust things, and "try this out and see how it works". In the middle of each quarter they have what they call a "Go/No-Go" meeting which consists of the directors, including Chris, Erin, and Brian, taking a look at the features and deciding what does and doesn't "hit the quality bar". What should be happening is that all future work of the thing is completed, so that it's just minor bugs at that point in time, and then from there it gets dropped into the stream and it's ready for release. Before they weren't having that - some teams were and some teams weren't, so some of the quality was there and some of it wasn't. So this (seemingly the Go/No-Go meeting) allows them to make sure that there's a gate for their work to pass through, to make sure the quality they're aiming for is met. This also allows the teams a chance to reflect on why they might not have hit their quality target, which could be things like a vacation, someone was sick, or the feature was more complicated. There are a lot of times when they put things together where they have their best estimate of how long a certain piece of development is going to take, and sometimes they meet that estimate and sometimes it takes longer, but the Go/No-Go meeting allows them to look at the feature and make sure that it's hitting the quality level that they want, and then gives them 6 weeks to make sure that they're releasing to the Evocati on time, and then Wave 1 PTU, and they're making sure that the Quality of Life bugs are getting fixed and that features aren't getting dropped in 3 weeks before they're supposed to be going Live. An important point for Brian is that their releases are solid on being date-driven, and that if a feature isn't ready, then it doesn't release for that patch, and that they're not holding up any quarterly releases because a feature isn't ready, because that does everyone a disservice. That is to say, they think it's more important to keep the cadence going for the releases, rather than making sure a feature releases for a certain patch - it means that the team is immediately addressing those issues without working on bugs whilst they're in Live, and this reduces some complexity on their end as well. Jared adds that he thinks that one of the hallmarks of Star Citizen's development is the constant iteration and re-evaluation of their process - that they want to get better at making the game just as much as they want the game itself to get better, so these kinds of changes are inherent to the company. Todd says that what people need to understand is that in normal game development a company would just "run" until they reach Alpha, at which point they'd look at what they've done and realise that they've made a huge mess that the need to clean up before Beta, which is when they have to polish and tune the game, and have an aspect of iteration. In their case, having a Live product since very early on in its development creates challenges that sometimes they're used to and sometimes they're not, so it's a learning process for all of them regardless of how long individual people have been making games for, because Star Citizen is "a very unique beast". Jared says it's a double-edged sword of challenges and opportunities, where there are things that they have to account for but there are also benefits of running a Live Environment, such as the ability to get instant tangible feedback during the development process that can help guide them. Todd agreed, but added that sometimes it feels like they're building a railroad whilst they're on the train.

They have ships that they are building and that they've done concept sales for, so that pipeline is just running. For what they would consider careers or professions, Todd (and he thinks all of their system designers too) views them as a collection of different activities, so what they're doing is building those activities, and when they come together then you would have something that would be considered a profession. They have priorities for both the PU and Squadron 42, where from their development standpoint Squadron 42 is their top priority, and as a result most of the team and most of the resources are focused towards that. On top of this, whilst they have things that are solely Squadron, and some that are for both Squadron and the PU, there are also things that are solely for the PU, and it's those things that won't get as much love (for now) due to their priority as a whole being Squadron. When Squadron is done and ready to go, the PU should get some more attention. That said, they do have resources that are solely focused on the PU, so for example this means that they have a team that is focused on Resource Gathering, which includes Mining, Salvaging, and Harvesting, and then they also have teams more focused on things like Cargo, but that team has also done working on Scanning and other aspects that they consider to be integral to both projects. As such, their priority is to finish that work before they return to any PU-focused work. Todd then gives an update on the status of some professions, saying that Mining is in progress, where they've done Prospector mining, are working on FPS mining, and will need to do Orion mining when "that starts getting ready"; they've also got Salvage but that falls under Resource Gathering like Mining does; then they have the early stages of Trading that he wouldn't consider Hauling; then there's Piracy, Security/Mercenary, and Bounty Hunting, and these would be the first five that they'd be focusing on (so that's Resource Gathering, Trading, Piracy, Mercenary, and Bounty Hunting). After that there'll be secondary professions like Refueling, Rearming, and other similar things.

Todd thinks that it depends on the bug. He uses the HUD bug as an example, where you look at certain bright backgrounds and then can't see your HUD, saying that it's something that just hadn't been prioritised because they know that they're re-doing the HUD and adjusting it. They've had initial talks regarding how to fix it, and for Todd it's a Quality of Life experience that will need to get fixed, ideally sooner rather than later. However, with Staggered Development, if they're building features that are intended to release within a certain time-frame, and their time building the features is half of that time, then that leaves less time to fix things, whereas if they spend three quarters of that time they have instead of half, then they have more time with which to fix the bugs and work on the Quality of Life. As such, Erin, Todd, and QA go through and look at the bugs, and pick out bugs that need to be prioritised (and this can involve working with PR too) which are typically related to the gameplay experience aspect, regardless of whether the bug in question is trivial, minor, or moderate bug, instead of only focusing on critical bugs and blockers. So this means that they've changed their pipeline to get these bugs fixed throughout the quarter as well, so Players will start seeing Quality of Life issues being slowly resolved. Brian adds that they're moving forward so fast and focused on the future that it's really important for them to stop and recognise that there are some bugs that have been there for a while that need to be dealt with. Todd continues by saying that with the Quality of Life stuff, when they take those bugs into account they know roughly when working on something that will cover the bug, such as with their UI reworks, so if they have an MFD bug but the ship UI is being reworked, they'll assess whether it's going to be fixed based off of that work, or whether they can live with it for a little while. Simply put, they don't want to waste time by fixing a bug that's going to be dealt with anyway by something like a rework, and therefore they want to be as efficient as possible. Typically they'll look at a bug and judge whether it's going to get resolved in the next 6 weeks or in the next 3 months, and if so then they won't fix it, otherwise they will, and that's a juggling act they go through every quarter. Jared says that that's a big part of why the new Staggered Development initiative is taking place, which is a desire to have more time to spend addressing bugs and Quality of Life issues, so if things go as they hope they will, it should lead to an overall improved experience with many long-standing bugs being addressed. Todd adds that he's never seen a Game Dev get it right the first time.

Absolutely not. They've only done two episodes of Pillar Talk, so they're still exploring the format and all of the different areas that they can touch on with that format. For the second episode Erin was visiting the LA studio, and since they had already moved towards the new Staggered Development initiative, they thought it was a good opportunity to have him talk about that candidly with John and Eric, and attempt to shed some light on why they're doing a lot of things that they're covering in this episode of SCL. In the future, Pillar Talk will continue to address Pillar issues with Pillar directors. If the show was only going to be about stuff that was specific to a patch, they probably would have called it Patch Talk, so they're going to continue to iterate with Pillar Talk as a format, just as they do with anything else.

They had a big summit last year to figure out what work needed to be done to implement SSOCS, and have been working on it ever since, which is almost a year now. The meeting that Chad was in that made him late to this episode was a meeting with CR about their progress, of which the mood is pretty positive because they've made "very meaningful progress". They've made some large changes to Object Containers in terms of how they load entities, separating them into Dynamic Entities and Static Entities, where the former are streamable but the latter aren't. They've made a Star Engine Service, which is written similar to game code but can be deployed as a cloud service. Using this they built the Star Hash Service, which is a kind of coordinate system across the universe (like geohashes), allowing them to partition the universe and know what's streaming when, as well as being able to store those things and look them up. They built a service to keep track of Entity Aggregates in the universe, "which was kind of the roots of entity trees". The Star Hash Service has also been hooked up to the Streaming Manager, which was previously created to govern CSOCS, so it knows if certain aggregates are streamed out, or whether to stream certain aggregate groups in. They've also implemented a Prototype In-Memory Persistence Model, which allows them to write out the state of any Star Hashes to a local cache whenever they're streamed out, so that they can test game code (like service beacons) to see what breaks. For SSOCS to work they need to implement Global Persistence, which completely changes how the game runs, and how entities are spawned and loaded. They've had to revisit existing gameplay features to make sure they aren't broken, which they've done. They next have to implement the real backend for persistence, because Global Persistence will require them to be able to handle a much higher volume of data, which is a Work In Progress. The last big thing is the changes to game code that are needed, which requires all game feature teams to revisit their features. They have unknown unknowns too, because they need to test heavily to know what work will need to be done. They're also considering phasing out SSOCS so it won't need Global Persistence for it's first release, because their Prototype Model is working well. The Player won't notice much difference, but there should be some streaming benefits from this. Server Meshing is a similar situation, but SSOCS is a prerequisite so there's only so much they can do before SSOCS is completed.
The engine they had was CryEngine, and now they have Lumberyard, both of which are level-loading based engines, so there's no entity streaming in them as-is. Years ago they made some large changes to the engine called Object Containers, which is their own grouping of entities as well as level data like brushes. They planned years in advance where they wanted to get to, both now and in the future, which was a huge push for foundational changes. They built on top of Object Containers with Net Bind Culling and Serialised Variables, allowing them at runtime to be able to replicate and unbind entities from Clients. Then last year they deployed Client-Side Object Container Streaming (CSOCS), which is taking the Object Containers at runtime and streaming them in and out, basically unbinding and binding Object Containers. That alone was a multi-year effort.
Now they're doing the same thing on the server (Server-Side Object Container Streaming) and that too is itself a large effort. It started in full force last year - they had a big summit where they got the programming disciplines together in Germany and had a week-long deep-dive on the specific implementation details for the effort across the entire game, including the core engine, game code, as well as the backend services in order to execute this. They've been working on SSOCS ever since then, which is almost a year now. Chad claims that they've made very meaningful progress, and that he just got out of a meeting with Chris Roberts about the progress they're making, and that the mood was pretty positive coming out of it.
Some notable things that have happened so far include: they've done a large set of changes to Object Containers in terms of how they load entities - they've now separated things out into what are called Dynamic Entities and Static Entities, essentially allowing them to differentiate between what is streamable and what isn't; they've made something called a Star Engine Service, which is a type of game service that is written in a similar way to game code but can be deployed as a cloud service; using the Star Engine Service they've built what they call the Star Hash Service, which is their version of a kind-of coordinate system across the universe similar to geohashes. This gives them a way to partition the universe so that they know what sections of the universe are streaming at any given time in an efficient way, as well as storing and looking them up efficiently.
So they built a service that keeps track of all of what they call Entity Aggregates in the universe, which was kind of the roots of entity trees. In addition, the Star Hash Service has been hooked up to the Streaming Manager. The Streaming Manager was previously created to govern the current CSOCS, but now they've done the work to connect it to the Star Hash Service too, to drive streaming events to indicate to it that certain aggregates are streamed out, or to collect certain aggregate groups and stream them in. They've still got a bunch of work to do, but what they've done is they've implemented a Prototype In-Memory Persistence Cache (I think he meant Model instead of Cache). For SSOCS to work they basically have to implement Global Persistence, which is a huge set of changes for the game, completely changing how the game runs and how entities are spawned and loaded. For testing purposes they made the Prototype In-Memory Persistence Model, which allows them to write out the state of any of the Star Hashes to a local cache, whenever they're streamed out. This allows them to test game code such as the mission system, the transit system, service beacons, etc. to see what breaks whenever they start streaming things in and out of the game server.
Due to how significantly they're changing the way the game works, they have to revisit the existing game features to make sure they aren't broken, and to fix them in places that they are, which Chad says they've done. The next big things for them to do are to implement the real backend for persistence, which requires rewriting the way that the game writes out to persistence, and to the backend, the cloud services that handle that data so that they're much better at handling much higher loads - this is necessary because there's already a large amount of persistence data in the game right now, due to persisting Players and ships and items, and this is changed all the time by things like flying around and using fuel, or when something breaks off your ship, but Global Persistence means they're looking at persisting the whole universe for all of the game servers and for the whole game, so there's a much higher volume of data to deal with, thus requiring a really big set of changes on the backend to handle that. This work is a work in progress that continues.
The last big thing (and he adds that there's a lot of little details too but he's covering the big-ticket items) is the game code changes that need to happen, meaning they need all of the game feature teams to revisit their features and make sure they're not broken, which is a big effort. As such, until they start testing heavily, they won't even know of all the work that they're going to have to do, so there's a lot of unknown unknowns. Chad sees the progress they've made so far this year as good, but says however that one particularly positive thing that they've figured out is that their Prototype In-Memory Persistence Model seems to be working very well, so they're considering phasing out SSOCS, so that it doesn't need Global Persistence the first time they ship it. This means that they ship it in such a way that if a server goes down, then its state is lost, but Player state isn't lost, so from the Player's perspective the game won't have changed, but it does mean that they can add in some of the streaming benefits without yet having the Global Persistence benefits, which will be released once they've finished that work. As such, a part of SSOCS could end up on a more accelerated release schedule than they maybe anticipated.
Moving on to Server Meshing, it's something that has also been a long time in the making. The Net Bind Culling and Serialised Variables that were mentioned earlier were a prerequisite for Server Meshing. Similar to SSOCS they have begun significant planning and work on the feature, however SSOCS is a hard requirement for Server Meshing. This means that even whilst they can make progress on Server Meshing, because most of the work for Server Meshing falls on the network team with support from the core engine and game code teams (whereas SSOCS is mainly the opposite with the addition of backend services), they can do some work in parallel but they can't deploy it in full until SSOCS is done because it's a prerequisite - it's how Server Meshing fundamentally works - so it'll come after SSOCS for sure.

They don't want to commit to release dates quite yet for SSOCS because things are still in flux. They can consider content swaps if they wanted to add in a new area and take something out to account for it. That said, no decisions have been made on that. Even if they released SSOCS earlier than they anticipated, they wouldn't know what the result would be because they'd have to measure. That is to say, any time an optimisation is implemented, they don't know if the job is done until they've taken a measurement to be able to conclude that it's working. So even after they've got SSOCS done, it's not a guarantee that they can keep increasing the content, and they may find that the gains aren't as much as they'd like, which would require them seeking other solutions. So these details will become more clear as the plan for SSOCS gets filled out and as they do more testing and can actually say with more confidence what the performance behaviour is.
Todd adds that microTech and New Babbage are still being built, so no matter what the Content Team will still be working on those locations. He continues to say that when they get the LODs, the AI, and all the other downstream dependencies in there, then that will give them an accurate profile for them to know whether the server will be able to handle it and if it can't, then they evaluate and consider taking something out, or the server can handle it and everything's okay. Part of the benefit of SSOCS is that it allows them to stream out areas where no Players are, but there's an unknown about how much that impacts the universe, because if your most expensive assets and content areas are the popular Landing Zones, depending on Player habits and where they go, they might find that those areas are constantly streamed in and are effectively pinned to always be streamed in.
So whilst they do stream out most of the PU, it can end up not impacting their performance issues that much because most of their performance issues are at those large Landing Zones. What they're more confident that SSOCS will do is make it so that the universe can be more detailed, so they could add much more outposts or truck stops or whatever, because if the server is capped at 50 Players then it doesn't matter if there's 1000 outposts, because only 50 can get loaded in at any given time. Chad says it gives a kind of upward maximum on the maximum distribution of what can be loaded in (I think he just means it increases their maximum load limit). But really it comes down to what the reality is in terms of performance, which they'll have to measure, because if the reality is that the Landing Zones get streamed out half of the time, then that might be good enough.
Jared specifically responds to why SSOCS isn't on the Roadmap, saying that it's not a list of things that are in development, but a list of things that they think and feel confident that they'll deliver on time to be included in a particular patch - it doesn't always work out that way, but with something as big as SSOCS they want to make sure they're more confident about when they can deliver it before adding it to the Roadmap.

Chad says there's not really any gameplay features that rely on SSOCS - it goes more the other way where SSOCS relies on the gameplay features being written in a way that works with it. Really it gives them a way to scale better so that they can put more content and more features in, but not so much that there's some added behaviour or feature that SSOCS adds in that now the feature can do something that it couldn't do before. The tech that they write to create SSOCS could enable, but it's not server streaming that does it, it's more that the foundational technologies that they make in order to create SSOCS could themselves lend to some interesting future development, which is especially true with Global Persistence. SSOCS requires this to work, because they have to stream out an area and store it out, but GP is something that they really want in the game and doesn't require server streaming and could technically have it without it (although the performance wouldn't be good), but it's something that they're making that could be thought of as a feature that they made along the way in support of SSOCS.
Todd adds that the only thing that the game teams will be responsible for will be making sure that their game code works with SSOCS, which means that if they're doing that then they're not doing feature development, which is unfortunate but also a necessary evil. Brian adds that they had a similar thing with CSOCS, where the unknowns were unknown so they just had to take a chance but they managed to get it sorted.

No. There are some fundamental reasons as to why they need to keep wiping the persistence database right now, which is largely because the game is very much in flux at the moment. With every patch, they're changing the format of the data, and pretty dramatically so at times, so it'd be foolish to end the wipes so early on despite this reality. Instead, their goal is to get to a place where the game features are more stable and less tumultuous before they "flip the switch". On top of this, they need a strategy about what they do when they change the formats of data [after they stop wiping], which will happen and won't just stop - they just want to get to a point where they're doing it less often. Chad clarifies that this isn't something that has been forgotten about, and that they've had a few meetings recently to discuss this but it's something they care a lot about. He thinks that they have a really good plan about what to do, long-term, about stopping the wipes, about how they can migrate data, and how they can give the gameplay programmers a methodology to ferry their data whenever they change their formats.
To give a little bit of hope, they are also exploring (but can't promise) potential ways to persist things more permanently sooner, which would be important things like ship purchaces or UEC - things that are seen as important to the Player's progression in the game. They're exploring possibly storing a much more course level data about them, across wipes, so that they can kind of restore Players back to where they were before - their ship might not be in the same place, their gun might not still be equipped, but like the UEC they previously earned, they still have it. That is, it's the higher priority things such as these that they will look into finding a way to persist between wipes, things that negatively affect gameplay when they're reset. Eventually they do want to stop the wipes entirely, but they're looking to start with the basics and having a long-term strategy for stopping the wipes.
Todd adds that another reason why they can't just stop wipes with the release of Global Persistence, is that the in-game ship prices are going to take a long time to tune in and balance, so whilst they don't want to wipe every quarter, they do need to be able to wipe when they need to do so, as they adjust the economy. Apart from just wanting to allow Players to make and keep progress as they play for their own benefit, instead of having to try and achieve their goal within 3 months, it also benefits development to do this because it helps them to test the economy and better understand if things are priced in such a way that the Player(s) can afford them within the time-frame that the Dev's are aiming for, and it depends on the telemetry that they're getting back. Right now they just don't know - they have a best estimate, but they need to be able to see it working consistently in practice for them to properly adjust it.

Todd doesn't think so - they've changed the way that they develop things and are also at a different stage in development. A lot of the time when they're talking about features like Law, or features that they're currently working on, they have an internal document of what they want to achieve, which Todd would call almost like a one-pager, which has the very high level beats of what they think they can hit for Tier Zero, and what they need to hit for Tier Zero. The previous documents used to go through Tier Zero to Tier Four, so there were a lot of things that would happen when they get to Tier Zero and release it, and then it would change, thus making Tiers One through Four completely moot. Todd's more than happy to talk about what they're working on, and how they're moving forwards, and sharing those design ideas with the community, but he doesn't think that the deep-dive documents are worth putting out any more. Chad adds a more programmer perspective, saying that the sync-up between programmers and design would often reveal technical considerations that hadn't been fully considered until they started implementing the design, as well as more design questions that hadn't already been answered by the document. So now it's "more Feature Teams" and programming is working closer with Design, allowing them to be more agile with said design to the benefit of all, which is to say that the programming side gets an earlier view into the design process to give feedback, and design has a better source of information in terms of what's possible and what's reasonable within a certain amount of time. This reduces expectations on the programmers too who would previously be looking at the potential Tier Four implementation and seeing that they've got to hit that long-term goal that they're not confident that they'll do anyway, which might then affect how the programmer does the implementation. As such, switching to this more agile method has felt like a good set of changes. Jared adds that the design documents worked against agile development, and worked against one of the biggest benefits of Star Citizen, which is having the Live Game Environment where they can put out iterative things, see how they work, and get feedback. He uses an example of the Proximity Assist that will come in 3.7, as an iterative improvement to the Hover Mode that was released previously in 3.6. So their more agile development allows them to adjust between their implementation of Tiers, to create a better system that wouldn't necessarily be possible with the long documents because they would either lock them into something that would deny them the feedback of the community, or be what was the case for most of them, which was that they became wildly inaccurate.

It'll be coming back. Todd says they just had a meeting with Chris about refueling and the two different aspects of that. John Crewe's Pillar is the vehicle side, so one of the vehicle feature teams will focus on it soon, and then Todd's Pillar will focus on the Resource Gathering side of it. The former would be the fuel scoops, and the latter would be quantum fuel mining or harvesting, as well as the gameplay loop of refining and then being able to sell or transfer that fuel. Todd thinks we'll see glimpses of this once the designated teams complete their current work, because frankly these fuel features aren't needed for Squadron 42, which is the priority. If the PU team can work on it instead, then that's what they'd do.
Jared adds that going forward with future major additions or changes to the Roadmap, although maybe not with smaller ones, they're going to start adding Comm Link posts about why each successive change occurs when they do.

It's due to the complexity, and their desire to have everything as accurate as possible. Publishing the Roadmap is their ability to be transparent about what they're doing, to show their progress and what they plan to do in the future. Their end goal is to give everyone the most up-to-date information, but they also want it to be accurate. So when something on the Roadmap comes in early or late, it has a knock-on effect with something else, so they take the time to verify what impact the change has had, which itself takes time, and then once everything's verified they go through and give an update. What they've realised is that it seems like too much of a gap in between. They've already discussed this internally, and moving forward they're going to change the frequency of the updates, which will mean smaller updates more often. Some of the backend stuff might not be as 100% accurate, because they haven't gone through the entire process yet, but it'll give a clear glimpse of how when they know something moves, they should update the Roadmap to reflect that so that people know what the expectations are. This is also true on the flip side, where if something is finished sooner, then that should be updated as well.

Vulkan's going good. They had a summit a little while ago where the Engine Team and everyone on the rendering side got together to discuss what it is that they need to do, where they add and who's going to take on what. It's broken down into three stages: Stage One is where they clean up the use of the global state and the rendering code, which has been underway for approximately the last few months; Stage Two is a refactor of the render passes to take advantage of new APIs, as well as current and future GPUs to get more out of them, which started a couple of weeks ago after the summit, and that progress is going good; Stage Three is the implementation of the actual Vulkan backend, and whilst on paper the work on that hasn't officially kicked off yet, parts of the team have already started to work on this, and there are some parts of the Vulkan backend that's "already been in there", so progress overall is good. Brian continues to say that it's "not an all-or-nothing", and that they could have some stuff come in before the entire Vulkan backend is there. He's been told that DX11 will already benefit from the first two stages, and as such there should be some performance improvements because of that. Ultimately the plans aren't to just support "Vulkan" just by straight ports of the render, but to actually refactor all of the render code so that they can take advantage of everything that Vulkan has to offer.

Yes and no. A portion of the team will probably roll over fairly quickly, although Brian's hoping a handful of them take a few days off because they'll have been working really hard. Others will go directly on pre-productions and probably some forms of production for Chapter 2 (Episode 2? The 2nd Squadron 42 game anyway, because Squadron is intended to be a trilogy). It's also important to note that some people, or some disciplines, won't be needed all the way to the end for Squadron - they're working now but they'll roll off, so before Squadron gets officially released, they'll be able to roll over to the PU. So as they get further along they'll constantly evaluate where they are, look at the resources, see the status of everything, and most likely update the Roadmap accordingly as to whether that increases their progress on what they can provide for the PU, while the rest of the team readies themselves to jump onto Chapter 2.

Yes. What they did previously is that they'd be working, and designers and programmers were not allocated to just balancing, so they've created a balance team that for the entire quarter will be focused on balance issues, focused on fixing things that are just not working how they want them to. So this team just got created, and the main designer on it was focusing on the Vanguard before and building that, and then from there he's moving over to the tuning and polishing of these things. From his standpoint he would be building something, and then would be able to fit tuning in for about 3-4 weeks to do as many changes as possible, and then would go back to building something. As a result, they didn't get into the cadence, nor did they get into the balance changes that they want to do for the long term.
Players should see stuff in 3.7, but should see a lot more in 3.8 and 3.9. Specifically, this new balance team will be doing general tuning passes, working on pip and targeting problems (which would include the gimble assist as well as the fixed gun problem), turret behaviours, making missiles it's own mode, working to encourage closer combat and penalise combat at higher speeds, accuracy and shield degradation, these types of things and more. They're going to be able to tune in testing and iterate on these things at a much faster rate than the have before. They see this as a core change, about getting the combat to feel right so that it's more intimate and less pixel-hunter, so that's their goal to tighten that up because it's needed for both Squadron 42 and the PU, but Squadron specifically because its first iteration has to have combat done right.