SDL Shooter

Simple space shooter game created using SDL (Simple DirectMedia Layer) and C.  Sprites created with Aseprite.

Energy meter added.  Using any weapon will deplete energy, but it will gradually refill over time.   Each weapon has three strength levels and energy consumption increases with the strength of the shot used.

Below are the weapons in the game.

 

Weapon Name Weak Attack Mid Attack Strong Attack
Speed Shot Slightly increases fire rate Moderately increases fire rate Greatly increases fire rate
Multi Shot Shoots in two directions Shoots in three directions Shoots in four directions
Wave Shot Shoots one wave projectile Shoots two wave projectiles Shoots four wave projectiles
Blast Shot Damages all enemies on impact within a small radius Damages all enemies on impact within a medium radius Damages all enemies on impact within a large radius
Spin Shot Four projectiles rotate around the ship Eight projectiles rotate around the ship Sixteen projectiles rotate around the ship
Freeze Shot Freezes an enemy in place for 1 second Freezes an enemy in place for 4 seconds Freezes an enemy in place for 20 seconds
Seek Shot Locks on enemies within a small range Locks on enemies within a medium range Locks on enemies within a large range

 

 

Enemies will drop various bonuses, such as refill energy, increased attack power, increased defense power, and health refill.

Create your own levels by editing level_00.txt.  Separate waves with a single equal sign ‘=’ on a line.  Place enemies using the numbers 1, 2, 3, and 4.

Create Linux build by running ‘make linux’.  Tested and works on Ubuntu Linux.

Get the source code at https://github.com/gatechgrad/SDLShooter

 

Enemies

  • Alpha – Moves left and right in a horizontal motion
  • Bravo – Moves to the right at constant speed
  • Charlie – Moves downward in a wave motion
  • Delta – Moves in a circle motion
  • Echo – Moves to random locations;  Vulnerable only when eye is opened

Weapons

  • Normal shot – 5 energy
  • Fast shot – 8 energy
  • Triple spread shot – 15 energy

 

Released

Scratch Shooter

Scratch Shooter

 

Scratch Shooter is a simple space shooter game created in the Scratch game development environment.  This game was created as an example for the November 2019 Knoxville Game Design meeting.

Enemy creatures continually spawn at the top of the screen, and gradually move downward over time.  Enemy ships will float down from the top in a curve motion.

Play Scratch Shooter on Scratch website

 

 

Released

Scaling Models

The enemy HP values have been removed from above the enemies on the game screen, and a damage value that floats over the enemy when hit has been added.  I created a new class for overlay text, which is used by both the 2D and 3D game screen.  This prevents the code from being duplicated for things like the status text and enemy damage.  I added a new property to the enemy that is the dying state and counter.  This was needed because the damage value does not display if the enemy is not alive.  This kept the last damage number from displaying.  Now I’ve changed it so that the damage value displays if the enemy is alive or dying, so the final damage number now correctly displays.  The dying counter will also be needed to display a death/blowup animation.  On the 2D game display, I added logic so that the enemy just fades away using an alpha color value based on the percentage of the dying animation passed.

screen080

I created a simple graphic for the projectile.  I mapped this graphic to a simple 2D plane in Blender.  It’s important to remember that all points of the Blender model must have a Z coordinate equal or less than 0 (non-positive) to appear.  This may be backwards for my game, since I am rendering the 3D world with the Y axis facing downward, which makes translating from the 2D to 3D coordinates simpler.  Remember, the model coordinates are relative to the small orange dot, which is not necessarily the location where the axes cross in Blender.  It is a good idea to put the orange dot at coordinate 0,0,0 in Blender to keep from getting confused.  Therefore, all vertices must be moved in edit mode (not object mode) for the changes to appear in the game.  Similarly, scaling an object in Blender’s object mode will have not effect on the model in the game.  The model must be scaled in edit mode with all vertices selected for the size change to appear in the game.

Also, I converted the List of loaded Model objects to a Dictionary object.  I thought that a Dictionary was the same as a hash table, but Chris Gardner (@freestylecoder) explained to me that Dictionaries don’t allow multiple values to be assigned to a key like a hash table.  He said that Dictionaries should be used like symbolic links, which is what I am doing with my constants which represent each model in the game.  The previous method I was using was kludgy and bad style, which was adding the Model to the List and setting the constant ID of that object to the order number which it was added to the list.  That process was a hassle to maintain and a recipe for disaster later.