Network improvement! (mini-update)

Just a small update this time.

After testing the multiplayer feature over the internet, I am happy to report that it was a massive improvement over the previous version. I want to offer my thanks to Nick, Ragnar and Jonny for the testing session, which actually turned into a game (sort of).

That can only be good right?

So it turns out that there is a silver lining to last week's cloud of despair. Having wrestled long and hard against the pathetic TCP protocol, I found myself having to confront a completely different beast: the pathetic UDP protocol. Yes, both of these network communication methods are rubbish, complex and not very efficient, but it turns out that UDP is at least allowing my game to work. So the silver lining is that I have been "forced" to learn two methods of network communication. It could come in handy one day I guess.

So while testing the online gameplay, I noticed a number of other problems. Apart from the ridiculous amount of accuracy needed to hit an enemy (as described in the last blog post), it became blatantly obvious that using sprites for explosions isn't going to work. The main problem right now is that explosions always appear - even if they occur behind a building. I'll try to explain what I mean...

The "art" of aiming and firing a weapon involves many senses, and a person sub-consciously makes decisions about the trajectory and point of impact, based on multiple factors. One of these factors might be the results of a previously taken shot. The same applies to videogames. And there is a big flaw in Tank while using sprites for the explosions. If I was to shoot at an oncoming enemy player, and my projectile was to go straight over his head and hit the ground behind him, then the explosion would obviously occur at that point. But as sprites are rendered on a 2D plane (namely "in front" of the 3D plane) then the explosion would appear to be in front of the enemy tank. This would make my brain conclude that I need to aim higher (in order to shoot further), whereas in reality, I am already shooting too far.

So once again, I'm having to make a pretty major change to the game code, in order to rid the program of it's current explosion routines. Which, I might add, took me ages to get working. So I am working on a prototype routine which involves a primary shockwave at the point of impact, and then....well, I don't know what yet, it's still a prototype. But I am hoping to integrate the "splash damage" collision detection into this new routine. Also, it's going to be 3D based, so it's possible that shockwaves and explosions could be partially hidden by nearby buildings.

Here is a video of the very first attempt at this. Bear in mind that the sprite-based explosions are still present here, but you should notice that the shockwave on the further building appears "behind" the closer building. Note, when I make the first shot, the shockwave routine is disabled. I turn it on for the remaining shots.

The video is only running at 30fps, but it's just to demonstrate what I'm attempting to achieve.

So this is what I'm working on right now. Once I have it working properly in single player, I will create a multiplayer version. This is my primary task at the moment. 

I'm still thinking about solutions for the "where the hell is everybody?" problem, and thanks to suggestions from friends, they range from overhead icons, through a minimap to a full-on proximity warning system a la Aliens!

This was meant to be a mini-blog, but as usual I've found myself banging on and on. Let me sign off by saying the multiplayer system is totally useable now (even though I have an idea of how to optimise it further if needed), and I can press on with other important things, like blowing sh*t up!