Thursday, May 10, 2007

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.

No comments: