Collaboration

Testing & Debugging

Today has been a productive day, I caught up with Pete over MSN fairly early in the day we spent most of the day working away on the project and discussing problems/issues. The first order of the day was to get Pete to test what I have done so far on his machine and help me debug the engine. We instantly encountered a problem with the texturing part of the engine, Pete informed me that he couldn't see the missile, city and turret textures on his machine, despite them being there and working perfect for me. After trying just about everything we could think of I remembered that usually textures are supposed to be sized in a factor of two (e.g. 8x8, 16x16, 32x32) and after checking the sizes of the problem files they proved to not be a factor of two. I quickly changed them and uploaded it and Pete informed me that they are now working as expected. We also discovered that Pete's machine was having problems with file paths and wasn't reading the TGA images I had made, but it was reading the Bitmap files. The only difference between these two methods was the way the file was retrieved, so to resolve this I did what ever the Bitmap function was doing. The bitmap function makes use of a static class titled "ResourceRetriever", the RR is specifically designed to read files inside a Jar file. After making the changes everything was working as intended.

I referred Pete to a good Java Game book (Developing Games in Java - David Brackeen, .et.al) which talked about an easy method of collision detection and how to make use of it in a simple game. I read quiet a fair bit of useful information in that book, including things like Thread, Memory Management, Optimization and Networking. I will be implementing different things from the book at a later stage if Pete and I actually decide to release the project and try to get a fan base. But for now, I just wanna get something operational and using our theory of multi-player event based play.

Networking

While Pete looked into the collision detection information I started working on the Network part of the engine again, in an earlier post I think I mentioned that this section will need some more work a little later on, well the time has come. I started tweaking what was already there, by reducing the amount of code and making methods for things that are reused several times. I also started adding some checks for different indicators that the server and clients would be sending and retrieving. These indicators are listed below:

Server:

• /event - This triggers the server to send an event message to all clients, except for the one that sent it.

• /ready - This tells the server that the client who sent the message is ready, which then communicates with the ServerManager telling it to increment the ready count.
  

• /unready - Same as above but decrements the ready count.
  

• /loaded - This tells the server that the client who sent the message has finished loading the game is ready to start playing. It also communicates with the ServerManager telling it to increment the loaded count. Once all clients have finished loading, the server will then send all clients the confirmation to start playing.
  

Client:

• /event - The client waits for this command to be triggered by the server. When this is triggered the client makes use of the Network Bridge (designed to bridge the gap between the engine/game and the network communication) to then invoke the "onEvent()" method that developers use to cause a negative effect on the player.
  

• /load - When the client receives this command the game will begin loading all associated textures, display lists and any other files required to be loaded. When this action is finished the client returns a "/loaded" command back to the server. This also makes use of the NetworkBridge to invoke the loading procedure.
  

• /start - When all clients have successfully finished loading the game and has sent confirmation to the server, the server will send this command to each client telling the engine to commence gameplay. This also makes use of the Network Bridge.
  

When I was finished coding, I got Pete to help test my current implementation, but encountered a few problems with the ready count not operating correctly (only because I forgot to decrement the count when a client left the server) and the game not actually commencing although it had reached the loading stage. After making a few tweaks I eventually ironed out all the wrinkles and it is working as expected. At this stage I think we have made great progress and things are looking solid, I am confident that we will have a functional demo by the end of this semester. I also changed the network GUI around slightly to be more functional with the current setup. I added a ready button, moved the trigger event button to the top and make sure the start button was only operational by the host.




The Loader

Ok, one of the things I found whilst coding the texturing part of the engine was that it can take a little while to load textures, and can leave the game hanging for a good second or two before anything actually occurs. So when I encountered this I instantly recognised that were going to have to build a loader for all these textures, but also at the same time we can take advantage of having it and use it as a waiting screen to synchronise all players when they begin playing the game. It wouldn't really be fair if a player was still loading whilst another was already gaming and could possibly cause an event to be triggered. In building this loader it meant that the current Engine build would have to be slaughtered and lot of its initialisation code be removed and be placed into the loader, its actually a much better method of operation really, we would probably want to reduce the amount of code required to be run in the engine to maintain a good framerate. Because the game uses all textures, I made up a loaded screen texture with the words "loading" so the player knew something was going on. The loader also makes use of a TextOutput object to inform the player of what stage of loading they are up to, these stages are:

- Loading Textures
- Loading Display Lists
- Waiting for players...




Explosions!!!!

I also put together a little explosion animation. It was pretty simple actually, I just required a good set of explosion images (which I found amongst the open source 8bit image set I found earlier).

How did I do it? Behind the scenes in the explosion class it knows how big each explosion is, so in knowing that I can then divide the maximum size of the explosion by the 7 states it takes to start and end the animation, which then gives me a rate of for many frames per state is required.

rate = max / 7

Once I have the rate I can then make a check that the radius of the explosion has exceeded the rate. If it has I want to change the state to the next explosion image.

if(radius > (rate * CurrentState+1))
CurrentState++;


Thats about it, it works a treat and is relatively simple.


Pete's Enemy Missiles

I talked to Pete about how we should implement the actual game play, where the player has to compete against something. Now we want the game developer to specify what that action is because each game will be different, and each might require a completely different setup. I did suggest we make something like a Level Manager, and you tell it what objects the player is competing against and so fourth, but after some thought it I found it would probably be to restricted and not give the developer enough freedom to set their own rules. Anyway Pete opted to write this up, which only took him no more than 10-20 minutes to get a functioning enemy system happening.


Turret Texture

I found this other picture amongst the 8bit set which sort of looks like a turret, and the bonus thing about it is that it already has 3 states drawn for it (ready, loading and demolished) which are exactly what we are looking for. We might have to update it thou to make it look more like an actual turret later, but for now it will do as a place holder. Below is the original picture from the set.





Well, thats about it for today, below is a picture of the game so far. We have almost finished our first game, all we need now is the collision detection done and code up and actual event and that game should be 99% done. I think ill add in a trail for the rocket (like in normal MC) so the player can see the trajectory of the rocket.