Alpha 3.0 Production Schedule (updated 17th November)

13468936

Comments

  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 23
    rodarin said:

    You guys would spin it no matter what they did. What if the ELIMINATED (not even delayed) 50% of that list? You have an excuse for that already also. 

    There's no spin, the disclaimer is there. The schedule is what they use internally and so it reflects whatever gets changed, even if that means delays or cutting features out of the release milestone, something that happened with 2.6. The caveats are there loud and clear.

    The existence of this schedules come from the requests on the sphere of the so-called open development to provide clarity when it comes to the status of the announced releases, and they are fulfilling that.
    Post edited by MaxBacon on
  • NycteliosNyctelios Novo Hamburgo - RS - BrazilMember EpicPosts: 2,255
    I think they should drop the app/"third party" support until launch.
    I don't think hardware or platform integration should be a thing on a beta. Focus on optimizations.

    " Tawnos's blueprints were critical to the creation of my armor. As he once sealed himself in steel, I sealed myself in a walking crypt. "
    —Urza

    - Steam ID Discord ID: Night # 6102
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410

    Vrika said:







    Sad. They're already missing deadlines on the thing they just put up a week ago.






    Estimations moving around a bit is normal, they are only estimations.

    In the end what matters is how much they move around. If something gets misestimated by 25% that usually falls within margin of error and won't cause too much troubles because experienced managers know that it was an estimation to begin with and were prepared for some amount of error.

    On the other hand if something gets misestimated by 200% that is liable to cause a chain reacting where other teams need to redo their own plans because something they needed is not ready yet, efficiency all around the studio drops, and both budget and schedule are exceeded by a lot.


    They are estimations that they are missing a week later. After having missed an incredible amount of estimations. After having taken an incredible amount of money based on those estimations. And some of those recent estimations have already gone off by 200%.

    Like you imply, obviously these "estimations" don't actually mean anything. If they can mis-estimate over half of their estimations, what point does an estimation serve? After all, according to you, "they are only estimations." There is no reason why anyone should expect them to meet their goals. Estimations, according to you, are meant to be broken. This only means that their schedule is actually bullshit.
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24
    BeansnBread said:
    what point does an estimation serve? 



    They are meant to estimate, not to assurance. On the reality of development, especially a large-scale project at this, this will float constantly. Even if you finish your task within the deadline, how can you ever accurately estimate bugs and the time they will take to fix?

    Then obviously a company will internally want the most out of dev-time, so they won't be giving soft deadlines for their tasks.... and we are getting such internal data.
    Post edited by MaxBacon on
    Gdemami
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410

    MaxBacon said:



    BeansnBread said:
    what point does an estimation serve? 


    They are meant to estimate, not to assurance. On the reality of development, especially a large-scale project at this, this will float constantly. Even if you finish your task within the deadline, how can you ever accurately estimate bugs and the time they will take to fix?

    Then obviously a company will internally want the most out of dev-time, so they won't be giving soft deadlines for their tasks.


    Taking a comment out of context like that is to be expected from you.
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24


    Taking a comment out of context like that is to be expected from you.


    What I get on your context is that you're frustrated as they admitted on its disclaimer, that the dates given will in many cases be changed as the development flows.

    I guess they perhaps would require a PR/Marketing "translation" of the dev workflow when it comes to the estimates, giving soft-estimates instead.

    Post edited by MaxBacon on
    Gdemami
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410

    MaxBacon said:





    Taking a comment out of context like that is to be expected from you.


    What I get on your context is that you're frustrated as they admitted on its disclaimer, that the dates given will in many cases be changed as the development flows.

    I guess people like you, they perhaps would require a PR/Marketing "translation" of the dev workflow when it comes to the estimates, giving soft-estimates instead.


    People "like me" are made slightly woozy by how often they break deadlines. This is another blatant example and will continue to be an example of that until they decide that it's too toxic because they fail to meet their deadlines. I am witnessing a dishonest company take advantage of consumers good will by over-promising and under-delivering. 

    But I agree with you that these are fake deadlines. They are useless in any real world scenario since they are not going to be met. 
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24
    But I agree with you that these are fake deadlines. They are useless in any real world scenario since they are not going to be met. 

    It feels that for some people this less filtered feed of the information they work with internally seems to confuse/frustrate people as to why they give dates that will most likely be changed.

    They try to clarify the process but that seems to not be enough. 

    That's why I kinda agree they shouldn't publish their internal estimates like this, they should pass through PR/Marketing before reaching the community.
    Post edited by MaxBacon on
    Gdemami
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410

    MaxBacon said:

    But I agree with you that these are fake deadlines. They are useless in any real world scenario since they are not going to be met. 


    It feels that for some people this less filtered feed of the information they work with internally seems to confuse/frustrate people as to why they give dates that will most likely be changed.

    They try to clarify the process but that seems to not be enough. 

    That's why I kinda agree they shouldn't publish their internal estimates, they should pass through PR/Marketing before reaching the community.


    It doesn't confuse me. It's quite clear what they are doing.

    They are promising something they not only won't deliver on, but can't deliver on. And it has been evidenced, again, and within a week.
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24
    BeansnBread said:
    They are promising something they not only won't deliver on, but can't deliver on. And it has been evidenced, again, and within a week.

    That's not true, for example on the Schedule of 2.6 had its own tasks who got deadlines changed every week and the ones that met their deadlines.

    The ones facing delays, the most complex, bugs, dependencies, even one engineer who got sick forced a feature to be cut from 2.6, that's just how it rolls.
    Post edited by MaxBacon on
    Gdemami
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410
    edited April 24
    MaxBacon said:
    BeansnBread said:
    They are promising something they not only won't deliver on, but can't deliver on. And it has been evidenced, again, and within a week.





    That's not true, for example on the Schedule of 2.6 had its own tasks who got deadlines changed every week and the ones that met their deadlines.

    The ones facing delays, the most complex, bugs, dependencies, even one engineer who got sick forced a feature to be cut from 2.6, that's just how it rolls.

    One note on your last bit, it's been one week since the schedule was made public, not since this tasks had been scheduled and started dev.
    That they can convince people that meeting deadlines is no longer important is amazing to me in its own right. All they have to do is tell people that nothing is set in stone, present them with a huge list of things that they can't possibly be expected to produce and then pronounce it is completely normal not to meet deadlines.

    Even here you are asking me why I am so confused. You act like I don't understand production schedules and that it's normal for everything to be delayed at all times. Somehow, they have convinced you that their extreme lack of adherence to deadlines makes perfect sense (no matter how much money they take in based on those deadlines).
    Post edited by BeansnBread on
    Gdemami
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24
    (no matter how much money they take in based on those deadlines).

    The disclaimers are there, loud and clear, about what it is and how the process works, they are telling you the opposite of set in stone. You can go there and read the caveats before the schedule is presented. If they are getting money based such deadlines, for sure it's not by implying something they are not.

    Post edited by MaxBacon on
    Gdemami
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410

    MaxBacon said:



    (no matter how much money they take in based on those deadlines).


    The disclaimers are there, loud and clear, about what how the process works, they are telling you the opposite of set in stone. You can go there and read the caveats before the schedule is presented.

    If they are taking money based such deadlines, for sure it's not by implying something they are not.


    If only those were the only deadlines they lied about.
  • VrikaVrika FinlandMember RarePosts: 4,245

    Like you imply, obviously these "estimations" don't actually mean anything. If they can mis-estimate over half of their estimations, what point does an estimation serve? After all, according to you, "they are only estimations." There is no reason why anyone should expect them to meet their goals. Estimations, according to you, are meant to be broken. This only means that their schedule is actually bullshit.


    I miss over 90% of my own estimations about how long my trip to work takes, but last time I was late was is November.

    Estimations rarely hit bullseye, and you should not expect nor demand them to hit bullseye. You should only expect them to be reasonably close and only complain if they are missed by a lot. Not treat them like deadlines. Deadlines are different thing.


    That's not to say that Star Citizen wouldn't have given us plenty reason and them some more for how they've totally failed to meet many of their estimations over the years. But if you extend your complain to every estimation that gets missed a bit, and thus to something that's completely normal, you just devalue the good argument that you could make.
    Gdemami
     
  • BeansnBreadBeansnBread PshMember RarePosts: 6,410

    Vrika said:
    But if you extend your complain to every estimation that gets missed a bit, and thus to something that's completely normal, you just devalue the good argument that you could make.


    Do you not see what is wrong with this statement? If every estimation gets missed a bit (they are actually being missed by months already), then there is a serious issue. I understand the concept you are trying to explain to me, but in this case, I believe it works the other way around.

    They are using this to pretend like delays are completely normal and you are supporting it. From now on, every delay is to be expected because it is just an estimate. That June 29th date... Do you think they will hit it with all of that stuff on the list? Of course not. But ideally for them, everyone will accept that it was inevitable that they did not live up to their promises.
  • adamlotus75adamlotus75 LeedsMember UncommonPosts: 373
    The 3.0 patch needs to have everything they showed last August plus vastly improved netcode / client performance or you can kiss a general release of SC goodbye for at least another 3 years.  

    If i was betting they will either:

    Release a very limited patch in June with whatever they have ready, or

    Delay the patch until it has something more meaningful in it.  Think Christmas.

    They need to start delivering now or the project is dead in the water.
  • Octagon7711Octagon7711 Chicago, ILMember EpicPosts: 6,183

    MaxBacon said:

    Fixed a wrong bit btw, the "UI Owner Component" was not delayed from 28th April to 12th May, it's the opposite, swapped with another UI task.



    Vrika said:
    On the other hand if something gets misestimated by 200% that is liable to cause a chain reacting where other teams need to redo their own plans because something they needed is not ready yet, efficiency all around the studio drops, and both budget and schedule are exceeded by a lot.


    Yup this is the big headache of producers when a task delays to the extent other scheduled tasks with that dependency can't work until it is done that can cause the biggest delays.

    Then the worse thing you can't estimate is the bugs you'll consider blockers, how much time until they are dealt with.


    Wouldn't it still be a delay with swapping being the reason for the delay?

    "Change is the only constant."


  • VrikaVrika FinlandMember RarePosts: 4,245




    MaxBacon said:


    Fixed a wrong bit btw, the "UI Owner Component" was not delayed from 28th April to 12th May, it's the opposite, swapped with another UI task.




    Vrika said:
    On the other hand if something gets misestimated by 200% that is liable to cause a chain reacting where other teams need to redo their own plans because something they needed is not ready yet, efficiency all around the studio drops, and both budget and schedule are exceeded by a lot.



    Yup this is the big headache of producers when a task delays to the extent other scheduled tasks with that dependency can't work until it is done that can cause the biggest delays.

    Then the worse thing you can't estimate is the bugs you'll consider blockers, how much time until they are dealt with.




    Wouldn't it still be a delay with swapping being the reason for the delay?


    It depends on your point of view.

    If you're waiting for UI Owner Component to finish then it's a delay. On the other hand if you're waiting for next patch, then doing those things in different order should have no effect on its release date or content.
     
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24

    The 3.0 patch needs to have everything they showed last August plus vastly improved netcode / client performance or you can kiss a general release of SC goodbye for at least another 3 years.  

    If i was betting they will either:

    Release a very limited patch in June with whatever they have ready, 

    When it comes to releasing what they have shown on Gamescon 3.0 demo, that's a quite superficial release by itself.

    On the 3.0 demo, we saw the Delamar landing zone, landed on it, took a mission from the Miles guy, explore a wrecked starfarer, took and did fly the Dragonfly (released already), traveled to one Moon finishing the quest, on it, there was also the Rover.

    Seeing the schedule, all that was shown last year is on the 3.0 release, the release has more than what was demoed but less than what was originally road mapped.
    Post edited by MaxBacon on
    Gdemami
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24
    One relevant comment from a Dev on Reddit yesterday on the Network Bind/Unbing and Network entity update component scheduler:

    Both of these are very important, but by far the most important thing is to get object container streaming working. Object container streaming will allow us to only have a subset of entities on the client and server that are the minimum required for gameplay, which should dramatically reduce update time as well as a fair amount of memory usage. It will also make other game code behavior such as zone queries faster by making these queries operate on a smaller set of potential entities.

    Unforutnately this is not going into 3.0 as it is a huge epic legendary task that will introduce many complexities into various other systems in the game, but we are actively working on it.

     This kinda clarifies what is going on the network front, and what to expect to cause the biggest impact on how the game performs to be something to expect beyond 3.0. The goal mentioned is scheduled for 3.1.
    Post edited by MaxBacon on
    Gdemami
  • rpmcmurphyrpmcmurphy DublinMember EpicPosts: 2,569
    This object container stuff is a prerequisite for Sq42 from what I remember, the team working on it were hoping to have it done later this year, however if such a key piece of tech has yet to be implemented it seems unlikely that Sq42 will be launching this year :(


    What's interesting is that only a month ago Erin Roberts was saying that it was pretty much ready for 3.0
    The next big release improves things significantly because of the new
    object containers which turn stuff on and off, not just turn it off but
    everything else which is going on in there so people should see a
    dramatic improvement in performance, not necessarily the finished
    article, there are still other things to come but this should make
    things a lot better.
    http://wccftech.com/star-citizen-exclusive-interview-erin-roberts/

  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24

    This object container stuff is a prerequisite for Sq42 from what I remember, the team working on it were hoping to have it done later this year, however if such a key piece of tech has yet to be implemented it seems unlikely that Sq42 will be launching this year :(

    Why would it be?

    I think you might be confusing this with the MegaMap streaming tech that we saw implementation on the last 2 patches. SQ42 needs that because that is the fundamental tech piece that avoids loading screens.

    The object container streaming seems to be the PU implementation of the "Megamap".
    Post edited by MaxBacon on
  • rpmcmurphyrpmcmurphy DublinMember EpicPosts: 2,569
    No Max I am not confused about it. If anything it is you confusing it with other stuff. It has been widely reported that the room system, object streaming etc are all required for Sq42.

    From BoredGamer
    Squadron 42s Missions & Chapters are Optimized by splitting up the
    other chapters in the game into logical object containers using this
    system.
    An Object Container can contain many items & various room system “rooms” with varying pressures & contents.

    https://www.reddit.com/r/starcitizen/comments/5wjeka/item_20_object_container_streaming_the_room_system/

  • cheyanecheyane EarthMember EpicPosts: 4,907
    People do turn themselves inside out to explain and excuse this company. 
    image
  • MaxBaconMaxBacon Figueira da FozMember EpicPosts: 4,512
    edited April 24

    No Max I am not confused about it. If anything it is you confusing it with other stuff. It has been widely reported that the room system, object streaming etc are all required for Sq42.

    From BoredGamer
    Squadron 42s Missions & Chapters are Optimized by splitting up the

    other chapters in the game into logical object containers using this
    system.
    An Object Container can contain many items & various room system “rooms” with varying pressures & contents.

    Hah so the MegaMap will stream the object containers around you, in the case of SM/AC this is always a one-time load, the tech dependency seems to be when it needs to move in-between containers to stream them in/out as you move.

    With this stalled for 3.1, 3.0 will have to release the planet and moons without such tech, better hope they manage the servers to behave until this greater network pieces get available.

    But we can't tell if this isn't already used for SQ42, being that there's a singleplayer and multiplayer implementation of it to do.
    Post edited by MaxBacon on
    Gdemami
Sign In or Register to comment.