Project Management

Project management is the pinnacle to a project's success. I seek for opportunities to be involved in project management, to apply what I learn from each project and guide my teams to make a more successful game.

Summary

I started my position as the Technical Producer at Spartasoft Studio in May 2023. Our leadership team consisted of 8 discipline directors, myself, and the content producer. In my position, I suggested and led the leadership team to meet over the summer. Together we created design concepts and prototyped three of our favorites over 6 weeks. Our favorite prototype, an online hide-and-seek game was decided to be the game the studio would develop in the fall. After choosing the design concept, we identified and and designed a plan to overcome our largest challenges.

Over the course of the semester, I planned weekly meeting dates & times, I helped organize events, I gave presentations, and I organized a spreadsheet to manage the ordering and supply of merchandise. I built and adjusted project milestones, I constantly communicated with directors and studio members to meet our goals, I recorded our game trailer, I directed our QA team resulting in four game prototypes, and I met with faculty for organization advice on numerous occasions.

I was able to successfully manage our merchandise orders by using a spreadsheet and google forms. I reformatted the orders into the spreadsheet which would generate total & individual costs, generate total order quantity and sizes, track payment and delivery status, and auto generate order confirmation messages.

The most daunting challenge for this project is networking. Networking in games doubles or triples the amount of dev work that programmers and designers have to do. After discussing with graduates who worked on a networked game, we were hesitant to accept the game into development. But Spartasoft Studio has never shies away from a challenge, and everyone in leadership was ready to take it on.

To kickoff development, myself and my content producer built project milestones to reference when the directors create agile sprint goals. We held weekly meetings with all 84 members as well as leadership meetings every week to assess our sprint progress. I would facilitate these meetings, take notes, and keep us on schedule. We would address concerns from the directors, and plan out our future goals and milestones.

During the studio meetings, myself and my content producer would hold a quick presentation to keep members up to date on what is happening within studio. After the presentation, everyone would break-out into our group meetings and I would direct our QA team. I accomplished this by breaking them out into teams, helping them to create design concepts with my feedback, and offering assistance for them to meet their prototype goals. I would simultaneously act as a studio coordinator, to try and clear up as much confusion between directors as possible. After our meetings, the directors would have a quick team huddle to discuss any pressing changes or questions.

New Structure

We had several setbacks in development which required major adaptations of our milestones/sprints. As we closed in on our deadline we reassessed our progress. A lot of our content was able to make it into the project but our gameplay was not implemented. The majority of leadership wanted to continue development on the project- to give us the chance to push towards our vision. We made sure to poll our members- it's crucial to us that our members are making assets for a project they enjoy. The results showed astounding support for continuing Market Mayhem, with over half of our members interested in continuing to work on it, and a third with no opinion. So it was clear what we should do.

As Market is nearly done in term of art and design, we decided it would be best to run two projects side-by-side this next semester. My content producer and I setup a meeting with a faculty member who had run an indie studio for years. Together, we designed a brand new structure for Spartasoft Studio. We would have two project running at once, with our team members flexible to work on either project as needed. Additionally, we are introducing team leads to hold responsibility for their own area of development and report to team directors. Finally, we have onboarded three project managers to act as communicators and milestone enforcers, to maintain cohesion of the studio.

As Market is nearly done in term of art and design, we decided it would be best to run two projects side-by-side this next semester. My content producer and I setup a meeting with a faculty member who had run an indie studio for years. Together, we designed a brand new structure for Spartasoft Studio. We would have two project running at once, with our team members flexible to work on either project as needed. Additionally, we are introducing team leads to hold responsibility for their own area of development and report to team directors. Finally, we have onboarded three project managers to act as communicators and milestone enforcers, to maintain cohesion of the studio.

We love the idea of our QA Prototypes, and are introducing Skunkworks projects. Our Skunkworks projects will consist of design concepts, prototypes, libraries and code samples and more to be used in future projects. All of our Skunkworks projects will be build by members during sprints in which they have little to no work to do.

We designed this new structure with three goals in mind: communication/cohesion, to keep members busy, and to finalize the game that we love.

This semester, Spartasoft Studio was given a lot of room to grow. We took on an incredible challenge and made extensive adjustments to our structure afterward. We underwent enormous changes in leadership and have acclimated well. I am very proud to see how Spartasoft Studio is steadily growing, and excited to see what the future holds.

Outcomes

Unfortunately, we did not meet our project goals that we had planned for the end of the semester. This can be attributed to many things but the most important ones were:

- Networking took longer than expected. We underestimated and planned a 2-week development schedule based on how long it took to make our networked prototype. During development, we switched networking platforms and had several issues with the new one which came with huge setbacks, leading networking to take up about 2 months to develop.

- Assets stuck in test scenes. After assets were functional in their respective test scenes, they were not adapted into our main gameplay loop. This led to last-minute attempts to implement features before building, which went poorly.

- Irregular build schedule. Because we were not making test builds regularly, it limited our play testing ability, leading to poor QA. 

- Schedule. We did not initially account for the 3 weeks we would have to cancel our general meetings due to holidays/MSU days off. We were forced to adapt our milestone schedules to accommodate, pushing our goals weeks later into our project timeline.

I'm really glad that our programmers were given the chance to learn networking. Networking is very underrepresented in our education, and giving our programmers this experience will aid them greatly in future endeavors.

One of the major lessons I learned is to devote more effort into our milestone creation. We did not have a clear expectation of where we wanted development to be throughout the project, making it unclear where we wanted to be next. Without these milestones, it made adaptations sprints more difficult.

I've made personal developments this semester that I am forever grateful that Spartasoft Studio has given me the opportunity to unveil. I've noticed that I happen to lose focus when numerous things come my way, and that jotting notes on even the smallest things have saved me. I had an outstanding workload and it took its toll on me nearing the end of the semester. I persevered and performed strongly through it all, but I noticed how I wasn't able to give my best attention to Spartasoft Studio at times. To combat this, I will manage my workload this upcoming semester,  vigilantly maintaining a personal schedule, and experimenting with consistent note taking and journaling.

Summary

The MSU Game Development Minor is a 2-year program at Michigan State University, allowing a cohort of 40 students the opportunity to take four consecutive game development courses together over four semesters. The Minor is well renowned for game development education, pushing Michigan State to be a top competitor for game development education. For more information, click here. At the time of writing, I am in the second class of four in the minor: Rapid Game Prototyping.

In the fall of 2023, I was a leader on two 5-week game projects with 5 and 8 team members respectively. I was accepted into the minor on account of my programming skills, and use that as my primary skill for the projects I am a part of. To compliment my producer role at Spartasoft Studio, I immediately wanted to take any opportunity at production.

Production on these projects requires a lot of project management and organization, as well as the responsibility for our success. I facilitate discussions, plan team meetings, and oversee the entire development of the project as well as creation of our milestone documents and presentations for the professor. The most important responsibility I have as producer is delegation, to make sure everyone on the team has a comfortable amount to work on that best works toward the overall development of the project. 

Outcomes:

I have gained substantial project experience so far. My most notable areas of improvement are team organization, facilitating discussions, prioritization and project scope, and most importantly- delegation. 

Delegation is the skill I am trying to work on the most. It's challenging for me to pick work for individuals on account of not wanting to overwork them, and also wanting interesting tasks for myself. I've learned to understand that I should delegate the most important work to my team, and that I can be there as a support dev to fill in the gaps. I've also seen that a lot of people are different, and it's crucial to understand how each individual works best so I can support them to the best of my ability.

Both of my projects this semester did not live up to the level of playability I wished to get out of them. For the future I will increase the playability of my projects by prioritizing tasks related to play testing and QA rather than more content or juice. 

Another major outcome I noticed is that my teams were the most productive while we were all working at the same time. For my next project, I want to do a test-run in which my team will all work in-person regularly, to see if this increases productivity.

Project Summary

In November 2023 I formed a team and oversaw development of a VR game in 48 hours. The team consisted of myself doing programming and project management, two more programmers, a beginner programmer/designer, three artists, and one sound/designer. Myself and one of our programmers had the goal to learn how VR games were made in unity, with our other programmer being a mentor for us as they had over a year of VR dev experience. As the producer/project manager, I was the head of the project and made the calls, organized the team, and made sure our project stayed in scope. 

I kicked off our project by starting a brainstorming session to come up with an idea to fit the theme Pandora's box. We landed on a concept called Pandora's Boxing in which the player would fight off waves of enemies in VR. Immediately after deciding on this, I developed a task list. I decided to go with a standard green-yellow-red light system which I wrote out on a whiteboard. Because of the size of our team and length of our project, I deemed it a waste of precious time to setup an online task list when we were already so tight-knit. 

Later in the project's development, I ran into time troubles and saw that we could not implement everything we had hoped for. With agreement from the team, I decided to cut out other weapons from development to focus on our overall game loop and playability.

Outcomes:

This project ran into huge technical issues that I could have handled better. In the moment, we wanted to work in person together because it would be more efficient- so we spent a lot of time trying to fix our machines and making the lab machines work. But, we were unable to fix the issue and lost half of our precious dev time. With time being our largest time constraint for this project, we should have migrated to work on our desktops sooner to reduce the time lost to troubleshooting. I've learned for the future to look at setbacks like this differently, to lean into solutions that best benefit the team and our largest constraints on the project. 

Secondly, we had too many artists. I was happy to have all three of them on the team, but there wasn't enough for each of them to work on that would get used in the project. Since we were so new to VR development, another programmer would have been really nice over an artist. In the future, I will cater my teams to meet the demands of the project better.

Projects never go exactly to plan, and this project was no exception. A few hours into the project, myself and the two other programmers all had completely different critical technical issues with our laptops. We agreed it would be best for us to work in the same space and prioritized troubleshooting our machines or getting the MSU lab computers to work for us. Unfortunately, we could not find solutions, and had to resort to working at home on our desktops. This was a major setback that I approached with bad decisions and it cost us over 24 hours of development time, leaving us less than half of the game jam period left to program the entire game.

Once we all got to our working machines, we had 24 hours left in the game jam and this meant we had to prioritize what we dedicated our time to work on. As a result of the setback, we still had very limited knowledge on how to use Unity's OpenXR Toolkit, so this became the top priority. We generally understood the player from the OpenXR package, and added it into our game. Next was to tackle the core gameplay - combat. 

In order to make this work, we picked our two highest prioritized weapons, the gloves and the sword. For the enemies we would need to define a simple behavior so they could move and attack, a spawning system, and a health system. I imported my health system for this project, and with a few minor tweaks it was ready to go. I delegated the enemy behavior to our designer/programmer who was looking to learning how to program. I introduced them to the Unity NavMesh system and helped them learn by creating a conceptual model on a whiteboard and helping them with bugs along the way. 

Working on the programming for the weapons was a great opportunity to learn how the OpenXR inputs and interactions work. In a few hours we made it so that holding down the trigger on each hand would make boxing gloves appear, each able to damage enemies if they are moving fast enough. Our next task was to playtest and confirm that combat is working, and to implement the next weapon into the game- the sword.

It turned out that enemy behavior did not work well coming out of the test scene, and our gloves had a few issues with dealing damage and defeating enemies. I delegated the playtests and bug fixes to one of our programmers, while I worked on the sword. After both were solved, we had dwindled down to the final few hours left in the jam, we had to choose what we could include.

We wanted the game to be as playable as possible, and decided what we could do to improve our game's playability in such a short amount of time. We revamped our enemy spawning to include a wave system, tweaked the enemy behavior to fly at the player better, added an opening sequence when starting the game, and cleaned up some minor visual bugs. Overall the game turned out well, and was an exceptional first experience for VR development.