Modules, project organisation and plugins

Hey all,

Apologies in advance for the wall of text, but I couldn’t find a way to bring across my questions and dilemmas without some context.

I have a question regarding best practices and the philosophy behind UE project organisation and the way to set up game modules. After a long absence from C++ programming (I’m a web developer in my day job), I started seeing so many cool things happening in the games space that I just had to dive back in. With major game engines embracing the subscription model, it become even more clear to me that Unreal Engine was where it’s at for me.

That said, I’m experiencing some getting-started issues that are keeping me from “really diving in” for now. I’ve forked the engine source code, generated project files and created a game project (TestFPS) with the intention of using this as a sandbox to play around in. I specifically want to start procedurally generating terrain and other meshes, and it occurred to me that if I were to write a lot of code for custom meshes, it might be a good idea to put this code into a separate module so that it would be easier to reuse in other projects later on.

I think I got my separate module (called ProceduralContent) set up correctly now. At least, I can see a separate editor DLL is being created and it has “ProceduralContent” in the name.

My directory structure thus now looks like this:

- TestFPS
    - Source
        - ProceduralContent
            - Public
                + ProceduralContentModule.h
            - Private
                + ProceduralContentModule.cpp
            + ProceduralContent.Build.cs
        - TestFPS
            - Public
            - Private
            - Resources

This was however a painstaking manual process. I set up the folders in windows explorer manually, then made the filters in Visual Studio correspond to the filters and had to take care that the files I created were saved in the correct folder (why does Visual C++ not support folders in the solution tree?) Then I noticed that where a lot of tutorials/guides were able to directly use #include "ProceduralContentModule.h", I had to write out the full path ( #include "../Public/ProceduralContentModule.h"). I read that Unreal uses a different build tool which knows to look in the Public folder for includes, but I could not manage to get it to do that. A lot of the suggestions I’ve read seem to mention that regenerating project files can help with things like this, but that batch file is with the engine source code and doesn’t appear to do anything for my game projects.

That’s one thing. Another issue for me is creating new code files. I notice that if I add a class from within the editor, it will automatically include a .generated.h file. However, since I expect to be doing a lot of C++ code, especially in the ProceduralContent module (and I’m not even sure if the editor can add classes to modules that are not the main game module), it doesn’t seem practical to me to have to run the project to get to the editor, add a new class, stop debugging and then begin editing it. In other words, what is the workflow for C++ code if you expect to be working from Visual Studio mainly (at least for a while)?

And finally, as I mentioned, I want to start writing custom mesh classes that take care of creating their geometry procedurally. I noticed there is a “CustomMeshComponent” plugin, but I could not get this included in my project. I know there is a wiki page that bypasses this plugin and basically recreates the custom mesh component, but where possible, I’d like to use engine code because i’ll probably be better supported and improved in the future. I then read up on the philosophy behind plugins and became even more confused. Apparently your game is not supposed to “depend” on plugins, but then how could you ever use something like CustomMeshComponent in your game?

I guess I’m also asking what the best way to go about this procedural content is. Should I continue looking into the CustomMeshComponent as a viable solution, given the way I’m setting things up, or should I follow the wiki article on procedural mesh generation and roll my own custom mesh component class?

Thanks for any and all answers. And again, apologies for the wall of text!

I can try and answer some of your general questions about modules.

Unfortunately adding new modules is currently a very manual process. I wrote a small “how to” for adding a new editor module, and the process for a runtime module (like the one you added) is very similar. What is the proper method for extending the Editor Engine? - C++ - Epic Developer Community Forums

There’s some more information about the source code layout used by UBT here: Explanation of Source Code folder structure? - C++ - Epic Developer Community Forums

The class wizard in the editor is (as of 4.4) able to add code to any module referenced by your .uproject file.

You shouldn’t need to mess with the Visual Studio solution. Providing your module is referenced by your .Target.cs file (see my previous links), you should just need to re-generate your solution and it will be updated as appropriate (you right click on your .uproject file and choose “Generate Visual Studio project files”. If this option isn’t available, then make sure you’ve run UnrealVersionSelector.exe for the UE4 build you made - UE4/Engine/Binaries/Win64).

Thanks so much for the UnrealVersionSelector suggestion; I must’ve missed that. I feel pretty comfortable with custom modules then, being able to regenerate project files correctly has fixed the include path problem and I suspect will also alleviate the pain of manually syncing folders with the filters in the project!

Still one question about the class wizard though. I’ve compiled engine version 4.4, but there doesn’t seem to be module selector in the class wizard. Currently I put the newly created files into the correct folder by specifying the full path for the .h and .cpp files (the class wizard then asks if i want to create them in that directory). Is that correct?

Are you using latest from the 4.4 branch? If so, you should see a combo box next to the name field in the class wizard.

To make sure, I recompiled the engine after checking that I was indeed in the 4.4 branch (and pulling, but nothing new). This is the class wizard for me:
[class wizard][1]

Ah, sorry, I meant the class wizard in the editor (“Add Code to Project”).

Ah cool, yes, it allows me to select the module there. So that’s the preferred way of working then, for now? Whenever you need to add a new C++ class you build & run and then add the new class from the editor?

If you’re comfortable enough to add classes directly to your code, then you don’t need to use the class wizard in the editor (but it is handy to make sure you get your includes/dependencies correct). Your call :slight_smile:

We are working on improving the hot-reload support though, so you’d be able to add a new class from the editor, and then it would rebuild and reload the module without you having to restart the editor :slight_smile:

Perfect, just takes a bit more planning upfront if I want to create multiple classes to make sure I add them all in one go :slight_smile: Thanks for the help.

Hi Jamie … trying to follow your example for adding a custom module as OP, however its unclear what TargetType to use in the Target file for the new module and what to use in the Module section of the .uproject file.

I am using new 4.5 engine, if I follow instructions exactly for Editor example but use TargetType.Game for my custom module (as its not an Editor) UnrealBuildTool complains when generating the project files

UnrealBuildTool Exception: ERROR: Not expecting project Intermediate\ProjectFiles\Sandbox1.vcxproj to already have a target rules of with configuration name RocketGame (GameFrameworkTarget) while trying to add: Sandbox1Target

(Sandbox1 is Unreal project and GameFramework is module Im trying to add for reusable code)

I’ve answered your other question: Adding Custom Module to UE4 Project - Programming & Scripting - Epic Developer Community Forums

We can follow this up there.