Sean Gibson's ePortfolio

  This sprint, I worked on some upgrades to the heavy enemy, some touch-ups to the wave system, as well as ensuring that the player will always see the tutorial once before they first play the game. Starting off with the heavy enemy, feedback indicated that it felt too similar to the medium enemy. They were essentially the exact same, except one was bigger and shot more rapidly. In order to further differentiate the two, we decided to give the enemy a burst-shot, as well as a unique ground slam ability that would hinder the player for getting too close. For the burst fire, I decided to use a delay loop that would retrigger until int Burst Index reached 0, decrementing it at the end of each loop. At the end of the loop, an event is called that notifies the AI controller that the burst fire sequence is complete. I think that in the future, it might be better to take another stab at this using a timer handle, and probably some more descriptive function names than “FireProjectile...

  This sprint, I started by implementing alternate success conditions for certain scenarios. This means that for some scenarios, there will be multiple different stat checks that can lead to different outcomes, and potentially different scenarios down the line. Two different outcomes of the scholar’s exam scenario. One for high intelligence, and one for high charm! This was an interesting programming challenge, as I had to figure out how to associate these alternate conditions with the data table that is currently holding all the scenario information. The interesting thing about these alternative outcomes is that they function as almost half a scenario. They have no intro dialogue, but they do have a unique stat check, outcome dialogue, and list of scenarios to unlock on success. Because of this, I decided that I would copy the current scenario into a new struct. That way, I could “swap out” certain pieces of data at runtime without having to fill my data table with duplicate inf...