3/6-3/20: The Core Game
I’ve had a lot of progress over the past two weeks. Here are my updates:
Playtest & Notes (4 hours)
Over the past two weeks, I attended playtesting sessions with Matt Rader(Serenity Forge), Amber Renton(Microsoft), and Austin Yarger(Arbor Interactive). We have increased the frequency of our playtests because the game is in a state where we can get a lot of feedback. I took notes for both playtesting sessions and wrote down as many points as I could (an example of which is shown above). They were able to pinpoint where the combat was working and where it wasn’t. In addition, I hosted my own playtesting session with Rachel Liu (Rice Games) to get more specific first impression feedback.
Fixing Enemies (5 hours)
During the playtest with Amber Renton (Microsoft), the enemies were experiencing incredibly strange bugs. They got stuck on geometry, rarely attacked the player, and overlapped with the player significantly. This was because the enemy programming was not managed effectively. The main problems with the enemies were:
The enemies were initially architected with the intent to have reusable components for all the different states. However, these states were not well planned out and well communicated. I wasn’t able to pick up on this because I was busy focusing on other parts of the game.
The enemies each had a “Brain” component that controls the overall logic. The brains were often 600+ lines and were monolithic classes. The logic and subclasses had too much spaghetti code to debug. As a result, when enemies broke, they were impossible to debug.
The enemies went through 4 refactors in 5 weeks. The intent of various parts of the code was way too complicated to reason through.
As a result, I got together with Isaac Huffman to completely rewrite the enemy AI. We greatly simplified the architecture of the enemies into a simple, 200 line enemy controller. It had no modularity but was much simpler and easier to understand. I will address this with the programming department, but for now we need to move forward with the rest of the enemies.
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 take 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 (4 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 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.
Merging Pull Requests (2 hours)
I spent a significant amount of time this week merging pull requests and solving merge conflicts. This week, 73 pull requests were merged in, about 70% (about 50) were merged in by me. There were 4 merge conflicts, 3 of which were simple. However, much of my time (about 45 minutes) was spent on a merge conflict with our audio director, whose changes were so sweeping as to cause several merge conflicts. No merge strategy worked, so I had to add the audio director to redo his changes on a new branch.
Breakdown
Playtest & Notes (4 hours)
Fixing Enemies (5 hours)
Lead Meetings (4 hours)
Studio Meetings (4 hours)
Merging Pull Requests (2 hours)
Total (19 hours)