2/6-2/20: Going into Alpha

I’ve had a lot of progress over the past two weeks. Here are my updates:

Task Creation (1.5 hours)

I spent time making tasks for the programming departments this sprint. These tasks came primarily from playtesting feedback, talks with the design department, and the features I know are unimplemented. Many programmers said my method of making tasks with a HELPFUL LINKS section and a NOTES section assisted them in their task (this is blatantly inspired by Austin Yarger’s teaching techniques, I’m sure he won’t mind). These tasks include bug fixes, new features pitched by design, new tools for designers, and improvements to existing systems.

Notes for Playtesting Sessions (1.5 hours)

Over the past two weeks, I attended playtesting sessions with Jordan Ajlouni and George Castle. They played the most recent builds of our game. Because those builds are incomplete, most of our time with our advisors was focused on our approach to design and art. I took notes for both playtesting sessions and wrote down as many points as I could (an example of which is shown above). They gave us valuable insight into where to go next and what to focus on. In addition, they found many bugs (which we can fix during production).

Cheat Code Experiments (1 hour)

I decided to create some cheat codes so our development team can experiment with changing different values at runtime. This can be particularly useful when we want to test out values in the build themselves, rather than in the editor. One of the cheat codes I created was SetComboTime. Calling setcombotime in the console with a float argument sets the combo time (the amount of time between combo hits) to the argument. Making a new cheat command was pretty easy; because of our existing reflection system, commands are automatically integrated when you make the class. This allowed me to confirm that combos were actually working in the build (which was unclear). In the future, I plan to experiment with more cheats code to help our development team.

Pause Menu Integration (1 hour)

This week, our programmers created a good pause menu. However, it only existed in a lab scene and was not integrated into the main game. I took the initiative to add this menu to all the scenes. I reworked the existing UI architecture into a “UI Package” prefab. This package includes the HUD canvas, the pause menu canvas, and the developer’s console. Now, whenever a developer wants to create a new scene, they can just import the ‘UI Package’ prefab and the scene just works.

Cooperative Multiplayer Bug Fixes (4 hours)

Previously the cooperative multiplayer system does not work as intended. Whenever a player connects a keyboard and a gamepad, both players respond to gamepad inputs, while only one responds to keyboard inputs. We want one player to respond to keyboard inputs and another player to respond to gamepad inputs. This was a really hard bug to solve, because we were dealing with Unity’s player handling code, not ours.

After a lot of debugging, I traced it back to a single line in our code. A few weeks ago, when first implementing cooperative multiplayer, there was a bug where the PlayerInput class spawned a lot players into an empty scene. As a result, we decided to handle player spawning manually. This created issues where we weren’t using the PlayerInput API correctly. I traced our issues to a line in our code where we assign each player a controls object. However, this is something the PlayerInput API is supposed to handle, so us handling it caused the player’s controls object to be in a damaged state.

Leads Meetings (4 hours)

As Project Lead, one of my responsibilities is to create the agendas for leads meetings. These are meetings where we talk about our department’s progress, ensure we’re on the same page about important decisions, and discuss the next weeks of development. I spent roughly one hour a week typing up the agenda before the meeting. This allows us to create our quickly discuss all the points we feel are relevant. The leads meetings takes roughly an hour per week. Overall, these meetings are really helpful for us to understand where we are and answer cross-departmental questions and dependencies.

Studio Meetings (5 hours)

As Project Lead, one of my responsibilities is to create half the slides for and host the studio meeting. I create slides on the project’s progress (including our burndown chart), what we’re doing in this sprint, and the MDP devlog process. The slides usually take an hour to 1.5 hours to create. Having these slides allows members to feel like the content of the meetings are structured. The meetings last for about one hour. At each studio meeting, I usually hop into one of the department meetings (this week it was programming, last week it was art) and listen in, actively providing answers and insights.