-A simple state machine that allowed other programmers to add there modules into the game without interupting its flow. I had a seperate file where programers would add the id there functions returned to an global enum list. These enums would help track the IDS of different modules. In short to go to any other module within the game from your module you simply returned the enum of the corresponding module such as MENU_1
I have to admitt I went a little over board for this small of a scale project. All classes derive from a base class and have a sound state machine, animaton state machine, and a AI state Machine. Basically every entity in the game can be created to handle its own individual animation, sound and movement, it's a great feature but it was a little more than what we had time to use in this project.
Collision actually later became the brunt of the optimization. We decided to make alot of the tiles and simple objects in the game into entities that way they could take advantage of the features that were built into them. With alot of entities especially when bullets came into play it was important to make sure that i narrowed the scope of the collision checks to just within a few tiles of a bullet. With up to four or more enemies on the screen firing out about 1 bullet per second it would leave about 20 bullets on the screen 24 times the 3000+ entities checked per frame really chugged, so we ended up with about 6-7 different collision functions. Each having a specific test.
I just made the music change when the enemies were attacking you and when you triggered certain events to try and give a feeling of intensity.
Probably the most complicated part about this project was the A.I.There were five AI states used in this game. In the idle state if a A.I. unit was created with more than one way point he would traverse his way points until the player came within his field of vision. (I found out quickly that there is alot of trig in messing with facing vectors and angles to get a correct looking turn). Then he would change to attack state and start pathfinding toward the player. If the enemy was a shooting enemy he would fire bullets at the player and keep a certian distance from the player(seperate collision check) The last three states i only used for the end guy though i had originally planned otherwise. The flee state would cause the enemy to move away from the players position and not attack. It lasts for a few seconds and is triggered by a random chance when the units hp is low. The dodge state is triggered the same way and last for a few seconds i wanted you to be able to see it happening so i made the guy spin a circle and nothing damages him in this state. The last state is the bzerk state the enemies rushes at you shooting and moving at 3 times his normal rate
Problems with pathfinding : Normally the enemy would pathfind directly toward the player unless the player ducked behind an object and caused him to fail his ray of vision test. Then the enemy would pick up on his waypoint trail which was stored inside the player class. This trail updates every second and was only about 14 points long. Unfortunately i didn't have enough time to make the enemy pick up the closest waypoint instead he would just grab from the end of the list. There are apparant prolems with this. If the player gets too far away from the enemy, the enemy gets a waypoint that he has to go through a wall to get too. Here a simple reset would have been sufficient. Also the enemy has to turn the other direction to get to the point and that just looks funny. Alas i ran out of time in the end we had but a few days left a only one level.
(Main)
