A 3D billiards simulation game:
During this era, videos games for computers were either designed by companies and sold in software stores (which sold games in boxes with floppy disks or CDs to install the game), or you could sometimes get 'shareware' games which were written by single hobby programmers or small teams. With shareware, you could install a game for free which allowed you to play up to a certain point, but for the full game you mailed a check to the developer who would then send you the full game (or a code to unlock the full features) by mail.
I thought it might be interesting to try to write a shareware game which I could sell this way, and settled on trying to write a 3D simulation game to play billiards. There were no similar games for billiards when I started this project.
So I bought some books that shared ideas about how video game development worked, and started writing my own 3D-gaming engine from scratch. This involved a lot of cool applications of trigonometry and other math :)
I had also come up with what I thought was an innovative way to handle the fact that people had widely varying computer CPU clock speeds at that time, but you still had to make the ball motion look physically correct regardless of the speed of the computer it was running on. I did this by doing something I called 'timeslicing' - dividing ball animation into slices in time, because each frame of animation of the balls moving around after a shot would be composed by the game engine, copied into the video frame buffer, and then rendered, and that took a specific amount of time in the real world.
The problem was that how much time it took to render a frame of animation wasn't constant - it varied not only depending upon the particular computer hardware the game was running on, but also by things like how many balls were on the table, how many balls were in motion, and even the size of the ball images.
To solve this problem, I included an opening animation when the game started which shows an 8-ball rolling towards the observer...but the game used this animation to measure how much actual real-world time it took to animate different size ball images. This info was stored for later use, and for any particular animation of the result of a pool shot, I was able to write an algorithm which could predict how much real-world time it would take to animate the next frame of shot animation based upon how many balls where visible and the sizes of the balls. Once the current frame was loaded into the video buffer for display, the algorithm would then advance 'play-time' by a 'time-slice'...just the right amount of time so that the next point where we calculated where all balls were would be precisely at the point in real-time when the current animation frame just finished being displayed.
The result was a system that could correctly adjust automatically so that the ball physics matched how balls would really move, and if you were running on a fast computer you would just get more frames animated per second automatically, so the animation looked smoother, but on slower computers, the frame rate would automatically adjust to lower frames per second automatically so that the balls always moved in a realistic fashion.
Unfortunately, when I was at the point where the main 3D engine was up and running, but I hadn't added the rest of the pool table and all the game scoring code, another shareware game, Virtual Pool, was released...I was about 2 years too late! So I abandoned the idea of distributing my game as shareware, and actually never finished coding it.
Still, it was an interesting process developing the game to this point - by clicking the mouse I could change the location of the player, zoom the view in and out, and change the orientation of the pool cue before making a shot, and then it would animate the balls on the table surface. Here are a couple of screenshots from my partially developed game:
