This is really good video. Thank you so much. Bering trying to follow the same process for a Custom Plug-in that uses third party libraries. Although having problems at the moment since is not finding the correct files 😢
This video will help me a lot in trying to get an external library such as opencv to work as a plugin inside UE5. I'm almost there, but need a little help. Would I get any tips in the Discord ? Many thanks, b
Thanks for tutorial! I think a great tutorial you could do in addition to this is showing how you might go about converting an existing project with all classes inside the primary module into separate modules. I'm in that process right now. Say I have a MainMenu module I want to implement, but there's some classes it uses that will also be used by other modules (for example a Pause Menu that shares the same SettingsMenu class). Should those classes be put inside their own separate module as well, maybe a module named MenuComponents?
@@markoleptic4501 So id keep related things together. In your case you have a menu system so its probably wise to keep them all together in the same module
Good tutorial, but honestly, I'm not sure if I'll keep creating my own gameplay modules. I was creating so that it can be reused and I separated quite a few gameplay modules for my game. There are some annoying downsides to it such as: 1- It's a bit annoying to add a single module (even if it's simple) to the 'game module'; 2- It's harder to keep your single module dependency separate from the other modules; I'm seriously thinking to refactor and get rid of my gameplay modules. Good thing I'm not far ahead in my project, I'm not at the beginning either, but if I'm going to get rid of them, I shall better do it sooner than later. Please, don't get me wrong I can see why they can be useful, but honestly for my game, since I don't really plan to sell separate parts of my code, I'll probably keep most stuff inside my GAME MODULE. Unless I find opportunities to create a separate logic that could be reused on other projects, such as Save System, Mission System and whatnot.
Agreed on #1, thankfully rider has the option to add an unreal module so it's doable in seconds. Unfortunately that means it's behind a paywall. For #2 I believe that is the point. It requires additional thought to keep features separate and make more portable code as a result that is typically harder to break when you need to refactor something. It also depends on how you use it. For example I'm rebuilding Nazi Zombies (again). Currently I have 4 modules, 2 of which need to communicate (BaseGameModule and Buyables) which is done by an interfaces module: AbilitySystemCore which contains a complete setup with a custom ability system component, ability, and enhanced input component to make using GAS drastically easier and I can bring this module into any GAS project and start using it. Buyables which contains a base actor for barricades, wall weapons, mysterybox, and corresponding data assets to define them such as what mesh, decal, class, etc they use. Interfaces which contains various interfaces to allow for communication. In this example I have a InteractInterface, the Buyables module depends on this interfaces module and they implement the Interact Interface. BaseGameModule which is the one created via the project. It depends on the Interfaces module and has my pawn, player state, controller, interaction component, all that in it. When I walkup to a barricade it checks for if I'm looking at something that both blocks the collision channel I set and if it implements the Interaction interface, if it does then it will call GetInteractString and broadcast it (UI is bound to this event) and display the given message on screen. Likewise if I want to interact with the barricade to buy it I just call Interact on it which is a part of the interface and the barricade handles it's own logic. In the Buyables and Interfaces example, imo there would be nothing wrong with discarding the interfaces module and implementing the logic only in the Buyables module for GetInteractString and Interact. Then make a child class of them which implements a interface in your BaseGameModule that simply return/call the already written functions on the parent. But yea if your early on in the project, nows definitely the time to make that call lol.
Hey SneakyKitty, I notice the Kantan DocGen module in your folder structure. Have you gotten it working in UE 5? Does it document blueprint well enough for you? Now THAT would be a video I would pay for.
Havent tested it in UE5, but it does generate it good enough for my use cases. I need to generate documentation at some point in the coming months so I'll be giving it a go again and hopefully can make it work. If so I'll try and record a video on it
I recommend standard modules for key parts of your game. For example lets say your making something like a door system thats intended to be used throughout your game, that imo makes sense for a normal module. Now lets say you want a feature thats only active during the winter and your game is a hunting game. When winter rolls around you want to turn all the deer into reindeer and occasionally spawn a santa running around the woods. Imo that makes sense for a game feature module so you can turn it on/off as needed (ie winter time)
Thanks for the explanation! Do you think that choosing a class in an RPG game is applicable for GFM? Also thanks for making these series! There are so many concepts in UE that aren't fully covered in docs so I appreciate any and all that youre willing to make videos about. For example I just saw in Lyra and Ancients that they use a PawnComponent for player controls and that isn't discussed anywhere online or in tutorials
@@onx2rj If you have plans to at some point disable that class then that might be a good idea. Np, I'll need to look into that as I've been wanting to figure out a good way to handling inputs
Hi what would a process of turning on engine plugins using a custom plugin in unreal engine c++ look like? Could you talk me through it I am having a hard time wrapping my head around it. Also would it be better to use modules for this instead of a plugin workflow? Thanks for sharing your knowledge it is very valuable.
Is there an option to disable module in shipping build? I found "IncludelistTargetConfigurations / ExcludelistTargetConfigurations (array)" and I put it in .uprojet file inside module configuration but it doesn't work for some reason
It is itself but it doesnt recognize itself if that makes sense, its kinda weird. Its like trying to include niagra headers without adding Niagara to your build.cs
A bit late to this but I did all these things and I can create a class belonging to the module but I can't actually see the module folder in the content drawer?
So with modules you do not have an actual content folder for assets if thats what you are asking. If thats something you want then Plugins are better suited. Regardless you should see a C++ folder in your content browser which contains your modules classes. If you dont see it, try deleting your binaries and intermediates folders and regenerating project files and confirming that the module is active in the .uproject
It is good to use Modules for game-specific stuff but I find it too much effort to do. I may try it again. Currently, I usually make a Plugin for anything that isn't tied to the game itself and could potentially be reused in another project, coz then I can easily add it to any other project.
It's not much effort. Create a folder, copy/paste files, add a few lines and you have a module. I use the plugin workflow often as well if its something I'll consider selling later on. I kind of want to make a video on the differences between gameplay modules and plugins. The main thing I like about plugins is you can have content with it if you need it where as modules are just the core classes. Both have their place. Either way features should be in one or the other lol
@@SneakyKittyGameDev A discussion on plugin vs modules would make a great topic. I recently moved to putting 95% of my game code into plugins based on the functionality. A plugin for generic non-game/genre specific stuff, another for character features, another for adding interactions, another for all save/database related function. Given it's mostly C++ they may be better off as modules...
They do the same thing differently. Two main reasons for using a plugin would be 1: If your building something that may contain content then use a plugin. 2: If your module is going to be distributed to people that don't know how to compile or are using a blueprint only project then use a plugin as it can be compiled and have its binaries created so those users can just plop it in and go.
Its simple once you do it a time or two as it will take 1-2 minutes to setup once you learn it. Its like learning classes, difficult at first, second nature after making a few of them
@@SneakyKittyGameDev I am trying to get a 3rd party library implemented. So it is required. I *think* I have it but I think I need to understand game instance subsystems first so I can get to a place where I can implement the 3rd party library. I have a External module, which has a lib and include directory. In the Build.cs I set it to Type = ModuleType.External; Added the include folder with PublicIncludePaths; Added the binary with PublicAdditionalLibraries; and created a new module which depends on the 3rd party library Module in PrivateDependencyModules (because nothing else but this module should touch it). Does it sound like I am on track?
@@meerkatpowergaming9412 Yea I'd say your on the right path. I've seen some other plugins (that require their own libraries prebuilt to use in multiple game engines easily) follow a similar suite and it seems like a fairly clean approach
@@SneakyKittyGameDev I attempted to do it and was successful. Yeah its pretty clean. You basically have one module as the "container" then have another which depends on it. I couldn't get the native library ws2_ws.dll or whatever websocks2 is to load, giving me missing syms so I had to scrap. I am using FSocket and ISocketSubsystem, which has been very annoying because Unreal has an extreme lack of example usage code and shit that dates back to unreal 4. Not to mention sockets and ambiguized by the modeling term sockets.
This is really good video. Thank you so much. Bering trying to follow the same process for a Custom Plug-in that uses third party libraries. Although having problems at the moment since is not finding the correct files 😢
by any chance are you trying to integrate opencv as the custom library ?
All the best
This video will help me a lot in trying to get an external library such as opencv to work as a plugin inside UE5.
I'm almost there, but need a little help. Would I get any tips in the Discord ?
Many thanks,
b
Thanks for tutorial! I think a great tutorial you could do in addition to this is showing how you might go about converting an existing project with all classes inside the primary module into separate modules. I'm in that process right now. Say I have a MainMenu module I want to implement, but there's some classes it uses that will also be used by other modules (for example a Pause Menu that shares the same SettingsMenu class). Should those classes be put inside their own separate module as well, maybe a module named MenuComponents?
Oh boy, read up on redirectors lol. Did that for my entire plugin and without redirectors fixing the blueprints it would of been a nightmare
@@SneakyKittyGameDev Will do! Do you think separating the modules like I discussed is good practice?
@@markoleptic4501 So id keep related things together. In your case you have a menu system so its probably wise to keep them all together in the same module
Good tutorial, but honestly, I'm not sure if I'll keep creating my own gameplay modules. I was creating so that it can be reused and I separated quite a few gameplay modules for my game.
There are some annoying downsides to it such as:
1- It's a bit annoying to add a single module (even if it's simple) to the 'game module';
2- It's harder to keep your single module dependency separate from the other modules;
I'm seriously thinking to refactor and get rid of my gameplay modules. Good thing I'm not far ahead in my project, I'm not at the beginning either, but if I'm going to get rid of them, I shall better do it sooner than later.
Please, don't get me wrong I can see why they can be useful, but honestly for my game, since I don't really plan to sell separate parts of my code, I'll probably keep most stuff inside my GAME MODULE. Unless I find opportunities to create a separate logic that could be reused on other projects, such as Save System, Mission System and whatnot.
Agreed on #1, thankfully rider has the option to add an unreal module so it's doable in seconds. Unfortunately that means it's behind a paywall. For #2 I believe that is the point. It requires additional thought to keep features separate and make more portable code as a result that is typically harder to break when you need to refactor something. It also depends on how you use it. For example I'm rebuilding Nazi Zombies (again). Currently I have 4 modules, 2 of which need to communicate (BaseGameModule and Buyables) which is done by an interfaces module:
AbilitySystemCore which contains a complete setup with a custom ability system component, ability, and enhanced input component to make using GAS drastically easier and I can bring this module into any GAS project and start using it.
Buyables which contains a base actor for barricades, wall weapons, mysterybox, and corresponding data assets to define them such as what mesh, decal, class, etc they use.
Interfaces which contains various interfaces to allow for communication. In this example I have a InteractInterface, the Buyables module depends on this interfaces module and they implement the Interact Interface.
BaseGameModule which is the one created via the project. It depends on the Interfaces module and has my pawn, player state, controller, interaction component, all that in it. When I walkup to a barricade it checks for if I'm looking at something that both blocks the collision channel I set and if it implements the Interaction interface, if it does then it will call GetInteractString and broadcast it (UI is bound to this event) and display the given message on screen. Likewise if I want to interact with the barricade to buy it I just call Interact on it which is a part of the interface and the barricade handles it's own logic.
In the Buyables and Interfaces example, imo there would be nothing wrong with discarding the interfaces module and implementing the logic only in the Buyables module for GetInteractString and Interact. Then make a child class of them which implements a interface in your BaseGameModule that simply return/call the already written functions on the parent. But yea if your early on in the project, nows definitely the time to make that call lol.
Hey SneakyKitty, I notice the Kantan DocGen module in your folder structure. Have you gotten it working in UE 5? Does it document blueprint well enough for you? Now THAT would be a video I would pay for.
Havent tested it in UE5, but it does generate it good enough for my use cases. I need to generate documentation at some point in the coming months so I'll be giving it a go again and hopefully can make it work. If so I'll try and record a video on it
When would you recommend a standard module like this vs. the Game Feature Module?
I recommend standard modules for key parts of your game. For example lets say your making something like a door system thats intended to be used throughout your game, that imo makes sense for a normal module. Now lets say you want a feature thats only active during the winter and your game is a hunting game. When winter rolls around you want to turn all the deer into reindeer and occasionally spawn a santa running around the woods. Imo that makes sense for a game feature module so you can turn it on/off as needed (ie winter time)
Thanks for the explanation! Do you think that choosing a class in an RPG game is applicable for GFM?
Also thanks for making these series! There are so many concepts in UE that aren't fully covered in docs so I appreciate any and all that youre willing to make videos about. For example I just saw in Lyra and Ancients that they use a PawnComponent for player controls and that isn't discussed anywhere online or in tutorials
@@onx2rj If you have plans to at some point disable that class then that might be a good idea. Np, I'll need to look into that as I've been wanting to figure out a good way to handling inputs
Hi what would a process of turning on engine plugins using a custom plugin in unreal engine c++ look like? Could you talk me through it I am having a hard time wrapping my head around it. Also would it be better to use modules for this instead of a plugin workflow? Thanks for sharing your knowledge it is very valuable.
Are you referring to making your plugin dependent on an engine module? and having your plugin automatically turn it on?
Is there an option to disable module in shipping build? I found "IncludelistTargetConfigurations / ExcludelistTargetConfigurations (array)" and I put it in .uprojet file inside module configuration but it doesn't work for some reason
at 6:27 why did you add "CustomDoor" to public dependencies array. isnt it already itself
It is itself but it doesnt recognize itself if that makes sense, its kinda weird. Its like trying to include niagra headers without adding Niagara to your build.cs
@@SneakyKittyGameDev i think there is something wrong with it. after i try it, i will inform from here
Yes. I think it is better added in the project.build.cs public dependencies chain.
👍👍👍
A bit late to this but I did all these things and I can create a class belonging to the module but I can't actually see the module folder in the content drawer?
So with modules you do not have an actual content folder for assets if thats what you are asking. If thats something you want then Plugins are better suited. Regardless you should see a C++ folder in your content browser which contains your modules classes. If you dont see it, try deleting your binaries and intermediates folders and regenerating project files and confirming that the module is active in the .uproject
It is good to use Modules for game-specific stuff but I find it too much effort to do. I may try it again. Currently, I usually make a Plugin for anything that isn't tied to the game itself and could potentially be reused in another project, coz then I can easily add it to any other project.
It's not much effort. Create a folder, copy/paste files, add a few lines and you have a module. I use the plugin workflow often as well if its something I'll consider selling later on. I kind of want to make a video on the differences between gameplay modules and plugins. The main thing I like about plugins is you can have content with it if you need it where as modules are just the core classes. Both have their place. Either way features should be in one or the other lol
@@SneakyKittyGameDev A discussion on plugin vs modules would make a great topic. I recently moved to putting 95% of my game code into plugins based on the functionality. A plugin for generic non-game/genre specific stuff, another for character features, another for adding interactions, another for all save/database related function. Given it's mostly C++ they may be better off as modules...
Why not use a plugin instead of a module since it does the same thing anyways
They do the same thing differently. Two main reasons for using a plugin would be
1: If your building something that may contain content then use a plugin.
2: If your module is going to be distributed to people that don't know how to compile or are using a blueprint only project then use a plugin as it can be compiled and have its binaries created so those users can just plop it in and go.
@@SneakyKittyGameDev plugin it is then. I know how to use them and so do my team members
That is a lot of manual effort for something so simple.
Its simple once you do it a time or two as it will take 1-2 minutes to setup once you learn it. Its like learning classes, difficult at first, second nature after making a few of them
@@SneakyKittyGameDev I am trying to get a 3rd party library implemented. So it is required. I *think* I have it but I think I need to understand game instance subsystems first so I can get to a place where I can implement the 3rd party library. I have a External module, which has a lib and include directory. In the Build.cs I set it to Type = ModuleType.External; Added the include folder with PublicIncludePaths; Added the binary with PublicAdditionalLibraries; and created a new module which depends on the 3rd party library Module in PrivateDependencyModules (because nothing else but this module should touch it). Does it sound like I am on track?
@@meerkatpowergaming9412 Yea I'd say your on the right path. I've seen some other plugins (that require their own libraries prebuilt to use in multiple game engines easily) follow a similar suite and it seems like a fairly clean approach
@@SneakyKittyGameDev I attempted to do it and was successful. Yeah its pretty clean. You basically have one module as the "container" then have another which depends on it. I couldn't get the native library ws2_ws.dll or whatever websocks2 is to load, giving me missing syms so I had to scrap. I am using FSocket and ISocketSubsystem, which has been very annoying because Unreal has an extreme lack of example usage code and shit that dates back to unreal 4. Not to mention sockets and ambiguized by the modeling term sockets.