Where have you BEEN?!?!
Ok, it’s been a while, I know. I’ve been busy! First week in april I went to the wedding of one of Jo’s friends (which to be fair, was very nice!) since then it’s just been none-stop with one thing and another, including the mind bogglingly awesome portal 2, But, with this insanely long double double weekend event, I decided that I needed to say enough was enough and get back to development. There was also the event of dogsbody dying. I’ve now sent off the drive, and replaced it with an 80gb one as temporary measure so that I can continue with development…
Ok, so what have you got done in the mean time?
Well, if you cast your mind back to the last post, I’d just got balls of weapon type things flying around, but firing lots of them was causing the server to slow to a crawl. I spent a good couple of days googling ways to speed up database access, (improved SQL commands, locking the tables prior to use, moving the database onto a fast flash drive) but none seemed to make a massive amount of difference. In the end, it was taking about 200ms to update the position of 1000 entities. This is quite clearly not helpful at all! I’ve stuck a book entitled high performance MySQL on my amazon wish list and e-mailed/ text my brother to say that he still owes me a birthday pressie, but so far I don’t think he’s got the hint. I’ve read about something called MySQL cluster, for high performance distributed databases, but I’m not sure if this will meet my needs, or even what it actually is. I’ve decided to put this problem on hold though, in order to meet the 1st of may deadline I’ve set myself…
Ok, so things aren’t going swimmingly, but surely you’ve got something done?
Well yes. Like I said, I’ve put this particular issue on temporary hold until I can get a firm grip on other performance issues and how I want the server to behave in certain circumstances. So, soldiering ahead with some of the other stuff, the first of which was to make items “time out”, e.g weapons fire only has a short life span. This was relatively easy to do, a time stamp is stamped on an entry at creation, and it’s evaluated every time the server updates the positions of stuff. Thinking about it, and having read an article on eve-onlines dev blogs, they imply that their physics calculations are only carried out once per second. Which, means that their database isn’t quite as impressive as I thought it was, but, is still impressive. My original idea was to have many servers serving the same solar system, with all sorts of other wonder, but I’m starting to think that that is just too much wishful thinking, and that maybe one server per system is the way to go. It certainly would simplify some of the database access stuff, and would then allow the server a lot more freedom with how it manages the world (less calls back and forth), but, at the same time, that would then relegate the database (for movement parts anyway) to purely the role of data backup, which removes at least some of the performance constraints. For now, this isn’t much of an issue, and I’m content to leave it as is, pending the whole performance mysql book thing.
We were promised pew pew.
No you weren’t. Seriously. Go back and read it, and I made the distinct statement that pew pew was some distance off. I’ll wait here while you do that.
Ok, we still want pew pew…
Ok. I shall ignore that for now. Once the server was no longer updating and had in fact removed the expired entities (in this case read as energy balls), they were no longer being processed, and new clients wouldn’t see them, but, they were however being stuck in space and could be flown up to and even through. They caused no interactions, as they were essentially ghosts of balls past, but they were a nusiance nonetheless. What was needed was a way of the server telling the client that certain things had been removed from the game. This raises the question of “removal in a puff of logic” or destruction in a BOOM kind of way. I’d kind of been toying with the idea of removal and destruction as two separate events, but I think this might be a little too complicated to implement, to start with anyway. I’ve kind of liked the idea of the client having to marry up the removal of a ship because it’s been blown up, with a big explosion where it was, as apposed to being told that a particular ship has been destroyed. It comes down to the data, as received from the server, not being perfect, but deliberately so. I mean, If it looks like a duck, moves like a duck, and quacks like a duck, then it’s probably a duck right? Why would a ship being replaced with an explosion be any different? It certainly opens up a can of worms later on though… Anyway, I decided on removal of energy balls. Fortunately, I’d thought of this a while back, and there was an unimplemented thread that requried minimal stitching up to get it to work. Voila! balls that disappeared after a few seconds.
WE WANT PEW PEW!
It’s a good job I just finished the first draft of pew pew. It’s not perfect, and absolutely far from it. It was a relatively easy prospect to add very rough, radius based colision detection. This now means that balls of energy, colliding with a ship will result in the ship being removed. There is no explosion effect (yet) but it works: client with guns and death. It’s not tested yet, but there is no reason that it shouldn’t work first time. Two ships, logging on to the server together, should see each other, and be able to shoot the crap out of each other (or crash into each other!)
We love you.
I know. This has been an insanely long post, even for me, so I shall cut it off shortly. I’ve got a few things I want to tweak, and Icarus will be ready for version 1.0 release! I want to add some kind of basic HUD, a cross hair and some kind of threat indicator to let you know where the other ship is. Speaking of the other ship, I think it’s time to get rid of the default model and replace it with something a little more… suitable. I should be able to just update the appropriate actor class (responsible for anything drawn on the screen) to load the model from a mesh as apposed to directly creating one. Should is the operative word here…