Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Worlds #49

Open
3 tasks
toqueteos opened this issue Mar 13, 2015 · 8 comments
Open
3 tasks

Worlds #49

toqueteos opened this issue Mar 13, 2015 · 8 comments

Comments

@toqueteos
Copy link
Contributor

We need to settle down what is a world for us.

The other day discussion about this was interesting, but IRC is volatile without logs so... here we go. I won't copy my notes from the IRC so each and every one of you can write your proposal as you like.

Feel free to edit this post as discussion goes forward with a checklist of what things are required.

  • World = Dimension?
  • Inter-world communication? yes/no
  • Ticks. How and Where.
@toqueteos toqueteos added this to the MC 1.8.3 milestone Mar 13, 2015
@fenhl
Copy link
Member

fenhl commented Mar 13, 2015

tl;dr:

  • World = Dimension? No, one world can have multiple dimensions.
  • Inter-world communication? No for vanilla, yes for mods.
  • Ticks: synced per world.

My proposal is that we should follow the precedent set by vanilla, which despite not having multiworld support suggests a definition of “world” which can be extended to modded Minecraft: a world is a set of dimensions which tick in sync. This also answers the third point: each world has its own tick loop. If we read a vanilla world directory this will be one Overworld, one Nether, and one End, but mods can add or remove dimensions.

Aside from inter-dimension communication which will be frequent even in vanilla, an API endpoint for inter-world communication sounds sensible. Since each world runs on a separate thread, this would require something like queues.

@RichardlL
Copy link

Here's another world problem :p
You have to ask yourself how compatible you want to be with minecraft. Vanilla minecraft worlds generation is done by having random 3D array of Perlin noise generated for the map, with element of the from -x to x, generated, then is added/subtracted to the height above sea level.

This makes it so the "earth" is generally below the air, yet has mountains and floating islands (surface caves are the opposite of floating islands)

The block type is then determined by biome on and relative height (e.g. in dessert biome, top 8 blocks are
sand, next 3 are sandstone, rest below are stone, then ores are generated later on)

This exact perlin generation algorithm is proprietary, and you have no way of easily knowing.

Since I decided I would never have the attention span to be able to duplicate it, its useless to try to copy, and I would come up with a better algorithm (at least I justify it to myself that way :p)

The benefit of perlin noise is that its fractal, so it looks natural (like how the golden ratio is fractal in nature)

What my plan is use sea level, and then generate on top of that using a combination of random
mathematical equations:

  • quadratic

  • linear

  • logarithmic,etc

    Each equation would have a partner equation, and a where their y's match (random)

    For example
    image would be one

image

and this would be another

And then you would choose a random y, Graph up to that for the first one, and then take that y, and graph down from it for for the second graph.

This is two dimensional, but you can easily make it three by weighting random values

so instead of

Y = 3x

it could be

Y = 3x +2.5z

For a linear equation. The numbers would just be random (exponents would be random quadratic, bases in logarithmic.)

Also plan on doing this for "surface caves", just choose a negative y, and use opposite sides of the y axis,

Repeat this n times on a half the scale each time small scale to simulate the "natural" fractal effect, n being when mine craft blocks couldn't accurately represent the changes (change in y is less than 1)

The advantage of this makes world generation much cheaper, since with perlin noise you have to calculate the average of every block, with respect to every block around it. You could then just save the equations, and re-graph it every time you need to load it. With multi-threading in Rust (hopefully someone adds gpu support too) It will be faster just to regenerate the world than doing Disk I/O (you would still have to save abnormalities, like trees, plants, player edited objects, which are then edited in after generation), and be able to cache the equations or chunks, or both, depending on ram/cpu usage

Lol, I went overboard again, but I guess the purpose is that you have to decide how compatible you want it with vanilla, as trying to get map generation be compatible will be a lot of work, and if its worth it to just redesign it your way.

@bvssvni
Copy link
Member

bvssvni commented Dec 6, 2015

@RichardlL Intriguing. I almost understood something of it!

@RichardlL
Copy link

lmao! Who is This projects leader, anyway?

@fenhl
Copy link
Member

fenhl commented Dec 7, 2015

We don't really have one. I started the project but I don't have any administrative powers, other than strong opinions.

@fenhl
Copy link
Member

fenhl commented Dec 7, 2015

I agree that it will probably be impossible to recreate world generation perfectly, but we should still try to emulate it as closely as possible, to get the worlds to feel similar. That would mean using Perlin noise for the basic terrain, although using a different implementation could be useful for now. If I recall correctly, @amaranth has been playing around with Perlin noise implementations in Rust, so we might be able to use some of their work.

However, this issue is not about world generation, but rather about what we want to consider a world and how ticking should work.

@RichardlL
Copy link

@fenhl
Have you seen my comment in PistonDevelopers/hematite#203

About throwing out the tick system altogether?

It could still be designed to be the same as vanilla.

The problem with ticks in minecraft is it is basically runs on the same loop that Magen/packet handling does, so it just updates a place randomly, which is the seed for time. This is one of the two ways you can do it, the second being setting a time for every thing that needs to be updating, and each then check each tick if the time has passed. (Which is even more inefficient them random

My proposal is use threads, and block use "sleep",to update time dependent function Instead of having a block require a certain number of random updates, so we aren't using cpu cycles uselessly.

Of course you can only do this if you're multi threading, so vanilla minecraft had to do the "random update" method, since the main thread can't wait

@fenhl
Copy link
Member

fenhl commented Dec 7, 2015

Minecraft also has block updates other than random ticks, which need to be synchronized in order for things like redstone to function correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants