So, this weekend I started working on saving/loading the chunks. I read a little from various minecraft posts, and from what I saw, they are just zipping the chunk data and storing it that way.
Awesome, I'd rather just zip up the bytes of block data and do that anyway.
So, everything went well until I actually tried to save the file information in Unity. From what I understand (and experienced), you can't just save stuff out to the file system that way. Especially from a web player. So this tells me it's time to have an actual remote application (server side), with the main app being the client.
So, I've got a small .exe so far that accepts requests to save the chunk data. It'll just be a seperate executable that is responsible for saving, loading, and probably ultimately generating chunks. The good thing about this is, it paves the way for multiplayer.
The direction (for now) I see this going is, this will take some burden from the main project. The seperate executable will be responsible for generating all terrain, decorating it, saving, loading, etc. I don't exactly have the design in my head for handling saving and loading unity objects that potentially travel between chunks.
I want this stuff to be as transparent to the developer/player as possible. People who add new unity gameobjects to the world shouldn't have to worry about them being saved or loaded, they should just have to worry about their own custom behavior. But, in my mind I had expected each chunk to 'own' the gameobjects that were in that chunk. Here's what I had in mind:
When a gameobject is created, it gets a unique id. Just an incremented integer value should do. Each gameobject gets added to a list of gameobjects stored in the chunk that the gameobject is placed in.
What this means is, there has to be a central way of keeping track of when a gameobject moves from one chunk to another. This _might _mean all decorations that are unity gameobjects (can I just call them entities?) have to attach a script that on Update(), checks to see if the entity is in a different chunk, and if it is, transfer it to the new chunk's list and request that the changes to the two chunks (new chunk and old chunk it was in) are saved.
Then…the server piece has to notify the clients that the entity is a new location, it seems. Or, each client might just send quick requests to the server on a regular basis, to ask if any changes apply to them. This could get tricky, I'm new at this, and this is the current approach that seems clear to take. I'd like to discuss this more in depth if anyone has any thoughts/suggestions. I would like to stick with the .net remoting if possible, it seems pretty straightforward for the initial work I've done.
So, the approach I have in mind is:
The server keeps track of chunks that are have been changed. Any chunks that are altered have the last alter date/time saved.
Every x milliseconds, the client notifies the server of it's player location, and a list of chunks that have been altered since the last communication, the time of the change, and the action performed. The server will account for time differences between clients, so it knows exactly who did what first. If two players are digging in the same chunk, but are from different parts of the world, it needs to be able to know the exact common time between all clients.
The server sorts the actions by time, and applies the changes to the chunk. So if player A and B are digging at the same block and A starts digging 50 milliseconds earlier than B, the server will receive have been receiving messages from both of the players that they are digging. Eventually, the server gets enough digging events to know that the block should be removed, so in its response it sends back to both players it lets them know that the block is gone. Both player clients immediately redraw the chunk.
Anyway, this is premature, I'm just working on the saving/loading right now. But more and more, I see that the server will be doing a -lot- of the actual chunk work. Should be interesting!
I genuinely enjoyed reading this article.
Sounds great & well thought out. Looking forward to hearing more as it comes together :)
I was looking into saving/loading recently too and came across this handy dll
It was re-written entirely in c# and just needs dumped into the plugins folder & added to your assembly directives to work. Just passing it along in case it helps :)
On a side note…I actually meant to post this in the general dicussion, but I suppose this place is good too :D
Log in to post a comment.