IMHO there is a basic error they're making, which is to do all of this in one product. When they have two internal architectures sharing one interface, the overall scope bloats up, which leads to some miserable UX.
With most game projects, the point is to ship them once and then start anew with the next one - long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business - they can afford to keep around the staff dedicated engine work for the long run. The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.
>IMHO there is a basic error they're making, which is to do all of this in one product.
If they were to start from scratch, DOTS would be missing so much functionality that it wouldn't really be useful. By essentially using the strangler pattern, they are allowing people to get access to the newer architecture immediately, and then gradually adding more and more over time. Eventually, years from now, they will completely replace the old architecture. I'm sure there will be some version of what you're talking about here
>as long as the previous engine has the proverbial lights kept on
with the old architecture.
> long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business
That's less the case these days with plenty of indie games produced by very small teams that are in early access release/development cycles for years. It's also very common to reuse existing codebases for new games.
>The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.
The outcry over Unity abandoning the old way of doing things is pretty loud. Many people use Unity for multiple projects, and they get mad when Unity makes big changes that invalidate their knowledge, which is one reason Unity is making the changes so slowly.
With most game projects, the point is to ship them once and then start anew with the next one - long-term maintenance isn't the primary decision driver, and the games for which that is the case are rather exceptional and sit at the top end of the business - they can afford to keep around the staff dedicated engine work for the long run. The majority of users in contrast are equally as likely to welcome clean breaks as they are to despise them; as long as the previous engine has the proverbial lights kept on, there isn't an issue.