Super Retro Mega Wars

Finishing Touches

2007-05-28T23:23:00.000+10:00

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!

2007-05-22T14:32:00.000+10:00

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

2007-05-22T01:42:00.000+10:00

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

2007-05-20T12:41:00.000+10:00

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

2007-05-17T21:48:00.000+10:00

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

2007-05-16T17:30:00.000+10:00

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

2007-05-13T13:27:00.000+10:00

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

2007-05-10T18:18:00.000+10:00

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.

Music

2007-05-06T21:02:00.001+10:00

I found this website today, I was sort of browsing the net for other old style games and I discovered that someone else made use of a music format I had never heard of before. He referenced to this address for music:

http://modarchive.org/index.php?ArticleIndex

From what I can gather its a type of music format that lets people pick a bunch of electronic instruments and allow them to compose music electronically, but the most important fact about this format is that the file sizes are really small in comparison to mp3's and other file formats. It can be compared to a MIDI but about 100 times better, the website mentioned above contains a large library of music all made by contributing artists. I haven't discovered if the music is royalty free or free to use else were, but from what I can gather it seems to be open for use since you can download any song you want and play it no problems. This gave me an idea about implementing something that can play this type of file in our game! Thats when a Google search provided me with this solution:

https://jmod.dev.java.net/

This website is for a Java API someone is developing designed specifically to play this type of music format. I haven't looked at the website throughly but from first glimpse I can tell it is exactly what we would be looking for if we were to implement this type of music in our game engine.

This is exciting, if we are allowed to use the music in our game without any license or royalty problems it means we can have good quality music and low file sizes and we wont have to suffer with crappy old MIDI's.

Collision Detection Hmmmmm

2007-05-05T18:12:00.000+10:00

Well after all the effort I made in trying to thread the collision detection system it worked out to be pointless. In the end the actual thread was doing nothing more than looping and waiting, my original idea was to thread the actual collision checks so that it would check parallel to the renderer, but I found it was doubling or tripling up on the checks and causing more collisions than their really was. I want to be able to do something with it though, possibly have the cell purging and moving threaded, that might reduce the load, or should I thread the whole update process? leaving the engine just to render as is? Hmmmm I was thinking of slowing the thread to the frame rate (usually 60fps) but without testing it I cant be sure it would give accurate results.

I think I'll just dump it for now, so that way collisions are accurate. The only problem I'm having now is that some objects (notably the player ship) isn't colliding with some asteroids as expected. I think we will have to look into the collision detection much deeper to find the hole in our code.

More Tweaking

2007-05-04T15:33:00.000+10:00

Right, in my previous blog I didn't go in depth about collision detection and left it for later, here I'll talk about it more and fill you in about what I've been doing. Previously I had explained that I threaded the collision detection, to be more accurate I only threaded the collision checking and not the rest of it that dealt with organizing game objects into their cells. Because more than one thread (The main thread and the collision check thread) was accessing the same lists I had to try and achieve some sort of synchronization, I don't want the engine to add an object to a collision list in the middle of a check and have it be missed or removed before it can be used or checked. Java's approach to this type of synchronization is were you nominate which object you want to use and that object becomes locked to all other threads until it has finished doing what its doing. This is a good method of keeping things organized but it can cause deadlocks, wereby if threadA needs to access an object ThreadB has a lock on, whilst ThreadB needs to access an object ThreadA has locked you end up in a pretty bad situation. I'm not sure if its possible to get out of a deadlock but by the looks of things its not. It took me sometime to get the code actually going, I was using a great book title "Java Threads 3rd Ed" to help me with some source and the ideas being threading and proper techniques. When I did eventually get the code working, for some reason when ever a collision occurred it would fire off 4-5 times (in this example I was getting about 10 asteroids appearing on the screen instead of 2) I believe this is because the game is only operating at around 60 frames per second compared to the collision checker which is probably running at triple that. I was also getting some deadlocking on occasions and the game was freezing completely. I'll have to keep at it, maybe I have the synchronization setup wrong.

Whilst coding the new collision system I decided to optimize the way the engine split objects up into cells and stored them in lists. After looking over Pete's code I discovered he was using ArrayLists to store each object, and then was using a very high iteration looping algorithm designed to retrieve objects that were needed for collision checks. The method "getObjects" is passed in a list of game objects and then its supposed to pick out any matching objects from the cells list, in theory this works but in practice it was horribly slow, Pete had used the "ArrayList.contains(Object)" method, which when looked into deeper just runs through a for loop checking for the passed in object and returns true if it has been found. Now if this method is looping through all of the objects in the input list (could potentially be in the hundreds) and then looping through all the objects in the cell list for each object in the input list it equates to A LOT of loops! e.g. 100 Objects X 10 Objects in Cell list X 9 Cell Lists = 9000 checks every time the engine needs to check for a collision. That is a lot of checks, to optimize this I looked at how the cell list operates and its general purpose. It's designed only to store objects contained in each cell but because objects have the potential to move out of their current cell the cell list is constantly being updated and objects are being moved from one list to another. The first data structure that popped into my head was a LinkedList, it is famous for its fast in and out processing and is just as fast at iterating through its contents as any other type of data structure (besides a binary tree) so remembering my old data structure techniques I converted the Cell class into a linked list that used a "cellNode" to store its data and references to the next node. After implementing this I immediately discovered a massive performance increase, which is exactly what I was looking for, previously with Pete's design I wasn't to happy to discover that if you placed more than 500-1000 objects on the screen it would start to chug and lose frames even on my PC which has enough power to run Neverwinter Nights 2 on full graphics at 1600x1050 resolution without losing a frame (A pretty good feat if you ask me) whilst our little game that is only 2D and uses basic primitives is chugging and grinding to a halt.

Another change I made was to the engine and the engine loader. Currently when you start a game a Loader is initialized and is setup to load all of the games textures into memory and build any display lists (currently not setup) for objects, when it has finished doing these things it then starts a new game/engine. But the problem with that is that it will make it harder down the track when we begin to have more and more games, and the need for a dynamic way of starting/loading games becomes necessary, I guess the main problem is, how do I tell the loader what game to load without having to change the code and recompile every time? This is why I decided to change the way it works. I want the engine/game to be started and then the engine starts its own loader, this in theory will actually allow developers to utilize this time frame to load any custom textures they need for their game, and this also solves the problem I described above because now it doesn't matter what game is started, they will all start a loader and load the game specific textures and display lists.

One thing thats been annoying me lately is the fact that all the objects related to a game (e.g. City, Turret, Missile - relate to Missile Command) are placed alongside the game class, inside a package specifically for that game. E.g. "retrowars.games.missilecommand". Whilst we have another package called "retrowars.modules.premade" which was actually designed to be the correct place to put all of these objects so that way other developers can use them for other things besides just that game. A lot of the functionality built into these objects is pretty generic and should be able to be used across all games. So I moved them all into the premade package and reorganised the game files to reside in just the "games" package, so we can have a list of more than one game. Netbeans did all the refactoring (changing of the code) for me.

Thats about it for today, their is probably a bunch of other little things I neglected to mention but its pretty difficult to keep track of everything you do whilst coding. I'm sorry but no pictures today.

Tweak Tweak Tweak

2007-05-03T00:11:00.000+10:00

Today whilst at my studios tutorial I was doing some updates on my blog when I remembered the "Lost Garden" (the blog site for a game artist) and decided to take a look at his site a little closer. I hadn't looked at his website past the Sinister Clone graphics he posted but this time I discovered a whole bunch of free game art under his directory. All the art is very well drawn and designed exceptionally well with animations, etc. I skimmed over the many many pictures looking for something I could use as an asteroid and discovered this neat little set, I think their original purpose were to be rocks, but I don't see how they can't be used as asteroids. Check it out below.

I set about making a couple of them into textures while I was at university so I could test them out a little later tonight. After finding these graphic sets I'm really keen to do some more coding on the engine, but I have been holding off to give Pete an opportunity to do some coding. But if Pete isn't going to use the time I'm off doing other things its his own fault and it truly does reflect how much he is putting into the project. I do admit that the particle system is a great addition to the engine but I cant help but wonder if it was actually necessary at this point in time, I think we have bigger tasks to worry about at the moment like getting the game to a standard were we can present it and have it work effectively.

My asteroid set.

So when I got home from university I set about doing some coding, their have been a couple of issues on my mind and I asked Pete to take a look at them, notably the collision detection part which he coded, but nothing has been changed since, so I have taken the liberty. To start with I threaded the collision detection system so it runs parallel with the render loop to ensure maximum performance and frames per second. It wasn't an easy task, it required a lot of changes to be made over the whole engine and between the current games we have at the moment, for example the previous setup for collision detection was designed so that each game had their own list of objects that could collide and the developer would pass these two lists to the renderer telling it to check the collisions between them. This wasn't the ideal situation to me, essentially I don't want a developer to have direct access to the renderer and to be able to manipulate anything outside the scope of the engine. To resolve this I created a method that the developer can make use of titled "addObjectToRender(GameObject o)" which will pass the object straight into the renderer for processing. Now the more I kept at it, the more I found I needed to change elsewhere to make it fit in with what I was doing, so for now I'll leave the collision stuff and move onto some other things I added or updated and talk about all of that later.

Standing City.

Demolished City.

Soil Texture.

Most notably I added a Texture Manager, prior to this I was using the Loader to statically load each game object's texture and pass the object its texture id (a reference to the texture in memory). But what this meant was that the loader was holding onto the array of texture references forcing the objects to call back to the loader to retrieve that value, an example is below.

Loader:
public static int textures[] = new int[20];
...
int cityTexture = LoadTGATexture("images/city32.tga");
City.setTextureId(cityTexture);

LoadTGATexture:
gl.glBindTexture(GL.GL_TEXTURE_2D, textureArray[Count]);
return Count;

City Object:
public void render()
{
gl.glPushMatrix();
gl.glBindTexture(GL.GL_TEXTURE_2D, Loader.textures[textureId]);
gl.glTranslated(location.x, location.y, 0.0);
gl.glBegin(GL.GL_QUADS);
gl.glTexCoord2f(0.0f, 0.0f); gl.glVertex2d(-30.0, -30.0);
gl.glTexCoord2f(1.0f, 0.0f); gl.glVertex2d(30.0, -30.0);
gl.glTexCoord2f(1.0f, 1.0f); gl.glVertex2d(30.0, 30.0);
gl.glTexCoord2f(0.0f, 1.0f); gl.glVertex2d(-30.0, 30.0);
gl.glEnd();
gl.glPopMatrix();
}

The line I want to pay attention to is "gl.glBindTexture( GL.GL_TEXTURE_2D, Loader.textures[textureId]);" and how it refers back to the Loader. This is why I created the Texture Manager. I have made it a public object inside the Game Engine, so a developer can make use of it to load new textures and any game object can reference it. I created a method that a game object can use to retrieve its texture for binding titled "getTextureForBinding(int i)", this will retrieve the reference to the texture in memory based on the index given for the array. When a new texture is made the index is returned so that the object can store it for later use.

Now one of the other issues I wanted to check out, was if I could render primitives and textured objects at the same time. I wrote up a quick method for game objects so that it would draw its bounding circle (for collision detection) in red, and made use of the glEnable and glDisable functions to turn texturing on and off. Surprisingly it worked and its actually pretty handy being able to see the collision bounds for debugging purposes. The main reason I wanted to look into this was because Pete's particle engine ran a lot faster when it was using points which is logical and I couldn't imagine the load on the pipeline having to render a whole lot of textured particles, if I had to estimate it would be extreme! Below is a screenshot of Asteroids with bounding circles being drawn. One thing I notice in that picture is that all the asteroids are facing the same way, eventually I want to make them rotate and spin in different directions and speeds to break it up, shouldn't be to hard.

I also found this picture of space somewhere on the net, its actually much larger than this but I cut a 512x512 piece out and have pasted it below. It looks pretty good when applied to the asteroids background, but I'll have to get Pete's opinion too.

I'll talk more about how I'm going with the collision detection in the next blog. Thats it for now.

Particle System

2007-05-01T21:45:00.000+10:00

It looks like Pete's been doing some work lately, I know that he said that he had been working on a Particle System a few weeks ago in our tutorial, but I wasn't sure if he had actually done anything yet, but he has. He sent me what he had done so far, which was almost a complete product but rather than using OpenGL he made use of Java's 2D capabilities to draw to the screen, he asked me if I could convert it into OpenGL because he was interested to see how fast it would run. I quickly jumped into Netbeans and grabbed some GL base code from a tutorial project I had used to learn more about texturing. The base code made use of a reusable GLDisplay class and makes the whole process of setting up a display almost effortless. Once I had a window working I started cutting pieces of Pete's code out and rearranging some methods to work in a OpenGL context. It took me roughly half an hour to get the engine working and acting exactly like Pete's example, I encountered a few minor problems during that time, but they were easily solved. The first problem I encountered was related to when an explosion occurred, when an explosion occurs a set of 200 particles are made to shoot out in all different directions and at varying speeds, but in this case I was getting all of the particles clumped together and moving as one. To fix this problem I told the matrix (3D space) to reset its identity (3D coordinates) after drawing each particle which would allow the engine to move each particle independently, as I write this it dawns on me that I could have simply put that in the display function instead and would of got the same result, anyway by doing this it gave the desired result.

After sending the code back to Pete, he said he was going to implement it into the actual game engine and do some more optimizations like replacing the data structures with Link Lists rather than Vectors and some other general optimizations. I began doing a bit of tweaking and testing to see what the limits of the engine were, I discovered some interesting results. Firstly I found that the engine doubled in performance when the particle was told to update at the same time as it was being rendered, prior to this Pete was updating each particle first and then rendering it. I think that Pete has this "update then render" mentality stuck in his head because gamedev.net told him to do it that way, in this situation I think it would be better suited to having this logic combined. I changed the update function inside the Particle System class (A particle system is for example a particle emitter or an explosion, the system deals with its own set of particles that relate to its purpose) so that it would update five (5) particles at once, from reading a few game programming books this practice usually improves performance noticeably and by my observation it did just that. Lastly I wanted to find out just how many particles can be placed on the screen before the engine began losing frames per second and becoming jittery and slow. To achieve this result I used 5 emitters on the screen and altered the amount of particles per second that were being emitted. After tweaking the value several times I discovered that the engine would begin to slow and cause a cascade effect (because the frame rate slowed the existing particles were not dieing as fast as usual and causing more particles to gather on the screen at an exponential rate) at around 1975 to 2000 particles and above, 395 particles per second appeared to be the peak amount without causing frame loss. This figure could be significantly lower when implemented into our game engine and both Pete and I will have to look into performance optimization very soon.

Asteroids

2007-04-28T01:46:00.000+10:00

I made a start on our second game today (Asteroids). Using out existing structure I began piecing together the main game by implementing all the abstract methods. The structure I put together in the early stages of the project allows the developer to make use of event based methods, (e.g. onMouseleftClick) which simplifies the development process dramatically. Looking over the current collision detection system I feel its not up to a satisfactory standard, forcing the actual game to rely on generating and managing the lists of collidable objects.

The code used for Missile Command is still fairly generic so I copied across most of it, more importantly the initialisation code because it contained a lot of the setup. I also built some game object's for the game, see below:

Asteroid - This object will take care of all the asteroids on the screen and handles its own collision event. When a bullet collides with this object it will split itself into two smaller asteroids and destroy itself.
Ship - This will be the player controlled space ship, the player can fire bullets from this object. If it collides with an asteroid it will lose health or possibly explode.
Bullet - This object is setup to collide with all other objects, but because it is so generic its important not to put to much logic in it.

After I combined all of these things I was left with a semi working version of asteroids, I was getting the bullets colliding with asteroids and the ship moving around the screen. The ships movement wasn't entirely right I set it up so it would turn hard like a car would but I believe in the real game you float freely in the same direction until you accelerate. I told Pete about the problem I was having and asked him if he could work that out for me instead, he has been invaluable when it comes to the math and physics of the game. Pete also said he would look into the collision detection code and try and improve it, which will be great.

Whilst testing the ships movement I discovered that it wasn't moving correctly, for example if you turned to the left and held the key down it would move left once and pause for half a second and then repeat the turn consistently. Its the pause that is causing the problem it could potential cause the player to fail or die. So to fix this problem I setup a boolean (true/false) for each key that makes use of the keyPress. When a button is pressed the boolean is turned on and for each logic update/frame that is rendered to the screen it makes a check to see if the boolean is on, if it is it will execute the logic for that press. The boolean is then turned off when the key is released. Using this method ensures the motion of movement is smooth and instantaneous.

Screenshot of the game so far.

Week 7

2007-04-23T23:00:00.000+10:00

At today's tutorial I thought it would be a good idea to have look for some sound effects that can be used in our game, even if we don't find anything final I think its a good idea to just check out whats out there and what we can get for free. Pete found a lot of good sounds at Flash Kit, but I'm not sure if they are free to use or not, we will have to investigate it further.

We also talked about making a second game, the one we both agreed upon was "Asteroids". Pete and I both thought it would actually be pretty easy to make with our existing engine structure, and we already have all the code we need to deal with collisions, graphics and input it will just require its own game logic. I nominated to build it and leave Pete to fix up the collision code and do some other modules like profiles and stats.

Tom was pretty impressed with what we have done so far, a lot of the other groups haven't had much progress apparently. I built that version whilst at uni the day before, Pete and I have been using version 1.6.0 for our development whilst the uni computers use version 1.5.0. As I found out Java isn't backwards compatible, I guess when they make a new version it takes a long time and they tend to make major changes. Fortunatly it wasn't a massive effort to get the game compiled, the computers have Netbeans installed on them so I could open my project and compile it with relative ease and without any hiccups.

Thats all for today, ill post more later.

What do we have left?

2007-04-17T21:54:00.000+10:00

I caught up with Pete over MSN today, he's been working hard on the engine and has been developing a new concept (Gravity) and from all reports everything is going well. Now my coding frenzy has come to halt I think Pete's feeling a little more comfortable and I think hes starting to grasp an understanding of the code. Earlier today at uni I brang what I had so far on project and attempted to compile it but encountered a couple of problems. The first was that the GUI Layout was using a setup that only worked on Windows and with Java 1.6.0, while the computers at uni use Java 1.5.0. To fix this, I changed the layout of the GUI while Netbeans changed the code around for me. The second problem I had was related to the JOGL library (again), I put the required dll files and jar files inside the JDK but forgot to put them inside the JRE (Java Runtime Engine) which resulted in the game not loading and telling me it couldn't detect the dll's. After adding the dll's to the JRE it worked as expected. The reason I wanted to compile the source at uni was to check for any errors but also to get a working version to demonstrate.

I wrote down this list of tasks both Pete and I thought will need to be implemented:

- Losing Conditions
- Score Overlay
- Stop the game and display winner
- Finalise graphics
- Sound wavs and sound code.
- royalty free music?
- Player Profiling
- Statistics

I've been thinking that we should scrap the section were the player gets feedback on his opponents status, this could be a health bar or a doom like face that changes over time. But what happens when your competing against ten other players? Do you have ten health bars on the screen? I don't think so. So even though this idea is practical, it leaves to many questions and will make designing and creating the interface very complex.

I did some minor tweaks on the engine and loader at the moment if a player stopped playing a game then wanted to join or start a new one, the the game would crash, so I made sure that when the window was closed, it should reset or destroy all existing variables so that when the player starts a new game its a clean slate.

Thats all for now.

So ya...

2007-04-15T00:09:00.000+10:00

I've been thinking about the graphics and/or theme of the game were producing at the moment (Missile Command clone) and I would like to do something original. I was thinking about something along the lines of old skool 8bit style graphics with a big black bomb with a lit fuse that gets sling shot into the sky, whiles something I haven't thought of yet drops from the top of the screen. It's still a little hazy in my head, but I just need some time and a bit of inspiration from other pictures to find exactly what I want.

I also threw this diagram together that simplifies and better describes how the networking part of the engine operates and communicates between different areas, see below.

*Edit*

Collaboration

2007-04-10T20:22:00.000+10:00

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.

OMG Texturing

2007-04-10T01:27:00.000+10:00

Phew *wipes sweat from brow* I've been at it for the last 9-10 hours straight, only stopping for dinner. It might seem that its taken me a long time to do just one small part of the project, but I encountered a couple of hurdles along the way. Texturing is something that I haven't done before with OpenGL so its all new to me at the moment.

To start with, I jumped into Photoshop and started drawing up some images, even if they don't look very good they can be used as filler images until we get better ones later. Some of the pictures I put together are below.

Background

Missile

City

Turret

The Turret is actually not mine, while surfing the web I accidentally stumbled upon a blog website from some game programmer guy, and he had released a set of 8bit graphics he made for a game he was producing. Now he released the graphics in hope that someone would eventually build the game or make use of them in an active way. So they are Open Source and free to use, so in that case I am going to use them.

Lost Garden - Website of the blogger guy

Ok, so why the Phew? Well! I wrote up a couple of functions that allowed the developer to load textures (Note: only Bitmaps and PNGs at the moment) and got them to render on the screen relatively easy, It was how I had envisioned and was as I had seen before. But most of the day was spent tweaking and testing and tweaking and testing trying to find the right combination of commands to make OpenGL use alpha transparency. But I kept getting this messed up situation were the objects I'm trying to render to the screen would just blend together. Now I looked around on the net for a good 3 hours of those 9 (spread out over the total 9 of course) just looking for ways to get what I want, and just could not find a single thing. I tried anything and everything I could think of.

Then I had a break though, I found this little program titled "glSandbox". This is a program thats setup specifically for you to test different settings relating to blending and alpha testing, and it even let you import your own textures to a polygon. At first I still couldn't get what I wanted out of it, trying every combination I could in it to get the texture to be transparent.

When I was on the verge of throwing my hands in the air and quitting, I looked back at the glSandbox website and saw a picture of it, and on it was a polygon with a smiley face texture that was transparent. This is exactly what I want! And if this program can do it, their just has to be something going on that I don't know about.

So, I set about putting that exact texture into the program, and trying to duplicate the result. It didn't take me long before I discovered I had been doing it all wrong earlier, using the Blend when I should of been using Alpha Testing (which makes A LOT more sense now *slaps forehead*).

The next step I took was try to get my own texture to do the same thing. I had been using PNG's and Bitmaps during the course of my previous attempts and I thought I was getting really close when I was getting different alpha blends, but I couldnt' have been more wrong. The format that the smiley face is in is Targa, which is actually probably the best type of image to use for OpenGL (according to my OGL lecturer last semester) because it isn't compressed and it has an alpha channel. So I converted my texture into a 32 bit TGA and made my own alpha channel in Photoshop. Once I did this and tested it in glSandbox it worked immediately! Horray! finally getting somewhere. Now that I know that I have a working texture, I need to implement this into the actual game.

I found a control/class thats actually apart of the JOGL library, its titled "ImageTGA" and its been specifically designed and put in the library for the sole purpose of reading and writing TGA images, bonus! I quickly wrote up a function that used it, and tested this puppy out. Now I was getting proper transparency but something was up with the colours, It looks like its missing the colour red or its replacing the colour red with the blue, man I have no idea right now. I've looked up the glTexImage2D command on Google, this command sets up the texture, giving it its width, height, format, pixels, etc and saving it to the computers memory for use. Now I'm pretty sure its the "format" section that I need to work with here, at the moment I'm using "GL_RGBA" which stands for Red, Green, Blue, Alpha. According to the specification their are a whole bunch of different formats I can use like RGBA16 and so on. But after testing if these work, none of them gave me the right result, some might give me jumbled up pixels and other times the textures would still be blue. It wasn't until I looked into the javadoc intellisense inside netbeans that I discovered that the TGAImage class had a method titled "getGLFormat()" and inside the little popup box was written "Returns the OpenGL format for this texture; e.g. GL.GL_BGR or GL.GL_BGRA". Now I had heard of these two "formats" before, but that was last year in my OpenGL tutorials and what not and really didn't pay much attention. It obviously means that the colours are loaded in a totally different sequence, Blue being the first one. When I discovered this, I put the command in and just let the TGAImage tell the texture what format it is, seems to make sense also. After testing this everything is working as expected. YES! Texturing can now be ticked off the list.

Ok, now I that I have texturing sorted and perfected to a fine art, I've decided to try and help Pete's section (Collision Detection) along and write something up that records and sorts what cell/zone an object is in. Now the objects that require zoning are objects that can collide and enemy missiles, so I made a boolean for each object titled "isZoned" thats purpose is to tell the engine weather or not it needs to be sorted into a zone/cell. I broke the screen up into 9 sections so that when its time to check for collisions the engine is only making checks on other objects inside that zone/cell and therefore reduces the amount of processing required by the CPU.

So, in the Object Renderer I made use of the already existing Update function designed to update each objects movement information and or status, and got it to start sorting each object that made use of the isZoned boolean. I wrote a class that specifically did this sorting and add and removed objects from each zone/cell and attached it to a thread, so it would be processed independently rather than being apart of the main loop. The reason I choose to use threading in this way was to ensure that the main loop isn't sidetracked with processing a massive amount of sorting information and having the games frame rate drop to almost nothing. As it is, If you do produce a lot of missiles which create threads then it will slow your CPU and the framerate, so its a lose lose situation at the moment, either Pete or I will have to come up with a better concept later. But for now, I have successfully got it zoning each object in its correct zone which leaves Pete with a little bit of a headstart (I hope).

Thats it from me today.

WE HAVE SOUND

2007-04-10T00:03:00.000+10:00

Alright, I've been working my ass off all for the past week on this project and I have to say that Pete has put in almost nil in comparison. I think his putting to much pressure on himself and spending to much time working or traveling. I could never make the trek to Ballarat every weekend, it just isn't productive enough in my opinion. Anyway, as usual I'm holding the project together and doing the majority of work. I think after tomorrow I wont be able to come back to the project for a good few weeks since my other 3 classes are knocking on my door asking bout assignments.

Well, I went for a quick search and discovered a really good little MIDI player written in Java and makes use of the Sound API, after I looked over it it seemed worthy of being implemented into our engine so I stuck it in. A link to the source is provided below.

Java Sound API - MIDI Player

Since we have a MIDI player now, I guess were gunna need a MIDI too. I had a look around at some free MIDI sites, as well as royalty free MIDI's but nothing really stood out till I discovered this really old or just pethetic website with a whole big list of old game MIDI's. Some of them were for different levels and most commonly the intro's. After listening to a fair few I found the one, its called "Wizard Ball", it was some old Atari game or something, but the MIDI has a cool tune to it and I thought it was probably the best one I had heard so far that would blend in with the game. You should be able to listen to it at the link below.

Wizard Ball MIDI

After running a quick test, the MIDI Player proved to work perfectly and the engine is on its way.

Structure

2007-04-08T22:13:00.000+10:00

Like I said in my last post, I am going to talk about the structure, more specifically about the structure of the engine. I have been a busy working hard on this thing trying to come up with a good structure that's practical and hides away all of our complex code (mainly the OpenGL stuff). I've rolled with Pete's idea because it will work (Pete's idea was to make the engine the core and the game extend it), but what hes done so far tells me doesn't completely understand whats going on with OpenGL, but I can tell hes making sense of different bits and pieces. Earlier when I first implemented the GLDisplay and texturing utilities I made the actual game logic (object) implement the GLEventListener (this is the interface that OpenGL uses for its standard methods like display, reshape, init, etc) which would of given a developer a lot of access to the actual workings of the engine. So today I've been continuing where Pete left off and been busy separating methods and making methods that will be available to the developer and methods that need to be in the engine (tucked away). Below is a dot point list of what I have so far in the engine and game, I'll try to explain the purpose of each section to the best of my ability.

Engine.java - THE GAME ENGINE (Implements GLEventListener)

Engine - Constructor. In the constructor the engine sets itself up and activates the sound player, object render and input handler.

onStartUp() - ABSTRACT - This function is required for each game developed. It is called when the window is first initialised.

onEnd() - ABSTRACT - This function is required for each game developed. It is called when the window is closing.

onMouseLeftClick() - ABSTRACT - This function is required for each game developed. This function is called when the left mouse button is clicked. It is up to the developer to decide what occurs when this event happens.

onMouseRightClick() - ABSTRACT - This function is required for each game developed. Same as above.

onMouseOtherClick() - ABSTRACT - This function is required for each game developed. Same as above.

onKeyPress(KeyEvent e) - ABSTRACT - This function is required for each game developed. This function is called whilst a key is being pressed/held down. It is up to the developer to decide what occurs when this event happens.

onKeyRelease(KeyEvent e) - ABSTRACT - This function is required for each game developed. This function is the same as above, but it only occurs when the key is released.

KeyPress(KeyEvent e) - This is the engines own KeyPress event. When a key is pressed it is handled by the InputHandler which then tells the engine to activate this function. This gives us the developers the oppurtunity to setup some static key binds for things like Pausing or Help (F1) and Escape for quitting, just so that the game developer cannot override these keys with useless code. This function makes a call to the onKeyPress() function.

KeyRelease(KeyEvent e) - Same as above. This function makes a call to the onKeyRelease() function.

closing() - STATIC - This function is subject to renaming, but it is called when the window has been closed. It gives the engine a chance to stop any threads, sounds, music or input that might be occurring whilst the window is closing.

getHeight() - This method is used to retrieve the exact height of the OpenGL canvas. It's used in relation to the mouse axis Y, which needs to be reversed when dealing with coordinates in OpenGL.

togglePause() - This function just toggles a boolean between true or false. The paused boolean is setup in other functions to stop the flow of data and bring the game to a halt.

convertKey(int Key) - This function was made to work in relation with the InputHandler when registering a new help key. The developer has the option to register a new key in the help overlay so when a player presses F1 they are given a list of working keys. Example of this function in use would be: input.registerKeyStroke(convertKey(KeyEvent.VK_W), "Forward").

init - OPENGL - This function is apart of the GLEventListener. It is called when the OpenGL window is in the initialisation stage, it is useful for setting up things like clear colour, perspective and initialising any variables. This function makes a call to the onStartUp() function.

display() - OPENGL - This function is apart of the GLEventListener. It is called for each frame that OpenGL renders. When this function is called it sends the data down the pipeline for processing and output to the screen.

reshape() - OPENGL - This function is apart of the GLEventListener. It is called when ever the window is reshaped by the user. It is also called after init when the window is displayed on the screen. Its a good place to put concrete setup perspective code.

displayChanged() - OPENGL - This function is apart of the GLEventListener. It is called when the display is changed. This function doesn't usually get used and has no purpose in the project.

Well, what do you think? Pretty good aye?

I have done some more coding in some of the little classes Pete threw in but didn't really make use of yet. Because I cut out a lot of code from the actual game class (MissileCommand.java) I'm trying to make use of these classes in the game, just like how a developer making his own game with our engine would do. I've had great success and no real problems so far.

When I was fixing up the Missile class I copied across what we have so far in the laser class and applied to missile. Now at the moment that means the the missile has a line that follows its path, much like a trail, but I thought I would leave it in for now because later on we might replace it with a smoke trail. I added a little primitive block with a point to the render function and applied some basic OpenGL techniques to get the missile to point in the direction of its destination. It was pretty simple really, I made use of one of the methods Pete put together to return the angle in degrees and rotated it accordingly.Below is a picture of the game so far. It has three turrets (white), 4 cities (blue) and missiles that point in the direction of the mouse.

..

Networking Part 4

2007-04-08T21:56:00.000+10:00

I've decided to implement what I have so far into the engine, and make the GUI the actual start up place of the program. That way I can not only test to see if the networking socket code works but also keep this ball rolling with solid development. I also want to be able to start a game at the press of a button, just like it would if was starting the game with other opponents, but in that case the host might press the start button and it sends out a message to all clients that starts their selected game (thats a good idea, ill probably implement that... I know just how to do it too :D). Below is a picture of how the GUI looks right now.

If the player hits the "Start Game" button I want it to start a new GLDisplay, but if I close that one I want to be able to run a new one straight after it with out any problems. I think with the current setup and utilities I implemented this shouldn't be a problem.

I did a bit of extra coding in the networking part, just to check out what was going on when I triggered an event. Everything seems to working as expected. I will have to update it later so it doesn't send a trigger event back to client, but that is basic stuff at the moment and can wait.

I also put this diagram together, its a mix of a data flow diagram and a decision tree? I made it up just to help explain what occurs in the networking side of the engine.

I should probably dive deeper into some of those processes so that it makes more sense. Maybe I'll do that later, for now I'll go back into sorting the structure of this engine so it is more modular and extensible. Pete started making a few changes and moving a couple of functions around, he suggested that we make the Engine an abstract class and have the actual game class/object extend off it, which makes sense (I'll post more on that in the next blog).

Textures

2007-04-08T21:28:00.000+10:00

The network part of this project has reached a satisfactory stage to me, it will require some more work later on when we need to implement the event handler properly and possibly in game chat. So today I set about getting some texturing working, and see if I could implement it into our engine.

First of all, I did a Google hunt and found a couple of different websites and tutorials, notably the one listed below is quiet useful for information, which lead me to the next one.

Java Tips - Other API Tips

NeHe Java Ports

Now, the NeHe examples/tutorials are famous for being great and well documented OpenGL tutorials that a lot of develops use to learn different techniques when developing in OpenGL. It was a blessing to discover that someone had ported all of the NeHe tutorials into a working version using JOGL.

I downloaded and picked apart lesson06 and lesson09. Lesson06 was a simple 3D spinning cube that had a png textured on all of its faces, whilst lesson09 used a single star texture and had it duplicating and moving around the screen to reveal a cool pattern (Its purpose was to demonstrate how to move bitmaps around the screen). Below are pictures of both of the lessons after I had typed them into Netbeans and ran them.

Textured Cube Example

Spinning Stars Example

Whist looking at these example's I discovered that they used a bunch of utility classes that seem to be very robust and reusable. I spent a good couple of hours looking through all of them and getting an understanding of how they work. I was very impressed at the structure they used and how easy it is to create your own JOGL project using it. So after I got my head around it I started implementing the basic Display utilities and also all of the texturing utilities so we could make use of them also.

After playing around for a while, I've got it successfully implemented into our current project. Nothing has changed visually just yet, but I did find one issue that I quickly knocked out. The existing GLDisplay class I am making use of now used an FPSAnimator which has a few more options than the standard Animator. It was limiting the speed of the frames and also causing it run slower than expected (40 fps). I found this odd considering the lack of rendering and processing that was actually required of the program, usually we would get around 800 to 900 fps with visual sync off. So I replaced the FPSAnimator with a regular Animator and everything is normal again. I might switch back to the FPSAnimator later if we find a better use for it, but right now I don't think so. Anyway I didn't get around to actually make the engine use any textures yet, only because we need to get what we have so far working and I can replace the primitives that we use now with textures very easily when the time is right.

I've commited all the changes to the CVS and left a few notes for Pete to read over while I'm not around. The good thing about using a CVS is that you can comment all your code and leave notes around everywhere and or little tasks/jobs for your partner.

Networking Part 3

2007-04-05T02:32:00.000+10:00

Well, I've been coding away and trying to get a combined client/server GUI that can act as both a server or a client. When I set myself a goal I always achieve it and this is no exception. Below is a picture of the GUI so far.

The GUI can perform these actions so far:

- Detect Incoming Client Connection
- Detect Client Disconnection
- Simple Chat (between multiple clients)
- Disconnect all clients when the server goes down and provide an appropriate message.
- Trigger an event (This needs to be extended upon to fit in with the actual game engine)

Now, in the picture you might be able to see that when the Server's connection is terminated, the client is terminated afterwards. This is because when a host (player) starts up the server they then join their server as a client at the same time. Why? Because the server is only setup to deal with incoming clients and sending to and receiving data from clients. By trying to implement the client functionalities into the server I came across complications with sending the incoming data back out to the other clients. Hmmm its hard to explain the problem I was having because its very complex when your working with threads. If I think of a good way to break it down and explain it I'll write it up on here.

So far I feel like I have achieved a lot, and learnt a lot more about networking and Java sockets. I'm feeling confident in my ability to pull this off, only time will tell though.

Networking Part 2

2007-04-04T22:21:00.000+10:00

Ahhh so I've been putting together a client and server GUI so I can test out my code, below is what I've got so far.

This is the client GUI I have been using to test the server. I can successfully connect to the server and use it to send a message to server, but I've been getting a lot of mixed results. When I send a message across to the server, it can end up printing it out more than one, and it doesn't return anything back to the client either. I am going to have to delve deeper into the code and look a little harder at just exactly what is going on between the server and client, I'll probably end up making a total mess of the code and put in a whole bunch of println and error messages everywhere so I can debug the thing, but hey, thats how I figure out how things work.

Moving on, I had a bit of a revolution about how everything works and just so I made sure I knew what was going on instantly started to put pen to paper and write down what I thought was going on. I really didn't trust myself to remember it if I came back to it later, but as I was writing it down it all seemed to make sense, this can only be a good thing. I tried to draw up a diagram to also better illustrate how it works but I think it needs more work, you can check it out below.

I don't know if its readable on this site (probably not) but what its trying to explain is that each computer, weather it be a player or the host, all have the server interface and three other modules that make it up (Input Handler, Server Connection Manager, Client Connection Manager). The naming of these modules might be a little bit off, but its the best I can come up with at the moment, below ill explain what each one does in a little more detail.

Input Handler - The input handler is designed to retrieve all the incoming packets from clients and redistribute that information back out to the other clients. It keeps a list of all the currently connected clients and stores their information about their connection so the server can communicate with the client. Eventually we would like to have it handle the events that occur during gameplay.

Server Connection Manager - This manager starts the server socket accepting incoming connections and for each connection made a new Input Handler is assigned to that client. The server socket will continue to accept new connections until either the game is started or the host disconnects.

Client Connection Manager - This manager is setup to detect incoming events or chat from the server and deal with it appropriately.

All of these classes run on their own thread, which means that the actual gameplay will be smooth and uninterrupted by the network.

Networking

2007-04-04T20:45:00.000+10:00

So I've moved on to the networking side of Java now, I haven't done much with sockets and networking in any language before so this is all pretty new, though I do understand how the internet works. I started reading some information about sockets in one of the many e-books I got recently, what I've read so far is but isn't that helpful most of what I'm reading is about threading and input/output streams for sockets. What I've gathered so far, is if you create a socket that successfully connects to a server it sets up a dedicated link between the computers and any information/packets sent between them use TCP/IP which is a reliable way of communication. TCP was layered on top of IP to give each end of a connection the ability to acknowledge receipt of IP packets and request retransmission of lost or corrupted packets. Furthermore, TCP allows the packets to be put back together on the receiving end in the same order they were sent.

Some of the books I've been looking at include:

Java Network Programming, 3rd Edition - By Elliotte Rusty Harold
Java Network Programming, 2nd Edition - By Elliotte Rusty Harold

I also did some Google searches to get more of a basic tutorial on how to build a client/server network setup, some of the sites I notably bookmarked are below.

Writing Server Side Sockets
Reading and Writing to a Socket
Socket Programming
Multithreaded Chat System

Looking at the article "Mutlithreaded Chat System" it looked to have all of the characteristics I am looking for in developing this network. So I compiled and ran the code to get a better understanding of how it works. I discovered that for each connection made to the server, it starts a new thread that handles all the input coming from a client and then distributes the input back out to the rest of the clients. That example doesn't actually have any client, it gets the user to use telnet instead, so this means I'll have to write up the code for the GUI. Writing the client side is a good thing anyway, it means I get to play with the code and really start to understand it.

I'll post more soon.

Explosions!

2007-04-04T13:30:00.000+10:00

Alright, now that I have a vector at least traveling towards the mouse and reaching some sort of relative distance away from the center, ill start writing up the part were the missile explodes. This should be pretty easy, ill just write up a function that draws a circle based on a radius and then every time the explosion is rendered it parses a larger radius in.

Done. As expected it was pretty fast to code up, I added a new explosion object and set it to render when the vector reached its distance. Below is a screenshot of a bunch of vectors moving out to their destination and some explosions already going off.

I've palmed off what I've done so far to Pete now, he is going to fix the vector/laser class so that they travel the correct distance and probably try and work on some collision detection. Pete is the one that has a better understanding of the math behind everything were doing, I'm more or less just coding up the graphics and things to look nice. I don't know were to go from here, so I guess ill look into the networking side of things, I don't want to spend to much time thinking about what I should do next when their is so much to do overall.

I win.

2007-04-01T21:35:00.000+10:00

I've been working hard at solving this damned trigonometry problem thats been troubling me so much, just the other day Pete put together a simple 2D Swing Java app that followed the mouse around the screen and output the angle, it is what I was looking for, but the method he used is a LOT different to how I've got it working in OpenGL and the coordinate system. (Below is Pete's Example).

But sure enough, using a combination of both of our code I finally got it working as expect! Now I've got the vector following the mouse around the screen and pointing in the right direction, another hurdle down, I'm sure their will be a lot more hurdles to come, but hey, thats what studio's is all about isn't it? Learning new things and pushing boundaries?

How did I do it? Well it was actually pretty simple, as I suggested it would be in a previous blog. I had been trying this type of algorithm for a while but just wasn't getting anywhere with it until I picked some bits and pieces out of Pete's code (Look below for the code).

public void mouseMoved(MouseEvent e) {
double deltaX = e.getX() - 250.0;
double deltaY = (500 - e.getY()) - 250.0;
v.x = deltaX;
v.y = deltaY;
}

Whats happening is when the mouse is moved across the screen, its retrieving the X and Y position of the mouse and subtracting the start position (250.0) which is in the center of the screen. Then the vectors X and Y is set to the delta X and Y to give it its direction.

zzzzzz

Wednesday....

2007-04-01T20:43:00.000+10:00

On Wednesday Pete and I started dissecting the game into classes, so we could possibly start putting together a class diagram, and a get a better picture of the structure the game will take. Because the game is supposed to be extensible, and available for other developers to use the engine to create their own games, we need to modulate everything well enough so the developers can just pick and choose objects they want in the game, with the least amount of actual technical coding like OpenGL (a lot of developers might not be able to understand or use OpenGL, so by having our engine handle all of that is definitely the way to go).

The notes Pete and I took down include:

Indestructible Objects
- Modal Object
- Background
- Moving Objects (Bullets, Lasers, etc)

Types of Physics
- Gravity
- Wind
- etc

A utility class/package | This package will contain a lot of the utilities a developer might make use of to help build their own game.
- Vector class
- Rectangle class
- Sphere class
- etc

Bounding Boxes (for collision detection) | If we have enough time, it would be a good idea to make this up, that way it wont have to be hard coded.
- Editor or Tool to build bounding boxes for different shapes or objects.

Networking
- Player feedback (Doom / Duke Nukem Faces to represent the status/health of your opponent.
- Measure of other players progress
- Winning Conditions
- Events
- Simple chat binds (example: Hello, LOL Take that!, etc)

Profile
- Name
- Statistics | Things like, how many times you have won, what level you reach, averages, etc
- Handicap | This is made up of your statistics and make it a little more even when playing against opponents who might not be very good.
- Chat Bindings

Input
- Keyboard (KeyListener)
- Mouse (MouseListener, MouseMotionListener)
- Joystick ?
- Gamepad ?

Well, most of this information was set in our proposal, but some of these things weren't like in the Networking part having a Player feedback that makes use of a face icon is a pretty cool idea, even though it has been done before, players should be able to instantly recognise this and its purpose, if not we can provide some sort of tutorial in some documentation.

So next week our proposal should have been marked, I hope all the printing problems we had don't effect the overall mark. I'm also a little worried about Pete's grammar and writing since I didn't have enough time to read over it all, and I'm not sure if Pete did a lot of proof reading. But he did write a lot of filler, I think I might have to work on my writing skills more.

I think the progress I've made so far, is pretty good. I am trying to get back into the swing of coding and OpenGL more importantly (which isn't an easy task) after four months of being off and not doing any coding over that time it sure does make it hard. The more coding I do, the more it comes flooding back, so I will just persist.

Grrrr Trigonometry

2007-04-01T19:50:00.000+10:00

I did Trigonometry while I was in high school, and I actually did pretty well at it. But its been such a long time since I've used it that I cannot remember anything! I've been trying to get a vector to follow the mouse around the screen, and just keep hitting a brick wall. I've talked to Pete over the past week and he's been trying to help me with the problem providing a few equations and what not, but everything I try just doesn't seem to be working right.

I've tried these equations that Pete gave me:

tanӨ = o / a
Ө = artan( o / a)
Ө = artan( Y2 - Y1 / X2 - X1)

These equations are telling me what the angle is, but I'm not sure if that's exactly what I am trying to achieve here. I keep getting the vector pointing in the wrong direction, when I would move the mouse to different corners of the screen (for example, if i put it in the top right corner the vector would point 90 degrees to the right, and top left corner would result in the vector point 90 degrees to the north). This is getting frustrating now, because I've spent a while trying to solve this problem that is probably really really easy.

The whole point of getting the vector to follow mouse, is so that we can make a start on making our first game (Missile Command), which requires a missle/bullet to move to were the player is pointing.

Now the reason I think I've been getting skewed results is because of the mouse coordinates that Java has been giving me in comparison to the actual coordinate system in OpenGL. I did a test to find out if the coordinate system was actually working as intended (0, 0 at the bottom left), to determine this I set the vector to start at 0,0 and point out at a 45 degree angle towards the center, this proved that coordinates are setup right. Since OpenGL is working as expected, I did a mouse test to determine what sort of values it was giving in relation to how it should be setup. I am confident it is the mouse coordinates that are causing the problem because when I move the mouse to the bottom of the screen it gives me a Y value of 500, which means its reversed. Hmmmmmmmm I should be able to reverse it so it works with the OGL coordinates by using this simple equation.

Y = 500 - mouseY

oo

A Fresh Start

2007-03-30T15:20:00.000+10:00

Alright, now that I have this stupid problem with the glColor command worked out, I can get back on track and write up the rest of the code. When I finished writing it up, I did a Debug and got a strange result, below is an image of what I was seeing on my screen.

As you can see, it seems that the colours from all of the polygons are blending together, which suggests to me that its not culling the back faces. So delved into some demo source examples and picked out the command to cull faces (gl.glEnable(GL.GL_CULL_FACE)), YAY now it looks like it should and is working as expected.

Now that I have one of the most basic 3D things down pat, I can move onto a more complex tutorial I did in OGL, working with vectors. In the tutorial we wrote up a vector class that involved all the methods of finding different angles and multiplying or subtracting vectors, so I quickly wrote the class up using the C++ code as a guide. When I was done, I did a quick debug and found everything working as expected.

Here I thought I would take it one step further and see if I could get the vector to bounce off the walls. I tried using a few different techniques like, inversing the direction of the vector and trying to get it shift according to an angle, but nothing I was doing was working as expected, it was then that I remembered an old tutorial that I had looked at a while back when I was doing some coding in SDL.NET

SDL.NET Home
SDL.NET Pong tutorial

I remembered this tutorial had an object bouncing off the walls, and from memory it worked quite well. After looking at the section that deals with the collision and motion it revealed how basic it was! how embarrassing.

if(ball.Right > Video.Screen.Width)
ballSpeedX *= -1;
if(ball.Left <> Video.Screen.Height)
ballSpeedY *= -1;

It was a simple matter of multiplying the speed by minus 1, duhhhhh. When I applied this to my code, it worked as expected and my moral was rekindled. Now I thought I would get adventurous and see if I could get the ball bouncing off a brick (just like in the classic Breakout). I coded up a quick brick class that would draw a 20x20 pixel box on the screen and made use of a collision detection method. After a little while of playing around with the collision detection I discovered that I could get the ball to bounce off either plane, x or y, but not both at the same time. I'm going to have to look into more advanced ways of detecting collisions and dealing with them, because simple if's don't seem to cut it.

At this stage, I went hunting around the web for some tutorials and information on collision detection. Ill bookmark the good ones now and read them a little later down the track.

Arrggg Linux + JOGL

2007-03-30T14:33:00.000+10:00

Today, I was doing some work for my other subject "Enterprise Programming" which requires you to do everything on Linux. So while I was on Linux I thought I would attempt to get JOGL working with Netbeans, so I could do some development on it. I prefer to develop on Linux because I get to learn new skills and work with a new operating system, and also the look and feel of the OS is much more appealing to me than Windows. So I hunted down a heap of websites looking for a tutorial on how to install JOGL on a linux system, but I kept getting other people having the same problem and no one providing a solid solution. Every time I tried to compile some JOGL code it would tell me that it couldn't find the library files and cause an exception.

Some links I bookmarked:
Environment Variables
Hello World tutorial
JOGL forums
JOGL install tutorial

Arrggg!!! after about 2 hours of trying to get it to work with Netbeans, I installed Eclipse and tried to get it to work with that. NO SUCCESS BAH! I just cant figure out how this thing needs to be setup on Linx. I gave up and switched over to Windows.

I had installed Netbeans on Windows not long ago, just to get my PC ready for some coding when the time comes. I used the above hello world tutorial to test if JOGL was working on Windows and encountered the exact same problem that was happening on Linux, SIGH! I had looked at the JOGL install tutorial several times at this point, but I guess I just wasn't reading it properly because of my frustration, after reading it VERY carefully I discovered this section:

The .jar file jogl.jar needs to be in your CLASSPATH for compiling and running your code, while the native library file or files also need to be along the java.library.path at run time. You have two options of where to place these files.

Put the .jar in the lib/ext directory inside of the Java home directory, and the native libraries in an equivalent always-checked directory (such as jre/bin on Windows, or /Library/Java/Extensions on Mac OS X [note: this path has been changed since this article was first posted, on advice from Apple engineers. - ed). This approach gets you up and running quickly.

I soon discovered if I followed that to the letter it FINALLY worked! YAY. Ok, now that I have JOGL working on something I can finally start doing some test coding and try to get back into the swing of OpenGL.

I looked over the tutorials I did last semester in my OpenGL class and picked out one of the first ones we did, A spinning cube, and started coding it up in Java from C++. All of the OpenGL syntax is the same, and the translation between C++ and Java is very similar, so initially I thought this would be a fairly simple task to complete. I was wrong. I made use some of the demo code that is available from the JOGL website just so I could understand the layout and use of each section, to my surprise it was very similar to GLUT which is "Graphics Library Utility Toolkit" that simplifies the use of OpenGL, and also is supported on multiple platforms, so its commonly used on Linux for C++ OpenGL development. I reached the point were I was building the polygon method which would output all the vertex, normal and colour information to the screen for each side of the cube, because this function only made use of only OGL methods I just copied and pasted it in. It told me that all the functions inside the glBegin tags were causing an error, but to me they looked perfectly fine.

Example:

gl.glColor3fv(color[a]);

This means glColor3fv means its looking for 3 floats inside an array that specify the RGB values.

I was looking at the way I had defined the color array and the values inside it, to make sure everything was right according to Java's method of defining arrays and everything looked right, but it was still giving an error. After about an hour of doing everything I could think of, I finally discovered that the command was asking for two parameters, not just one. It was looking for an offset variable, which I have no idea what its use would be but if I was to take a guess it would have to be something like an offset value for the start off the array, or something similar to that. Frustrated at how long it took me to get this far I had to step away and thought I'll leave it till tomorrow and start fresh in the morning.

BLOG!

2007-03-29T12:27:00.000+10:00

Ahhhh I've had to move the posts from the other Blog over to this one, because I don't think the existing one Pete and I were using will be fixed before we have to hand in/present this on week 7. I hope this thing works. I'll be adding some more blogs after this, I've been writing them down in my book rather than posting.

Project Plan Part Four

2007-03-29T12:13:00.000+10:00

Getting it done, I've almost finished my parts.

I set today specifically to work on the project plan, I thought I would get in the mood by making up a document header to improve the aesthetics. I started with a few Google searches to find some pictures of classic retro games, for example Space Invaders or Tetris. The first thing that popped in my head when I thought of doing this was to have a picture of each game next to each other with the title clearly in the middle. The games I used are:

- Breakout
- Space Invaders
- Missile Command
- Asterids
- Meteor
- Tetris

(Actual images)

When I had all the images I wanted, I started cutting them up in Photoshop and sectioned them evenly over the header. To reduce the colour saturation I turned the opacity to 65% and used a light blue background behind it.

When I was done I copied a section of the space invades section and duplicated it down the left side of the page to ensure I had the right colour. Because it was duplicated several times I cleared most of the existing stars and drew some of my own using the brush tool and changing the size of the brush to get a better diversity of small and big stars. Lastly I added the subject code so it didn't look so bland and open.

With the page header done I began putting the document together by inserting the header as an image and using a text box over the top of it to add the content to the page. I did a few test prints to see how it looks on the page and checked the margins so that it was wide enough to bind the documents without cutting into the side.

I put all the bits and pieces I've been writing down in my notebook into the document. (Fill in more later)

Random Names

2007-03-29T12:12:00.002+10:00

During the tutorial, I turned to Pete and asked him, "Whats the name of our game? Whats the name of our company?". In response to that he quickly opened the browser and did a quick search for a "random name generator". Most of them were specific to character names, but we had a look at one in particular called "Band Name Maker", after the first few listings we saw a funny name called "Rat Torture" which both made us laugh and sparked an interest because of its originality. I began writing a few combinations down to see what we could come up with.

Rat Torture Games
Net Input and the Whiskeys
Rat Torture and the Beers
Rat Torture & Beer - This was more directed towards myself being the rat and Pete being the beer, but I don't think it rolls off the tongue that well.

Beer Torture and Rat - I'm pretty sure this is the name we agreed upon, and we will probably use this throughout the project.

OK, with that sorted we now needed a name for the game. Previously Pete has been calling it X-Mulge which i think is an acronym. Anyway we both started thinking of some words that describe the game. Some of the words I wrote down were:

Qwerty
Retro
Simple
Multiplayer
Competitive

It was at this stage, Pete started describing an RPG game he had saw on GameDev.net that has really long name, I cant remember it exactly but it went something like this:

Super awesome mega oldskool action RPG magic wizards

But this lead us to thinking of the same type of words to help describe and also improve the appeal of our game, some more words I wrote down include:

Super
Mega
Omega
Awesome
Hyper
Action
Awesomeness
Insane
Wicked
Retro Game Fighting
Retro Wars

Eventually with a little bit of discussion and so forth we came to like "Super Retro Mega Wars", which in my opinion describes the game pretty well, and I like the adjectives.

In reflection, this process was relatively painless and we both came to a solid decision on both names chosen. With this out of the way, its one less thing to worry about. I think that both of our thinking processes and they way we solve problems could be similar, I guess were fairly like minded and both have high expectations or goals which helps when working in a group. I have worked with many different people during all of my studies and in every instance I have had to put in 90% of the work while the rest of the guys/gals do almost nothing. Now their was an exception last semester when I worked with a guy named "Yannick", he was also a hard worker and being his final semester he really wanted to make the effort, so the last project was nice to have someone to fall back on and have some help. I'm pretty confident that we will get this project done, but I honestly think time will be a major issue, this is probably the one thing that I always stress about the most, TIME. Their just isn't enough of the damn shit I tell ya!

Over and out.

Project Plan Part Three

2007-03-29T12:12:00.001+10:00

OK, I admit I haven't had much time for the project plan over the past week, I've been busy working on the other three subjects that are all expecting assignments on week 4. But in my defense both Pete and I got a lot done during today's tutorial. Before the tutorial I gathered what Pete and I had done so far and made a list to sort of nominate what sections each of us can do.

Cam
- Skills + Bio (Personnel)
- System Requirements
- Work Breakdown
- Quality Issues
- Budget

Pete
- Target Audience
- Project Summary
- Intellectual Property
- Budget

Pending
- Implementation
- Documentation

I got the work breakdown, budget, system requirements and part of the personnel down roughly for now, I will polish them up before next Wednesday.

Project Plan Part Two

2007-03-29T12:10:00.001+10:00

I've been writing some note's in my book about our project plan, to get some inspiration and ideas I reviewed the last project plan I did (last semester). Some of the sections brought back some memories on how we tackled this at the time. During our tutorial Pete and I went over what parts of the plan we think should go in ours and came up with this list:

- Work breakdown
- Budget
- Target Audience
- Quality Issues / Assurance
- Documentation Plans
- Plan for implementation
- Intellectual Property
- Personal expertise/proficiency
- Developer Collaboration

Their might be more sections that need to be added to this list, but this is what we have so far.

I wrote down some system requirements, both minimum and recommended so the client/user knows what sort of specs will be required to play, and got down a list of skills that we will use to complete the project.

Blog! Ahhhhhh

2007-03-29T12:08:00.000+10:00

Still getting used to using this makeshift blog, conveniently supplied and hosted by Pete's work. Pete's been going through how to use the back end of it and how all the templating works. So far so good, I think it should work out to be a valuable resource in our project, and should make writing this diary so much easier.

During our tutorial today, Pete and I had a look at the back end and attempted to figure out a method of truncating this section of the blog to a specific number of characters (100 for example) and cutting out the rest and tacking on a "Read more" at the end. Pete found this good piece of code that looks like it would work well in a normal situation, but we encountered a problem with the templating section were it would look for open braces ( { ) and then look for a placeholder so it could be filled with content from the database. Because of this it meant that the code could not function because we couldn't put in the necessary braces. So, we will just move back to using the short description and for each post we make we can type up a quick summary.

In conclusion, I can't complain this truly is what we needed in my opinion, and having complete control over the site/blog sways in our favour.

Link: Truncating Code

JOGL

2007-03-29T12:06:00.000+10:00

After some discussion Pete and I made an informal decision to develop the game/engine using a mix of Java and OpenGL, the reason why we choose OpenGL was because I have some experience in developing with it and it also means our game will be cross platform and usable on Linux. Having our game's work on Linux is big plus for both of us, because ultimately i would like to get it hosted on a synaptic repository so other Linux users can easily download it and play it with their friends. Currently the Java library doesn't support all of the official OpenGL functions and using the Java 3D api probably wont run very fast, I did a quick search on Google and found the official OpenGL api supported by Java (JOGL), after looking at some of the examples and demo's provided on the site I came to the decision that this would be the best method.

Some links I found useful with downloading, installing and using JOGL.

JOGL Distribution (dll's and libraries)
Install JOGL for Netbeans
Older website with some tutorials on JOGL
OpenGL Red Book for Java

Project Plan

2007-03-29T12:00:00.000+10:00

At the end of last semester, Pete and I talked about starting a project and he pitched his idea to me about a multiplayer game that pits two players against each other in two different games, notably Tetris and Breakout. When we finished the year off, I did a bit of coding in C++ and OpenGL to have a look at how we would go developing this idea, it seemed achievable at the time because I had just finished learning OpenGL and C++ during uni so it was still very fresh in my mind.

Presently we've just started back at university, and its been a long four months. I really haven't had any time to keep coding since I've been busy working, but I think with a few weeks of coding I'll get back into the swing of things, I had the same problem at the beginning of last year and it only took me a week or so to get back to were I left off.

I've been working on and writing down notes on some things we can put in our project proposal, but I also took some notes down while Pete and I were at our studio's tutorial. Below are the notes I took down during the tute and the notes I came up with for the proposal and the project, the way I write down my notes should reflect my thought process and how I identify and solve problems.

What language should we use? C++ vs Java - Pros + Cons?
C++ is a very common language, it is very powerful and is favoured by industry when developing. On the other hand Java is a new and also very powerful language, it has a lot of libraries and classes that are easily accessed. I'm not going to go into in depth detail about the real pros and cons of both of these languages.

Do we want the game to be multi platform? Windows, Linux and OSX.
In my opinion, yes!@! Their is a shortage of good games available on non-standard operating systems like linux and osx. Obviously this isn't a major issue and is actually probably quite trivial, but none the less I think its important that we think of these type of things.

We will need to implement modules like a Particle Engine and Collision Detection, which can both be fairly complex, especially when dealing with 3D graphics (OpenGL/DirectX).

A GUI (Graphical User Interface) will be required to operate the game(s), what will this look like? How will it be implemented, using OpenGL or Swing controls?
I can't really explain how the GUI might look at this stage, its still early days, but I should try and get a concept idea drawn up for this project plan, just for show. About implementing it, well initially we WILL be using Swing controls because its a quick and easy way of debugging the game and testing it to see if things work.

On the topic of testing, we might actually need to get a few friends or associates to help test the game(s) for bugs, I don't think between the both of us we will have enough time to accurately debug all of them before the end of the semester.

The networking side of things, do we develop just a client? Do we develop a client and server, using application tier architecture?
We'll the networking part of the project should be the most interesting, this is the sole purpose of creating this project in the first place, so players can compete against each other. Well, making a client that can serve as the host of the game should work most effectively, I've seen many older games like this before and they have been successful. What would be the need of having a server? A centralised server could be used for advertising open games so players are not just limited to playing with their friends, and also possibly a scoring system or ladder for recording players high scores or ranking. This area has a lot of room from discussion and a bunch of ideas, but I think we need to stay conservative and try to bite off more than we can chew.

OpenGL or DirectX?
To start with, I have zero experience in DirectX, but i do have some in OpenGL, I was fortunate enough to have James Sofra teach me 3D programming last semester, which I enjoyed thoroughly, and feel confident that we can tackle this project head on in this department. Though I don't have a LOT of experience in OpenGL and this will still be a major learning curve developing something of this scale and magnitude.

Which IDE do we develop in? Netbeans? Eclipse? VS.NET?
I think any one of the IDE's above are capable and usable, Pete and I both have experience in all of them. I think the main reason for asking this question is to find out more specifically what CVS client do we want to use? Concurrent Vesioning System (CVS) was designed for developers to use as a way of keeping track of changes to the system, and allow multiple developers to work on the project simultaneously. If two developers write a patch of code in the same file at the same place, they will be shown the differences between each part, and the opportunity to fix up the code, and merge the two patches together. This sort of system is perfect for our project and will play a major part in the development.