It is ok that you have versions and different parts etc. but we would not expect that there is no better version of it after two years. It does not have to be the same as it was in the showcase. It is irrelevant how source control works and how they iterate.
It makes sense that programmers think things will be easier than normal, because in the realm of programming a simple task that has to be done 10,000 times can be done instantly as long as you know all the parameters of how it has to be done. That can be set up in 2 lines of code, over the course of about 8 seconds of work. When you're asking a programmer for an assessment of difficulty you're asking them to guess how quickly they can write a poem that perfectly encapsulates this set of five concepts. Poems can sometimes encapsulate all five concepts in just one haiku! And sometimes it'll take a sonnet. And sometimes an epic. But they won't know which one until they start writing, and they are NOT incentivized to highball their guess.
I only really disagree that he misunderstands. I think he is aware of all of this and choosing to feign outrage for content. I don't believe he's really mad, I think the character he plays on YouTube is mad and he is leaning into it as a result of increased viewership.
As a programmer, not in game dev but in web, I can tell you we do not think things are easier then they turn out to be. We usually give estimations to features with a generous margin for error and with solution principles in mind, because we need to manage resources. In principle everything is possible depending on how much money and time you push into it. What can happen is that things or concepts get changed during development, which will no longer work with the architecture you initially planned. So having a road map planed out early on helps to estimate any given feature, because we can keep those other features in mind while developing the architecture. If this is not the case in your work environment, we are not talking about experienced programmers. Of course there will always be errors and changes you can't predict and won't predict. But i think we are talking on different levels of failure here.
Sure, you will always first work on systems and the backend, before you implement something to look shiny. But what usually should not happen is that a feature is presented as high fidelity as it has been in AoC and then not delivering at all on it. If you push something like that into an alpha you make it crystal clear to the customer what the current issues are and that this is currently just a proof of concept to test backend processes. Usually end consumers don't understand or appreciate this kind of testing on the customer, so i would never recommend doing this at larger scale unless you previously made clear, that what you showed is just a high fidelity teaser to give an idea of what it could look like and that the alpha will not include such high fidelity since there are still systems being tested. As far as i can remember this did not happen. People expected the high fidelity showcase and got the barebone systems test instead without it being communicated. This should just not happen.
With web we for example work on multiple feature branches that are developed on developer machines. If those features are split correctly they come down to only a small amount of work for each feature or subfeature. Those go into review and testing on a staging environment and when they are looked over by QA and not bounced, they go into production. If your programmer did well, they encapsulated their module so it doesn't interferes with existing code. If two different modules use the same utility set or inheritance and thad changed, it should have been either captured by QA or by automated tests if possible. You don't just promisse a feature with a high fidelity showcase, if you don't know that you can deliver. This is then a case of over promise and under deliver. "This is how it works" is not a good excuse, cause this is not how it should work.
Steven should stick to what he can show and deliver. We have seen before with hello games what can happen if you do that kind of stuff. At least they delivered on their promisses in the long run.
I enjoyed this explanation of how things are done, you should certainly do more ashes content
What games have you previously worked on?
Hi random nobody, what have you worked on?
It is ok that you have versions and different parts etc. but we would not expect that there is no better version of it after two years. It does not have to be the same as it was in the showcase. It is irrelevant how source control works and how they iterate.
It makes sense that programmers think things will be easier than normal, because in the realm of programming a simple task that has to be done 10,000 times can be done instantly as long as you know all the parameters of how it has to be done. That can be set up in 2 lines of code, over the course of about 8 seconds of work.
When you're asking a programmer for an assessment of difficulty you're asking them to guess how quickly they can write a poem that perfectly encapsulates this set of five concepts. Poems can sometimes encapsulate all five concepts in just one haiku! And sometimes it'll take a sonnet. And sometimes an epic. But they won't know which one until they start writing, and they are NOT incentivized to highball their guess.
I only really disagree that he misunderstands. I think he is aware of all of this and choosing to feign outrage for content. I don't believe he's really mad, I think the character he plays on YouTube is mad and he is leaning into it as a result of increased viewership.
So why not steven just say game us 10yrs away from being complete?
So why not steven just say game us 10yrs away from being complete?
I think the problem is how they monetized the game and what expectation that brings.
RIP AoC Garbage woke game died before it even released
As a programmer, not in game dev but in web, I can tell you we do not think things are easier then they turn out to be. We usually give estimations to features with a generous margin for error and with solution principles in mind, because we need to manage resources. In principle everything is possible depending on how much money and time you push into it. What can happen is that things or concepts get changed during development, which will no longer work with the architecture you initially planned. So having a road map planed out early on helps to estimate any given feature, because we can keep those other features in mind while developing the architecture. If this is not the case in your work environment, we are not talking about experienced programmers. Of course there will always be errors and changes you can't predict and won't predict. But i think we are talking on different levels of failure here.
Sure, you will always first work on systems and the backend, before you implement something to look shiny. But what usually should not happen is that a feature is presented as high fidelity as it has been in AoC and then not delivering at all on it. If you push something like that into an alpha you make it crystal clear to the customer what the current issues are and that this is currently just a proof of concept to test backend processes. Usually end consumers don't understand or appreciate this kind of testing on the customer, so i would never recommend doing this at larger scale unless you previously made clear, that what you showed is just a high fidelity teaser to give an idea of what it could look like and that the alpha will not include such high fidelity since there are still systems being tested. As far as i can remember this did not happen. People expected the high fidelity showcase and got the barebone systems test instead without it being communicated. This should just not happen.
With web we for example work on multiple feature branches that are developed on developer machines. If those features are split correctly they come down to only a small amount of work for each feature or subfeature. Those go into review and testing on a staging environment and when they are looked over by QA and not bounced, they go into production. If your programmer did well, they encapsulated their module so it doesn't interferes with existing code. If two different modules use the same utility set or inheritance and thad changed, it should have been either captured by QA or by automated tests if possible. You don't just promisse a feature with a high fidelity showcase, if you don't know that you can deliver. This is then a case of over promise and under deliver. "This is how it works" is not a good excuse, cause this is not how it should work.
Steven should stick to what he can show and deliver. We have seen before with hello games what can happen if you do that kind of stuff. At least they delivered on their promisses in the long run.
To make an open development and expect that the people playing the game do it from a developer point of view is so naive is dumb.
You are right with most things and it is clear that Narc has no clue about actual game dev