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
