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.

Mmm updates

Current build of Asteroids.

During today's tutorial at university, Pete and I had to compile a version to show our tutor to show him some of our progress. But to do that once again I had to change the GUI from Java 6.0 to 5.0, because I built the GUI in Netbeans it used all the latest components and even throws in a bunch of its own (netbeans) components. So I had to resort to using a Null layout and reorganizing everything manually in the code, I probably should of done this from the beginning, but I was lazy and just wanted to something quick to use as a prototype for testing. Besides the GUI will eventually be coded in OpenGL and be apart of the game. Anyway when I got that going, we showed our tutor and he was happy with our progress, he asked if we could have a working version of the events by next week and we assured him we would.

Later after university, I continued working on the game, I was observing a strange problem were when ever you moved the ship and smoke would be emitted, when the smoke finished rendering everything would disappear for a 1/4 of a second and then come back. I literally spent about 2 hours looking for the solution to the problem, I looked over just about every single line of code to do with smoke about 10 times over. It wasn't till the 2 hours were up until I actually discovered that the game was progressively setting the alpha value to 0.0 when all the smoke was gone, and OpenGL being the state machine, it was making everything else's alpha 0.0 and not reseting the colour properly. I simply made the emitter reset the colour and alpha values back to normal when the smoke was finished rendering. Problem solved.

Pete had been working with the smoke for a little while, and had all of the logic down pat but really has no idea how to draw and texture with OpenGL, so its my job to finish off the smoke with its texture and get it blending properly. Pete based what he put in our game off an example I sent him of another smoke emitter written in C++ (Note: I'll post the link at a later date, I don't have it available at the moment) which already had a smoke texture, so I grabbed that to use as my test texture. After a bit of playing around I got it working, but I found the texture I was using from the C++ example to be causing the smoke to become white when it was really dense, so I jumped into Adobe Photoshop and just dulled it down a bit so the center of it wasn't completely white anymore, this worked a treat. See below for my textures and some examples of the smoke in action.

C++ smoke texture.

Updated smoke texture

Examples of smoke emitter in action:

Lastly I updated the smoke particle class (object) to include a growth rate, the rate at which the polygon increases in size over time, so that way the smoke particle looked more realistic and gave the effect that it was dissipating.

Pete's been hassling me to change from Netbeans to Eclipse, so today I decided to give Eclipse another go. I had previously attempted to get Eclipse to work at the beginning of the project, but I encountered problems getting JOGL to run/work, but now I understand how to setup the libraries and have done it so many times that its become almost second nature, I found it pretty easy to get the project moved over to Eclipse. Another reason why I switched over was because Pete totally screwed up the CVS server and wound up putting the source another folder deeper, so now we have "RetroWars/retrowars/retrowars/". It probably looks pretty funny but I couldn't be bothered fussing over the CVS trying to get it right again, so I'm just going to use what ever setup Pete has. After checking out the source, Eclipse decided that I had about 500 errors, compared to Netbeans 0.0, being unfamiliar with Eclipse I wasn't aware that it was set to a lower source level than what the game requires, the source level is what version of Java Eclipse uses to correct your source. The default source level in Eclipse is 1.4.0 but todays JRE (Java Runtime Environment) is up to 6.0, so I so selected 5.0 the happy medium for now because not all people have version 6.0 yet, and that includes all the university computers. One thing Pete did tell me about Eclipse was that it gave a lot of warnings related to redundant references and code, so I routinely went through the 200 warnings we had and cut it down to about 40. The left over warnings are references to some pieces of code I don't want to touch just yet or they are saying that we are using static variables in a non static method.

Previously I had put together a group of asteroid pictures and its now time to implement them. At present the asteroid class is just using the one texture so I converted it to use an array of textures (the asteroid textures), because I had a couple of different types of asteroids I got the constructor to pick a texture randomly based on its size, if the asteroid was the smallest size it has about 5 textures to choose from. It was important to have a set of different textures so that the player will feel more immersed in the game. Another little thing I noticed was that none of the asteroids were spinning around, if the asteroids were spinning it would give the illusion that they were moving though space, so to counter this I threw in a couple of variables, below are the variables used and their purpose:

rotated - The angle the asteroid will be rendered at. This is updated each frame were the rotationSpeed is added to the current amount of rotation. OpenGL takes care of rotating the polygon so keeping the double within the bounds of 0 to 360 is not necessary.

rotationSpeed - This is the speed in which the asteroid spins. This speed is determined randomly when the asteroid is created and is between -1.5 and +1.5.



Now with all the asteroids setup and going, I thought I would give our first game (Missile Command) some attention, Pete set it up to have some fire and smoke trailing behind it but I don't think he put to much effort into getting it right. One thing I wanted was to have the missile leave a trail of smoke behind it so the player could use it to judge the trajectory the missile is on, just like in the real Missile Command you can see a line following the missile. I attempted to tweak all the settings in the hope of getting it just right, but in the end had to luck. I'll get Pete to take a look at it since its his area of expertise.

Ok, Pete and I have been talking about the scoring system for a few weeks now, we have been discussing how the game triggers events and keeping a record of combo's and scores so they can used to make up statistics at a later stage. Pete's been telling me he loves having statistics and wants to implement a handicap system, were if your a really good player the game will be harder for you in comparison to a newbie. I'm fine with all of this and Pete seems to be leading this section so I'm more than happy to let him write it up and test it all out. It's basically my job to write up the OpenGL code and make sure the thing looks good. So at the moment Pete has a score item, which is used to store the value of the score and where the score comes from (e.g. asteroid). Using this I coded in a render function designed to draw the score to the screen, and made use of the Score Manager to render each score as they were created. Firstly I jumped into Photoshop and started putting together a set of numbers, I went through a lot of fonts but there was one that stood out the most and I thought it would fit the look and feel of the game quite well. Below is the number set I put together, the reason it is drawn like that is because I want to make use of texture coordinates to point at a specific number, so rather than having ten textures in memory I only have one. As you can see below their are two versions, but this is only to illustrate what the scores would look like on a white and black background respectively. The actual texture uses the black background with alpha transparency so the numbers can be applied to any background.

White version

Black version

Now that I had my texture it was time to make use of it. I started out by drawing a large polygon to the screen and manually changing the texture coordinates to attempt to get the right number, but it was just talking to long. So I made use of the keyboard and setup a set of keys to alter the values of the texture coordinates at runtime, after each alteration it would output the texture coordinates to the console. Using this method I was able to easily move the texture around the polygon and get accurate coordinates, when I had each numbers coordinates I put together a 2D array containing all of the values so that the coordinates could easily be read and switched at runtime. After implementing the texture coordinate array into the score renderer it was just a simple matter of rendering the right numbers to the screen, I used some basic Java methodology to convert the value into an array of integers I could use with the texture array to pick out the right numbers and print the poly's to the screen. The above description is a huge simplification of the process, which actually took me til 4am in the morning to get working. I had to leave the eye candy stuff for Pete later that day.

Score overlay example.

Lastly I created this new ship texture, I nabbed it from a texture set available from "The Lost Garden" blog I mentioned in an earlier blog. The ship looks pretty cool, I'm not sure if it really fits in with the whole space ship feel, but meh, ill change if we have to later.

Ship texture.

Ok, thats it. Hope you enjoyed.