Unreal Engine is not for programmers! ...?

Development Programming & Scripting C++
, , ,
1

Hello there,

I am a programmer, I would like to develop a game with the Unreal Engine and have been looking around trying to figure out how this engine works for a few days now…

What I have discovered so far is that this engine is definitely not made for programmers, from what I understand it is more designed toward users/developers who want to make a game with the already existing framework, a game that I would describe as “just as any other game”.

Let me explain how I came up to that “conclusion” and how maybe you could help me see it otherwise if I’m wrong…

Take for example the FoliageType “class”:
There is, in the engine, a class called ProceduralFoliageSpawner that can take multiple “Foliage Types” as parameter and basically just randomly spreads these Foliage Types around a given surface area, to simulate a “random” environment filled with various plants or whatever Foliage you give it.
In the FoliageType class, there is a property that controls the “Culling Distance” of the instances of this FoliageType, making the plants disappear at a given distance and re-appear when the camera (player) gets closer.
So let’s say you wanted to make a dozen different FoliageType plant types and rock types to put in your level, randomly spread out, using the ProceduralFoliageSpawner… it’s fine if you are okay with going and changing this “Culling Distance” property in each of your FoliageTypes manually, having to change it over and over again until you find what is suitable for you or when something during the development forces you to adjust your culling distance (ie. performance?)… but that’s just not the way developing works.
It would be way wiser to get some kind of “default” value to give to all of these FoliageTypes or even better, a wrapper to divide all of those FoliageTypes into categories.

What I’m talking about here is subtypes.

Ideally, you’d want to make a subtype of FoliageType and call it “SmallPlantFoliageType” with a lower culling distance and maybe a “BiggerRockFoliageType” with a bigger culling distance so the big rocks are still visible from afar while the small plants don’t eat processing power by being rendered even if not visible from so far away.

But no, you can’t do that.

If you extend that FoliageType class and dig into writting some C++ code for it you’ll get the infamous “Unresolved External Symbols” errors that occurs because the FoliageType is declared somewhere in the Engine source files but the whole definition of the class is not exposed because they removed it from the project (from what I understand) so it makes the compiling/building shorter, the FoliageType.cpp file doesn’t even exist, it is all pre-compiled and given to us as binary so there’s not even any copy/pasting of the original definition of FoliageType and making a new class out of it either, the code is missing…

Basically with this error Unreal Engine is telling you: “Hey, I don’t want you to extend this class”.

Fact is that if you can’t extend the classes that you want, if you can’t modify the “framework”, then there’s just little you can do.

I have downloaded the Engine source code from github and tried finding that FoliageType.cpp file in the Engine source project to no avail…
From what I understand from posts like these: https://answers.unrealengine.com/que…captureco.html it’s that it’s possible to have access to the complete source code and modify it however I want… but I am struggling with how I would be supposed to do that…
Even if the FoliageType definition C++ code existed in a file in the Engine source project, what would I do with it? Would I need to copy/paste it in my game project and make my custom “MyFoliageType” class and use that definition instead of the default Engine one?

I’ve also tried inserting my game project inside of the Unreal Engine source solution in Visual Studio… but that didn’t work out quite well… just made me lose another 40 minutes of building the whole engine again for nothing, getting the same errors at the end.

Please help me… is there something I’m missing here?

After reading this: https://answers.unrealengine.com/que…ape-class.html you come to think and ask yourself how you would even do a procedurally generated landscape if you can’t extend the basic Landscape class… would you need to re-write everything? make a new class MyLandscape that has completely nothing to do with the Unreal Landscape class and simply ignore the Engine functionalities managing the landscape? might as well just stop using the engine right now and code my own.

Thank you for your time,
WX

2

I would say it because of the modularity of the engine, for instance, you need to add the “Foliage” module to your .build.cs file

Also, i suggest you to go to your Engine option in EpicLuncher, edit , and check the debug symboles and engine source code. it will allow you to browse sources directly in VS

For instance, FoliageType is blueprintable ( it mean you can make a blueprint of it and set new default value for a special type of foliage ), so it’s perfectly expendable by c++

There is a non negligible learning curve for UE c++ but i can assure you, you can do a LOT more in c++ than in Blueprints.

Though, i kinda agree that some time you can’t really extend some classes in engine, and usually i duplicate the code to a new class and modify it on my side, so i avoid the “edit and recompile the whole engine” thing

Even if i’m a pure dev and not an artist/designer, i still recommand you to use blueprint some times, and not doing c++ for the sake of doing c++, many small stuff are faster to do in bp.

Last thing, when you make a c++ class that you will extend in blueprint, try to alway do a dummy blueprint between c++ and child blueprints that can be usefull to hook an event or stuff like that in 2 clicks ( and won’t hurt perfs as you still have all your core code in c++ )

exemple : c++ actor => c++ trap => BP trap => All your bp traps

3

So many things in this topic are bad assumptions and misinformation.

Took me 5 seconds to find “something that doesn’t exist”:

4

You are so right, and all those are in your reply.

Next time when you quote someone do it correctly, it might save you from thrash talking on somebody else’s post. The sentence you might have been looking for was probably this one:

If you actually knew how to program anything you’d know the difference between a class “definition” and a class “declaration”.

Re-read my post “BrUnO XaVIeR” and find the

and give me the definition of all the FoliageType methods.

You found the declaration of the FoliageType, good job.
Now give me the definition, which is what I talk about in this post.

Of course you know the difference… now.

5

Thank you for your help **Firefly74, **I went and enabled the debugging symbols in the Epic Launcher but I’m afraid it won’t help.

The engine source code option was already enabled in the settings and I have included the “Foliage” type in the Build.cs for my project but I still can’t find the definition of the FoliageType class anywhere in the source of the engine (while looking in the engine project contained in my game solution in Visual Studio).

The thing with blueprints is that they don’t act the same as the actual “base class types”, I can’t give a FoliageType blueprint to a “ProceduralFoliageSpawner” in the editor to spawn foliage. Couldn’t figure out either how to add a mesh component to a FoliageType blueprint… there’s no “viewport” tab in the editor when editing the blueprint.

I started fiddling around and found that when you instanciate the FoliageType the object created is actually an instance from “FoliageInstancedStaticMeshComponent” so I thought I’d instead make a class that extends from that… but it didn’t work.

Anyway, I’m just gonna give up… too many errors all the time in Visual Studio and it seems just too tricky to do what I want to do.

Thank you for your help anyway.
Best of luck

PS: To be completely honest… I knew it from the very beginning when creating my first C++ project in Unreal Engine… with the Visual Studio “Atomic.h” errors. Maybe some people can get around all of that but I won’t.

6

@WindraX I have used the procedural foliage spawner in projects and you can have as many of them as you want and each one with different items to spawn with different settings. There is no need to use C++ ever to get that to work.

It takes a considerable time to learn to code with the C++ Framework Unreal provides. The only thing I would tell you is that nothing in the engine is in binary format (except 3rd party tools in a specific folder and they are few) all the source code is there.

I will check why declaring the Foliage as a module is not allowing you to compile your code.

8

@WindraX I have looked at the source code and this specific case you are handling the asset is contained in different parts of the source. Let me explain this a bit:

If you look at the Source folder you will see a separation made as follows:

Developer
Editor
Programs
Runtime
ThirdParty

The structure above represent the concept of tools/framework available.

Usually for game developers wanting to extend functionality the folders of main interest are: Editor and Runtime

For tool developers wanting to extend profiling tools the folders of min interest are: Developer and Programs (if not all folders)

The foliage is a case where you have a Runtime portion which is what makes it being handled when playing a game and a Editor portion which allows you to handle it while in the editor and using with spawners (because spawners also runs in editor for you to see the result).

The editor itself is like a game with a complex UI.

FoliageType is indeed defined (.h) in the Runtime folder structure (as Foliage), but the definitions are found mostly in the Editor structure (as FoliageEdit). Inside this portion is where you will find the code to dig to understand how the FoliageType and everything else were done, including spawners.

Note that sometimes when you dig into some code that devs place a #if WITH_EDITOR …#endif to surround code that needs only to be part of the editor and not part of a packaged game, meaning that when you package a game what is inside that portion won’t be there. Make sure when you extend the FoliageType, that you consider this logic, so your final code will make sense where it needs to be.

9

Just a note, if you are looking for the definition of UFoliageType members, it’s inside Runtime/Foliage/Private/InstancedFoliage.cpp.