That’s an elite reference, I see what you did there.
Ok, progress has been slow this month, but there has been progress. So far, I’ve got some good stuff working, and I’m happy with that. I’ve got a few things to tick from the checklist, specifically, It’s pretty much back where it was before I broke it. When I picked up the repository, it didn’t even compile. Lots of head bashing later and I’ve got something that works (mostly). A few of the widgets are broken, but I’ve completely re-hashed the entity model and the contact model.
The entity what now?
From the clients point of view, it would get information about “stuff” from the server. This came in the form of an entity. Every different entity type (weapons fire, planets, suns, ships) all had their own class. This was already causing me a nightmare (for example, there were owned and non-owned varients which exposed read-write behavior or read only behavior) but it really didn’t fit well, and would have been a complete and total nightmare to maintain, and caused significant headaches when entities became “owned”, as I had to keep track of who had what class and make sure they received and updated to the new class. Now, the client only has one entity class, and attached to this are behaviors.
Sounds cool. What is it?
The idea is that as the client knows more about an entity, it will tag it with a behavior. This thing has a position in space? It now has the ISpatialPositionBehavior. It can be flown? It now has the IPositionalControlBehavior. The key thing is that they are interfaces, so can have umpteen different implementations depending on what, where and how they exist (for example it might wrap a call to the server to request a position update). The added bonus is that anything that consumes an IPositionalControlBehavior can actually consume anything that implements that interface. So, it could be a ship, or a missile, or a wing man…
Ok, so what else?
What do you mean what else? That’s a really elegant way of changing behavior of my objects at run time without having to redefine an object! Pah! No pleasing some people. As I’ve been re-implementing various bit, I’ve come across a few bugs (which I’ve done my best to squish). However, I’m spending increasing amounts of time chasing data, which is a pain in the arse. What I mean is, trying to specifically identify what the back end data is that is causing a glitch that I can see. I just flew through a ship, and neither of us blew up. the question is why? Where was I, where was the ship I thought I flew through, what positions were we both etc etc. To that end, I’ve started implementing a DDU interface. It’s a simple web site using MVC over ASP.NET and should allow me to get to grips with stuff that is happening inside of the client in real time.
Ok, what about Gravity?
Yeah, so the issue that was mentioned in my previous blog, regarding massive client/ server lag issues, it turns out was Gravity. When I looked again at the code, it made me cry a little inside. Although I was being vaguely clever with some of it, it was completely inescapable that I had accidentally introduced a triangular number performance algorithm. What this is to say is that every entity has to look at every other entity in order to determine it’s gravity calculation. So, if there are 10 entities, 55 calculations have to be made. When we get to 100, it’s 5050 calculations. by the time we get to 1000 it’s 500500 calculations.
Yeah, so that’s bad.
Till next time!