It is so obvious even from just reading the article that it really has nothing to with the engine as staff were already using Unreal and could have just rolled with that. Blizzard has become so utterly irrelevant.
Unreal Engine can obviously handle some things well, but when I’ve seen it used for less common mechanics, the results have been mixed. For example, climbing and traversing uneven terrain are pretty bad in games like Palworld and Palia. Compare to the Breath of the Wild engine, which handles those things beautifully.
It’s plausible that such mechanics were planned for this game, and that Unreal Engine made it difficult to get results that meet Blizzard’s standards.
I’ll consider the possibility that the engine is blameless when I see two Unreal Engine games that do it well, hinting that it’s not unreasonably difficult. Sometimes a tool just doesn’t work well for certain uses. That could be due to a design that tries and fails, or one that doesn’t try at all and lacks a good foothold for a custom approach.
In any case, my comment is not about one specific issue. Thus the words “for example”. The point is that what GGP said was obvious is in fact not obvious. Blizzard might very well have passed on that engine because of limitations they found, regardless of whether they detailed them publicly.
It doesn’t matter if you see it in games, it’s not a part of the engine. There’s no built in functionality for ledge grabbing and climbing, that is 100% game logic built on top of the engine.
The decision of whether to modify software to suit one’s needs is often about the level effort required, both initially and for ongoing maintenance and support. Having permission to do it doesn’t magically make it worthwhile.
And no, Unreal Engine is not open-source. (Which brings up another possible factor in Blizzard’s decision: Royalty payments.)
Normally I wouldn’t try to be an armchair game developer, but I’m leaning towards agreeing with this. the article does say:
Epic’s incredibly popular engine reportedly could not support the team’s 100-player ambitions
which is a surprise to me, considering how robust it generally is. It’s superficial, but I can point to Fortnite as a game using Unreal and supporting a hundred players in one lobby along with being able to spawn custom buildings on the fly.
The closest analogue I can think of is FrostGiant using Unreal for presentation, sound, and inputs, but their custom Snowplay engine for everything else in Stormgate. This makes sense to me given they’re trying some tricky and somewhat novel things (at least) on the networking side that Unreal doesn’t support.
All that to say: I’m very curious about the details on how Unreal was unable to achieve what they wanted at the number of players they were targeting. I’m also curious why reducing scope (either in number of players or feature set) wasn’t a viable option, especially after so long in development. I don’t mean this as a “they’re obviously dumb and wrong”, I am genuinely curious what was planned and not working. I hope we get more details because cancelled games (and the development process as a whole) is fascinating to me.
It could be the networking can’t handle what they want. A game like fortnite doesn’t need anything super special from a networking perspective. Blizzard lost their best to frostgiant for networking.
It is so obvious even from just reading the article that it really has nothing to with the engine as staff were already using Unreal and could have just rolled with that. Blizzard has become so utterly irrelevant.
I’m not so sure.
Unreal Engine can obviously handle some things well, but when I’ve seen it used for less common mechanics, the results have been mixed. For example, climbing and traversing uneven terrain are pretty bad in games like Palworld and Palia. Compare to the Breath of the Wild engine, which handles those things beautifully.
It’s plausible that such mechanics were planned for this game, and that Unreal Engine made it difficult to get results that meet Blizzard’s standards.
That’s not an issue with the engine that’s an issue with gameplay programming.
I’ll consider the possibility that the engine is blameless when I see two Unreal Engine games that do it well, hinting that it’s not unreasonably difficult. Sometimes a tool just doesn’t work well for certain uses. That could be due to a design that tries and fails, or one that doesn’t try at all and lacks a good foothold for a custom approach.
In any case, my comment is not about one specific issue. Thus the words “for example”. The point is that what GGP said was obvious is in fact not obvious. Blizzard might very well have passed on that engine because of limitations they found, regardless of whether they detailed them publicly.
It doesn’t matter if you see it in games, it’s not a part of the engine. There’s no built in functionality for ledge grabbing and climbing, that is 100% game logic built on top of the engine.
Unreal Engine is open source, if there was something it couldn’t do then that could be rewritten so that it can do it
The decision of whether to modify software to suit one’s needs is often about the level effort required, both initially and for ongoing maintenance and support. Having permission to do it doesn’t magically make it worthwhile.
And no, Unreal Engine is not open-source. (Which brings up another possible factor in Blizzard’s decision: Royalty payments.)
What do you mean it’s not open source?
i have cloned their GitHub repo many times
Also no it doesn’t bring up royalties because that isn’t related to source code
Read the license. It’s what we generally call “source available”, but it does not qualify as open-source.
https://en.wikipedia.org/wiki/Open_source_license
https://en.wikipedia.org/wiki/Source-available
It brings up the issue of royalties because those are part of Unreal Engine’s license terms.
Open source and free are different
It can be considered open source because you can sell derivative engines (there are no royalties on that btw) and push upstream
Under your source available link the inability to create derivatives is the common theme for what makes it not open source
https://opensource.org/osd/
If someone else comes along, Unreal Engine checks all of those
Normally I wouldn’t try to be an armchair game developer, but I’m leaning towards agreeing with this. the article does say:
which is a surprise to me, considering how robust it generally is. It’s superficial, but I can point to Fortnite as a game using Unreal and supporting a hundred players in one lobby along with being able to spawn custom buildings on the fly.
The closest analogue I can think of is FrostGiant using Unreal for presentation, sound, and inputs, but their custom Snowplay engine for everything else in Stormgate. This makes sense to me given they’re trying some tricky and somewhat novel things (at least) on the networking side that Unreal doesn’t support.
All that to say: I’m very curious about the details on how Unreal was unable to achieve what they wanted at the number of players they were targeting. I’m also curious why reducing scope (either in number of players or feature set) wasn’t a viable option, especially after so long in development. I don’t mean this as a “they’re obviously dumb and wrong”, I am genuinely curious what was planned and not working. I hope we get more details because cancelled games (and the development process as a whole) is fascinating to me.
It could be the networking can’t handle what they want. A game like fortnite doesn’t need anything super special from a networking perspective. Blizzard lost their best to frostgiant for networking.
Ark Survival Ascended can handle a large number of players as well, apparently. The default max is 70, but that can be changed with ini settings.