I am casually developing an idea for a game. Or rather playing around with different concepts needed to build a basic game.

Right now I am looking at quad trees.

My game map will basically be a square grid. I was thinking of using a quadtree to represent the areas that has been explored on the map.

My question is: How do I store the information of the quadtree in a database?
Some time ago (a couple of years) someone told me about storing the data in a single string. For the life of me I cannot recall the exact method to store it or to change the data (adding new explored nodes etc).

If anyone can enlighten me or point me to an appropriate site, please.

In general, I would suggest converting the quadtree to a geohash by indexing each of your quadtree's nodes with a binary representation of it's location (00 for NE, 01 for NW, etc.) and the prefixing each of the child nodes with the parent's index (e.g. the key 0111 would be the SE tree/leaf of the NW tree of the root). By then returning a string representation of the hash, you'll be able to easily store the data in a database while still being able to retrieve and modify it. Hopefully this helps.

In general, I would suggest converting the quadtree to a geohash by indexing each of your quadtree's nodes with a binary representation of it's location (00 for NE, 01 for NW, etc.) and the prefixing each of the child nodes with the parent's index (e.g. the key 0111 would be the SE tree/leaf of the NW tree of the root). By then returning a string representation of the hash, you'll be able to easily store the data in a database while still being able to retrieve and modify it. Hopefully this helps.

This is helpful for storing and retreiving a single node.

My problem is to find a way to represent the whole grid as a single string, and mark those areas that has been explored.

Somehow the following is stuck in my head, but it also has problems (I'll mention those later)

Lets take a 4x4 grid, so the quad tree will be 3 levels deep.

I'll order the quads NW, NE, SE, SW.

Empty grid.

---------
| | | | |
---------
| | | | |
---------
| | | | |
---------
| | | | |
---------

As none of the leaf nodes has been explored the whole grid is represented by the value 0.

Now our hero starts out. This means he has 1 leaf explored.
---------
| | | | |
---------
| | | | |
---------
| | |x| |
---------
| | | | |
---------
So the idea is to mark a node that has been explored and all its parents with a 1.
When we write the string when we get a 0 we do not delve into the child nodes as we know they are all empty. When we get a 1, we list the 4 children and their values.
So we will have
1 (root)
- 0 NW
- 0 NE
- 1 SE
-- 1 NW (this is where our hero finds himself)
-- 0 NE
-- 0 SE
-- 0 SW
- 0 SW
So we get the final string of : 100110000

After our hero walks around a bit we get this map

---------
| | |x| |
---------
| | |x| |
---------
| |x|x|x|
---------
| |x|x|x|
---------

And with that the string: 10110011111110110

And when he has completed exploring the whole map we get : 111111111111111111111 (21 characters)

Adding another level (8x8 grid) adds 64 more numbers, 5 levels deep (16x16 grid) adds another 256, 6 levels (32x32 grid) another 1024 ... and you can see where this is going.

So the string is getting a bit big when you get to a 1024x1024 grid. The more you explore the longer the string gets.

I guess I could use a 2 to mark a node when all it's children has been explored. That will make the string shorter.

But the other problem is still on how to update this string, as the hero explores, in a way that is not too resource or time intensive.

Any ideas?

If I'm looking at this correctly, what you're expecting is that the string representing a fully explored region of 1024x1024 nodes would be nearly 80,000 1s. Depending on the database engine you're using, either a CLOB or mediumtext column will be able to handle storing the string as this will only come out to 77~kb.

As far as using the data in your application, I would still suggest that you use a map object to store the nodes. Since your hero is only going to be able to occupy one space at any given time, you're going to have a much easier time and your program will be more efficient if you are accessing and manipulating the data in a map than if you were constantly parsing an 80,000 character string.