Hey all Im looking into developing a rating based system for planets generated in the engine that can then feed top rated planets back into the engine via a mod and wondered if i could get a sample of the json used to define a planet in the engine just to see if the idea is viable. Does anyone know if a sample has been released or could a developer potentially share a sample.
It sounds like you're looking for the seed for the planet generator (think like how Minecraft does it). I'm pretty sure someone from Uber has said they were planning to share planets based on seed. A quick search of the forum should confirm (or refute) that. But to answer your question directly; I don't think one has been released. Someone from Uber may be willing to give you one, however expect there to be a pile of changes as the planet generator is refined. If you're patient enough to wait six weeks, you could possibly get it your self when the alpha rollout starts.
He's not looking for a seed. He can't even generate a planet from a seed unless he know's the exact code that generates the planet. A seed is just a random number, nothing special.
It sounds like he just wants a way to manage which planets are the most popular and make it easy for players to find and/or play them, in which case the seed is all that is needed as it will probably be easy to pass it to the client.
IIRC from the second last livestream, because of the multithreading of the engine, seeds are not enough to create the same planet each time. Ie. they'd need the full planet file to recreate it.
my guess would be: it depends. I doubt, that the asynchronicity introduced by the multi-threading will create totally different results using the same seed. The results may not be identical, but if you liked the general setup of the original planet you would probably get something similar for your taste using the same seed. So it would depend if you want to have an exact duplicate or a general style. (blind guess disclaimer: without knowing the source it's all speculation )
I very much doubt the results would be similar. Oversimplified example: If you generate a random number to determine the amount of trenches and another random number to generate the amount of mountains. In multithreading, the order in which these are generated is unknown, so say 1 number is 10, the other is 50. This will not give you a similar planet if the two numbers are swapped. Since there is a lot more complexity to a random map generator than this, I'd think the differences would be even greater.
depends a bit on what level you apply your parallelism and which parts have to be done in order etc. If you start on a global level you will probably get significant differences, if you start on a more detailed level you get similar shapes. As I said, without knowing the code it's more or less a blind guess.
Hey A seed would be no good. From the json i can potentially determine something about the planet to give stats on the planet. The idea would be to have a repository of highly rated planets and a mod that allows a selection of these top rated planets to be used to form the collection of planets in a map.
And exe files often contain assembler. (...) Random numbers might not be truly random in PCs, but you will not be able to predict the outcome of a certain algorithm if it uses multithreading. (Assuming you do not use syncing etc) Anyways, they've said they'd use a JSON file to transfer planets from the server to the clients. (I believe it was during a livestream) So, there you have it. A JSON file.
You still have to initialize the rand function. At least in c. If you do this with the same seed (often the actual time is used) you will get the same outcome every time. There are other functions as the better random from Intel but i doubt they will use something special like theis because of still available AMD server CPUs.
The problem is not that a pseudo RNG does not provide the same sequence of numbers given the same seed, but rather that the planet generation is multithreaded and that UBER is using an indeterministic algorithms to generate planets. That indeterminism results from the fact that the order of execution of the involved generation steps is more or less unknown. @Topic: You are basically asking for what usually is called a map-file in other games.
^It's called a race condition, and it basically states that if two things (threads) are happening at once in a program, you can never tell which will finish first, and if there are inter-dependencies between threads, you will have non-deterministic results. This can be avoided via having threads lock and wait, but then you are really undermining the advantages of making something multi-threaded in the first place.
That's easily fixed by using instanced RNGs, as long as you feed each thread it's own instance of an RNG seeded with values from the original RNG then you can get completely deterministic behavior even with multiple threads, but I'm not sure there would be a need for Uber to bother with that and it's not very scalable since it needs a fixed number of threads to create the same results. At any rate it seems I'd misinterpreted what kerry2279 wanted to do and seed values are not suitable anyway.
So we do have our own random number generators that are seeded the same etc. So it's *possible* to get the same result on different computers from just the seed data. In our office it tends to work most of the time. That's not really the issue. The real issue is that I don't want to have to make those algorithms backwards compatible across time. E.g. if we add more biomes, change weightings etc then your seed will break. This is going to happen very very often, so relying on the seeds isn't a robust strategy for distributing maps. Instead what we do is save the output of the planet generation algoritm. This is currently a huge blog of json that contains the positions of the brushes, what the surface is like, decals, feature locations etc.
Technically anyone could write software that would output it, yep. This is another goal, that the data is open enough other tools can manipulate and visualize it.