Opening It's long past time PocketMine-MP got support for dimensions. While there are nice simple dirty ways to do this, such as that implemented in Genisys currently, these aren't scalable at all. Can you have more than one Nether? Nope. Can you automatically load PC Nethers? Nope. So dump that idea in the bin where it belongs, along with Genisys itself. The design I am working on is aimed at PocketMine-MP 1.6.2, as indicated in https://github.com/pmmp/PocketMine-MP/issues/149. Basic goals: Load, travel to, work in and save dimensions from PC world formats, and also PE once we get LevelDB to work with php7. Be able to have per-world dimensions. Portals in world A's Overworld will take you to world A's Nether or End. More advanced goals: Provide a clean, easy-to-use API for plugin developers to add their own custom dimensions and modify the behaviours of existing ones. Design After a lot of planning and discussion, it became clear that there were two distinct ways this could be done, which will be described below. It is absolutely critical that we get this right, as such an upgrade could be dramatically breaking for backwards compatibility, and it needs to be worth the time and effort. Approach 1: Level as a Dimension Manager, with an array of Dimensions This was the design I initially opted for. Most things Level would be refactored out into a Dimension class, which all dimensions would then extend. Level would then be a manager of an array of Dimensions, with some basic methods for worldwide stuff like time management. This would allow stripping a lot of things out of Level into Dimension, which would draw a distinct line between what should be handled globally in the Level, and what should be handled locally in the Dimensions. Such a design would look something like this: Level (with basic global methods like setTime(), getName(), blah) Overworld dimension Nether dimension The End dimension Custom dimensions In a class-based hierarchy: Code: Level (with basic global methods for handling time etc) - Dimension - Dimension (overworld) - Dimension (nether) - Dimension (the end) - Dimension (custom dimensions) This design I believe is the cleanest way to do this, since it conforms with the way vanilla Minecraft handles dimensions. However, such a design would be potentially extremely breaking to backwards compatibility and would be a very large amount of work to complete. The majority of Level functionality would need to be refactored out into Dimensions, which would break near enough every plugin that does anything remotely to do with Levels. Which is a hell of a lot of broken plugins. I started to wonder if this was overkill just for a slightly cleaner design when similar things can be achieved with the design laid out below. Approach 2: Level with sub levels This design came to mind after realizing the design above would be a very large task, and is similar to the design originally suggested at https://github.com/PocketMine/PocketMine-MP/issues/3149 of having recursive levels. This involves having a regular Level as it is now, but with child levels (Nether, End, custom dimensions) which would extend the Level class. This would be much easier to implement, and much less breaking for backwards compatibility. However, I don't think it is a good approach because it blurs the line between Dimensions and Levels. A Level is not a Dimension. However, with this design they could be treated that way to reduce the amount of changes needed to PocketMine and to keep breaking API modifications to a minimum. This may be beneficial to those who will still want to use older plugins which depend on Level functionality. This design would look something like: Level as Overworld Nether sublevel The End sublevel Custom dimension sublevels In a class hierarchy: Code: Level (overworld) - SubLevel (dimensions) - SubLevel (nether) - SubLevel (the end) - SubLevel (custom dimensions) Summary What this ultimately comes down to is whether to refactor everything out to separate Levels and Dimensions, or whether to make them as one. Is it worth breaking lots of plugins for the sake of separating the two? I'm very much torn on this and totally unable to decide. Let's see what the community thinks.