MV3D Development Blog

Yaaaaay!

Anyway. v0.2 is done, v0.3 is in progress. (yaaay) Man, I’ve got to get some screen shots because character animation, lights, shadows, and water came together really quick. Now water isn’t finished because it isn’t integrated into the physics as I’d like it to be. Even with the Example Ogre water shaders, it looks cool. Oh yeah, so water physics. I think I’m going to try something, but I don’t know if it’ll work. My idea is for bigger bodies of water to define their shape in the physics engine, but instead of having things bounce off of them, a) let whatever comes in contact with it know that it has touched water (so if say you drop a sword into water, it could rust), but more importantly, b) slow the object down and do some very cheezy fake bouyancy tricks. So if you put something in water that is less dense than water, it floats, but otherwise, it sinks. Very fake and simple, but something. Could be cool, could suck, could be too CPU intensive. Should be easy to program.

What I’m working on now are the two more complex problems in v0.3. The one that I would say is mostly done is allowing each area in the game to have its own coordinate system while keeping a seamless transition from one area to the next both physically and visually. It does work at the moment. There is one physical glitch where if you stand right between the two areas, you seem to fall through the ground for some reason, and one visual glitch where there are a couple of frames of discombobulation when passing through the areas. The former should be solveable once I figure out why it’s happening– I am pretty sure I took that problem into account when designing how this all works. The latter may be a little tougher. It’s sort of an order issue. Visual representations are now grouped together in Ogre by area (before everything was all together on the client side), and whole areas can be slid around. Ok, so I didn’t want to get into this, but I think I have to in order to explain fully. Areas are seperated by Gateways, and Gateways can now define a translation and a rotation that happens to objects as they pass through (or see through) the gateway. The translation and rotation specify how to change a given point from Area a’s coordinate system into area b’s. So the server looks through the player’s eyes and finds all the areas they can see and determines that area a is where the player is, so that has a translation of (0,0,0), area b is through a gateway with a (100,0,0) translation, so it’s at (100,0,0). Area c is through a gateway in area b with a (100,0,0) translation, so it is at (200,0,0). It sends all this to the client, and the client (having grouped all of the objects for a given area together) moves them all into their respective offsets.

The problem comes in when you move from area a to b, the server will add (100,0,0) to the PC’s position and send notice of the area change to the PC. When the client gets the position change, it updates accordingly. When it gets the area change, it has to go through all the areas it knows about and adjust their offsets by (-100,0,0). It could just wait for the server to send out offsets again, but the server only does that every few seconds. Anyway, there’s a few frames between changing the position and changing the offsets where either your body is missing, or your surroundings are missing because one or the other hasn’t been updated. Fun stuff. I’ll figure it out. For the moment, I’m living with it and moving on to the other complicated v0.3 thing:

Creating a type of Area that can automatically split itself up amongst several servers. And you thought I hashed load balancing to death in the last update? Oh no! There’s more. Currently, the lowest level that can be load balanced is a whole Area. Under most circumstances, this is perfectly fine. But something that tends to happen in MMOGs is that certain areas/zones become very popular and you get many people hanging around in them. Often, this causes servers or clients to bog down. For now, I don’t care about the client part, but the server part is important. What do you do? Well, you make an area that can distribute pieces of itself across servers. So I am working on an octree type thing that’ll do just this. Somehow, I’ve managed to avoid octrees and quadtrees in my previous programming experience, but they seem pretty neat and are pretty much the way to go for what I’m trying to do. [an octree is a tree structure where each branch has either 8 sub branches or some number of leaves (not both)] The hard part comes in with distributing things. I suspect it’ll be a matter of finding a quick and painless way to change the master server for groups of objects at a time. Currently, if you make a master server into a slave server for an object, it dumps the object and reloads it over the network from the new master server. Not too fast. Hopefully, I can keep the object and somehow reconnect it to the new server.

Finally, I had a very good lunch with and his coworker today. Funnily enough, we compared stories of how slow / annoying our individual methods of persisting random Python objects to database without requiring a specific schema were. We chatted about a lot of other things of course, some of which I may bring up here in the future if they come to fruition. But in any case, it was good to talk to other programmer types about MMO related things.

And finally finally, MV3D dev may slow down a bit over the next month because I’ll be working on two video jobs.