A Fresh Start

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

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!

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

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

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

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

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

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

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

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.