Teleporting a player

Portals

  • WorldPortals + Inferno modules: Inferno essentially is a dual world already, the second “layer” is like 100k blocks straight down and there is a portal item that transfers you.
  • WorldPortals on the other hand seeds little multi-block portals in the overworld like you might expect normally, and does something similar to port you elsewhere
  • Inferno and WorldPortals are just two examples of how you can travel long distances via teleportation. With true multi-world you’d need to also move the player entity between entity pools and switch to a different set of chunks

The Teleport

  • switch game state temporarily to leave the player in limbo while you unload old stuff and reload new stuff, then re-enter the regular game state
  • look at what happens when the player currently leaves a game (saving and unloading the world) and enters a game (loads chunks + entities). More or less you need that just with two different save games with a few unified things mixed in like global chat
  • “unload all old, load all new” approach
  • especially if you can list some actual process on the loading screen. Maybe some world map stuff down the road
  • On some digging I’ve discovered that the changeState method is called when a new game is created or a game ends. This method takes a parameter the new state you want to go to. The current available states are StateMainMenu (called when someone pauses game and clicks mainmenu), StateLoading, GameState, StateInGame, LoadProcesses. So I think for the world to world transition we need a new state which first does something similar to StateMainMenu just instead of that take to a world transfer screen of sorts and then we need can simply load a new world like it is called when game is initialised
  • it may also be wise to try estimating when a player is about to travel and start loading chunks in the new location early, with low priority like if a player is within a chunk’s distance from a portal of some sort may want to at least fetch chunk data from the server (or have it generate the chunks on the other side if they haven’t yet)
  • may want to also delay unloading until players vacate the other side of the portal

Pools

  • a tiny little global entity pool so the player entities themselves remain global, you then just switch the player’s location (some new 4th coordinate for world) during the reload
  • In theory multi-world could be done with everything still in one big entity pool (would involve less complications), where yeah you could just decorate using world names
  • Maybe multi-world to keep scope low should focus on chunks and blocks, less so entities after all splitting pools per world could be done later on.
  • if you have everything in a single pool then yeah you need to essentially add a WorldComponent or a world variable on LocationComponent / BlockComponent

Save Game

  • more just how you would save the two worlds on disk. Currently there’s no layer for considering more than one world. A save game just has chunks right inside it
  • And regardless of what a player does (likely will almost always only care about one world) the server itself will need to maintain every world

Create Game

  • At present opening the preview moves you forward into a new module environment (to scan for world config etc) and if you go back the environment should reset - that is causing problems right now the new approach should be roughly the same thing just with more steps
  • probably one phase should be simply kicking off generation without even starting the player on loading into the world yet. That would especially be the case when a world calls for pre-generating various stuff, like a finite world map you could then show to the player to include a “Pick your spawn location” option
  • this

Universal Chat

  • i’ve thought of it more just as a way to keep chat global as players are in multiple worlds local chat might be a thing to do later?

Misc

  • Additional Worlds - not really useful. Stick with super basic worlds to begin with, you can always stretch later into functionality that will take two separate world generators and cram them into the same universe
  • like if a player ports from world A to world B and there are still a hundred chunks queued for generation to be made visible but the player isn’t there anymore - well, cancel all that! reply: Not sure about that but in our case if the player decides to switch worlds we want the generation to stop immediately and unloading to start.
  • different worlds would be hugely obvious candidates for having their own entity pool (whether Sector related or something “bigger”). We could probably do that at first without multi-threading (wait for Gestalt v6 for that) but in either case that would be a super simple way to do the world wrapping: one entity pool per world, so any entities in that pool by nature are associated with that world, without having to store that knowledge on any entity there (good to avoid any sort of excess)
  • For #1296 I think more shutdownhooks are needed which will initiate threads to take care of the issue. A thread will be called for every System.exit, this will improve logging and help make all the exits work consistently. May be this

Why Cerv Why?

  • Looking at saving, the chunks are all stored 8 zip files. Every save’s zip files have the same name. The name of the zip file depends on thechunkPos. Not sure what this chunkPos is? It’s a vector with diff values like (3,1,0) (2,-1,-3) (2,-1,0) (-1,-1,1). Not sure what these values are and how they’re decided. It could be possible to add a fourth world param to these to differentiate the world and thus modify the zip files accordingly.