Hi all, last week I told you about how the cave generator worked. Unfortunately, I've discovered that building a cave generator algorithm is one thing, but going from the blueprint to an actual cave you can walk around in is another. That is, I walked into several practical problems before I got it to work (and I still haven't got it working fully as I want it). These are the problems, and how I'm trying to solve them right now:
It's quite a lot of info to send
If you had a look at [the visual representations] of the generated caves last time, you might have noticed that it's quite a lot of information to send. Not that it's impossible to send all those x's, dots and pipe symbols, it's just that it did cause much longer loading times than I'd hoped for.
While grumbling about this, I realized that it's not only a lot of info, it's also a lot of redundant info. That is because each cave exists of 10x10 blocks, and each block has four possible exits (north, east, south and west), all of which might be open or closed, which gives us 2*2*2*2=16 possible blocks...
...so instead of describing the whole layout of the block, I now translate it to a number server side (0-15). The client consequently translated it back to the real block. This reduces a cave [like this] to a list of numbers like this:
1000000000000000000000000000000000000000000000
000000000000000000000000000000000000000020141011
000000000000000000000000000000001013100400000000
0000000000000000000000001007001500000000000000
000000000000000000100750070000000000000000000000
0000000000100500040000001300120000000000000000
0000100700150000000640110000000000000000000010061
002100900095004000000000000000000000000000010
06100210110000000000000000
Much better, huh?
It's quite a lot of stuff to render on screen
But there's another problem as well: these caves are huge. I have of course chosen this size myself (small caves won't be that exciting, as you can't get lost and stuff), but I didn't realize that so much game objects would have to be realized to actually display them. There are 100 blocks in one cave, and in one block fit 1557 rock objects... which leaves us with 155700 objects for the game to handle! Some quick tests show that, even with some smart optimizations to make sure the game only considers objects that are closeby (like I do in the main world), this is simply too much.
There is one big benefit to rocks, though: unlike the softstone underground, or the trees in the main world, the players can't take them away. They don't move! That means I can take one 'snapshot' (=OpenGL DisplayList, for those interested) of them as the cave loads, and then use that all the time, instead of the individual pictures of the rocks!
This gave me a speed-up of about 20-30 times (yay!) but it had one problem: while the rocks couldn't move, the player could: sometimes the player is behind rocks, sometimes he is in front of them, but if all rocks are combined into one image, rocks will be always either behind or in front. I fixed this by splitting my snapshot in two: one of the forward facing rocks, which will always be behind the player, and one of the backward facing rockes, which will always be in front of the player:
And that seems to work! I'm still not fully happy with the framerate, though, so let's stop talking and get back doing!
If you want more development, see [twitter] or [facebook]. If you want to be a tester, you can subscribe on [olvand.com].
Cheers Wessel!