Peter Eldredge PPJ #3

Overall Project Framework - 3 Hours

Improved Enemy AI - 2 Hours

Health System - 1 Hour

Heat System - 1 Hour

Collision System - 1 Hour

Player Control Tweaks / Bouncing help - 2 Hours

Overview 

This week was mostly about refactoring our code to make a sustainable foundation for the game. This meant redoing most of the core systems, and building upon them. Even with this time commitment, it improved the rate at which new features can be added so much that I was able to re implement nearly all the important data based systems and add several new features relatively quickly.

Overall Project Framework

The key component of this rewrite was towards an event based architecture. This allows any class to "Subscribe" to a certain event. When that event is fired, each class that Subscribed gets alerted, and can take any required actions. This drastically reduces "Spaghetti Code" and allows all components to act independently.

I wont show the Event Manager class, as it is fairly long and a bit dense, but I can show some examples to demonstrate the concept.

In this example we can see the event PlayerAttackedEventArgs. The only data it contains is the Damage property. The Attack class, which all attacks are derived from, can trigger this event. This will create a new event object, passing it all the necessary information, then send it to all classes listening for the PlayerAttackedEventArgs.

In the highlighted lines demonstrate the event system in use. In the Subscribe() function, which is called in OnEnabled(), we make the lambda OnAttacked() listen for the PlayerAttackedEventArgs That function calls the TakeDamage() function using the Damage property from the event. Hopefully you can see the uses, as in this class alone we have 4 events that are being listened for.

Improved Enemy AI

Some refactoring happened with the enemy behaviors system, but the biggest changes were the new options that could be added to attack behaviors. Now attack behaviors can specify the rate at which the enemy tracks the player, and the enemy can have optional attack points which determine the location attacks spawn at. Here is some of the code behind how the enemy determines its current behavior, and demonstration of it in action.

The enemy checks every frame to see if any AttackBehaviours meet their UsageCondition. The first behavior that does is the behavior that will be used for that frame. The AttackBehaviour will also specify how the Attack will be carried out as well as how the enemy will Track the player.

Here we can see the three main components of an AttackBehaviour, the UsageCondition(), the Attack(), and the Track(), as they are implemented for the Laser Attack Behavior.

The UsageCondition() function determines whether not the behavior is valid for the current frame, returning True means it is, returning False means it isn't.

The Attack() function contains all the information needed about the attack, and how the attack is executed.  

The Track() function contains the information about how the enemy should be tracking the player, if at all.

Health System / Heat System / Collision System

You have already seen parts of the Health System in the overall project framework. Listening for/ Triggering events is one of the primary ways these systems work and interact with each other. They each have a general purpose that is hopefully self explanatory by their name.

The collision system triggers events whenever the player collides with something that any other system can listen for.

The heat system is what controls the heat, and listens for any event that could affect the heat.

The health system controls all affects on the health, and listens for events that could impact the health.

All these systems work in conjunction yet separately. For example, when the player collides with a  rock, the CollisionSystem triggers the ObstacleHitEventArgs event. The HeatSystem listens for this event, and calls the TakeDamage() function. The ShipController also listens for this event, the will trigger the BounceBack function.

Additionally, when the player overheats, the HeatSystem triggers the OverHeatedEventArgs event. The HealthSystem listens for this event, and then starts the OverheatRoutine() coroutine.

Hopefully I've been able to demonstrate the power of Event driven architecture, and how it will help us add functionality more rapidly in the future.

Heat Accumulation Changes

One system that had a large change was the way you accumulate heat. Now, while holding the ignition, heat will accumulate based on an animation curve until the overheat state is reached. Once you release the ignition, your ship will cool off, and you cannot reignite until your ship has completely cooled. Additionally, there is a penalty if you overheat, where you will remain in that state for a few seconds without cooling after releasing the ignition. The hope is to improve the visuals of this system in the upcoming week with effects on the player and screen, instead of just using the heat bar.

Here is the current code for accumulating heat. I plan of refactoring it once we get to the tweaking phase and have a fully fleshed out input system.

Player Control Tweaks / Bouncing Help

I also helped Jake a bit with the player and various miscellaneous things. I'm sure he will talk more about these systems.

Group Positives

Everyone has fit themselves into general areas / tasks and it seems like things are progressing relatively well. I do feel like the game is starting to come together on different fronts.

Group Negatives

Same issue as usual, we were left throwing everyone's work together Thursday morning. I think for this upcoming week we are going to try and have our weekly meeting sooner so everyone knows their tasks for the week.

Upcoming

I am going to continue to help with any implementation, primarily regarding the gameplay system or the player physics. Hopefully once most of that is sorted I can continue to expand the enemy systems more and get more into the design aspect of them.