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!