Saturday, April 28, 2007


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.

Monday, April 23, 2007

Week 7

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.

Tuesday, April 17, 2007

What do we have left?

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.

Sunday, April 15, 2007

So ya...

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.


Tuesday, April 10, 2007


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, 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.


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:

  • /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.

  • /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...


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))

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

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.





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.


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.

Sunday, April 8, 2007


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. - 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 ( 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

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).


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.

Thursday, April 5, 2007

Networking Part 3

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.

Wednesday, April 4, 2007

Networking Part 2

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.


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.


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.

Sunday, April 1, 2007

I win.

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.



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.

- 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)

- 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

- 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

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