Finishing Touches

Pete and I found a problem with Missile Defense last week at university, whilst we were trying to get the game up to scratch for some beta testing we discovered that it was freezing at the end of the game, and either of could not figure out why. I have been busy with some other things lately so I hadn't had the time to sit down and look into it closely. But tonight I spotted the problem, it was almost a fluke and if I hadn't done what I did I doubt we would of spotted it before our presentation on Wednesday. What was happening was when all of the players cities had died, the code was attempting to send more tanks off to kill the cities, but the code was getting caught up in an infinite loop looking for an available city. To resolve this I changed around the code so that if all the cities are dead it would break out of the loop and continue on, this resolved one of the major issues we have been facing the past week. Horray.

I created a set of player head textures, they are designed for the Player Manager and allows players to see the progress of their competitors and to see who's still alive and who is sending you the events. Below are the head textures.


After doing some play testing with Pete, we've found that we are at the stage were the game is almost complete and were simply making superficial changes and tweaks to polish the game up. Pete's also done a make-over on the GUI, below is a picture of the java based GUI with a custom look and feel.


So, tomorrow Pete and I will be doing some more play testing and tweaking the game a little more to try and balance the play, and also start to put together our presentation for Wednesday.

Thats it for now.

Getting Close!

Missile Defense

Today after uni Pete and have been working our butts off in the hope that we can get the game ready for the scheduled Beta Test tomorrow. Pete has been working on the concept of Power ups, a Power up in our engine doesn't alter the game in any way it is designed to send events off to other players to increase their load. The reasons behind implementing Power ups was to give the player some incentive to move around whilst playing Asteroids, during our testing sessions the both of us found that most players would stay in the middle of the screen rotating around and not moving. By introducing Power ups we hope to break this pattern of behavior and reward risk.

I started putting together some new textures for Missile Command, but rather than following the same theme as Missile Command Pete and I both decided to change the game to be land based. The objective of the player is defend their bases from the onslaught of kamikaze tank drivers, hell bent on blowing up things. In that respect we opted to rename the game from Missile Command to Missile Defense, I think it suits the game much better. Below is a background texture I for Missile Defense, I drew this one myself in about 5 minutes.

Background I drew in Photoshop.

I also added the below turret texture, it is split into two parts so that we can have the turret move and rotate on the base. The texture might not look much like a missile launcher, but it was the best we could do in the time frame we were given. I coded it so the turret followed the location of the mouse, its small things like this that really make a game in my opinion.

Turret Textures.

I created a new Tank Game Object, this object is not much different from a missile, but it uses different textures. When a new tank is generated it randomly chooses a texture and tank type, to keep the game as random as possible.

Tank textures.

I created a new texture for the city object, I also make it randomly select one when the object was being created. Each city has two states, a normal state and demolished state.

City textures.

I made a helicopter animation, using a set of helicopter textures. Below is the method I used to get accurate texture coordinates so the animation flowed properly. The idea behind adding the helicopter was that when a large event occurred in Missile Defense, the helicopter would appear and begin shooting missiles at the players cities. It would be up to the player to shoot down the helicopter.

Working out the texture coordinates on a large poly.

I updated the blending mode for smoke particles, previously the smoke particles were looking very white but we want the smoke to look more gray like what the actual texture looks like. I used the glSandBox again to do some more tests to figure out the optimal blend mode. In then end I got the particles looking much better, so I can't complain.

GUI Tweaks

Its getting pretty close to the Beta test and I haven't heard a word from Pete since last Wednesday. I'm getting a little worried he's not going to show up or help me try and get the game to a beta test stage by this Wednesday. Ahhhhhhhhhhhhhhhhhhhhh.

I updated all of the asteroid textures today, I found that they had a black border around the edge of them because when they were being loaded into memory OpenGL is using a linear filter (Anti aliasing) and causing the alpha channel and edges of the asteroids to blend slightly. I think the problem could of been solved by increasing the alpha testing, but I'm not sure what other side effects that might cause, so I just did it by hand in Photoshop.


I also updated the GUI so that it started a count down timer when the host player begins the game. Earlier when we were testing the engine, we found that having the game pop up instantly would catch people off guard or they could be in the middle of typing a chat message and the game would take the focus. So to help with the problem I got the GUI to create a new thread and count down 5 seconds, whilst having the server distribute the message out to the rest of the players.

Another little detail I discovered was that it was impossible to know when or if a player had closed his window and was ready to play again. With all the testing we have done so far, I discovered that having more than one window/instance open at the same time can cause some problems with textures and different modules. On the contrary though the game can be run multiple times giving the player several game windows, its just that the engine doesn't like having two instances of the same game on the 1 client (GUI). To fix this dilemma I modified the networking code so that when a player closes the window the engine fires a trigger off to the server notifying the server that the player has closed the window. The server than makes a count of how many players have closed their window, if all the players have closed their window then the GUI will allow another game to commence, otherwise it will inform the host player that not everyone has closed their window yet. I guess its important to make the engine/game as stable as possible and take every precaution available, just in case these things do happen.



I'll leave you with this picture of the GUI, I'm not certain if I have posted it before or not, but it demonstrates the count down timer very well.

A Sound Manager

Today I added a new Sound Manager into the engine. I got a lot of the base code from a great Java Game development book (referenced below). The sound manager works by creating a pool of threads (16 in total) and when a sound is parsed to the manager it sends it off to the pool to be queued waiting for a free thread to execute the sound on. The manager also makes use of a Sound object class that allows you to store the sound information as an object making it highly reusable and eliminating the need to read the file more than once.

Whilst testing the new sound manager, I discovered that the sounds I was using all had different bitrates and sample rates, some were 22050Hz while others were 44100Hz. This was causing a problem because the manager only allows you to use only one audio format, so I downloaded a program called "EArt Audio Converter" it is designed to convert all sorts of file types (mp3, wav, etc) from one type to another. In this instance I only wanted to use it to convert my wav files into a new wav audio format and make them all the same. The version I used was only the trial version, and according to the interface it would only convert 50% of the file, but after converting a couple of files it seemed like it was doing the whole thing, maybe the files are to small to be cut short *shrug*.

Eventually I got all the sound files I wanted to test out to use 44100Hz at 16bit stereo, its pretty high quality I think, but I don't particularly care at the moment. So any of you developers out their, just remember that you have to convert all your sound wav's to this format or it wont work.

Lastly, at the beginning of the project I noticed that the original GLDisplay code used an FPSAnimator which is apart of the JOGL library. The FPSAnimator acts like a thread that executes a set of OpenGL functions which can be used to render things to the screen, their is another one just like it called Animator. Both of these objects do the same thing by making the java source code execute the OpenGL functions, but with the expection that the FPSAnimator is specifically designed to restrict the frame rate to a desired rate, the rate is not guaranteed but the FPSAnimator does try its best to limit the frame rate. The Animator is specifically designed to run at the maximum amount of frames per second, and this can be achieved by turning v-sync off (at the beginning of the project I was getting 3000 frames per second). Anyway, so at the beginning of the project I replaced the FPSAnimator with the a normal Animator because for some unknown reason it was acting strange and rather than limiting to 60 frames per second it was averaging about 40. It was only recently after doing some testing at uni that I discovered that having a faster frame rate increases the speed of gameplay and possibly makes it harder to play than we intended. So to counter this I put the FPSAnimator back in, and played around with some of the settings and worked out that by telling it to schedule at a fixed rate eliminated the early problems I had. It may have also improved the performance of the engine because the FPSAnimator attempts to avoid using all the CPU time.

Retro Wars on Linux

I got Super Retro Mega Wars working on Linux. I checked out the project using Eclipse, and got it to download all the files. It's pretty easy installing JOGL, but I did have problems actually getting it to run, I think Linux has some path problems because I couldn't get the JVM (Java Virtual Machine) to register/detect the JOGL .so (similar to dll) library files without forcing the IDE (Eclipse/Netbeans) to look in a specific directory. I believe Pete and I will both have to do some extensive testing on Linux to make sure users can easily setup and play the game, we might have to look into compiling the project with Ant and using someway of forcing the Jar file to look in a specific directory for the library files. But I'll do that when I finish university.

Below is a picture of SRMW on Ubuntu:

Week 11 starting to finish up

Winning display.

This week both Pete and I asked Matt if we could host a Beta Test during next weeks tutorial session. He was pretty enthused to have the opportunity and seemed pretty impressed that we had reached that stage. I think we still have a fair bit of coding to do, but we are definitely ready to get some real testing done, and it needs to be on a bigger scale.

We set about getting some serious coding done during our class, one the first problems and most sever was with the collision detection. We discovered that the collision detection system wasn't colliding with objects as they should. Both Pete and I attempted to rework the Collision Manager and put in as many debugging messages we could to help diagnose the problem. The problem seemed to occur after Pete had made changes to the Vector class turning it into a base class with two different types of vectors as sub classes (Cartesian and Polar). We end up spending most the day trying to fix this problem by optimizing our code and changing it around to be more modular, but none of this seemed to resolve the problem, but it did improve some performance in the game. In end after close to 5 hours of looking over the code, Pete discovered that it was actually a very small problem inside the Vector class were it wasn't comparing the location of the two objects being checked for collisions, the problem was fixed once Pete updated the code. This seems to be the problem the both of us are visiting more frequently lately, the more complex and large the code gets the hard it is to find and debug these problems no matter how big or SMALL they are.

Pete's been talking about the Combo system for about a week or two, so we stepped back and started talking about how the combo system should work. To start with we both agreed that the combo system should be the main source for triggering events to other players, so depending on how big the combo was determines the strength of the event. Based on this theory Pete set about coding it all whilst I worked on other things.

I tweaked the GUI some more, this time I brought back the Listbox on the right side to list all the available games. At the moment, it is not possible to change which game you play unless you physically change it in the source code. So I setup the Listbox with both the games we have so far, and made it switch the active game each time you select one. The engine then gathers the active game and creates a new instance of it.






I added in a couple more triggers for the engine, this time to deal with when the player dies or wins the game. First of all I created a new texture in Photoshop that can be used for more than just 1 thing, by moving around the texture coordinates I can use the one texture to get all three words off it. I decided to update the "loading" texture as well because I have been using one specific font for everything else in the game, so I thought it would be fitting to use it here too to maintain the look and feel.

After doing some testing with Pete I found the winning triggers were not working accurately, the engine wasn't reporting the correct winner, in some cases reporting all players to be losers. I'm not sure of the problem at the moment I will have to trace the data flow to make sure everything is being set properly.

More Updates

The old blue bullet was beginning to annoy me in Asteroids because since changing the background (also blue) its become harder to see. It was also a little to big in comparison to the ship. So I hopped into Photoshop and put this new bullet texture together, its pretty small but it uses more predominant colours (red and orange) and stands out a lot more, I'm also happier with the size of it in relation to the ship.

Another thing that has been annoying me is the fire that comes out of the back of the ship. At the moment the emitter actually starts from the center point of the ship so a lot of it is actually rendered behind the ship, and also because it starts from the center point it turns/curves all wrong. I attempted to get the fire to sit at the back of the ship by applying some extra units to its location, but in doing that it was producing undesired results were the fire emitter would either not move from the center of the screen or it would move in strange directions around the screen.

Pete and I were talking about combo's and I suggested earlier that we should have a pop up when you complete a combo, weather it pop up were the combo ended or just somewhere on the screen. I made the below texture, nothing much to it at the moment.

Combo Texture.

I've been looking at Asteroids and having the ship firing just the one bullet doesn't look right, I decided to make the ship fire two bullets, one from each wing. The tricky part is trying to get the bullets to fire from the wings all whilst the ship is moving around and rotating. I'm lucky Pete wrote up some good vector classes for me, I made use of a Polar Vector to move out 90 degree's towards the wings, doing that seemed to work a treat.

Ship firing two bullets.

I've been trying to design some art for Missile Command, I am trying to use Illustrator as my starting point and try and gain some inspiration from the vector drawing, but my drawing skills are just to poor to be able to draw anything useable. I've been asking around at uni and in forums and all sorts of places for people that can draw and possibly help us with some art, but it feels like I'm hitting my head against a brick wall. Were going to have to figure something out soon once the desperation sets in.


I coded some health into the players ship, the idea being that when it reaches zero the player's ship explodes and he/she loses the game. If a player collides with an asteroid the velocity of the ship and the asteroid is taken into account when calculating the amount of damage the players ship will incur, so if the player is traveling really fast and collides with an asteroid they will die immediately compared to traveling slowly and tap the asteroid only causing slight damage. I got Pete to add an explosion effect to the ship when it died that turned out pretty good.

Pete asked me if I could update the networking code to include the strength of an event between players, so each client can interpret the strength according to the game style. For example, Missile Command wouldn't be able to handle a 100 hit combo from Asteroids because it would spawn to many missiles, whilst it would take to long to gather a 100 hit combo in Missile Command leaving Asteroids with nothing to do. Anyway I simply updated the current command for triggering an event and tacked on the strength, when the event is parsed into the client it is split down into sections allowing each part to be read separately. After writing it up and doing some basic tests it worked as expected, now Pete can continue to work on the scoring mechanisms for the game and make use of the strength.

When Pete was finished doing some work with the new event code we decided to some testing to see if it would work in a real situation and to check out the cause and effect of sending events down the network. After a couple of tests it proved to be a success, the games were reacting just how we had anticipated but with the exception being that we hadn't really written any code to normalize the incoming strength so we were experiencing a lot of asteroids appearing on the screen at once, which meant the average time spent playing a single game was around 20 to 40 seconds. But either way, our original concept of having old retro games in a new multiplayer environment is being achieved and I think its bringing new life to some old classics.

Lastly, I tried to export the engine into a jar (executable Java file) using Eclipse, but after testing it I discovered that the GUI wasn't reacting as expected. The buttons were not reacting at all making it impossible to even start a game. I looked over the files in the Jar notably the manifest file, which is designed to contain the base information and references for the Jar file to read. I compared the newly created manifest file with one generated using Netbeans and found that Eclipse was providing an almost empty manifest. I replaced the eclipse one with the Netbeans one and the game began to work, this is interesting considering I thought that I setup Eclipse properly, but maybe I haven't.