Show Posts
1
General Discussion / Re: I hope to God Brickadia is not most Blockland players choice as a successor
« on: January 19, 2022, 10:16:02 AM »
I thought this thread kinda died after I posted so I haven't checked in a bit 
.
We already are using Unreal's "modding framework" (aka the asset system, PAK files) for everything in Brickadia. How we add content and a modder adds content is identical: You cook a PAK/IOStore file (whether that is with the Brickadia Unreal Editor or however you produce it) and have the game load that at runtime. Basically everything (except C++ additions) we've created are already using the same tools you would use to make your mods. Most UE4 games have absolutely garbage editors, I agree. I don't know how the forget they are able to work on their games if their mod editor is that bad, this is certainly not the case with Brickadia. There are a huge number of modules and things that modders will probably never touch, so we can make the editor much lighter. In its current state, the Brickadia editor loads miles faster than the editor we use at work, so some work has already been done there.
One of the differences in making Brickadia mods though is that you use Behaviors for logic/code rather than make it in a blueprint/c++ mod. Mods will mostly be for adding content (bricks, weapons models, maps, things that are nice to use the editor for). We do plan on moving a ton of things to Behaviors as it becomes more developed, currently we are transitioning our components system. Behaviors in design are very similar to components in Unity/Unreal/ROBLOX, where they can add functionality to bricks, players, items, minigames, the server, etc.
Yes it is possible, but there are some differences due to licensing.
UE3 and UE4 are very similar in their modding tools (with the exception of UnrealScript being replaced by Blueprints, but they run on the same VM and do the same things). The major difference is in licensing, you needed to buy a fairly expensive license to use UE3. With that, you could distribute the editor and game together, which is why a lot of UE3 games can have their editor on Steam or bundled with the game itself.
UE4 changed the license quite a bit, making it easier to access but at the cost of restricting where you can distribute the editor (Github or Epic Games Marketplace). This license also means that the editor and the game code must be seperate, so we cannot copy/paste the editor's implementation of importing static meshes into the game for example and add hot-loading static meshes in a day. There are plugins that add runtime import for those things, but the main flaw with them is that they load from a format that is useful for storing everything about that asset (for example, an FBX file stores an ENTIRE scene), so the real solution is to actually create an optimized PAK/IOStore file that the game can load, which Unreal will happily do so at runtime.
Our goal is to reduce the need for the UE4 editor whenever possible / we have the resources to do so, which is why Behaviors has grown in scope a lot. Personally, I would love to trash the whole editor and just have everything done in-game, but there are a lot of things the editor does that optimizes PAK/IOStore files that we would have to recreate. Keep in mind that the engine/editor is easily several million lines of code, that's not possible for a small dev team to just throw away. s&box (when it was on UE4) also did away with the editor and recreated many things by themselves. In about 2-3 years of (full-time) work, they were able to add static mesh and skeletal mesh and hot-loading shaders/material graph, all still using Unreal's asset system (they create an optimized PAK file that the game loads at runtime). That's a tiny fraction of what the Unreal editor can do, but honestly that's probably enough for 90% of mods!
The great part about us using Unreal's asset system is that you could replace the editor at any time along development and cook PAK files yourself that the game recognizes and loads, though it's not a focus since it would be a huge endeavor to replace the editor. It's such a huge endeavor that even game engine games like CORE (which is also built on Unreal) also haven't done this, even though they have the resources to do so. They've just went with the "kit-bashing" approach like old school Roblox.
We do want something like Steam Workshop, but since our goal is to put Brickadia on our website and any storefront we can put it on, we plan on making our own version of it called the gallery.
As mentioned earlier, the scripting language in UE3/4 basically use the same underlying system and are equally as capable. UnrealVerse is something we are looking forward to, but not because it changes anything about modding but because we can finally trash Blueprints. The main thing we are looking to see with Fortnite modding how Epic supports loading/unloading PAK files at runtime. Loading is easy, but unloading is a lot more difficult because we also have to cleanup any references to those mods being unloaded (A very difficult problem). Behaviors is the scripting language we are developing to replace the need for blueprint/code mods essentially.
While we are working to make Behaviors easy to learn, it's still a scripting language even if you can use it visually. We are working on the wires system, which is much simpler to use.
ue4 c++ reflection go brrr
Context: The game we collabed with was developed by Pandan, who we've been friends with for a long time and is also a long time Blocklander. Not sure what the issue is.
.im no game developer, but most games "mod support" is are like frameworks that the developer themselves create (the modding capability is not something built into the engine) that allows content to be loaded into the game externally. for every itsy bitsy little thing they wanted to be 'moddable' they would have to make its own framework for. things that replace assets like player models, textures, sounds, ect. or even stuff like custom maps. are simple frameworks to make. that means easy modding capability those games have is only in the span of whatever framework the devs decide to create. to get brickadia to be even closely as moddable as blockland there would have to be some sort of quote unquote framework for literally everything in the game, as blockland was created on an engine that was created to BE moddable all around, requiring no framework to be made (well, sorta).
generally speaking, games made with mod support in mind from the start will basically make their game with the mod framework, or depending on exactly how you go about things, you just make your internal developer tools public. you don't have to create additional APIs for modders afterwards, because you already made them for your base game. this is more true with sandbox games than it is anywhere else, and blockland is a great example, because the base game's guns, vehicles, maps, prints, etc. are all literally just add-ons to begin with. everything else is the engine itself, which is not really relevant to your potential mod creators
with source for example, the hammer editor you use to make gmod maps is the same as the hammer editor valve used to make the maps for all of their source games. the APIs you use when you're making mods for source games (not including gmod's lua stuff which is a different thing) are the same ones they used. the source SDK is basically just their tools that they used, made public. same thing with bethesda's dev tools for TES and fallout games
We already are using Unreal's "modding framework" (aka the asset system, PAK files) for everything in Brickadia. How we add content and a modder adds content is identical: You cook a PAK/IOStore file (whether that is with the Brickadia Unreal Editor or however you produce it) and have the game load that at runtime. Basically everything (except C++ additions) we've created are already using the same tools you would use to make your mods. Most UE4 games have absolutely garbage editors, I agree. I don't know how the forget they are able to work on their games if their mod editor is that bad, this is certainly not the case with Brickadia. There are a huge number of modules and things that modders will probably never touch, so we can make the editor much lighter. In its current state, the Brickadia editor loads miles faster than the editor we use at work, so some work has already been done there.
One of the differences in making Brickadia mods though is that you use Behaviors for logic/code rather than make it in a blueprint/c++ mod. Mods will mostly be for adding content (bricks, weapons models, maps, things that are nice to use the editor for). We do plan on moving a ton of things to Behaviors as it becomes more developed, currently we are transitioning our components system. Behaviors in design are very similar to components in Unity/Unreal/ROBLOX, where they can add functionality to bricks, players, items, minigames, the server, etc.
i can't say i know a whole lot about unreal, but A Hat in Time is on UE3 and has mod support with a steam workshop, so in theory this would be possible for Brickadia too? or is hat game some weird exception?
UE3 is quite different, it's the last UE to support UnrealScript
Yes it is possible, but there are some differences due to licensing.
UE3 and UE4 are very similar in their modding tools (with the exception of UnrealScript being replaced by Blueprints, but they run on the same VM and do the same things). The major difference is in licensing, you needed to buy a fairly expensive license to use UE3. With that, you could distribute the editor and game together, which is why a lot of UE3 games can have their editor on Steam or bundled with the game itself.
UE4 changed the license quite a bit, making it easier to access but at the cost of restricting where you can distribute the editor (Github or Epic Games Marketplace). This license also means that the editor and the game code must be seperate, so we cannot copy/paste the editor's implementation of importing static meshes into the game for example and add hot-loading static meshes in a day. There are plugins that add runtime import for those things, but the main flaw with them is that they load from a format that is useful for storing everything about that asset (for example, an FBX file stores an ENTIRE scene), so the real solution is to actually create an optimized PAK/IOStore file that the game can load, which Unreal will happily do so at runtime.
Our goal is to reduce the need for the UE4 editor whenever possible / we have the resources to do so, which is why Behaviors has grown in scope a lot. Personally, I would love to trash the whole editor and just have everything done in-game, but there are a lot of things the editor does that optimizes PAK/IOStore files that we would have to recreate. Keep in mind that the engine/editor is easily several million lines of code, that's not possible for a small dev team to just throw away. s&box (when it was on UE4) also did away with the editor and recreated many things by themselves. In about 2-3 years of (full-time) work, they were able to add static mesh and skeletal mesh and hot-loading shaders/material graph, all still using Unreal's asset system (they create an optimized PAK file that the game loads at runtime). That's a tiny fraction of what the Unreal editor can do, but honestly that's probably enough for 90% of mods!
The great part about us using Unreal's asset system is that you could replace the editor at any time along development and cook PAK files yourself that the game recognizes and loads, though it's not a focus since it would be a huge endeavor to replace the editor. It's such a huge endeavor that even game engine games like CORE (which is also built on Unreal) also haven't done this, even though they have the resources to do so. They've just went with the "kit-bashing" approach like old school Roblox.
We do want something like Steam Workshop, but since our goal is to put Brickadia on our website and any storefront we can put it on, we plan on making our own version of it called the gallery.
its been said publicly in the br discord theyre holding out for the return of uescript in ue5 before deciding whether or not to commit to writing their own mod support, so the return of uescript could help a lot in making br particularly moddable
As mentioned earlier, the scripting language in UE3/4 basically use the same underlying system and are equally as capable. UnrealVerse is something we are looking forward to, but not because it changes anything about modding but because we can finally trash Blueprints. The main thing we are looking to see with Fortnite modding how Epic supports loading/unloading PAK files at runtime. Loading is easy, but unloading is a lot more difficult because we also have to cleanup any references to those mods being unloaded (A very difficult problem). Behaviors is the scripting language we are developing to replace the need for blueprint/code mods essentially.
m8 I ain't trying to learn how to program, I just want to forget around on a lego game. Having an event system like this is off-putting to me.
While we are working to make Behaviors easy to learn, it's still a scripting language even if you can use it visually. We are working on the wires system, which is much simpler to use.
unity c# reflection go brrr
ue4 c++ reflection go brrr
game is already having collabs lol, i guess the game is going down the yandere sim route
*in Yoda voice* Surprised by this are we?
Context: The game we collabed with was developed by Pandan, who we've been friends with for a long time and is also a long time Blocklander. Not sure what the issue is.
