GreenSlimeGames

Hey there folks, I thought I would take some time to explain whats happening with the game at the moment.  As my earlier posts have stated – the terrain is now saved to the server on game over.  Sweet, but aside from making crude pictures – what is the point of this data?

Well, now I have the data on the server, I can load that data back into unity.  Which basically means you an re-visit your old asteroid mines.  I’ve got this working in my test build, but it is still a bit to buggy to release.

But alas, not everything is as simple as it sounds.  You re-visit your roid and vroooom, all your mined out areas are suddenly repopulated with ore.  Eeeep, that isn’t very realistic – and though it would be a sweet reward to get players to re-visit asteroids … but as the old exploit shows, giant bits of already mined out areas are game breaking.

So, why can’t I store every bit of ore on the server and flag when it has been collected by a player?  Well, the ores spawn in a two dimensional plane and and on average you have around 670 ore spawns on a roid.  It is just way to much data to store, and to transfer to the client at runtime.  After some pondering, I’ve decided to solve this problem by procedurally generating every asteroid.  You might have noticed that every asteroid has a number on the stats screen.  This number is the start of the solution – every unique asteroid will have a seed value associated with it.  This seed value is used to generate ore spawns.  I’m currently working on an algorithm to pull this off.  Alas, I can’t just use the standard seeding of the random number generator – I need to create a cross platform solution, because at some point in the future, I need the server to be able to perform this calculation as well 😉

So how does this solve the problem?  Let me walk you through it 🙂

1. New asteroid is seed is requested from server.
2. Server records the seed value, and that it is discovered by player x, and timestamps this.
3. Unity client takes this seed value, and generates the ores procedurally based on this seed.
4. Player X mines and collects ores, and generally has fun.
5. Player X gets bored and self destructs.
6. Actually mined terrain environmental data is sent to the server.
7. Player Y looks through the most recently asteroids and sees Player X hasn’t exploited the 500-600m depth on the asteroid, which really contains the ore Player Y needs.
8. Player Y ( in his unity client ) requests to mine the same seed value as Player X.
9. Client requests the terrain data from the server for that seed value.
10. Terrain data is used to re-create the environment Player X mined out.
11. The seed value is used, and all spawns are re-spawned in un-mined areas.
12. Player Y mines, and collects the ore he so desperately needs.
13. Player Y leaves the roid, which uploads to the server the new terrain environment.
14. Fin 🙂

As you can see, this is a pretty simple system – but it actually allows for a helluva lot of cool features – and starts evolving the game into a more consistent universe.  A lot more to come soon 🙂