Hi everyone,
I am thinking about to structure an upcoming Project in a more generalized way so we can reuse as much code as easy as possible, but i want to make sure that there aren’t any major downsides.
The idea is to bundle different functionality sections into separate Plugins, so we can reuse single plugins on other side Project or replace them with another Plugin.
What are the downsides of using this kind of approach ?
Thanks a lot !
Cheers
Dominic
The only downside I can think of is if you’re a ‘hot-reload addict’… then you’ll hit a few issues down the road.
Apart from that there’s only benefits of taking the approach you mention;
For indies and small studios, the more code you can reuse on next projects, the better for everyone. And plugins are a key factor to achieve that.
The more modularity, the better, if something breaks on a new engine release it will not affect other parts. Keep it simple and modular, thats the key.
There is no support for the hierarchical dependence of plug-ins when your plug-in should depend on another plug-in.
.h files can be connected, but there are problems with compilation.
There are no performance problems specific to plugins (it literally has no relevance), nor is there any issue with plugins depending on other plugins, unless you’re trying to setup mutual dependencies which you shouldn’t be doing anyway.
The thing to realize is that UE4 plugins are not actually plugins in the normal sense at all. They’re just loose collections of code modules and/or assets, with a very small amount of extra built-in engine support for dealing with them. You can set up static dependencies on modules in plugins exactly the same as if the modules were in your game project; making them technically libraries, not plugins. And when packaging, their modules get directly linked in to the executable just like any other module.
So yeah, go for it. Aside from what Bruno mentions, I know of no reason not to use plugins for anything that you may want to reuse at some point down the line.
Thank you for all these useful information.
Actually i am a Hot Reload addict and even prefer Blueprints over C++ where ever it make sense because of this reason, but i also try to always find the best way to structure things without my personal preferences involved.
@kamrann i read through your Website Blog, thanks for writing these things down ! Are there any pros and cons when it comes to Plugins vs. Modules ? (for shipping code)
@PrHangs It’s really not a case of one vs the other. Plugins contain modules; they can contain assets too if wanted, I think they now have support for shaders, and hopefully will get config files eventually too.
If you have something that is and always will be just some code you want to reuse, then yeah you could simply make a module and then reuse it in multiple places. I’ve done this using git submodules on occasion. Fundamentally though there isn’t really much difference between doing that, and sticking a uplugin file along with it and including it as a project-level plugin.
https://docs.unrealengine.com/latest…#codeinplugins
“as we do not currently intend to support plugins that are directly dependent on other plugins”
dependence of the plug-in from another plug-in is possible, just with it there may be problems
That is old docs page.
Engine changes a lot, but old docs are still the same.
I’ve separated a lot of my code into Plugins, and plugin dependencies do work. Works really well. The idea is that I can easily reuse code across multiple projects and write more flexible code.
Had zero problems with Hot Reload and Plugins, but I only ever hot reload if modifying .cpp files.
I finally had some time Testing Modules and Plugins.
With Plugins its super easy, you just use the wizard in the engine and you can copy paste it in another Project and it just works. Hot reloading wasn’t working at all for me, I only changed things in the .cpp file.
@TheJamsh have you noticed any limitations on Hot Reload with Plugins ? Or do i have to do anything special to make hot reaload work ?
The Module was also easy to create and copy into another Project, but you need to register it in the .uproject and .Target.cs. Also hot reloading was not working at all.
If its true that Plugins have no downsides compared to modules i think they are easier to use and are more flexible(can contain Content and so on).
It’s hard to say to be honest - but HR works for me in my plugin-heavy project. I’m still using PCH’s in that project though, perhaps in newer versions of the engine it doesn’t use them anymore? I know some stuff regarding PCH wasn’t working in earlier builds.
@TheJamsh By default the Plugin uses the normal Header, what i have to do to use precompiled headers ?
What also kind of works is: in the editor go to Window->DeveloperTools->Modules and Recompile from there, but it will break as soon as you compile in VS.
I think there’s a new flag in the Build.Cs file for each module - but I can’t remember what it is. It was added in either 4.17 or 4.18
When your current project uses a feature inside the plugin, depending on how this feature is used, the Loading Phase attribute must be set properly, so the engine knows the priority and at each step during editor or engine inicialization the plugin must be loaded, and also what to disconnect when hot reloading. Thats just theory of course, problems might occur if the plugin’s code is not working properly and prevent the loading.
While developing the code keep it as module and once finished make it a plugin.