Final Week & Postmortem – Noah

The project’s done. This week was spent putting everything together. Fixing bugs and making sure everything works to the best of our ability.

For the final sprint, I worked on implementing player health, the respawn mechanic, and several bugfixes.

Player health was in the build for a while, but issues with colliders kept keeping health from properly updating. Tom and I fixed the problems, and the player health UI now updates to reflect the player health variable. I also worked on implementing the respawn mechanic. After one player dies, the camera will adjust its player following code to only follow the remaining player. When the second player dies, the game will fade to black with a game over message before reloading the level.

I also worked on bugfixes. Most of my involvement with bugfixes was helping the other programmers when issues arose. We worked hard through the week to look over our code.

The bugs I personally fixed were related to the sister’s animation, her shield, and the brother’s slingshot. All of the sister’s animations looped, so when she aimed upwards, she continued to look up over and over. She now only looks up once. I also repositioned her shield to be drawn closer to her body, and to be taller. Now, enemy bullets won’t sneak past her shield before she can pull it up. The brother’s sling shot fired in odd positions depending on the direction you were aiming at. I cleaned up the code so that the slingshot firepoint would stay consistent.

The good of this week was that we were able to push hard into building a vertical slice of the game.

The bad is that we didn’t have the time to polish and bug test as much as we’d like to.

Post Mortem

This was a interesting project to work on. I enjoyed working with this team: everyone had a strong work ethic and our project management kept us on task.

The programming team was able to learn source control quickly, which greatly helped our ability to save and share code.

Unfortunately, we didn’t much time to work on this project. We worked on this game as part of an introductory course, so many of us were learning our development programs and tools as we were going through the weeks. If we had a few more weeks of development, we would have more work time in which we all understood how to solve our tasks.

We also overscoped. Even for a simple sidescroller, we had too many features, which cut into polishing the core mechanics. In the future, we should focus on the minimum viable product before exploring other ideas.


Menus, Powerups, Updates in General

It’s the end of another week of development. One week until the end of the project.

These past two weeks, we’ve been working towards getting all of our features in.

I added in a main menu and audio options for the player.

The art team made some pretty assets for the main menu.

I also set up the game’s audio system this sprint. I’m using Unity’s AudioMixer to determine the difference between background music and sound effects. Audio sources within the engine are marked to either play using “BGM” or “SFX” settings. This way, the player can reduce BGM to a lower volume, and it’ll affect all sounds marked BGM without having to edit them individually. I want the code base to require as little busy work as possible, because bugs can easily happen when you miss something you forgot to keep track of.

I also worked on power-ups. I made an abstract “Powerup” class, which contains something of a blueprint for specific Powerup classes to fill in the blanks for. For example, the Powerup class has a abstract method ApplyPowerup(). Different powerups will do different things, but all powerups will have some sort of effect. So by marking ApplyPowerup() as an abstract method, I am requiring any inheriting class to have an implementation of ApplyPowerup() to be a valid powerup.

We also got new environment from the art team, so I replaced the old sketches with the new assets.

It’s a beach.

I also helped the other programmers with some code updates. The old bullet shooting code was instantiating way too many bullets at once. There could be twenty bullets taking up the same space. There’s supposed to be a bullet fire delay, but the delay wasn’t having any affect. This is because the delay was being called by the bullets themselves, so there wasn’t anything being delayed. I changed it so that the delay was called by the slingshot instead, so a bullet would not be able to be fire so long as the slingshot was in a “in delay” state.

There were also some problems with the old powerup code. There was too much coupling, which meant that the code was too dependent on other classes to function. Updating powerups would mean you would have to update several methods in several classes that you might not realize are related.

Next week’s when it’s all due! Please look forward to it.

Time your shots

John Harvey, Week 10 Journal

Week 10 the hopeful final stretch for my shield & sling code!!!

This week a very brief reflection notifier on the shield. The shield will flash during the frames it is able to reflect. Frame perfect. Adding the notifier actually enabled me to see a bug in my code that made the shield just continuously switch between states. This was resolved immediately, without stress. The little brother’s sling should now shoot only a set amount of bullets in a set amount of time. ex: 3 bullet per second.

So, I again used a IEnumerator to assign the RapidFire state to a limited time, 2 seconds. It switches a bool statement, stateSwitch, so the Sling script knows when to fire bullets faster.


Positive: Easier to code, since I already had this previous knowledge from last week. I spent about 2 hours fixing this and finding possible solutions to bugs that were found. Code was merged properly and works.

Negative: A few bugs popped up that were resolved except one. This one has to do with that fact that I’m having the sling be thee collider with the power up instead of the character..

I am aware this is a problem.

Bullets, UI, and Enemy Triggers

It’s the end of the third week of development.

This week I had a pretty bad cold so unfortunately I was stuck taking care of it. I was still able to get some work done though. I prepared a canvas that’ll display player health, shown below. The red numbers represent each player’s health, and the blue number represents the sister’s shield meter. Later these’ll be replaced with art assets. The HUD doesn’t do anything yet though, as the player health scripts aren’t working. But that’ll be something we fix this coming week.

Other than that, I worked on helping the other programmers with their sprints. The scripts that handle player shooting weren’t working properly. It turned out that the bullets were all in front of the rest of the game, so they weren’t colliding with anything. Each bullet was also an entire sheet of bullet sprites instead of just one, so that had to be fixed too. Bullets weren’t moving either, but that was fixed too. While bullets had a set speed, that speed wasn’t being applied.

We’ll probably have to redo some of the enemy spawn triggers. We’re getting a lot of suppressed errors because triggers will ask enemies to do things, even after they’ve been removed from the game. I’ve suggested that triggers should simply activate groups of enemies, and not tell enemies what to specifically do. We’ll see how that goes this week.

Positives this week were that everyone seems comfortable with source control now. We had some issues last week with what and how to commit, but this week went much more smoothly. Tom is also starting to work on programming too, so that takes some of our load off.

Negatives were that our code base is a bit messy. Bugged code is still being pushed to the master branch of our repository, so that can mess with someone’s progress if they aren’t careful.

Next week will be a lot of bug fixing.

See you later.


Reflection state, Bounce Back

John Harvey, Week 8 Journal


This week my main focus was on the shield and how it can bounce projectiles back towards the enemies. Also, I needed to integrate my code with Noah’s.

So, I again used a IEnumerator to assign the reflection to a limited time, 1 second. It switches a bool statement, so the GameManager knows when to bounce back projectiles.

Positive: It was surprisingly easier to code this week then last. I spent about 3 hours fixing this and finding possible solutions, instead of 8. Code was merged properly and works as of right now.

Negative: As of the time of posting I have not been able to test Projectiles bouncing back, as a meeting is being held tonight to flesh out the final things with enemy code colliding with player code.

Can IEnumerators accept floats…?

Erin’s Update 5/21



(A little humour from the desk of the programming team)

Hey folks! It’s Erin. Things are going will with the programming team. We’re all on the same page with source control now and that’s working well — no longer should we have to spend late nights merging code. Our three enemies move; the pufferfish shoot bullets, the anglerfish bob and are ready to receive attack animations, and the sharks attack at the right heights! Communication is running smoothly, and, thanks to our Discord and our excellent project management team, we’re able to stay on the same page without having to coordinate 8 people’s schedules!

Positive: The enemies are all in place in some form! Everything is progressing.

Negative: No work has been done on the boss; though this was a stretch goal, I think it’s something important to have even in a slice.

Camerawork, Boundaries, and Source Control

It’s the end of the second week of development. The programming team worked on building the main mechanics of the game such as shooting, blocking, and enemy behavior. These base mechanics are integral to gameplay so it’s important to get these roughed out first.

I worked on improving player movement this week. First, I changed how the camera works. In last week’s build, the camera only followed the brother, leaving the sister to a ‘supporting’ role in the game. Now, the camera follows the midpoint between the two siblings, putting them at a more equal level of importance in the game world.

The camera now also has boundaries on its left and right edges, so players can’t wander off screen.

I also created a camera clamping script to keep the camera contained to a box the size of the level. This way, the players can’t guide the camera off the level. As the players progress, this box shrinks from the left, stopping the players from moving too far backwards. Since we don’t have plans for players to backtrack, we’d like to push them to keep moving forward.

Other than my own development, I helped the other programmers learn source control. During the first week, we had the programmers send their scripts for me to arrange. It got confusing which file was the most recent, which files were working; it was a hectic process. So this week we thought it’d be best for all of us to be up to be caught up with Github. Now we don’t have to worry about making backups, and we all have access to the lastest build of the project. Development should go much more smoothly when we can be sure our code is working before sending it out.

One problem we’ll have to face next week is that not all our code matches up. We still have some inconsistencies with how mechanics are coded, so sometimes a feature can’t be added without heavily rewriting someone’s code. So next week we’ll sit down and decide on how all our classes should be connected. If we talk more to each other about how we’re designing our code we’ll be good!

See you next week.


Tengo sueño.