Olvand is a little multiplayer sandbox RPG, where the players live in self-built towns and can go on all kinds of adventures together. Imagine living with your friends in a small town in the mountains, or creating a new group of friends in a pub in the metropole you all live in. There will be several minigames the inhabitants of a server can play together, among which will be combat based games like King of the Hill or Capture the Flag. You will be able to play against other people in your city, or as a city against another city, or as a whole server against another server. The combat works with self-built guns, in which all kinds of powers can be combined to create unique effects. You can sign up to be a tester on olvand.com.
Some pictures of what I want to add in the future:
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:
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!
Latest tweets from
It can take up to a few hours for tweets to begin appearing.