MV3D Development Blog

I’m probably not as funny as I think I am. Anyway, before getting into the topic here, I will mention that a lot of the load balancing, redundancy, and fail over is working. Areas and the objects in them all work with it. Next are Realms, Accounts, and Directories. I’m hoping those will be a little easier since they don’t have any moving parts like Areas and Objects. There are still some bugs though. I’ve connected a client to a server that was the slave for an area. Killing the master server makes the client’s view go completely bonkers for about 5-10 seconds before returning to normal. I have to do more research on why that happens. I think disconnecting and reconnecting solves it, so it could be a client issue. Either way, there is more work to be done there.

Now, profiling. Maybe I discussed it earlier. I think I even put up some results. Well, that was using my own home made profiler. Now I got Python’s profiler working with the client and server. After some frustration due to ODE Physics being the cause of all the slowness, I came up with a very good idea. I know it was a good idea because a server with 5000 objects used to run at about 1 iteration every 10 seconds. Now (as long as those objects are stationary), it runs 1 iteration every 0.05 seconds, or 20 per second. In fact, the maximum number of iterations allowed is 20 per second. It only uses 40% CPU.

But what about moving objects, you say? I need to devise a few more tests, but that shouldn’t be a problem as long as you have a reasonable number of them. 1000 or 5000 moving objects in one area is not reasonable. 100-200 is probably maximum (50-160 would be players and the rest, things that just happen to be rolling around or something). But to tell the truth, 5000 objects in one area is a lot. 500-800 maybe (not including terrain, which could be 250 objects, but they don’t have bodies, and they are constantly disabled, so there).

How do I know these things? I don’t really. I have to sit down and figure out what exactly is the expectation for area size. Of course, areas can be any size at all, but physics, I believe, will dictate a maximum complexity. If you are on the 7th plane of hell, and it’s really just a plane with no other geometry, it can be pretty darn big. But if you are in a city with lots of buildings and other objects, smaller may be the way to go.

I am really itching to see how the client performs when you have 5000 objects around. However, I have to rewrite a bit of the code that decides which objects to send to the client. Currently, every 20 iterations or so, it checks all objects (in one big loop) and sends any updates. With 5000 objects, that’ll cause a burp in the server every 20 iterations. Instead, it should do, say, 5 checks per iteration per client.

Meanwhile, I have a tester now. He has been very helpful, though I feel bad since his experience logging in to the server has not been very good. For some reason, he never sees the ground and has a pretty horrible ping time (possibly?). I’m not sure about the ping time yet because there are a few other factors that could cause slow ping like symptoms. For instance, the dreaded bug #100. I still have no clue what’s up with that one. So the odd thing is that you’d think (or I would) that these problems were related to not being on the local LAN with the server. Not true. I’ve logged in a bunch of times today from a T1 line. No problems whatsoever and the lag is minimal. Either way, I am very happy to have a tester, and he is certainly doing a good job and finding all these issues! Well, I guess if he had gotten logged in with no problems, he wouldn’t have much to test.
Speaking of testing. I tested that terrain from below over the T1. It went about the same speed it does over the LAN (actually seemingly faster?). That was a very happy thing. The way terrain works in MV3D is very experimental. Unlike in other games, the client has no preconception of what the terrain is shaped like. It all gets sent from the server to the client in little chunks. The fact that it didn’t seem to slow things down (other than my laptop with its puny 3d card having a bit of trouble rendering it faster than 40fps [which isn’t too shabby, but I get 400 on my desktop]) is definitely a good sign.

Back to more coding.