Skip to content

Instantly share code, notes, and snippets.

@celeron55
Last active January 8, 2022 07:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save celeron55/e16200de201750869f576187ee581f2c to your computer and use it in GitHub Desktop.
Save celeron55/e16200de201750869f576187ee581f2c to your computer and use it in GitHub Desktop.
Minetest's future 2022-01-08
I was inspired by yesterday's #minetest-dev discussions to write down what Minetest's future looks like to me currently.
- Directly serves gamedevs and server admins
- Doesn't need to cater to players by itself regarding to gameplay, gamedevs and server admins already have players in mind
- But players essentially become gamedevs when they open the content database and server admins when they open the hosting tab
- think more along the lines of Roblox than Godot (I'm flexible about this though. Have to see how it goes), but don't make separate game distribution unnecessarily difficult
- Multiple worlds with separate lua environments
- this is necessary because a single world per game server is a special case. There's no way we can get away with supporting only the special case
- the client needs to view only one world at a time (for now)
- communication between environments via messages or RPC of some kind. Also a shared key/value database?
- the current lua api becomes the world api, and a new game/manager/overworld/lobby api (with its own non-world lua environment) is added to manage the worlds
- Worlds essentially are like scenes or models in some systems. The game environment's job is to create and delete them, and pick which world is shown to each client. A client is always viewing one world.
- Need to think about the naming though. The main menu should still talk about worlds, so these multiworlds need to be called something else. Spaces? foo = overworld.create_space(), overworld.get_client("celeron55"):set_space(foo) or something
- non-first/third-person controls and cameras have to be supported, again because we're wasting the engine by locking it into a special case.
- This practically means that something along the lines of my scriptable player physics concept has to be included.
- "what the player controls" and "what the player sees" have to be separated, not because of RTSes or something, but even because of stuff like cutscenes or viewing other players.
- Once these are working, stuff like seamless VAEs aren't such a ridiculously big stretch anymore. But this needs to be developed in smaller steps
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment