No Max. This is a weekly update. Something CR (almost head in hands) has alluded to with comments in the run up to the Evocati release along the lines of "if it can't be finished on time why don't they just say".
I know how it works. I have managed projects from small to larger than SC. Software and non-software. In multiple EU countries, in the US, cross-continent.
At the end of the day the "not knowing" comes down to those involved believing that pigs will fly rather than saying this will probably need more time. And if it doesn't then it finishes a few days early! As I said its a weekly update. It can be a very tough thing to instill though because people - by default - don't like reporting slippage until they have to.
And for management as early as possible is best. CR would be much not having to explain slips and would much rather report stuff happened on time or even early!
This no longer applies because they have stop giving those estimates publicly, instead focused the schedule on what's left, first what was left to the Evocati to start, then what was left to the next phase of the Evocati and now to the start of the public PTU.
The method changes and they pretty much grab Jira that is the issue tracker many companies use and translate that in the number of bugs and issues up for completion for the build, while they internally for sure can and will face slips, publicly that is shown as a slow burndown rate instead of delays.
One of the things I wasn't expecting to see on 3.0:
The ability for AI to pull you out of Quantum Travel. One interesting mechanic especially when players get to do this while doing things as bounty hunting.
This week in closing out Alpha 3.0.0, we released fifteen internal builds and three more to the Evocati for testing. On Wednesday, the team coordinated several 60-player Evocati tests, which went well. The test was to gauge increasing the maximum number of players on a server that may now be possible thanks to some recent network and game code optimizations that are part of the engineering team’s performance and stability drive. We wanted to thank all our testers who participated and also give a big thanks to everyone who contributed to the Spectrum thread. We took your feedback into consideration and continue to welcome your thoughts here.
A big thanks to everybody who contributed their feedback to the Spectrum thread. We took your feedback into consideration and continue to welcome your thoughts here.
One question that came up often was the difference between a ‘task’ and a ‘bug.’ A task can be anything from crafting a feature to refining a game mechanic to improve the player experience. A bug is an unintended result that occurs while using a functioning mechanic/feature. To use an example, getting the physical shops and the ability to buy items into the game is a task, having item names and descriptions not appear in the mobiGlas while shopping is a bug.
Finally, as you may have heard during the final presentation at CitizenCon, we are going to switch over to a quarterly release schedule for the PU in order to provide content drops on a more consistent basis. To that end, we will be modifying the Beyond 3.0 Overview section to a new PU Roadmap that will show you exactly where the various features and additions will fall in our quarterly release schedule. If a feature requires more work, then it will transition into the next release. This roadmap will be posted once 3.0.0 goes Live.
So remaining category has its set of remaining bugs and ongoing tasks to be completed:
This makes up 82 Bugs and 269 ongoing Tasks. Even with multiple ETF builds last week and +100 bugfixes it was nullified by the number of newly issued up bugs.
In the report page, you'll see a status update in each of those sections and the bug-fixing changelog.
How long do you think before they miss their quarterly release schedule and then announce they are switching to a every 6 month release schedule?
The 2.x releases were already 2-3 (max 4) months apart, so seems achievable.
The only thing that would mess that up is the testing phases so I would put it more 4 months > Evocati > PTU > Live > 4 months as something more solid.
Or even as @Vrika said, but that could mean very broken releases just to have stick to a target date so I wouldn't see that working properly.
How long do you think before they miss their quarterly release schedule and then announce they are switching to a every 6 month release schedule?
Where I can not fault your logic, one of the major differences once 3.0 hits is the incremental patcher. Up till now and after 3.0 lands, we will be getting far more patches considering they are far more easily delivered then a 30g download every time they wanted to deliver.
The true question, will they hold true to their major milestone delivery every quarter. I hope they do!
Where I can not fault your logic, one of the major differences once 3.0 hits is the incremental patcher. Up till now and after 3.0 lands, we will be getting far more patches considering they are far more easily delivered then a 30g download every time they wanted to deliver.
The true question, will they hold true to their major milestone delivery every quarter. I hope they do!
--Izz
That is true.
If the old method stood, each member of the Evocati would have downloaded already +500GB of patches, by the end of testing each member would likely have downloaded 1 Terabyte of data at the pace testing goes.
But I would say this is more useful for smaller patches, especially more frequent hotfixes.
The only thing that would mess that up is the testing phases so I would put it more 4 months > Evocati > PTU > Live > 4 months as something more solid.
<snip>
I would assume that they will adopt program freezes. Which is what they did to get 3.0 to Evocati. So basically carry on as they are with a 3.1 freeze some weeks after 3.0 is released to alpha.
There are pros and cons with using freezes of course. They would support "time phased" releases though - which in turn avoids the "pressure cooker" situations that can surround a "feature based" approach. (Which is why they said they were going to do timed releases after getting 1.0 out to alpha!)
Anyway: teams develop for "3 months"; build is frozen and handed off to QA; QA package the release and progress through Evocati, PTU and alpha. Bugs found during testing are ideally addressed in the on-going development - depends what they are though.
If a bug is found and not fixed before the next drop QA need to communicate this to testers so as to avoid "wtf we told them about this bug in the last drop, they just don't listen, we are wasting our time".
I would assume that they will adopt program freezes. Which is what they did to get 3.0 to Evocati. So basically carry on as they are with a 3.1 freeze some weeks after 3.0 is released to alpha.
Their are pros and cons with using freezes of course. It would support time phased releases though which in turn avoids the "pressure cooker" situations that can surround a feature based approach. (Which is why they said they were going to do timed releases after getting 1.0 out to alpha!)
Anyway: teams develop for "3 months"; build is frozen and handed off to QA; QA package the release and progress through Evocati, PTU and alpha. Bugs found during testing are ideally addressed in the on-going development - depends what they are though.
If a bug is found and not fixed before the next drop QA need to communicate this to testers so as to avoid "wtf we told them about this bug in the last drop, they just don't listen, we are wasting our time".
But that was also the huge problem of 3.0, it's impossible to predict how many bugs, especially how much time will it take to work through that until it's out, so if you include the testing in that timeframe then it's doomed that the timeframe goes off the rails the moment something goes beyond whatever "buffer" they give it.
That's why I was thinking that the first release (evo) and final release (live) should be the freezes, this has the benefits
a) allows a release to the evo on time, even if the build is still very raw because that phase is meant for it
b) the unpredictability of testing stops being a factor to failing that timeframe and becomes more achievable, giving backers a much better idea of when to expect the next update counting from the live release of the previous one instead.
I would assume that they will adopt program freezes. Which is what they did to get 3.0 to Evocati. So basically carry on as they are with a 3.1 freeze some weeks after 3.0 is released to alpha.
Their are pros and cons with using freezes of course. It would support time phased releases though which in turn avoids the "pressure cooker" situations that can surround a feature based approach. (Which is why they said they were going to do timed releases after getting 1.0 out to alpha!)
Anyway: teams develop for "3 months"; build is frozen and handed off to QA; QA package the release and progress through Evocati, PTU and alpha. Bugs found during testing are ideally addressed in the on-going development - depends what they are though.
If a bug is found and not fixed before the next drop QA need to communicate this to testers so as to avoid "wtf we told them about this bug in the last drop, they just don't listen, we are wasting our time".
But that was also the huge problem of 3.0, it's impossible to predict how many bugs, especially how much time will it take to work through that until it's out, so if you include the testing in that timeframe then it's doomed that the timeframe goes off the rails the moment something goes beyond whatever "buffer" they give it.
That's why I was thinking that the first release (evo) and final release (live) should be the freezes, this has the benefits
a) allows a release to the evo on time, even if the build is still very raw because that phase is meant for it
b) the unpredictability of testing stops being a factor to failing that timeframe and becomes more achievable, giving backers a much better idea of when to expect the next update counting from the live release of the previous one instead.
That's how I would go about it at least.
What if a raw drop is still in Evocati after 3 months? Do you create a second Evocati version? Or if the previous version was still in PTU so you create a 2nd PTU? Your own - valid points - can be used against your own solution.
You can end up drowning in what-ifs.
It will come down to if by "quarterly releases" they mean "quarterly releases". If this is the case then their mantra will be "release with bugs if necessary" rather than "only release if all bugs are sufficiently fixed".
Now since your comment is 100% valid the way they could attempt to introduce control - since they will make estimates! - is to limit the amount of new stuff that goes into a patch. Potentially holding stuff back for further internal bug fixing and polish.
A new version could release with a known bug however. Hence my comment about why QA's communication will be critical. And why the priority will be fixing bugs in the development software rather than the frozen branch. (They will hope one fix does both of course).
At some point - post 3.0 - we will know. Maybe by the end of next March?
My opinion of an ideal testing scenario through release once the differential patcher is in play is to have an evolving test schedule. What I mean by this is as follows.
Today we have Evocati, PTU, and GA. In the past, the patches were major undertaking as everyone needed to download the massive release every time the smallest of changes were required.
Tomorrow, post differential patcher, that is no longer the case.
[what I am about to say is what I would like to see happen, under no way was it confirmed by CIG]
I would love to see the following: Evocati servers stay in place, they get all the sub point releases first. 3.01a-3.09z level releases.
PTU then tests all the point releases. 3.1-3.9 before those are promoted to GA
GA would then get the builds after scrub from PTU.
As for the quarterly releases, what I would anticipate is those are major releases. Most likely 3->4 as an example. They could do point releases, they were talking about the next major being 3.1, but that is simply semantics as to the numbering in my opinion.
There is no reason not to have continuing testing throughout the process once the differential patcher is in place. It would certainly quite many concerns by having numerous micro patches versus very large and sporadic major patches.
This week in closing out Alpha 3.0.0, we released three more builds to the Evocati as well as fifteen internal builds. The team also reviewed last week’s tests where we increased the number of players on a server. These tests were incredibly helpful to the team and even resulted in revisiting the priorities of bugs that became much more prevalent when the number of players were increased.
In larger news, we’re approaching a PTU candidate build. All of the directors are in daily reviews to assess the current state of any remaining tasks and the latest bug fixes. As you’ll see from the graphic, we’ve reduced our overall count to 179 Must-Fix issues.
So remaining category has its set of remaining bugs and ongoing tasks to be completed:
Last week the total number was 351, this week sits at 179.
On some highlights:
Shopping pretty much complete now, fixing & polish remain. The first pass on pricing of shops has been done.
Continuing to bring online missions and logic passes on the 2 main mission givers.
Starmap now rendering in the ship's UI with a method to transition between radar and map.
Now possible to logoff from the game from things as ship beds.
Finishing up the afterburner, working on gravlev issues.
Midway through a pass on atmospheric flight mode.
Following the performance drive of the network tests on ETF, changes made for servers to utilize more cores without extra overhead, and other things needed to allow high player counts.
In the report page, you'll see a status update in each of those sections and the bug-fixing changelog.
This ATV was one of the first ones I can remember where they mentioned PTU in the messaging. They must feel that they are very close to pushing it to the greater community.
Another week and yet another way of categorizing and displaying everything that needs to be done.
Would it kill CIG to pick one way of making progress reports and stick with it?
If you look at it as more of a PR move to put the best face forward, and not to deliver accurate progress reports, it makes much more sense.
Hiya Argle, nice to see you're still here. To get to your point however of course it's PR driven. They are reporting more data about a specific part of development then they have in the past so there is some trial and error involved to get the most data out in the most concise format. What we are seeing is the very definition of Public Relations. It's the PR Department's job to make sure that the information is presented in the best way possible. It's always about PR whenever you hear anything from a developer CIG included.
In the latest newsletter, 3.0 PTU currently aimed before 20th December, what is legit because the holiday break they'll push as far as possible to get that out by then, we will see how this flows in the next weeks.
In the latest newsletter, 3.0 PTU currently aimed at 20th December, what is legit because the holiday break they'll push as far as possible to get that out by then, we will see how this flows in the next weeks.
The screenshot said it's before 20th December, not at 20th December.
But it's only another ETA in a long series of 3.0 ETAs that they've failed to keep.
Didn't the same thing happen to 2.4 or was it 2.6? It ended up being long overdue and people were so upset that they released it in December when it wasn't really ready and did a few patches after that to fix the major problems and then focused on 3.0.
"We all do the best we can based on life experience, point of view, and our ability to believe in ourselves." - Naropa "We don't see things as they are, we see them as we are." SR Covey
Comments
The method changes and they pretty much grab Jira that is the issue tracker many companies use and translate that in the number of bugs and issues up for completion for the build, while they internally for sure can and will face slips, publicly that is shown as a slow burndown rate instead of delays.
The ability for AI to pull you out of Quantum Travel. One interesting mechanic especially when players get to do this while doing things as bounty hunting.
So remaining category has its set of remaining bugs and ongoing tasks to be completed:
This makes up 82 Bugs and 269 ongoing Tasks. Even with multiple ETF builds last week and +100 bugfixes it was nullified by the number of newly issued up bugs.
In the report page, you'll see a status update in each of those sections and the bug-fixing changelog.
They've never tried to be honest, their aim is to look cool.
The only thing that would mess that up is the testing phases so I would put it more 4 months > Evocati > PTU > Live > 4 months as something more solid.
Or even as @Vrika said, but that could mean very broken releases just to have stick to a target date so I wouldn't see that working properly.
The true question, will they hold true to their major milestone delivery every quarter. I hope they do!
--Izz
If the old method stood, each member of the Evocati would have downloaded already +500GB of patches, by the end of testing each member would likely have downloaded 1 Terabyte of data at the pace testing goes.
But I would say this is more useful for smaller patches, especially more frequent hotfixes.
There are pros and cons with using freezes of course. They would support "time phased" releases though - which in turn avoids the "pressure cooker" situations that can surround a "feature based" approach. (Which is why they said they were going to do timed releases after getting 1.0 out to alpha!)
Anyway: teams develop for "3 months"; build is frozen and handed off to QA; QA package the release and progress through Evocati, PTU and alpha. Bugs found during testing are ideally addressed in the on-going development - depends what they are though.
If a bug is found and not fixed before the next drop QA need to communicate this to testers so as to avoid "wtf we told them about this bug in the last drop, they just don't listen, we are wasting our time".
x9000'
That's why I was thinking that the first release (evo) and final release (live) should be the freezes, this has the benefits
a) allows a release to the evo on time, even if the build is still very raw because that phase is meant for it
b) the unpredictability of testing stops being a factor to failing that timeframe and becomes more achievable, giving backers a much better idea of when to expect the next update counting from the live release of the previous one instead.
That's how I would go about it at least.
You can end up drowning in what-ifs.
It will come down to if by "quarterly releases" they mean "quarterly releases". If this is the case then their mantra will be "release with bugs if necessary" rather than "only release if all bugs are sufficiently fixed".
Now since your comment is 100% valid the way they could attempt to introduce control - since they will make estimates! - is to limit the amount of new stuff that goes into a patch. Potentially holding stuff back for further internal bug fixing and polish.
A new version could release with a known bug however. Hence my comment about why QA's communication will be critical. And why the priority will be fixing bugs in the development software rather than the frozen branch. (They will hope one fix does both of course).
At some point - post 3.0 - we will know. Maybe by the end of next March?
Today we have Evocati, PTU, and GA. In the past, the patches were major undertaking as everyone needed to download the massive release every time the smallest of changes were required.
Tomorrow, post differential patcher, that is no longer the case.
[what I am about to say is what I would like to see happen, under no way was it confirmed by CIG]
I would love to see the following:
Evocati servers stay in place, they get all the sub point releases first. 3.01a-3.09z level releases.
PTU then tests all the point releases. 3.1-3.9 before those are promoted to GA
GA would then get the builds after scrub from PTU.
As for the quarterly releases, what I would anticipate is those are major releases. Most likely 3->4 as an example. They could do point releases, they were talking about the next major being 3.1, but that is simply semantics as to the numbering in my opinion.
There is no reason not to have continuing testing throughout the process once the differential patcher is in place. It would certainly quite many concerns by having numerous micro patches versus very large and sporadic major patches.
--Izz
So remaining category has its set of remaining bugs and ongoing tasks to be completed:
Last week the total number was 351, this week sits at 179.
On some highlights:
In the report page, you'll see a status update in each of those sections and the bug-fixing changelog.
This ATV was one of the first ones I can remember where they mentioned PTU in the messaging. They must feel that they are very close to pushing it to the greater community.
--Izz
Would it kill CIG to pick one way of making progress reports and stick with it?
If you are holding out for the perfect game, the only game you play will be the waiting one.
Bren
while(horse==dead)
{
beat();
}
In the latest newsletter, 3.0 PTU currently aimed before 20th December, what is legit because the holiday break they'll push as far as possible to get that out by then, we will see how this flows in the next weeks.
But it's only another ETA in a long series of 3.0 ETAs that they've failed to keep.
"We all do the best we can based on life experience, point of view, and our ability to believe in ourselves." - Naropa "We don't see things as they are, we see them as we are." SR Covey