Future Plans

#For the player

##Player notifications

• Flash the screen a shade of red whenever the player is injured

##Interface features

• Create settings class and GUI

##Possible additions

• Bosses

• Levels

• A tutorial

• PowerUps

  • Supply planes
  • Health packs

• An ammo class (with limited shots)

• New winning conditions

• Weapon specialization

  • Missles deal extra damage to bosses

#For the programmer

##Organization

• Organize files into sub-directories as more classes are added
  • Enemies
  • Weapons

##Optimizations

• Split the GUI and the turn processing into multiple threads so rendering can occur at the same time as processing
• Prevent QTimer from starting again until processing is complete to prevent lag from building up
• Partition the scene into multiple vertical rectangles for faster processing.
  • When an object is added to the scene, add it two the partitions it is in.
  • When checking for colliding objects, only local items must be checked (items in the same partition)
  • Optimally (assuming no partition overlap, which will happen in practice) decreases number of items that must be checked by O(m) and thus overall order notation by perhaps O(m²), where m is the number of partitions.

##General Coding Improvements

• Use std::uniform_int_distribution instead of rand for better random
• Allow easier adding of enemies and weapons
• Allow enemies to be added without their classes and probabilities being hard-coded into Enemy.cpp
  • Have each Enemy have a const static int representing how common the enemy should be
  • Use pre-processing to build this into Enemy.cpp so the super class need not have any knowledge of it's sub-classes
    • Consequently remove un-needed headers from Enemy.cpp