Wednesday, May 4, 2011

OK, some database stuff.

These are my initial thoughts on how to handle storing the world in a MySQL db. Having never attempted to do something like this before, they may not be very good ideas. So, feel free to chime in if you want.

An initial thought is to have a table with, at a minimum, the following data:

x-coord
y-coord
z-coord
field that holds a reference to the block id that occupies it

Of course, this also requires us to have a massive table of the blocks available in the world.

As you can see, a simple 100 meter x 100 meter x 100 meter "section" would require 1 million records.

One option is to divide the world into logical "areas" - that is, have two tables for each area, one with the coordinate triplets and one with the blocks. This would require flagging all the blocks at the perimeter of the area, so that we could know when to switch tables.

Another thought is that since the Z space is not going to be used nearly as much as the X and Y space, it might be possible to fake it. Most the air blocks are identical, and I don't see a need to duplicate them thousands of times. We could just reference one standard air block, which would significantly reduce the size of the block table. If someone wanted to build a floating castle or something, then we can just generate some unique blocks as needed.

The block table will contain all the details for the blocks...type, ambient messages, etc.

Another table would be used for objects. If a block is part of an object, we put a reference to the object ID in each block. Then, when we need to interact with the object as a whole, we look up the object to get the face descriptions, etc.

No comments:

Post a Comment