Reply With QuoteAh, so there is a small chance that the estimates are slightly less optimistic than normal. Well, that's good.
...http://www.underworldascendant.com/t...ev-updates.php
Key Points:
Prototype build sometime during Q4 2015.
Pre-Alpha build sometime during Q1 2016.
Using Agile Principals for development...What is Agile?
- Agile Principals are good...I use them.
- Estimates for the Prototype and Pre-Alpha builds are conservative...so there's a chance we'll get them both sooner than that.
Ah, so there is a small chance that the estimates are slightly less optimistic than normal. Well, that's good.
For perspective...
1) The UA team already has an early prototype with Unity 4, so the likely Unity 5 prototype will be time-accelerated by this circumstance.
2) They are using Agile Principals to manage this project...That means increased efficiency, utilizing time-boxed scheduled iterations with interactive feedback from the fanbase during this process.
Knowing that they are using a time-boxed iteration process, with experienced veterans at the helm, one can extrapolate the full production schedule utilizing the quarterly time-boxes that have already been provided:
- Prototype build sometime during Q4 2015.
- Pre-Alpha build sometime during Q1 2016.
- Alpha build sometime during Q2 2016.
- Beta build sometime during Q3 2016.
- Final build sometime during Q4 2016.
Last edited by Vae; 12th Mar 2015 at 05:29.
They don't have an "early prototype build", they have a prototype cobbled together with Unity assets. This is not the game they are making, it's more like a proof of concept than anything else.
And agile methods are not a magic wand that makes all development troubles melt away -- with such a small team and no corporate oversight, the problems that come from having a more rigid top-down management system would be practically non-existent anyway. There will be no time won, because none was wasted in the first place.
Last edited by Starker; 12th Mar 2015 at 03:30.
Thank you for catching my unintentional use of the word "build" in that particular context...I will edit the oversight, so as not to confuse others.Originally Posted by Starker
Although it is true the early prototype serves as a "proof of concept", and does have the obvious Unity placeholder assets, it also contains some time-saving transferable development within it...so the salient point of (1), still stands.
Of course not, and I never said otherwise...so your explanation of the obvious has no impact against the premise stated in (2).And agile methods are not a magic wand that makes all development troubles melt away
You are erroneously concluding that all small teams working without a top-down corporate management system, are equally productive and efficient regardless of methodology...That is clearly false.with such a small team and no corporate oversight, the problems that come from having a more rigid top-down management system would be practically non-existent anyway. There will be no time won, because none was wasted in the first place.
That's not what Starker said at all.
Personally I see no reason to doubt that a team with their experience and small size would have good feedback loops in place, regardless of whether they happen to call that agile or not. I agree the team looks promising, but most projects blow their deadlines, no matter how conservative such deadlines may be. We'll see. I don't see much point in guessing at this early stage.
Vae, you are overselling the time-saving transferable development part quite a bit. Let me just quote Tim Stellmach (emphasis mine):
There are definitely bits and pieces of logic we can salvage, such as the system for converting the bridge from a solid object to an exploding one and making that explosion look sensible and cinematic. The spiders contain some experimental steering behavior code that is actually capable of a good deal more then you see in the video snippets.
This is stuff that we will definitely build on, but I don't want to oversell it either. Its bits and pieces that still need to be fitted to a larger over-all game architecture. There is a reason why we have a delivery date almost 2 years out. We still have a lot of work to do.
As for the rest...
All the benefits of a "time-boxed iteration process" mean nothing if you fail a sprint or two. Any team that is flexible enough to avoid the problems that agile development is supposed to solve will not significantly benefit from an agile method, assuming equally competent teams. And if a team is used to a certain workflow, imposing a specific agile method might work against it, even. The best producers are those who know not to meddle with a working solution.
Besides, the bottlenecks of development are not usually the development methods used -- it's stuff like pipelines working slower than expected, not having enough people to do [insert an important aspect of development here, like animations], office politics getting in the way, etc.
I cannot possibly be overselling something which has never been defined...Up until now, you've been arguing with an imagined idea of a specific amount of time, which I never presented.
In fact, that statement from Tim only proves my point...Any time saved by having an early prototype, rather than starting from scratch, will help them meet their scheduled deadlines.
That's an "if" statement...Meaning that if not failed, there are gained benefits...Therefore, you now admit that a development method can and will produce varying results, regardless of the presence of a top-down management system.All the benefits of a "time-boxed iteration process" mean nothing if you fail a sprint or two.
Yes...and that's why the Underworld Ascendant team chose to go with Agile.And if a team is used to a certain workflow, imposing a specific agile method might work against it, even. The best producers are those who know not to meddle with a working solution.
Yes...bottlenecks can and do occur on various levels...I'm glad that you now agree with me, that development methods do in fact have an impact on meeting deadlines...Besides, the bottlenecks of development are not usually the development methods used -- it's stuff like pipelines working slower than expected, not having enough people to do [insert an important aspect of development here, like animations], office politics getting in the way, etc.
Last edited by Vae; 12th Mar 2015 at 17:22.
I have not been arguing with an imagined idea of a specific amount of time. I'm saying that the effect is not as big as you imagine it to be. Not on the scale where you can claim that they will meet deadlines because of it. It's peanuts, really, compared to all the work that lies ahead.
It's like saying that a mountaineer will make it to Mount Everest on schedule, because they left 6 hours early when you don't know whether they will have to stay put for three weeks because there's an unexpected storm or a blocked path. And there are always unexpected snowstorms and blocked paths in software development.
Yes, if they stay on schedule, they will meet deadlines, if you want to get tautological. But failed sprints happen all the time and they are more likely to happen in this case because of higher standards and because they are wading in new experimental territory. They are not making a sequel to Call of Duty here, it's a new immersive sim of an unprecedented complexity.
And I'm telling you it's not such a big deal as you imagine it to be. It's not like they would've chosen Waterfall otherwise.
No, I'm telling you that the particular development method does not have a significant impact in this case. Not to the degree that you can with any confidence claim that they will meet deadlines because of it. When push comes to shove, it all boils down to the skill of the team and how good they are at communication, not to following some development method.Yes...bottlenecks can and do occur on various levels...I'm glad that you now agree with me, that development methods do in fact have an impact on meeting deadlines...
One might, however, say that they didn't make enough kickstarter money to blow off the deadline.Running out of cash can be highly motivating. Not necessarily in a good way, but hey.
Well, there's still Early Access and publishing deals and getting additional investments (with the KS results sort of proving customer interest in the project) and taking out loans. Not to mention the all too often used method of just not paying salaries.
And they're probably not even using pure Agile. He says they're using "agile principles," which, shocker, just about everybody does. Double Fine utilizes agile principles, and it's not like Broken Age hit all their sprint goals and milestones every time.
I've worked with a ton of game devs, and maybe two of them came close to hitting their milestones consistently, and those were for comparatively simple projects.
BWAHAHAHAHAHAHAHAHA. A 20-month production schedule? For a game of Underworld's scale? Are you insane? Going from Alpha to Beta in a quarter? Jesus christ.Knowing that they are using a time-boxed iteration process, with experienced veterans at the helm, one can extrapolate the full production schedule utilizing the quarterly time-boxes that have already been provided:
- Prototype build sometime during Q4 2015.
- Pre-Alpha build sometime during Q1 2016.
- Alpha build sometime during Q2 2016.
- Beta build sometime during Q3 2016.
- Final build sometime during Q4 2016.
You can laugh and call them insane all you like...yet, it bears no fruit to shoot the messenger.
It does when messenger is pulling the message out of his ass.
Such a misguided attack has only left you in a sea of confusion.
But don't worry...I'll be glad to spell it out for you, so that you will suffer in ignorance no longer...
Publicly displaying the approximate release date for UA is a reflection of their production schedule.
Yeah. They've been puttering about the games industry since time immemorial, so they pretty much know what to expect going in. Considering they've don't have to build an engine alongside the game, have tons of middleware to fall back on they didn't have previously, hell...it could be done. It's pretty loose, but it's possible.
Though I'm taking bets now that it won't quite make it. Spread's Q2 '17.
Source? The only dates in the blogpost you linked are the prototype and pre-alpha dates. And that same blog post says:It's a Q3 2017 release, at best. Early Access release in 2016, maybe.I know people have already been asking for release dates for the game and alpha builds. There is no set in stone dates yet.... We don't know peoples workload, we don't know all the systems we need to build, etc. etc.
They may be using a pre-existing engine, but unless they've worked out a source code access license for Unity 5, they're going to be trying to bend that engine to do a lot of things that it's not really designed to do, and doing so purely through the high level scripting that Unity allows, with a small team.
The Nov '16 Release is the date that was given as their estimate in the Kickstarter campaign. That being said, it was only an estimate and IMO is likely to slip to 1Q-2Q '17. I've developed under agile and scrum at work for years, and it's not a magic bullet for hitting dates. It has its advantages and disadvantages, but ultimately if you don't have competent people running the show (product owner, project manager, release manager) then you'll miss dates no matter who the developers are or what the development process is. That's a general statement, I'm not saying anything specifically about the folks at Otherside.
I'd take the gut feeling of the senior programmer over any projected date backed up by calculations.
Yes, it's pretty amusing that certain people in this thread are making huge assumptions and guesstimations based on their own experiences, when they really have no idea at all how much work has been done on the game to date.
Since Unity 5 only released a couple weeks ago (admittedly with a lengthy beta preceding it), it seems safe to assume that the amount of completed work is "not that much."
None of the facts underlying this conversation can be taken seriously.
Here are a few facts taken from this study: http://gamasutra.com/blogs/PaulTozou...d_the_Rest.php
Relevant parts (emphasis in bold added by me):
Our second big surprise was in the area of production methodologies, a topic of frequent discussion in the game industry.
We asked what production methodology the team used – 0 (don’t know), 1 (waterfall), 2 (agile), 3 (agile using “Scrum”), and 4 (other/ad-hoc). We also provided a detailed description with each answer so that respondents could pick the closest match according to the description even if they didn’t know the exact name of the production methodology. The results were shocking.
What’s remarkable is just how tiny these differences are. They almost don’t even exist.
Furthermore, a Kruskal-Wallis H test indicates a very high p-value of 0.46 for this category, meaning that we truly can’t infer any relationship between production methodology and game outcome. Further testing of the production methodology against each of the four game project outcome factors individually gives identical results.
Given that production methodologies seem to be a game development holy grail for some, one would expect to see major differences, and that Scrum in particular would be far out in the lead. But these differences are tiny, with a huge amount of variation in each category, and the correlations between the production methodology and the score have a p-value too high for us to deny the assumption that the data is independent. Scrum, agile, and “other” in particular are essentially indistinguishable from one another. “Unknown” is far higher than one would expect, while “Other/ad-hoc” is also remarkably high, indicating that there are effective production methodologies available that aren’t on our list (interestingly, we asked those in the “other” category for more detail, and the Cerny method was listed as the production methodology for the top-scoring game project in that category).
Also, unlike our question regarding game engines, we can't simply write this off as some methodologies being more appropriate for certain kinds of teams. Production methodologies are generally intended to be universally useful, and our results show no meaningful correlations between the methodology and the game genre, team size, experience level, or any other factors.
[...]
It seems that in spite of all the attention paid to the subject, the particular type of production methodology a team uses is not terribly important, and it is not a significant driver of outcomes. Even the much-maligned “Waterfall” approach can apparently be made to work well.
Underworld Ascendant Playable Prototype (11-28)
wait I was right?
We will slip a bit from here on out tho, by about a quarter each release.
Posting Permissions
