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.

Advertisements

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.

koko_desu_ka
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.

pufferfisk
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.

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.

ghdora.PNG

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.

 

untitled
Tengo sueño.

Movement, Controllers, and Putting Code Together

It’s the end of the first week of development. While the art team was working on laying out the concept for story and character design, the programming team worked on a quick prototype of the game mechanics.

I was in charge of getting a movement system setup, along with controller support for the two players. I had some old code from a previous 2D platformer project so I used that as a base. Since this game will have two players, I had to decide how the camera would function. Since the brother is the slower of the two characters, I had the camera follow him exclusively. The sister’s position in the game has no affect on the camera. I added restraints to the sides of the screen so that the sister can’t wander off where the camera won’t see her.

Controller support was some work. The process behind setting it up isn’t too difficult once you know what you’re doing. But before you do understand the process, it’s a bit obtuse. Unity has a list of input settings to toy with, but the setting names don’t always convey what they actually do. For example, I made a setting that mapped jumping to a button on Player 1’s controller. I edited the setting to “Controller 1”, which I thought would keep that button to Player 1’s controls. However in testing, jumping with that setting caused Player 2 to jump too. Turns out setting “Controller 1” only works for certain situations, and otherwise you have to name the button according the the controller you want to use. Once I figured that out it was easy, but it was annoying getting there.

Lastly I took the code from the other coders and added it to what I had. Unfortunately not all of it worked, so I had to cut down or dummy down some of the features we would have liked to have for our prototype. Next week though we’ll be having a meeting on how to better share our code.

Week 1 had a pretty tight schedule and I didn’t get any sleep tonight, but at least the demo’s finished.

See you next week.

-Noah Nam

untitled
Our prototype, with rough placeholder art. The reused character sprite is from King of Fighters, Noah’s favorite fighting game.