Clunky question I know, I’ll try to elaborate. One of my colleagues on Game Dev at University is very much against off-the-shelf game engines as he says that you always end up with a bloated game that has mechanics that are not used, rather than something built for purpose that only has the components that the game requires. I am wondering if, on build, Unreal strips away parts of the engine that haven’t been utilised?
Nope.
Your friend is not only 100% correct, but also underestimating how trashy pre-packaged engines actually are.
It’s a give and take of diminishing returns though.
Can you write a decent rendering pipeline yourself that looks good and performs well ? No?
Then your only option is an engine.
Something like Gdot has the ability to package very little of itself into the final product by design - however compared to everyone else, it also offers next to nothing.
And - if you know what you are doing, you can get even Unreal to package just what is strictly necessary.
You should follow the guides to win the Game Jam’s tiny awards, since they stress most good practices for removing the bloat.
However in engine, at the core level, you have classes and pre-made things that are always jammed full of stuff you’ll never really need in 99% of cases.
So unless you know the engine very well, and you look into each class you include, there’s really no way to know how much trash you’ll be accidentally packaging.
A blatant example is the character class, which includes network replication, for instance…
3 Likes
I agree MostHost_LA.
The problem is that most people need month/years to develop their own game even with a good engine like Unreal or Unity. Most people think it is super easy and give up after some time.
When you then also try to implement an own engine you really have to know waht you are doing, else you will give up even earlier.
I would always stick with an engine
1 Like
Nope.
Last week I build a simple project with only Paper2D and minimal plugins, when I package the game it compiles and add VR, XR, AR, Chaos, Niagara, Vulkan and everything else inside Engine\Source\Runtime even if never used.
Apparently, starting from 4.15, it is setup to only include what it uses:
But the engine is not a silver bullet; it requires work from you the developer, as well. If you don’t need functionality in your game, it’s not the engine’s job to *magically* figure that out for you (because it can’t); it’s yours. For example, if you don’t need networking in the character class, you should remove the networking functionality from it yourself (you have access to the source after all). There’s no way for the engine to just “detect” that you’re not making a multiplayer game.
Of course, this also goes for any other game engine; this is not just an Unreal thing.
2 Likes
The engine helps you so much it seems like magic, but it is not magic.
As mentioned, you must learn how to tell the engine what sort of project you are making and for what platforms and even what sort of shader permutations you need or don’t.
Maybe compared to somebody’s theoretical ideas this is better or worse than making your own engine, but if you are in the demographic of people who ask beginner-level questions on forums, you are most certainly better off using an engine. It’s like asking if it is better to drive a BMW or make your own car. Somewhere out there there is a dork who will seriously try to argue for making your own car - but virtually everyone is not doing that and it’s for practical reasons.
Here is probably the biggest thing to consider: a non-technically inclined beginner can make a good quality game in less than a year using an engine like unreal.
To build an engine would require expertise gathered over decades, and then the work will take years.
So even if Unreal has some bloat included in the package and this upsets you - it’s kinda tough luck, and for somebody serious about publishing games and making money at it, this should probably be a non-concern. You’ll have problems to solve that make an actual difference in your bottom line.
1 Like
Stupid Q.
I’ve taken the habit to develop parts/modules of my project in distinct project in and of themselves. The intent would be to migrate from each of those projects into the finished product. I might be playing around with different things until I get what I want so in an effort to make sure all the old-stuff is never carried forward, I’ve been of the mind to have a single project I migrate all my finished-parts into.
My thinking is that when I go through the migration process, since I can cherry-pick which items go over, I’d end up with less bloat owing to ‘scratch work’ and any associated resources…
I get this might help reduce bloat insofar as resources like textures, meshes, etc.
This make any sense? Anything this process might miss or is this kind of a non-starter?
Non starter, the only parallel is that you use the word bloat, really.
The engine classes are what’s bloated, and obviously you control what you add into the final project however you see fit.
I think we all use slush/test projects to manage testing vs final work anyway.
In a sense, you should be concerned about what you include.
On the other hand OP was asking about stuff that isn’t that easy to control.
For everyone else, there’s also this.
Using blueprint the engine will include kismet. That’s a bloat-load of functions that may actually never even get used.
I really don’t think IWYU will go as far as excluding functions that aren’t actually used from a header file - and I could be wrong, but I do doubt it because of the way stuff compiles.
Ergo, in theory, a cpp project where you directly include only stuff you need into the classes, would always have a lower profile than a blueprint one.
In practice, we can all agree that if you went and started from near 0 with every project you made you’d get nowhere really fast…
One of the biggest problems I have with Unreal is that optimizing it for your project can be very difficult. There’s stuff that impacts performance that you don’t need and unless you know the engine very well then it’s hard to figure out what you need to do to.
From what I’ve seen, small developers and hobbyists have trouble making games with Unreal that run well.
Some projects I’ve used Unity for because you can start out barebones and add the extra things you want so it’s easier to know what things you’re using that impact performance, but Unity doesn’t have their source available like Unreal so you can run into something that can’t be fixed without that.
Cry engine can literally make you cry, but it does have a git with source and far better performance than unreal.
It really kind of is like starting from 0 on everything though. Which is why not many indy use it for final products.
Doing more yourself means less bloat…
Thanks for the responses so far. My colleague is a senior lecturer in Game Dev, and one of his modules is on game engines. In the 2nd year we did a bit of game engine building with Ogre. I’m personally very pro Unreal Engine. I think UE5 is going to completely change the traditional game creation pipeline, but I’m looking at it from more an artist’s perspective than a programmer. He asked me last week if Unreal did do anything to manage all the stuff you don’t utilise on build, and I didn’t know so I said I’d try to find out.
I appreciate the time and consideration given to the question.
Personally, I think your expectation is unfounded.
But you can always hope.
The reality is epic has no interest in even making the engine perform OK.
They are far more concerned about one off New features, which are worked on for 10 minutes and then discarded as “beta” for years and years without ever being completed, fixed, or even remotely adjusted…
1 Like
You know in real world of making real applications (games, some big systems, really anything serious), you have only 2 limitations: money you can spend on project, and people you can get.
Time/deadlines are not limitations, you simply need smart CEO or sales person to not promise something that cannot be done.
However many times you just cannot secure required talents for making your project. And people who could code working and well designed engine from scratch are very rare. So they can be picky about which job they want and can be picky about salary. For making big game, you need like 20 of such people. Then one really experienced in that to lead them as a team.
It is much easier to get 20 people that can use engine like unreal and produce quality game with it. And really nobody cares about size of binary, now those 500-600 mb used by code seems big for mobiles, but it is nothing on PC or bigger consoles. And epic knows this, they do not care about stuff that is not important or not bringing them more money.
ps.
About 20 years ago i was puzzled/angry (just like you are now) about why nobody writes drivers in pure ASM anymore, or why they do not do asm games. And that asm can be optimized much better (it was like this back then before compilers got much better and before new CPU that can optimize running code on the fly).
btw, one game i know was pure asm (on PCs) is Epics pinball game.
pps.
About unreal, unity, godot and rest of engines. You pick TOOL that best suits your situation.
1 Like
I love how the tl;dr seems to be: “Nah, it’s a disaster. But, disaster management can be a more attainable way of shipping a product”.
Which is a much more fun reply than I expected.
1 Like
I would ask this colleague to list the number of successful commercial products they have shipped using the make-your-own method. My guess is that the number is next to zero. Its easy to tout the benefits of such an approach in a vacuum; but unless you have years of experience in game engine design (or your game is has very simple needs), you are going to get nowhere fast using that approach.
2 Likes
“Sure, you can code Windows, but will you be able to?”
The answer to that is no.
You just steal the software from Xerox and pay them next to nothing.
Well, Xeroxs’ business model WAS based on copies… Whynot M$?
The Witness and Braid immediately come to mind, so I hope we do get a list of games this lecturer shipped this way, because it’s usually easier to get lists of “games made with Unreal” or “Games made with Unity”.
There’s a ton of games that use custom engines, that used to be pretty much the standard before UE3 became big. Probably like half of console games still at least.