What Did I Do For The Project?

I was the producer for Wizards and Warriors. I’m currently a product owner for a separate XR project, and I really wanted the chance to apply what I learned from that project into a game setting. So, after I was voted by the team to be producer, I tried my hardest to make sure that development was organized and that things were moving along inside the project. I did my best through applying a horizontal development structure, agile product management methodologies, an up-to-date Kanban Board, regular discord communication, and helping with debugging.

For a class project, I wanted development to be as horizontal as possible. This means that everyone should have equal say in the finished product. In my mind, everyone on the team is a game designer, regardless of title, so I tried to make sure that no one person (especially myself) was dictating the whole design of the game. I mostly did this through trying to generate discussion, and I especially wanted to hear concerns about the game itself that people were having. This way, once concerns were brought up, we could have discussions as a team that brought to light issues that the game might have. Discussions brought about solutions, and I hope that everyone felt like their voice was heard when it came to the game design of Wizards and Warriors. I think a big part of product management is making sure that the entire team is heard, so I tried using methodologies I picked up from previous projects as much as I could.

I wanted to apply as much Agile Product Management methodologies to the game development process. It’s a tried and tested development structure, so I figured it’d be worth trying to apply to our game, and I think we got good results. So, first, I split our work up into 6 total weekly sprints. I organized retrospective meetings at the end of each week so that the team would be kept up to date with what everyone was working on. During these meetings, I tried to make sure that everyone’s voice was heard, and I made sure everyone spoke up at least once so that we all heard from their perspective. That way, development could be horizontal, and no part of the game got left behind too far. I tried to give everybody as clear and as manageable goals as possible during these sprints so that all of our developers thought that they could complete the tasks given to them. I think these goals were helpful in making sure that the game was moving along at all times and so that development was transparent.

Another tool I used was a kanban board using GitHub. I used this board to help keep development transparent and project goals clear. This was especially helpful early in development when everyone was still trying to figure out what the game exactly was. It’s hard to keep development up-to-date while a game is still taking shape. The kanban board ended up being really helpful to keep things clear. I could see developers pulling it up, seeing what was currently being worked on, the size of the task assigned to them, the sprint milestone, and what needed to be completed exactly. It took some overhead to get it done, but I think it helped keep things clear and communication smoothed out. Towards the end, I think the kanban board was starting to lose its use as a bunch of smaller tasks needed to be completed to get the game done in time. So, instead I re-shifted focus to personal conversations of what needed to happen to make sure the game was done. I tried to make these conversations virtual and as public as possible so people could still know what others were working on.

I handled lots of communication with Discord. Discord was a very nice tool to make sure that things were developing along. I split everything into threads so that things wouldn’t get too drowned out by a constant flow of communication. This way, people could just stick to the threads they were assigned to, but they could still look at other parts of the discord to see how development was going. This kept things transparent and visible. It was also helpful for ensuring that co-op development wasn’t getting overwritten. For example, our two level designers were working at the same level, so they could easily create conflicts. However, they were both able to use discord to communicate when they were working on the level and what they were working on. That way, any merge conflicts could be avoided!

One last thing I did for the team was that I was able to help with some debugging for the project. I think one of the trickiest bits was the animation blueprint graph in our design. Since I’ve had experience with this (not to mention a lot of other parts of Unreal Engine), I was able to take a look at some things and help with debugging. I hope it was appreciated and people were happy to have a second eye on things!

All in all, I’m pretty happy with how development turned out for Wizards and Warriors. Working with the team has been great, and this is absolutely an experience I’d shoot for again. I learned a lot through doing this, and I know I’ll do better next time. Between the kanban board, discord communication, debugging, and the sprint retrospectives, I’d say I was working on the project for about 5 to 6 hours a week. I honestly felt a bit like I wasn’t doing enough sometimes, but team members would communicate to me that the things I was doing were helpful, and I remembered that everyone has a role to play. I’m glad I was able to do my part!

What Was The Most Difficult Part Of The Project?

While I’m largely happy with the way development for Wizards and Warriors went, there were two main parts of the project that I think ended up being the most difficult part of development. Namely, there were some development bottlenecks caused by ambitious implementations that was outside the scope of our project, and there was some over-reliance on some of the developers that stretched them out too thin.

During development, I’d take a look at some people’s code during debugging or if they were just showing it off, and I’d notice that their implementation was super ambitious. I had some concerns, but I didn’t want to get in the way of their education. So, I figured I’d just let them keep at it and see how it goes. This was not smart. This led to some project bottlenecks that I could have completely avoided if I’d just been more clear with them or asked them to simplify. In the future, I’m going to keep in track with development code much more often. Before or after retrospectives I’ll check the code to see that state of things. And then, I’m going to bring up my concerns to the developers. I’m going to be much more clear on why I’m concerned and then hear them out on why they are doing it that way. If it doesn’t seem worth the effort, then I’m just going to have to ask them to pivot their workflow. It’s much more important that code gets done rather than making pretty code that doesn’t work.

I really really didn’t want to overwork anyone during the development of Wizards and Warriors. I tried to make sure that development goals and their timelines were reasonable so that nobody would be overworked. However, we had a few skilled developers who were talented in a couple different directions, and I wanted to use their abilities. This led to me overextending them during the project, and I’m afraid they ended up overworked during some sprints. My apologies to anyone on the team who felt this way. In the future, I absolutely plan on reevaluating everything that’s going on inside the project and keeping an eye on how much a person is working. Another thing I plan on doing is just asking during retrospectives if anyone is feeling overworked by the project. I hope for some honesty so that I can pivot them towards a more healthy workflow. 

Overall, I’m very proud of the team and the result of Wizards and Warriors. I’m really proud of how the project came together, and I believe that everyone’s work was used to the fullest inside of the game. We made a really modular system, and we rarely ran into conflicts during development. This was absolutely critical in making things move along and making sure that our game got completed. Through this experience, I was able to learn so much about project management. I learned development strategies, new communication techniques, and how to apply agile management to game development. It was a really cool experience that I hope I’ll be able to try again.