Monday, June 11, 2007
Congrats to Rafael Nadal on his 3rd French Open. While I'm not crazy about him being 21-0 at the French, he is currently the only man who can challenge Federer. So hopefully Federer loses at one of the other major tennis tourneys, then maybe I can root for someone else at the French.
Sunday, June 10, 2007
I bought one of these things over the weekend:
While they certainly may not get you out of life's jams like they do on the commercials, they are fun to play with. "That was easy!"
While they certainly may not get you out of life's jams like they do on the commercials, they are fun to play with. "That was easy!"
Sunday, June 03, 2007
Over the past week I have spent a lot of time working on my video game. For those of you who don't know, I have been trying to develop a computer game using OpenGL in the style of a game called "Super Ships" that I had for the Mac as a kid.
"Super Ships" was a game where you had a collection of 2-D starships that you could choose from, and place up to eight of them (I think) into deep space, and have them battle against each other. You could pit teams of ships against other ships (useful if you were battling more powerful ships). The part of the game which I enjoyed the most was the section of galactic takeover... where you would start off in control of one or more planets, as did the CPU. For each planet that you controlled, you would build up defense drones and star fleets, and then travel to neighboring planets in hopes of conquering all of the planets in the star system before the CPU did.
After my Mac got worn down, I never could find a PC equivalent version to this game, so recently I figured I might as well try to develop an equivalent game myself.
In the process of attempting to develop this game, I've learned several lessons along the way:
1) I've realized the necessity of having a clearly defined structure to the game coding prior to just coding away. It seems that with each enhancement to the game that I make, it affects many different areas of the program, despite my best efforts to modularize and encapsulate the different components to the program. (In relation to my job, it really makes you appreciate the importance of a "Functional Requirements Document" when developers are designing large scale business software!)
2) The necessity of deciding on setting limits on certain game parameters. Currently, I've gotten to the point where you can design ships in a ship editor, choose a subset of them to be placed in a battle scene, and a rudimentary algorithm to make enemy ships battle against one another.
Several areas where the parameters currently need to be limited are:
a) Ship velocity. Ships are undergoing continuous deceleration/re-acceleration in the battle scene as they attempt to aim towards enemy ships, and in the process the velocity gets so fast that they bounce off the wall so much you can barely tell where they are going!
b) Number of weapons. I developed a ship which looks kind of like a poor excuse for one of those Borg Cubes from Star Trek... and could set it to it could fire like 30 weapons at once! (Pretty much a single shot from that ship and you're toast.)
3) Awareness of what key strokes are supported by an interface. I anticipated on using the arrow keys to control ships and spacebar to fire a weapon, but my library doesn't seem to support these keys for some reason! (Well if I can find a library that will support these key strokes it will be very easy to fix... hooray modularity!)
4) The need for a degree of randomness in a game like this. I was showing the progress that I had made to one of my co-workers, and he made the point, "Well, are these exact events going to occur every time? The outcome will be exactly the same every time then!" Good point... need to implement some random actions.
Live and learn.
"Super Ships" was a game where you had a collection of 2-D starships that you could choose from, and place up to eight of them (I think) into deep space, and have them battle against each other. You could pit teams of ships against other ships (useful if you were battling more powerful ships). The part of the game which I enjoyed the most was the section of galactic takeover... where you would start off in control of one or more planets, as did the CPU. For each planet that you controlled, you would build up defense drones and star fleets, and then travel to neighboring planets in hopes of conquering all of the planets in the star system before the CPU did.
After my Mac got worn down, I never could find a PC equivalent version to this game, so recently I figured I might as well try to develop an equivalent game myself.
In the process of attempting to develop this game, I've learned several lessons along the way:
1) I've realized the necessity of having a clearly defined structure to the game coding prior to just coding away. It seems that with each enhancement to the game that I make, it affects many different areas of the program, despite my best efforts to modularize and encapsulate the different components to the program. (In relation to my job, it really makes you appreciate the importance of a "Functional Requirements Document" when developers are designing large scale business software!)
2) The necessity of deciding on setting limits on certain game parameters. Currently, I've gotten to the point where you can design ships in a ship editor, choose a subset of them to be placed in a battle scene, and a rudimentary algorithm to make enemy ships battle against one another.
Several areas where the parameters currently need to be limited are:
a) Ship velocity. Ships are undergoing continuous deceleration/re-acceleration in the battle scene as they attempt to aim towards enemy ships, and in the process the velocity gets so fast that they bounce off the wall so much you can barely tell where they are going!
b) Number of weapons. I developed a ship which looks kind of like a poor excuse for one of those Borg Cubes from Star Trek... and could set it to it could fire like 30 weapons at once! (Pretty much a single shot from that ship and you're toast.)
3) Awareness of what key strokes are supported by an interface. I anticipated on using the arrow keys to control ships and spacebar to fire a weapon, but my library doesn't seem to support these keys for some reason! (Well if I can find a library that will support these key strokes it will be very easy to fix... hooray modularity!)
4) The need for a degree of randomness in a game like this. I was showing the progress that I had made to one of my co-workers, and he made the point, "Well, are these exact events going to occur every time? The outcome will be exactly the same every time then!" Good point... need to implement some random actions.
Live and learn.
