School and Personal Projects

Index:
    1. Chopper Patrol - Unreal4/UMG/C++
    2. Scorched Waters - SDL 2.0/C++
    3. Rocket Lander - SDL 2.0/C++
    4. Trench Defender - Unity/C#
    5. IEEE Robotics Competition - Capstone Team Project

Chopper Patrol is my personal attempt to recreate some of the core gameplay of an old favorite PC game, SimCopter. The player pilots a helicopter in a 3D world with simplistic flight control. Unreal UMG widget blueprints were used to create the menu system and responsive in-game HUD.

A nifty User Interface

The in-game HUD has several features that provide interactive feedback to the player. The compass bar at the top of the screen accurately scrolls with player rotation to show direction. Three individual dial gauges use rotating needles to display readouts for speed, altitude, and the main rotary’s RPM. Each gauge also grows in scale when hovered over by the mouse to give a zoomed in view. Vertical progress bars fill to indicate the player’s pitch angle (forward/backward lean). A click button control panel allows the player to pause the game or toggle helicopter functionalities such as a spot light and radio.

Programming Flight

The player indirectly controls their altitude by changing the speed at which the rotary blades turn. While the chopper is in the air and there is no input, it will the hover in place. Increasing the rotary blade speed when hovering moves the helicopter upward. Vertical lift will continue even after player input is released, until the blades slow back down to their hovering speed. The same hover speed tethering is in place when decreasing blade speed to move down.

Users control the chopper's pitch and yaw for forward/backward speed and direction adjustments. Pitch will slowly recover to an angle of zero, similar to how rotary RPM returns to hover speed.

This indirect control of altitude and direction creates the feeling of weight and momentum, which was a fun and sometimes challenging part of piloting in the orginal game.

Return to Index

Scorched Waters is a 2D battleship shooter played against an AI opponent on top of a dynamic water particle simulation. This was a solo developed project written in C++ using Simple DirectMedia Layer 2.0.5. SDL provides basic device IO that allows for reading input and drawing sprites, but all of the physics for this game was programmed without the framework of an existing engine.

Water Partical Simulation

The water particles interact with each other based on Smoothed Particle Hydrodynamics (SPH) model of simulating fluids. The basic idea is that each particle computes its pressure as a sum of contributions from neighboring particles. Pressure determines the force and velocity of every particle for each frame, with particles tending to move away from high-pressure areas towards low-pressure. The combination of gravity, pressure, and bounding conditions on the edges of the game-world result in the simulated "water-ish" movement. Here is an excellent walkthrough on the basics of SPH from Lucas Schuermann, for further math details and a guide on 2D implementation.

The ships Y positions and render rotations are affected by high pressure particles. Each ship has a left and right endpoint that check for the average Y position of nearby particles at or above the resting density. The length of the ship and the Y position on both ends are plugged into an arcsin function to find the angle at which to render the ship each frame. These position and rotation calculations create the bobbing effect of the ships sitting on top of the water.

Projectiles and ship explosions also interact with the water system by greatly increasing the pressure of whatever particles they collide with. Doing so creates a mini explosion of water at the point of contact.

Optimizing Performance

Before specifically investigating performance, running the game with a large number of particles could quickly make the frame rate unplayable on my outdated laptop. In the final version, there are 170 particles on screen that each computes the distance to every other particle in order to calculate their pressure, force, and resulting movement vector every frame. Profiling in Visual Studios diagnostic tools showed over 95% of CPU execution time spent on the O(n^2) calculation for distances between particles. This became a clear and necessary target for optimization.

I implemented a spatial gridding system to have particles only check for interaction with others in the same vicinity. The spatial grid is a 2D array of squares that maintain a list of particles within their bounds every frame. Particles not inside the same grid square ignore each other for distance calculations. Particles close to the edge of a square will end up in multiple particle lists, but this is needed to avoid missing interactions along the edges of the squares. The spatial grid improved FPS by over 100%! The game became playable at this ~10 frames per second.

C++11 multithreading is used to process both halves of the water simulation in parallel (literally both left and right halves of the screen split by the volcano). These seperated halves were initially a single data structure, but I divided them into two and had an independent thread run physics calculations on each before both are joined back to the main thread at the end every updated frame. Threading increased performance enough for another 3-4 frames per second. This was a noticeable improvement, but I know there is still more that can be done.

Return to Index

Rocket Lander simulates space combat and flight in a simple 2D game. The player controls the angle of their rocket ship and can thrust or fire missiles in the direction they are facing. They must destroy increasing numbers of alien spaceships to complete each round.

The player controls movement with arrow keys and fires with Space or Shift. Applying thrusters consumes fuel, which can be partially restored from landing pads. Random pads are also assigned temporary power pickups that give 10 seconds of double fire rate or flight speed without fuel cost. Crashing into a pad at the wrong angle or with too much speed will destroy the rocket. Warning messages appear if the player does not meet safe landing criteria or falls too close to the bottom of the game world.

Alien ships spawn one after the other with simple AI that tracks the player's altitude as they move back and forth across the screen. They will periodically fire in the player's direction. After completing each wave, an additional alien must be destroyed before the next wave is finished. Wrecked alien ships will populate the screen, acting as debris for the player to dodge.

All code for ship and projectile movement, fuel tracking, screen scrolling, collisions, landing, HUD messages, playing sounds, animating sprites, spawning aliens, etc. was done by me. Sprite textures, except for the background image, are my creation. Coded in C++ using SDL 2.0.5 in Visual Studios 2015.

Return to Index

Trench Defender is an arcade style shooter where the player increases their score by preventing enemy tanks from advancing.

As the player completes waves, their tank receives upgrades to its reload speed, armor, and movement. Late game upgrades include 3 round burst fire mode and an auto deploying energy shield that operates on a short cooldown. Enemy forces also grow in number and variety with different behaviors and characteristics being revealed over time.

Checkpoints are awarded every 3 waves which prevent the player from having to start at Wave 0 upon death. Different enemies award different kill bounties, and deduct points if able to get past the player. Random drops of special ammo begin occurring after the first wave of enemies.

The project started as a Game Scripting class assignment to recreate Space Invaders, but grew to be my first published web game. It was solo developed in Unity with scripts written in C#. Code and game assets were created by me.

Free to play web game.

Return to Index

The capstone project for my Computer Engineering degree from the University of Houston was participation in the IEEE Region 5 Robotics Competition. I was on a team of four electrical/computer engineers who designed, built, and programmed an autonomous robot that navigated a predefined playing field to harvest and deliver energy from simulated renewable resources. Out of over 30 teams from schools and organization across the South Central U.S., we placed 7th after being eliminated one round before the finals.

The competition required a small, autonomous robot to harvest energy from renewable sources and deliver the energy to a flag raising mechanism. Fully raising the flag marked the completion of the course, with times being compared for the competition. A diagram of the 8’x8’ playing field is shown here.

Robotics Competition Playing Field

Playing Field Details

The walls that enclose the 8ftx8ft course and create the cubbies in each corner rise ~5 inches above the surface. In corner 1 is a light bulb meant to represent solar energy. In corner 2 is a battery representing hydro-electric energy. Corner 3 holds a hairdryer representing wind energy. Corner 4 contains the flag raising mechanism to which all energy is delivered by running a motor that raises the flag.

Random Source Activation

For each of the first three minutes for running the course, only one of the three sources will be on at a time. The order of the source switching will be random as determined by a random number generator. At three minutes, all the sources will be turned on until five minutes at which time the round ends as a failure to finish.

Robot Details

Our robot design made use of an MSP 430 Microcontroller programmed in C. We used an old computer fan and spring wires to harvest energy from the wind and battery sources. Movement was controlled by a 6 v 285 RPM motor (2 ft/second) using pulse width modulation to change speed. 3 infrared close-range sensors, 2 high-resolution shaft encoded motors, and line sensors were used for navigation.

My primary contribution was work on the navigational algorithms used to move the robot about the field for particular time intervals or after specific voltage readings. We programmed functions to align the robot along a wall from any approach angle, back out of a cubby, and navigate from any given corner to another, among other things.

Return to Index

Tim Godwin