4 ms·

When reading sections of the article about Unity's permanently experimental features, I was wondering why they didn't use a different engine (probably because t

When reading sections of the article about Unity's permanently experimental features, I was wondering why they didn't use a different engine (probably because their expertise is in Unity). Does Unreal for example have support for this kind of game? Oh and I have to mention the cascaded shadow mapping: "taking about 40 milliseconds or almost half of total frametime. ". - 40ms is 25fps all by itself!

honkycat 3y ago
unreal absolutely does have support for this type of game. It is really a smattering of different loosely coupled tools that you can bring into the project, or roll your own. The star is absolutely the rendering engine and visual programming tools IMO. Unreal really excels at action games, but you can absolutely implement custom camera RTS controls and such. Batteries included but replaceable. The question "does X engine support this kind of game" is a bit.. off. You would be amazed at how many features these engines pack in. However: You would also be amazed at how NOT "plug and play" they are. It still takes a TON of effort and custom code to make a sophisticated game.
munificent 3y ago
Unless you've worked in games, it's really hard to understand just how massively tied to the engine a game is. Imagine you have a web app written in Ruby using Rails with data stored in Postgres. You have a few hundred tables, millions of rows. Millions of lines of Ruby, CSS, and HTML. Thousands of images carefully exported as JPEG, GIF, or PNG depending on what they contain. Now imagine being told you need to simultaneously port that to: - Not run on the web. Instead be a native application using the OS's rendering. - Not be written in Ruby. Instead using a different language. - Not use Rails. Instead, use a different application framework. - Not use Postgres. In fact, don't use a relational database at all. Use an entirely different paradigm for storing data. - Not use CSS, HTML, and raster images. Instead, everything needs to be, I don't know, vector images and Processing code. That's about the scale of what moving from one game engine to another can be like. Depending on the game, it's isn't always that Herculean of a task, but if often is. A mature game engine like Unity is a programming language, build system, database, asset pipeline, application framework, IDE, debugger, and set of core libraries all rolled into one. Once you've picked one, moving to another may as well just be creating a whole new game from scratch.
bluescrn 3y ago
Unity's killer feature is its C# support. It's enabled small teams to do far more in less time that they could ever hope to do using C++, and avoiding some of the nastier types of bugs that C++ game developers have to deal with. And if you've got a team of experienced Unity developers, some who've been working with C#/Unity for their entire game dev career, switching to C++/Unity isn't the most practical option. While many concepts are similar between engines, you're going to be back at the bottom of the learning cliff for a while. It sounds like Unity isn't really the problem in this case, it's more about too many polygons, poor use of LOD, and sub-optimal batching (too many draw calls). It was probably more of a time pressure issue than a tech issue, as game development is usually a race against the clock.

honkycat 3y ago

unreal absolutely does have support for this type of game. It is really a smattering of different loosely coupled tools that you can bring into the project, or roll your own. The star is absolutely the rendering engine and visual programming tools IMO. Unreal really excels at action games, but you can absolutely implement custom camera RTS controls and such. Batteries included but replaceable. The question "does X engine support this kind of game" is a bit.. off. You would be amazed at how many features these engines pack in. However: You would also be amazed at how NOT "plug and play" they are. It still takes a TON of effort and custom code to make a sophisticated game.

munificent 3y ago

Unless you've worked in games, it's really hard to understand just how massively tied to the engine a game is. Imagine you have a web app written in Ruby using Rails with data stored in Postgres. You have a few hundred tables, millions of rows. Millions of lines of Ruby, CSS, and HTML. Thousands of images carefully exported as JPEG, GIF, or PNG depending on what they contain. Now imagine being told you need to simultaneously port that to: - Not run on the web. Instead be a native application using the OS's rendering. - Not be written in Ruby. Instead using a different language. - Not use Rails. Instead, use a different application framework. - Not use Postgres. In fact, don't use a relational database at all. Use an entirely different paradigm for storing data. - Not use CSS, HTML, and raster images. Instead, everything needs to be, I don't know, vector images and Processing code. That's about the scale of what moving from one game engine to another can be like. Depending on the game, it's isn't always that Herculean of a task, but if often is. A mature game engine like Unity is a programming language, build system, database, asset pipeline, application framework, IDE, debugger, and set of core libraries all rolled into one. Once you've picked one, moving to another may as well just be creating a whole new game from scratch.

bluescrn 3y ago

Unity's killer feature is its C# support. It's enabled small teams to do far more in less time that they could ever hope to do using C++, and avoiding some of the nastier types of bugs that C++ game developers have to deal with. And if you've got a team of experienced Unity developers, some who've been working with C#/Unity for their entire game dev career, switching to C++/Unity isn't the most practical option. While many concepts are similar between engines, you're going to be back at the bottom of the learning cliff for a while. It sounds like Unity isn't really the problem in this case, it's more about too many polygons, poor use of LOD, and sub-optimal batching (too many draw calls). It was probably more of a time pressure issue than a tech issue, as game development is usually a race against the clock.