Ok, so you’ve had a load of stuff, and the last thing was you squishing a very long standing bug.
Yeah, squishing that bug was immensely satisfying. It represented a bit more understanding of a few things for me, as well as seeing unit testing, the direct3d work I’d been hammering my head against and a few other things, all finally come together. With that in place, it meant that I could finally get to work making the whole thing compile again.
What, how do you mean, make it compile again?
Well, basically all the work I did in January on the client, effectively broke the server. A whole load of types were simply removed as they were no longer needed (to do with how the server sent information to the client). The way entities were represented was completely re-written (see previous posts on inheritance structured entity data types now being a single class using composite aggregation) meaning a lot of the code on the server was completely out of date and superfluous and just plain wrong. So, I set to with a flamethrower and attacked it. It was quite liberating. Removing a whole load of classes which simply didn’t need to exist, and had comments even questioning why they existing, removing methods which belonged to entities (which was never going to be maintainable) which now belong to behavior/ property/ metadata classes. There was one particularly satisfying bit were I started to re-write the collision detection and handling code, and it just worked (well, from a reading the code point of view anyway!). A lot of good things were factored like that, away from method calls on things that were utterly inappropriate and into their own class. It wasn’t all great though. As I’ve previously mentioned, I know I’ve broken a WHOLE load of stuff, and a whole load of stuff that I don’t even know.
What’s your next step then? I mean, how are you going to approach unbreaking all that stuff?
Unit testing basically. I know, I know, I keep banging on about it, but it really really does make developing soooo much easier. Take for example this whole EntityDescriptor mess that I was on about the other day. I’ve half heartedly stated a constraint (you can only have one of something) but never really worked it through with examples, or tested the code. For example, do I distinguish between interfaces and classes? What if one class implements two interfaces? How will that work if I try to add a different class, implementing an overlapping interface? Would the code, as written, allow two classes that both implement the same interface? And what about the retrieving code. How well does that handle some of these odd edge cases? There really are so many things about this, which seemed a good idea at the time, but will probably come back to bite me, purely because I don’t have a full understanding of how I expected it to work. So, by writing a unit test around exactly that, I’m forcing myself to confront and then define (for the tests of time) exactly how I’m expecting certain things to behave. This is great, and means I’m much less likely to get to a position where I create a function, come back to it later and tweak it such that it works for how I’m trying to use it and have then broken the original function is an odd and subtle way. I’ve got a unit test sat there telling me what the method is supposed to do!
Ok, you’re starting to sell me on this unit testing malarkey.
And so I should be. It’s already saved me a couple of times from costly errors. Ok, so apart from the descriptor stuff that I seem to have done to death now, there is a whole heap of other stuff that got refactored. Some of it made great sense. Some of it made kind of sense, but other bits were just very much get the fecking thing working as I don’t understand at all how I want this thing to work. A great example of the latter is the updating of the world data. I know that I want each segment of the world updating to be in it’s own stand alone class. So rather than have a method that says “Do collision detection” I want to be able to have a class which does that and exists in a pipeline, allowing me to change the order in which these things are executing by just changing the way the classes are populating into a list.
As for something which is half baked, but kind of right, well, I guess that’s the universe view. This is a view that represented, on the server side, a clients view of the world. It populates from the full universe and represents the subset to which the client is interested in. Quite how/ who decides how this happens is still to be determined. It will definitely follow the model I’ve started down, of having source classes which each represent a particular aspect. The two that spring to mind are one that will allow gigantic things to show up (think planets and local stars) proportional mass/ size to distance etc, but also perhaps another which will only show things within a few hundred km in high detail, and allow diminishing detail the further away entities get.
Anyway, I think that’s quite enough for now!