Even in Rockstar titles they are not iterating on core features during content merges. Much of their game's backbone is built out with features iterated around them. It's a mischaracterization to say it's an isolated environment that any team works in.
This is a problem with QA making suppositions about what devs do.
Must be the reason why all Rockstar's games development goes so mooth /s
Core features are constantly iterated through development right until the last moments of development. There's always something to polish it further and make it better.
In the end rockstar titles use very simple, linear but tightly engaging gameplay. Yet their development is always troubled. It's almost as if game development at that lvl is just naturally difficult to pull off. No matter the time, talent or budget.
Uncharted's - You jump, you climb, you shoot. They added grappling and driving a jeep for 4.
Just the adding of grappling and driving the jeep encompasses major work, many many iterations to get to the point they are showcased in the finished product.
"You might think, after the accumulated lessons and experience of the three other Uncharted games, that for Naughty Dog, Uncharted 4
would have been a walk in the park. But between a director change, a
major reboot, a compressed schedule, and months of crunch, making Uncharted 4
felt more like a hike up Mount Kilimanjaro. Put another way: One of the
series running jokes is that whenever Nathan Drake jumps onto a roof or
cliff, it's probably going ot collapse. Toward the end of Uncharted 4's development, everyone at Naughty Dog could relate."
In the end rockstar titles use very simple, linear but tightly engaging gameplay. Yet their development is always troubled. It's almost as if game development at that lvl is just naturally difficult to pull off. No matter the time, talent or budget.
It's not a thing of simplicity.
They already had an vastly expanded game-engine developing over the years they just re-use on further games, just like with the Fallout IP, so a lot of the effort goes on the creation of content & assets. Or when the game scope is just locked to what the engine can do to minimize the core undertakings.
The case of SC is different for having to have developed the engine through the years to tackle its scope, and as the scope grown vastly after its crowdfund they spent years on that effort and still have stuff to do, so the realities are different hence why they need to develop relevant pieces of the codebase and features on isolated branches that are then merged in to not stall the other devs work.
Must be the reason why all Rockstar's games development goes so mooth /s
Core features are constantly iterated through development right until the last moments of development. There's always something to polish it further and make it better.
In the end rockstar titles use very simple, linear but tightly engaging gameplay. Yet their development is always troubled. It's almost as if game development at that lvl is just naturally difficult to pull off. No matter the time, talent or budget.
Goes to what was stated. Just because core engine and feature is in place does not mean implementation of all mechanics that relies on it is there. The flight model for Anthem was in and out of that game for years prior to it's release, does that mean everything thing else around it worked?
Developing core engine components while developing the components that relies on them is a shot in the dark. It's more people causing each other more problems. What you bring up about the Drake titles would have been worse if Naughty Dog had to build the physics for the game at the same time as the grappling hook rather than absolving its introduction to the model they'd built.
I find it strange to see people claiming that because doing things one way still has problems, then doing it another way that is even more costly and problematic is totally sensible. Like the car takes a moment to turn over any ways, might as well fill the tank with thermite too.
Anyway you choose do it you will run into problems, the more ambitious or more uncertain is the feature or task to tackle the bigger the problems that arise.
Thanks to it's backers CIG was given the leeway to tackle these problems with the freedom of knowing they were safe to venture into uncharted terrain, to push the game into being something more than what was made before. It's not about building a old game with HD graphics, CR made that already with the wing commanders, freelancers back then.
With this he has the means to do the game of it's dreams, that just coincidently, is the dreams of many other gamers and sci-fi fans across the world, ofc it will take time, it's no easy task, or else some other company would have done it by now.
So complaining or getting frustrated about CIG delays or changes of scope in Star Citizen or Squadron 42 is mostly pointless and irrelevant! Because even if there wasn't CIG, Star Citizen or Squadron 42, gamers and sci-fi aficionados, mmorpger's would still be dreaming and waiting for something like it, just without any prospects on the horizon
They have - finally - addressed the need to re-schedule stuff. (Probably a re-baseline).
The reason they have given is drivel; not saying they haven't made internal changes to teams / workflow but what they have put out is drivel.
From the outside looking going forward they will have a schedule with features they hope to deliver in the coming quarter. Whereas previously they .... had a schedule with features they hoped to release in the coming quarter.
So in a nutshell. They were slipping behind their planned releases. They have reorganised. Re-planned. They hope to deliver on their new targets going forward.
Anyway you choose do it you will run into problems, the more ambitious or more uncertain is the feature or task to tackle the bigger the problems that arise.
Development is complicated enough without getting drunk, spinning in a circle, and playing pin the tail blindfolded to assemble task list. That does not further any element of the actual features being developed.
That speaks to bloat in the company more than anything else. Again, gotta put ones ducks in a row.
Instead SC spins its wheels and has to iterate and then reiterate every time a minor feature is merged.
Maybe. However if so then it may come down to the ever present trade off.
Smaller teams are more efficient and easier to manage; larger teams less efficient. harder to manage. As the number of teams goes increases, efficiency goes down and management issues multiply. And more people will mean you won;t hit the minimum cost.
The potential benefits:
Larger teams will (usually) deliver things faster. Delivering things faster will usually give you the lowest probable cost - its the reverse of delays leading to cost overruns. (Probable costs but you give up the option of aiming for minimum cost by adding insurance; you pursue activities that may not be needed in order to reduce project risk - if something goes wrong and the alternative is partly developed its not a total job stop situation etc.).
These are general axioms.
The clever bit is first to know that it is horses for courses.
SC is no different. And the key question: is it in SC's interest to be as cheap as possible or as fast as possible?
And in SC's case they need speed if they can afford it.
Which is not to say that some stuff may be totally unnecessary. It does look like speed is a driver however.
That speaks to bloat in the company more than anything else. Again, gotta put ones ducks in a row.
Instead SC spins its wheels and has to iterate and then reiterate every time a minor feature is merged.
Maybe. However if so then it may come down to the ever present trade off.
Smaller teams are more efficient and easier to manage; larger teams less efficient. harder to manage. As the number of teams goes increases, efficiency goes down and management issues multiply. And more people will mean you won;t hit the minimum cost.
The potential benefits:
Larger teams will (usually) deliver things faster. Delivering things faster will usually give you the lowest probable cost - its the reverse of delays leading to cost overruns. (Probable costs but you give up the option of aiming for minimum cost by adding insurance; you pursue activities that may not be needed in order to reduce project risk - if something goes wrong and the alternative is partly developed its not a total job stop situation etc.).
These are general axioms.
The clever bit is first to know that it is horses for courses.
SC is no different. And the key question: is it in SC's interest to be as cheap as possible or as fast as possible?
And in SC's case they need speed if they can afford it.
Which is not to say that some stuff may be totally unnecessary. It does look like speed is a driver however.
This is why most studios, even large ones, ride a development curve and ramp up/down the people on a project over time as it is logical to do so. It's not always about big vs small, it's about when and how.
They have - finally - addressed the need to re-schedule stuff. (Probably a re-baseline).
The reason they have given is drivel; not saying they haven't made internal changes to teams / workflow but what they have put out is drivel.
From the outside looking going forward they will have a schedule with features they hope to deliver in the coming quarter. Whereas previously they .... had a schedule with features they hoped to release in the coming quarter.
So in a nutshell. They were slipping behind their planned releases. They have reorganised. Re-planned. They hope to deliver on their new targets going forward.
And in the coming months no one but new backers and people who have never heard of SC before will be completely surprised when features are moved around to release anemic patches cause they fell behind again.
Like all parts of game developing everything needs to be flexible and be adapted as it goes. Making big games requires a lot of people to work on it's many features and ofc when you have multiple teams working on specific sub-set of features some will take longer than other and the roadmaps will be updated to reflect that. Game development 101.
Like all parts of game developing everything needs to be flexible and be adapted as it goes. Making big games requires a lot of people to work on it's many features and ofc when you have multiple teams working on specific sub-set of features some will take longer than other and the roadmaps will be updated to reflect that. Game development 101.
And only shills would overlook the fact that CIG likes to quietly remove features promised for a patch slated for the upcoming release and move it to the next patch or further down so they can say they delivered their quarterly patch on time or only slightly late and 100% complete in the roadmap.
If they wanted to be honest with the people funding their paycheques they would leave the feature as incomplete in the patch it was promised in and also re-list it in the patch they hope to include it in in the roadmap. If they miss that window again it stays there as incomplete and repeat the process. Not this bullshit where every patch is 100% complete! We are doing just fine!
While we've seen much more content and implemented features these past two years, compared to previously - it has become increasingly obvious that they can't meet their goals using the relatively rigid 3 month schedule.
Going staggered, having two six-months schedules essentially means twice the time for proper implementation, though it also means fewer people working on said features.
Personally, I've never been a big believer in just throwing manpower at complex problems, because too many cooks tend to make more of a mess, regardless of the partially accelerated progress.
As for game development and how it works, it's really no different than how any large and complicated project works.
A lot of perfectly ordinary people should already know how common it is for large and complicated projects to be postponed, changed, scrapped or otherwise completely changed.
Certainly, in my place of work - that's just as much par for the course as it has been for Star Citizen.
At the end of the day, what matters is that we're seeing real progress - and, as I mentioned, these past two years have been better in that way than ever before, and that's significantly so.
I never expected them to deliver the most ambitious computer game of all time in a predictable way.
Then again, I've been following the gaming industry for almost 40 years. It was always the norm for games to be delayed if they did anything significantly new, and especially if they tried to achieve greatness.
The difference with Star Citizen is that development is almost fully exposed - and there's no publisher to cut off funding in the hopes of a greater return on an investment.
In this case, as long as funding is on-going, they can delay the game indefinitely.
Of course, it's never going to be received well by people who're ok with a lesser game, and especially not by people who don't believe Star Citizen can actually happen.
Personally, I would be extremely sceptical myself, except for the fact that the developers make a ton of sense whenever they reveal their reasoning and decision-making process.
When I hear Tony Z, Erin or Chris speak - they sound like people who understand game design, and certainly Tony and Chris are impossibly ambitious - but also incredibly convincing in terms of how they will make things work. Erin is more of a "reality" and "let's get things done" kind of guy - and the game would have been released years ago, under his command.
Which would be fine, if all we wanted was a better looking Wing Commander and Freelancer.
I want more though, which is why I'm happy with the visionaries calling the shots.
I will remain happy until such time as I see clear signs of this breaking apart - or that they can't actually pull off what they're going for.
Right now, they're down to only a few pieces of vital tech to make it to a stage where it's just content delivery and pipeline optimization.
SSOCS will be first - and then Server Meshing. When they have those working, there's really no way to fail - except, of course, if they run out of money or something similarly unlikely.
When I hear Tony Z, Erin or Chris speak - they sound like people who understand game design, and certainly Tony and Chris are impossibly ambitious - but also incredibly convincing in terms of how they will make things work. Erin is more of a "reality" and "let's get things done" kind of guy - and the game would have been released years ago, under his command.
Thats what makes it a decent con. So many people like you who will still fall for it because the con artists are so well practiced at their craft.
All they have been doing the past 7 years have been waiting for the tech to catch up with nonsense he spewed 7 or so years ago. It still hasnt. SO its all a waiting game. Even with stuff that is slightly more possible now than it was then theyre falling short of being able to implement it properly.
Seven years is an eternity in generational improvements the fact most of the stuff he was promising still isnt possible shows how delusional he was. Simply look at the specs (and cost) of the average PC back in 2012. Look at them now.
He has gotten a little 'lucky' as graphical improvements have been curtailed to boost overall performance. But mechanical changes have gone forward. But for the most part most 'feasible' stuff that can be done in MMOs has already been implemented. All the 'cool' stuff is still being dreamed about by guys promising to 'change the genre'. And those games are all still in tech demo phase or still begging for money phase.
Like all parts of game developing everything needs to be flexible and be adapted as it goes. Making big games requires a lot of people to work on it's many features and ofc when you have multiple teams working on specific sub-set of features some will take longer than other and the roadmaps will be updated to reflect that. Game development 101.
And only shills would overlook the fact that CIG likes to quietly remove features promised for a patch slated for the upcoming release and move it to the next patch or further down so they can say they delivered their quarterly patch on time or only slightly late and 100% complete in the roadmap.
If they wanted to be honest with the people funding their paycheques they would leave the feature as incomplete in the patch it was promised in and also re-list it in the patch they hope to include it in in the roadmap. If they miss that window again it stays there as incomplete and repeat the process. Not this bullshit where every patch is 100% complete! We are doing just fine!
So knowning and understanding that no development roadmap survives contact with reality, that items on a roadmap are just intentions not and promises (there are no promises in game development btw) and that juggling features and priorities is the norm within agile development makes me a shill lol
Less tunel vision on Star Citizen and more into other games development stories and Agile roadmaps would probably help getting a broader picture.
Those reactions and drama mongering are the reason most companies are so secretive about their development.
Maybe it causes some confusion to those used to be kept in the dark and feed on 4chan rummours but for people who understand game development it's just the nature of the beast.
Back when RSI started their quarterly patches, wasn't their original aim to develop things, and then once every quarter select what was ready enough to implement in this quarters patch?
As per their own info, I think they were supposed to be doing staggered development all along. Then sometime after 3.0 release and before now they apparently failed it and moved on to more rigid 3 month development times. Then now they're again moving back towards staggered development that they tried to do in the first place.
Back when RSI started their quarterly patches, wasn't their original aim to develop things, and then once every quarter select what was ready enough to implement in this quarters patch?
As per their own info, I think they were supposed to be doing staggered development all along. Then sometime after 3.0 release and before now they apparently failed it and moved on to more rigid 3 month development times. Then now they're again moving back towards staggered development that they tried to do in the first place.
Yes, and they have done that. The problem is that the features they put in, aren’t polished to their satisfaction, and while the patch does hit PTU on time, they want it to hit live on time.
This is not a huge change, but more a refinement of the way they have been doing things for a while.
The quarterly schedule wasn’t staggered before, though - only some of the content was staggered, like ships.
Back when RSI started their quarterly patches, wasn't their original aim to develop things, and then once every quarter select what was ready enough to implement in this quarters patch?
As per their own info, I think they were supposed to be doing staggered development all along. Then sometime after 3.0 release and before now they apparently failed it and moved on to more rigid 3 month development times. Then now they're again moving back towards staggered development that they tried to do in the first place.
Yes, and they have done that. The problem is that the features they put in, aren’t polished to their satisfaction, and while the patch does hit PTU on time, they want it to hit live on time.
This is not a huge change, but more a refinement of the way they have been doing things for a while.
The quarterly schedule wasn’t staggered before, though - only some of the content was staggered, like ships.
Saying stuff like "the quarterly schedule wasn't staggered before" - is nonsence. On their last update they reported progress on 2020 Q1! Go back and look at any update and they always show progress in future quarters. They clearly had "multiple pipelines" before.
And as @Vrika correctly said their stated intent was to release the stuff that was finished, if not it got pushed to the next quarter. Nothing wrong with that btw. And they have always said the estimates are best dates. So if a team thought it needed 3 month to finish and release - fully polished - and they needed 4 months so what, they just slip.......
Teams suggesting that they have to release stuff when its not polished - when that was not the declared (to us) plan and it was always said (to us) that the estimates were only best endeavours is a sign of teams under pressure.
Its the difference between us being told that the estimates are simply best guesses and may slip and the internal reality. To the teams the dates - clearly - have been fixed.
What has happened?
My guess is that - over time - their "schedule" had morphed into a something more detailed / sophisticated. Remember 2 years back things were pretty chaotic! Maybe networking was added and/or became more complex; maybe resource scheduling was added; maybe teams were having to estimate progress rather than simply take progress when a job was complete (a 0/100 approach). Many possibilities.
"Better" though always comes at a price. Not just in management hours but also in generating stress. And stress impacts efficiency. And the easy excuse for not delivering on your estimated delivery dates? Time "wasted" on reporting! Even though that effort will have been built in! Sometimes though that is the case - as I said above its often horses for courses.
So they have made some changes internally (possibly significant changes but invisible to us). Doesn't matter to us. They had a plan, they were slipping against it; doing a big update, new schedule soon. No big deal.
And going forward they will deliver quarterly patches of stuff that is finished against best endeavours estimates. Just like before!
Back when RSI started their quarterly patches, wasn't their original aim to develop things, and then once every quarter select what was ready enough to implement in this quarters patch?
As per their own info, I think they were supposed to be doing staggered development all along. Then sometime after 3.0 release and before now they apparently failed it and moved on to more rigid 3 month development times. Then now they're again moving back towards staggered development that they tried to do in the first place.
Yes, and they have done that. The problem is that the features they put in, aren’t polished to their satisfaction, and while the patch does hit PTU on time, they want it to hit live on time.
This is not a huge change, but more a refinement of the way they have been doing things for a while.
The quarterly schedule wasn’t staggered before, though - only some of the content was staggered, like ships.
Saying stuff like "the quarterly schedule wasn't staggered before" - is nonsence. On their last update they reported progress on 2020 Q1! Go back and look at any update and they always show progress in future quarters. They clearly had "multiple pipelines" before.
And as @Vrika correctly said their stated intent was to release the stuff that was finished, if not it got pushed to the next quarter. Nothing wrong with that btw. And they have always said the estimates are best dates. So if a team thought it needed 3 month to finish and release - fully polished - and they needed 4 months so what, they just slip.......
I honestly don't think you understand what they mean by staggered.
Once again, they didn't have staggered development teams for the quarterly schedule before. Well, except for some of the content, including the ship pipeline paradigm.
Meaning, they didn't have dedicated teams focused on two different schedules before. Before, it was all focus on one schedule.
Focus doesn't mean that nothing else is worked on.
It's not that complicated, really.
Teams suggesting that they have to release stuff when its not polished - when that was not the declared (to us) plan and it was always said (to us) that the estimates were only best endeavours is a sign of teams under pressure.
Its the difference between us being told that the estimates are simply best guesses and may slip and the internal reality. To the teams the dates - clearly - have been fixed.
What has happened?
Yes, the dates to aim for have been fixed. That's actually why we have dates as a word and concept. That doesn't mean anything - as things will slip, as they have always done - and will always do.
What has happened is that they want to deliver a more polished patch, and they want more time to work out issues than 3 months.
Again, it's not complicated.
And going forward they will deliver quarterly patches of stuff that is finished against best endeavours estimates. Just like before!
Well, we don't actually know until we see the results.
In theory, however, the difference is that each quarterly release should be more polished, and ideally it will hit live on time - instead of weeks later.
The setup with the teams to deliver their work quarterly isn't working as well as wanted and is causing issues by work having to be released by devs who wanted to spend more time on it.
Due to this, they are going to stagger teams to give the developers 6 months to finish their work instead of 3, with this the quarterly releases should still happen intending to add viability for more stable patches.
In recent times there is quite more work going on in parallel that will become the standard with staggered development with teams on each area working for features on different patches.
The roadmap was put under maintenance and will be suffering a major update to reflect this on SC and SQ42, what is said for SQ42 already is that its BETA estimate is pushed by 3 months. With the team resources split the nearest patch that is 3.7 will be a smaller patch.
Hmm, adding 3 more months on to infinity....how does that work exactly?
Just trying to live long enough to play a new, released MMORPG, playing New Worlds atm
Fools find no pleasure in understanding but delight in airing their own opinions. Pvbs 18:2, NIV
Don't just play games, inhabit virtual worlds™
"This is the most intelligent, well qualified and articulate response to a post I have ever seen on these forums. It's a shame most people here won't have the attention span to read past the second line." - Anon
Back when RSI started their quarterly patches, wasn't their original aim to develop things, and then once every quarter select what was ready enough to implement in this quarters patch?
As per their own info, I think they were supposed to be doing staggered development all along. Then sometime after 3.0 release and before now they apparently failed it and moved on to more rigid 3 month development times. Then now they're again moving back towards staggered development that they tried to do in the first place.
Yes, and they have done that. The problem is that the features they put in, aren’t polished to their satisfaction, and while the patch does hit PTU on time, they want it to hit live on time.
This is not a huge change, but more a refinement of the way they have been doing things for a while.
The quarterly schedule wasn’t staggered before, though - only some of the content was staggered, like ships.
Saying stuff like "the quarterly schedule wasn't staggered before" - is nonsence. On their last update they reported progress on 2020 Q1! Go back and look at any update and they always show progress in future quarters. They clearly had "multiple pipelines" before.
And as @Vrika correctly said their stated intent was to release the stuff that was finished, if not it got pushed to the next quarter. Nothing wrong with that btw. And they have always said the estimates are best dates. So if a team thought it needed 3 month to finish and release - fully polished - and they needed 4 months so what, they just slip.......
I honestly don't think you understand what they mean by staggered.
Once again, they didn't have staggered development teams for the quarterly schedule before. Well, except for some of the content, including the ship pipeline paradigm.
Meaning, they didn't have dedicated teams focused on two different schedules before. Before, it was all focus on one schedule.
Focus doesn't mean that nothing else is worked on.
It's not that complicated, really.
Teams suggesting that they have to release stuff when its not polished - when that was not the declared (to us) plan and it was always said (to us) that the estimates were only best endeavours is a sign of teams under pressure.
Its the difference between us being told that the estimates are simply best guesses and may slip and the internal reality. To the teams the dates - clearly - have been fixed.
What has happened?
Yes, the dates to aim for have been fixed. That's actually why we have dates as a word and concept. That doesn't mean anything - as things will slip, as they have always done - and will always do.
What has happened is that they want to deliver a more polished patch, and they want more time to work out issues than 3 months.
Again, it's not complicated.
And going forward they will deliver quarterly patches of stuff that is finished against best endeavours estimates. Just like before!
Well, we don't actually know until we see the results.
In theory, however, the difference is that each quarterly release should be more polished, and ideally it will hit live on time - instead of weeks later.
Except that - externally - the dates were not fixed. Check out their web page; its a BIG caveat - which is fine btw. To us its simply been a case of release stuff when its done.
What has happened is that some stuff has changed internally And as a result they hope they will be better able to provide realistic schedules and deliver against them.
I can talked at great length about team structures and different ways of working - the term "staggered" is pretty vague by the way.
And you go on about "its not that complicated" but: do you understand the term "fixed date"?
Ordinarily dates in a schedule are not fixed. Dates float. There are times when you will fix one or more dates e.g. if doing a backward pass. I assume they will be working to ASAP stuff but if they are constrained by e.g. money they might be doing some ALAP stuff. (I could explain but its not complicated ....)
Its simple:
A couple of years back they "struggled". They regrouped, said that getting the patch out had created stress and they would go back (again) to releasing stuff when it was ready. A more relaxed approach. Last year it went fine. This year - especially since the SQ42 schedule came out - not so much. And its clearly been taking its toll. Now they have regrouped and will start afresh.
No problem with that. Its not that complicated btw.
Comments
This is a problem with QA making suppositions about what devs do.
They already had an vastly expanded game-engine developing over the years they just re-use on further games, just like with the Fallout IP, so a lot of the effort goes on the creation of content & assets. Or when the game scope is just locked to what the engine can do to minimize the core undertakings.
The case of SC is different for having to have developed the engine through the years to tackle its scope, and as the scope grown vastly after its crowdfund they spent years on that effort and still have stuff to do, so the realities are different hence why they need to develop relevant pieces of the codebase and features on isolated branches that are then merged in to not stall the other devs work.
Developing core engine components while developing the components that relies on them is a shot in the dark. It's more people causing each other more problems. What you bring up about the Drake titles would have been worse if Naughty Dog had to build the physics for the game at the same time as the grappling hook rather than absolving its introduction to the model they'd built.
I find it strange to see people claiming that because doing things one way still has problems, then doing it another way that is even more costly and problematic is totally sensible. Like the car takes a moment to turn over any ways, might as well fill the tank with thermite too.
The reason they have given is drivel; not saying they haven't made internal changes to teams / workflow but what they have put out is drivel.
From the outside looking going forward they will have a schedule with features they hope to deliver in the coming quarter. Whereas previously they .... had a schedule with features they hoped to release in the coming quarter.
So in a nutshell. They were slipping behind their planned releases. They have reorganised. Re-planned. They hope to deliver on their new targets going forward.
Smaller teams are more efficient and easier to manage; larger teams less efficient. harder to manage. As the number of teams goes increases, efficiency goes down and management issues multiply. And more people will mean you won;t hit the minimum cost.
The potential benefits:
Larger teams will (usually) deliver things faster. Delivering things faster will usually give you the lowest probable cost - its the reverse of delays leading to cost overruns. (Probable costs but you give up the option of aiming for minimum cost by adding insurance; you pursue activities that may not be needed in order to reduce project risk - if something goes wrong and the alternative is partly developed its not a total job stop situation etc.).
These are general axioms.
The clever bit is first to know that it is horses for courses.
SC is no different. And the key question: is it in SC's interest to be as cheap as possible or as fast as possible?
And in SC's case they need speed if they can afford it.
Which is not to say that some stuff may be totally unnecessary. It does look like speed is a driver however.
https://www.epicgames.com/store/en-US/news/trello-revamp-tracking-features
Like all parts of game developing everything needs to be flexible and be adapted as it goes. Making big games requires a lot of people to work on it's many features and ofc when you have multiple teams working on specific sub-set of features some will take longer than other and the roadmaps will be updated to reflect that. Game development 101.
If they wanted to be honest with the people funding their paycheques they would leave the feature as incomplete in the patch it was promised in and also re-list it in the patch they hope to include it in in the roadmap. If they miss that window again it stays there as incomplete and repeat the process. Not this bullshit where every patch is 100% complete! We are doing just fine!
While we've seen much more content and implemented features these past two years, compared to previously - it has become increasingly obvious that they can't meet their goals using the relatively rigid 3 month schedule.
Going staggered, having two six-months schedules essentially means twice the time for proper implementation, though it also means fewer people working on said features.
Personally, I've never been a big believer in just throwing manpower at complex problems, because too many cooks tend to make more of a mess, regardless of the partially accelerated progress.
As for game development and how it works, it's really no different than how any large and complicated project works.
A lot of perfectly ordinary people should already know how common it is for large and complicated projects to be postponed, changed, scrapped or otherwise completely changed.
Certainly, in my place of work - that's just as much par for the course as it has been for Star Citizen.
At the end of the day, what matters is that we're seeing real progress - and, as I mentioned, these past two years have been better in that way than ever before, and that's significantly so.
I never expected them to deliver the most ambitious computer game of all time in a predictable way.
Then again, I've been following the gaming industry for almost 40 years. It was always the norm for games to be delayed if they did anything significantly new, and especially if they tried to achieve greatness.
The difference with Star Citizen is that development is almost fully exposed - and there's no publisher to cut off funding in the hopes of a greater return on an investment.
In this case, as long as funding is on-going, they can delay the game indefinitely.
Of course, it's never going to be received well by people who're ok with a lesser game, and especially not by people who don't believe Star Citizen can actually happen.
Personally, I would be extremely sceptical myself, except for the fact that the developers make a ton of sense whenever they reveal their reasoning and decision-making process.
When I hear Tony Z, Erin or Chris speak - they sound like people who understand game design, and certainly Tony and Chris are impossibly ambitious - but also incredibly convincing in terms of how they will make things work. Erin is more of a "reality" and "let's get things done" kind of guy - and the game would have been released years ago, under his command.
Which would be fine, if all we wanted was a better looking Wing Commander and Freelancer.
I want more though, which is why I'm happy with the visionaries calling the shots.
I will remain happy until such time as I see clear signs of this breaking apart - or that they can't actually pull off what they're going for.
Right now, they're down to only a few pieces of vital tech to make it to a stage where it's just content delivery and pipeline optimization.
SSOCS will be first - and then Server Meshing. When they have those working, there's really no way to fail - except, of course, if they run out of money or something similarly unlikely.
It's all a con - and people like me can't see it.
That was an incredibly persuasive take on it, and I must thank you for it!
Less tunel vision on Star Citizen and more into other games development stories and Agile roadmaps would probably help getting a broader picture.
https://medium.com/@jboogie/what-does-an-agile-product-roadmap-look-like-cf0dbe5be4ef
Those reactions and drama mongering are the reason most companies are so secretive about their development.
Maybe it causes some confusion to those used to be kept in the dark and feed on 4chan rummours but for people who understand game development it's just the nature of the beast.
We're the "us guys" - and we just don't understand that it's all a con because there are delays
As per their own info, I think they were supposed to be doing staggered development all along. Then sometime after 3.0 release and before now they apparently failed it and moved on to more rigid 3 month development times. Then now they're again moving back towards staggered development that they tried to do in the first place.
Good read
This is not a huge change, but more a refinement of the way they have been doing things for a while.
The quarterly schedule wasn’t staggered before, though - only some of the content was staggered, like ships.
Saying stuff like "the quarterly schedule wasn't staggered before" - is nonsence. On their last update they reported progress on 2020 Q1! Go back and look at any update and they always show progress in future quarters. They clearly had "multiple pipelines" before.
And as @Vrika correctly said their stated intent was to release the stuff that was finished, if not it got pushed to the next quarter. Nothing wrong with that btw. And they have always said the estimates are best dates. So if a team thought it needed 3 month to finish and release - fully polished - and they needed 4 months so what, they just slip.......
Teams suggesting that they have to release stuff when its not polished - when that was not the declared (to us) plan and it was always said (to us) that the estimates were only best endeavours is a sign of teams under pressure.
Its the difference between us being told that the estimates are simply best guesses and may slip and the internal reality. To the teams the dates - clearly - have been fixed.
What has happened?
My guess is that - over time - their "schedule" had morphed into a something more detailed / sophisticated. Remember 2 years back things were pretty chaotic! Maybe networking was added and/or became more complex; maybe resource scheduling was added; maybe teams were having to estimate progress rather than simply take progress when a job was complete (a 0/100 approach). Many possibilities.
"Better" though always comes at a price. Not just in management hours but also in generating stress. And stress impacts efficiency. And the easy excuse for not delivering on your estimated delivery dates? Time "wasted" on reporting! Even though that effort will have been built in! Sometimes though that is the case - as I said above its often horses for courses.
So they have made some changes internally (possibly significant changes but invisible to us). Doesn't matter to us. They had a plan, they were slipping against it; doing a big update, new schedule soon. No big deal.
And going forward they will deliver quarterly patches of stuff that is finished against best endeavours estimates. Just like before!
Cheers Max.
"True friends stab you in the front." | Oscar Wilde
"I need to finish" - Christian Wolff: The Accountant
Just trying to live long enough to play a new, released MMORPG, playing New Worlds atm
Fools find no pleasure in understanding but delight in airing their own opinions. Pvbs 18:2, NIV
Don't just play games, inhabit virtual worlds™
"This is the most intelligent, well qualified and articulate response to a post I have ever seen on these forums. It's a shame most people here won't have the attention span to read past the second line." - Anon
What has happened is that some stuff has changed internally And as a result they hope they will be better able to provide realistic schedules and deliver against them.
I can talked at great length about team structures and different ways of working - the term "staggered" is pretty vague by the way.
And you go on about "its not that complicated" but: do you understand the term "fixed date"?
Ordinarily dates in a schedule are not fixed. Dates float. There are times when you will fix one or more dates e.g. if doing a backward pass. I assume they will be working to ASAP stuff but if they are constrained by e.g. money they might be doing some ALAP stuff. (I could explain but its not complicated ....)
Its simple:
A couple of years back they "struggled". They regrouped, said that getting the patch out had created stress and they would go back (again) to releasing stuff when it was ready. A more relaxed approach. Last year it went fine. This year - especially since the SQ42 schedule came out - not so much. And its clearly been taking its toll. Now they have regrouped and will start afresh.
No problem with that. Its not that complicated btw.