Jade Spooner
Contributions
This was my final project for my Hardware Architecture class that I went especially overboard on. My idea was to create a game similar to a classic physics based Flash puzzle game. I didn't see the difficulty at the time, but I certainly realized it when it finally hit that I'd have to code the physics from the ground up with no floating points!
Because the core gameplay mechanic was shooting a bullet that would bounce against the environment, this was the first thing that needed to be coded after the basic player controller. The rotation of the gun was simple using an affine sprite and angular code to automatically allow the sprite to turn when interacted with. The difficulty began when coding the bullet. Floating point operations would slow the entire game dramatically, so I opted to code the entirety of the collision function with fixed point numbers using bitshifting. The bullet could be fired from any angle, so the method had to first check the angle before running a digital difference analyzer to determine whether the bullet would hit a bounceable wall. If it hit a bounceable wall, it would then calculate the angle at which it would reflect off. However, the bullet may still have some travel distance remaining after colliding with the wall. Therefore, the method additionally had to be properly recursive to complete a frame of movement. This took multiple weeks to perfect, but in the end worked excellently with no impact on framerate!
The second component that was more difficult than I expected was movable crates. The first major problem that needed to be solved was pushing multiple crates at once. One object pushing against another is simple; multiple objects pushing in a line leads very quickly to clipping and incorrect physics. To make sure that other boxes were moving properly with the first pushed box, recursion was implemented to chain together the boxes. Additionally, if the end block was colliding against a wall, it would chain through all previous calls to properly stop all of them.
The second major issue was crate interaction while falling. This was more of a fringe issue, but still an important one to correct. The problem is, originally, the crates that fall first were the first instantiated, not actually the one that needed to fall first. Therefore, I needed a way to sort the existing crates from the first to fall to last to fall. Because the first to fall would be the one lowest on the screen, I used a sorting function based on their row position to arrange the movable boxes in an array to the order in which they fall.
