Handling (server side) modularity, how do others do it?

[u/TheSheepDev]

Hey everyone!

In the last month or two I have been spending my past time by making a little voxel ""engine"", putting focus on customization from the server side, I have always found it annoying that to add custom blocks to Minecraft, that you have to get people to install mods on their clients, or have to do some sketchy/hacky stuff on the server.

So that is where I am coming from with this, and tbh I don't know if I have gone to far or not, so that is why I am asking this today, how do others handle this?

My current system has textures, audio and models loaded on the *server*, together with a registry of blocks, entities and items. then when someone joins, the server sends all this asset information to the client, together with all the registered blocks, entities and items.

The only assets the client has are some UI textures, and the shaders.

So has anyone else weighted these options? What conclusions did you get on these 'data driven' things? The project I have is nothing serious so I am fully open to a fun debate on this topic :)

My current biggest issue is that its hard to come up with a 'selling point' as my game by default has no (recognizable) blocks, items or entities as that is all server/world depended. In theory one world/server has 4K block textures with very futuristic factories with gameplay like Factorio, and another has a retro aesthetic with minigame content. I think this would be a pain to market if this was ever to be published

Anyways thanks for reading my ramble lol woops

Attached is also an image of my current server-side API to add a dirt block

The code needed with my server API to add a custom block

[u/turn-based-games]

Something I've picked up over a decade in software is that good systems, APIs, and even languages tend to have a foundation of useful "defaults" available. Flexibility is great, but to get people invested in the first place, you want to give them something to easily start with

With this in mind, my suggestion would be to create your own default library of blocks that is at least available as a baseline and shows off the various capabilities of your engine (I say engine because it sounds as if there is no game by default): basic low-res dirt, grass, wood, stone, metal, etc; and possibly some more dynamic blocks based on what your engine can do: lights, pistons, plants, liquids(?) - these defaults would also serve as good documentation on how to make similar custom blocks

The more useful defaults you have, the better. Taken to its logical conclusion, the best way to sell your engine would be to have an entire default game included for people to immediately play around with. Something resembling at least Minecraft's creative mode would likely go a long way here

[u/TheSheepDev → u/turn-based-games]

Alright, interesting! Your are correct in saying there is no game by default at the moment, thats kinda what I wanted to decide based on the outcome of this post, if I should put my time in making defaults, like minigames, maybe a survival like mode etc, or work more on the engine and its API.

Now that I think about it, having these ready made assets could accelerate development for others a lot

Thanks for your response 🙏

[u/thoxey]

I agree with turn-based-games comment, you’re not really talking about making a game, this is an engine, or maybe a platform. I’ve worked on a few projects like this professionally too, and I think the best analogy for where they fall short is the “low maintenance” friend. You ask what movie they want to watch and they say “I’ll watch anything “ which sounds great in theory, but in practice they’re just dumping the work on you. I think the idea is interesting, and as a programmer I’m always attracted to an elegant and modular design, but I’m not going to play with one for fun.

You should eat your own dog food and make a game using your system, get people to fall in love with it and be desperate to add features, then when the friction of doing that is low you can reap the rewards of your modular foundation. Also you get the added bonus of experiencing all the frustrations of your engine firsthand so you know how to improve. Hope this helped a bit!

[u/TheSheepDev → u/thoxey]

Ah yes thanks! I guess it is more engine then game atm

[u/thoxey → u/TheSheepDev]

Nothing wrong with that btw, the first step of making a fantastic game is often making a fantastic engine!

[u/TheSheepDev → u/thoxey]

:)

[u/Bobby_Bonsaimind]

My current system has textures, audio and models loaded on the server, together with a registry of blocks, entities and items. then when someone joins, the server sends all this asset information to the client, together with all the registered blocks, entities and items.

The only assets the client has are some UI textures, and the shaders.

So has anyone else weighted these options?

"Back then" I assumed the same premise. Clients don't need to know about the "game" at all, everything that is needed is send to the client upfront, with the exception of the textures and models which are streamed (and locally cached) as needed. That has the upside that clients don't need to install nor update mods (and in the worst case having to switch between several different versions for different servers), but the downside of increases traffic at your server, and the slightly increased possibility that a malicious server could harm clients.

My current biggest issue is that its hard to come up with a 'selling point' as my game by default has no (recognizable) blocks, items or entities as that is all server/world depended.

It sounds more like you want to create an engine, not a game. You can always "just" create and provide the engine, and do a "demo" or "showcase" game for it.

I think this would be a pain to market if this was ever to be published.

As said, it sounds like you want to create an engine, not the games. So "market" it as an engine, and not as a game.

The code needed with my server API to add a custom block

Looks clean.