Version 0.15 additions:

- new improved targeting reticle which shows up under any view (1st person, chaseCam, cornerCam etc.)

- targeting reticle now adjusts to ship's momentum, thus providing an accurate estimate of where your shot will go. Coding this involves taking the ship's orientation quaternion and projecting a fictional, instantaneous shot approximately 25 ship lengths in front of the player (at least that's how I chose to do it)

- shots are now much faster, able to traverse the length of the holodeck in about half a second. This allows for much more accurate, "laser-like" shooting

- you can now adjust the distance of the chaseCam from the player ship

- new Allied ship which hatches from certain small asteroid chunks when the asteroid is shot (these special asteroids have a reddish tint to them)

- the Allied ships look like the player ship, but are red instead of blue. They will actively attempt to hunt down and kill enemy ships in the arena. Quite helpful! But of course they steal points from the player this way.

I'll be in New York City for a week, so the next update will be in 10 days or so.

- Now that the quaternion problem is solved, I've had time to take a breather and return to some existing elements of the game that needed attention. For instance:

- Increased asteroid size by a factor of 4+. This makes them easier to hit, but also tougher to avoid. In general I find that it makes the asteroids more a part of the game when they are bigger.

- New enemy ship graphics (I added enhancements to a free model I downloaded from TurboSquid.com)

- New ChaseCam view allows more panoramic view around the ship

- Revised the particle systems routines to make the particles move more realistically

- I found that the less text I render, the better. There was a dramatic speed improvement when I removed the debugging text.

- Created a basic framework for powerups - a few of the smallest asteroids are of a slightly different colour, and will release a random powerup when hit. (Coming soon!)

- More combing of old code and fixing little errors

- Experimented with temporary gravity toward the -z wall (this could be a powerup)

Quaternion by-product work that needed doing:

- Enemy ships tracking abilities re-implemented, quaternion-style

- Shots re-implemented with quaternions

- Re-worked object struct, getting rid of a lot of unneeded parameters and adding others

Enemies now start off quite weak and non-aggressive, so the early levels are fairly easy

Enemy shields, intelligence and aggressiveness increase with each level

Lots of bug fixes

Did some internal re-naming to make the code more readable

After much reading, internet googling and experimentation, I've been able to implement quaternions as the basis for ship orientation and movement.

Still lots of work to do though, as many items (such as the shot spawn routine, and enemy analysis of which direction to move for attack) are still Euler-angle based. For now, though, v0.09 is the first version which allows true 3D movement, uninhibited by gimbal lock.

My goal for version 0.10: to have it as fully functional as the last Euler-angle based version, with shots and enemy AI all working normally but using quaternions.

All ships (including the player) now have regenerative capability. Energy levels slowly restore over time; the rate of recovery is proportional to the amount of energy available.

The next major obstacle is overcoming gimbal lock; it's too obvious a problem to be ignored.

The only viable solution is conversion of the 3D orientation algorithms from Euler Angles to Quaternions, an extension of the complex numbers first studied by Hamilton in the 19th century. They were thought to be of very limited value until more recently, when their functionality as a 3D orientation system was discovered. They avoid the problem of gimbal lock completely but the tradeoff is their nonintuitive nature; it's difficult to immediately sense a direction from a given Quaternion, the way one can with Euler Angles.

Upgraded text display - I use a bitmap font now instead of OpenGL's stroke font

Revised data display - horizontal energy bar, layout updated

Crosshairs when viewing from player ship, improves aim noticeably

"Laser" style shots now instead of sphere shots

High score is now saved to disk in user's preferences folder

Many small improvements to data structures

Added rudimentary artificial intelligence to the enemy ships; they are now "aware" of the player ship, and will actively attempt to shoot the player down.

A minor problem that I had to solve was: how to take the delta vector between the enemy ship and the player ship, and translate that into a target body attitude for the enemy ship. This was solved by a quick trip to Mathematica, and their excellent page on spherical coordinates. The conversion is as follows:

theta (swivel) angle = arctan(dy/dx)

phi (tilt) angle = arccos(dz)

where dx, dy and dz are the attributes of a vector d describing the distance and direction from the enemy ship to the player ship. This vector must first be normalized.

As I knew would happen eventually, I've run into the well-known 3d spatial orientation problem of Gimbal Lock. When the player's ship is at extremely high (or low) angles of attack, that is, the z-angle is at or near +90 or -90 degrees, the normal left-right swiveling movement of the spaceship becomes indistinguishable from movement about the y axis (in this case, roll).

It's not a huge problem, because the player can either tilt further (through the deficient z-angles) or back the tilt off into a more usable range. Initially, though, it can be confusing.

If I really want to solve the problem (and I should, since in the heat of a game you don't want unexpected reaction to your keyboard commands), I may have to use Quaternions instead of Euler Angles to describe the player's orientation in 3D space.

Items added:

- Energy bar showing player energy

- Levels: a level ends when all of the enemy ships are destroyed. When the new level starts, new enemies (and asteroids) spawn.

- Lives: the player is no longer invincible, and has a limited number of lives (3 for now).

- Action screen display: informs player of important state changes (eg: "Level 1", "Level Complete", "Ship Destroyed", "Game Over"

The project is now an actual game, with a start and finish.

The graphics are all still extremely basic for now; essentially they are placeholders until I finish working on gameplay basics and start concentrating on the "look" of the game. This won't be for a while yet as there are still many basic elements in need of attention, such as enemy AI, screen information, level loading parameters etc.

Added flexibility to the arena structure; it can now be any rectangle (not just a cube).

Reorganized the code files. The current list is now as follows:

asteroid.h, asteroid.c

glm.h, glm.c

globals.h, globals.c

holodeck.h, holodeck.c

objectInits.h, objectInits.c

simpleShip.h, simpleShip.c

sounds.h, sounds.c

splash.h, splash.c

main.c

Changed the keyboard input routines: an array of bytes now represents the on/off state of each key. A key down event turns the key's byte on, and a key up turns it off. This allows much smoother, faster and more fluid player inputs without relying on the key repeat feature of the hardware.

Added a very skeletal "Splash Screen" state in which the program is running, but there is no game playing. This screen will allow conveyance of such information high scores, settings, and info on how to play.

Added a basic scoring scheme; found and fixed some bugs and issues dealing with such questions as: if a ship gets blown up by a shot, how do we track which object actually *fired* the shot? That is, who gets credit for the kill?

Finally got the movement and shot-firing directional vectors working properly.

The ship's orientation is represented by two angles, which I call "tilt" and "swivel". Extracting a cartesian vector from these 3D spherical coordinates (i.e. a radius and two angles) is as follows:

x = cos(swivel) * sin(tilt)

y = sin(swivel) * sin(tilt)

z = cos(tilt)

Then, the radius r is simply the magnitude of the vector; that is, how fast the object is going.

Many more additions to the basic structure this weekend:

- Sounds are now implemented using OpenAL and .wav files. I've got various shot and explosion sound effects as well as a background theme that a friend wrote some years ago.

- The computer ships now have the ability to fire shots. They are still "dumb", mostly just thrusting around randomly, but I want to make sure all of the ship functionality works perfectly before concentrating too hard on AI.

- Added an external spectator view option, and found (after looking at the player ship from an external viewpoint) some bugs with my orientation routines. I've managed to largely fix the bugs after some hours of frustration.

- A major internal change (and surprisingly difficult to make happen), is that the user's ship, instead of being a unique, specialized (and therefore wasteful) data construct, is now identical to all of the computer controlled ships. Instead of computer-generated inputs to direction and thrust, however, the player directly manipulates the controls. But the ship itself is identical to the others. This ensures that the player's ship and the computer ships are subject to the exact same physics laws, and it also automatically makes the player ship vulnerable to pulverization by shots, asteroids and other ships, without a lot of extra code.
- An added nice side effect to the above change is that it's now trivial to change the camera view to show the viewpoint of any object in the game.

- There are now 3 different kinds of asteroids: small, medium and large size. The large and medium ones take damage when hit, and eventually crack apart into smaller asteroids.

- The asteroids "tumble" through space now instead of drifting without any rotation.

- Added more performance diagnostic text to the text bar. A "maxObj" display shows the maximum number of active objects seen during the game. This will help me to determine an optimal size for the object array.

Turned CubeRoids into a full-on Apple XCode 3.0 project, rather than just using XCode as a code editor and building the executable from the command line.

The end result really isn't much different (the performance is identical), but the target executable is now a standard Macintosh application instead of a command-line executable, and XCode's structured view of the various code files will allow much improved organization.

Added lots of internal structure this weekend:

- Now that the text info box is running, I've added a frames per second (fps) counter to monitor performance. At the moment I'm getting between 90 and 300 fps, depending on how many active objects (ships, explosion debris etc.) are active.

- The "thinking" and movement routines, now that they are fully separated from the drawing routines, have been throttled to 30 cycles per second. This means that the game plays at a constant speed, regardless of frame rate, and provides compatibility for slower machines and possible future networked play.

- All collision checking is now handled by one routine.

- Collisions are sent to a Collision Dispatch function which allocates damage and performs physics deflections, depending on which objects are involved.

- Asteroids now take damage, and blow up when struck by a ship.

The code blocks are starting to get quite large, so I will probably have to break them up into more files soon.

Added text. After poring through the Red Book and researching text display options online, I decided to start out with the easiest solution, which is the included GLUT utility, glutStrokeCharacter.

I moved the main action window to the left of the screen, and created a 2D, orthoganal projection text info strip on the right side. The text characters came out extremely large, so currently I am scaling them to make them fit. Later I'll play with the viewport dimensions to try to minimize the scaling operations.

1) Carefully extricated all of the pure drawing code from each object type; each type now has its own pure draw routine allowing for more clarity and ease of adjustment.

2) Refined the drawing code, removing a fair number of unneccessary calls.

3) Adjusted the lighting model, removing unneeded code and refining the "look" of the lighting.

1) Began the process of converting the user from a simple cameraman to a ship:

The forward/back keys now control a thrust component instead of arbitrarily changing the position of the camera. Thrust is applied in the direction of the camera view.

2) Removed the pseudogravity which caused shards from exploding ships to "fall" to the "ground". The game will be based in zero-g, so all particles should react accordingly. Therefore there exists no real "floor" or "ceiling" to the cube arena, but the walls may be distinctly textured to help with orientation while playing.

Revised and updated the blog content.

Revamped data structures to improve expandability and portability. Essentially I changed the objects array to an array of pointers instead of an array of static code.

This allows easier access to the array from various different code files, but has the unfortunate side effect of slowing things down a bit. My plan for tomorrow is to fine-tune it and carefully examine the code and see if I created a slowdown in the process of converting the data types.