For Beyond, our team focused on keeping our project simple and straight forward. Our professor would say “You’re making mashed potatoes, not steak. So make the best damn mashed potatoes you can.”  The team focused on making the simple mechanics of a top-down shooter as fun and as polished as possible.

Working on Beyond taught me so much about the challenges and tribulations a game designer and creative director go through when working on a larger interdisciplinary project. I've learned a lot about what it takes to be both a teammate and a creative lead. I did not take hold of the project as much as I wanted to, and the team had some hiccups as a result. In the future, I want to strive to keep the team's vision strong and work to keep everyone on the same page and passionate about the team they're working with and the project they're working on.
As tough as developing Beyond was, much of the development process went well: 

• The ‘Teams’ Game: When planning what game we wanted to make, we collectively got together and spent a few hours brainstorming what we wanted to make. This meant that everyone on the team had a part of the game that they could be passionate about and claim as their own.

Hoverdrive was an ambitious attempt to get a team of 17 everything they needed so that everyone had their desired portfolio piece. While that worked well for some, it meant the game as a whole didn't have the core vision it really needed to succeed. Still, I learned a lot from this project!

• Unreal Engine: Choosing Unreal as our base engine had its ups and downs, it was a great choice for our art team. Unreal's systems allowed our artists to push the game's visuals to a nearly professional level. The engine also gave us a good launching platform for networking, allowing even our designers (and myself) to achieve simple network functionality on our gameplay programming.

• Multiplayer and Blueprints: One element the entire team wanted to try was multiplayer. While Unreal was a great launching point to achieve that goal, our networking and programming team seemed to really struggle throughout the semester. We had focused on using Unreals Blueprint system, and that caused the programmers to really struggle to visualize or find the motivation to get work done.  Slow communication meant we didnt realize this until the end of the project.

• Mid-Season Refocus: About 2/3 of the way through the project, the team was really struggling with motivation. We had a big meeting during class and spent the time really fleshing out what we needed to get our game over the finish line. We settled some of the pressure points that had been left unanswered for too long and planned out all the remaining features. I think this meeting really revitalized the team's motivation, and gave the team the checklist they could focus on completing by the end of the semester.

Whistle Junction was a tough project for me, but it did have its highlights:

• Asking for help: The best part of the project was the amount of support I got. Third-Party tools allowed me to pursue the design I wanted, and fellow students, Teachers Assistants, and Professors all helped me make it a reality.

• Starting Large: Whistle Junction started with a very large design concept. There was so much I wanted to do with this game. This large starting scoped allowed me to figure out what was and wasn't feasible, and I was able to scope the game into something more achievable for one designer.

The complexity and small team size (of 1) meant that not everything was going to be smooth sailing:

• Complex Coding: During development, I struggled a lot to get the underlying core of the game just function. I had a lot of difficulties getting the game to behave the way I wanted it, which left me very demotivated throughout.

• Audio Feedback: Due to the last two issues, there are a lot of missing audio cues. Things such as switch tracks, running into cars, adn applying the brake are all missing important audio feedback that would have enhanced the experience.

As my first true video game, here's what went well:

• Playtest-guided Iteration: Playtesting constantly during the development of Lasershell allowed me to guide the games flow into something enjoyable yet still challenging.

• Stacking Elements: By introducing puzzle elements one room at a time, I was able to teach players the elements of the game without directly telling them, making for a smoother experience.

• Audio Designer: A sound design friend volunteered to make music and sound effects for Lasershell. Their work pushed the simplistic game art to the next level, grounding the game in its abstract art style.

Being one of my first big game projects, I learned a lot about what goes into making a game. I learned how to plan and pitch the project to others, as well as how to make prototypes for playtesting and how to perform those playtests. This project gave me the skills I need to move forward onto bigger and better projects, both solo and team.

One of the biggest challenges that hit us when developing SKYRÒDIAMA was having to deal with the Covid-19 pandemic. That forced all of us to only ever meet online, basically destroying the in-person collaboration that makes DigiPen special as a college. Still, the team did a good job of throwing together a small and fun driving project.

• Open World Design: I was able to explore a true open world for the first time here, allowing me to create 3 or 4 areas that are both interconnected but unique in visual and gameplay feel.

• Pre-Production Planning: As a team, we really hashed out and planned what game we wanted to make long before opening the game engine. This allowed the team to have a unified vision, even when no one could see each other in person.

• No Art Team: No art team meant the final result of the game was a bit cruder than we might have liked, however it provided me the opportunity to learn a lot of Unity's art tools, as well as how to source those art assets.

For our lack of experience during development, Stealther still had some highlight moments:

• Asymmetric experience: Stealthers 'cat and mouse' design not only allowed the team's system designer to create a ton of interesting abilities but also created great moments of play that had players laughing at its absurdity, 

• Encouraging Screen 'Cheating:' During playtesting, players often had trouble finding each other, making the game more difficult for the hunter. By changing the color of the level, players had an easier time finding their opponent, increasing the tension and excitement of the game. 

But we still had some good lessons to learn from this project:

• Unity Networking: For a team of three inexperienced designers, making a networked Unity game was a bit of a pipe dream. After three weeks and countless network bugs, the team switched directions, turning Stealther into a split-screen experience. 

     Being my first 'official' team project, Stealther taught me a lot about the trials and tribulations of working with other designers. I learned how to respond to someone with different ideas and opinions, and how to work together to make the best out of everyone's concepts mashed together. I also learned a lot about the difficulties of building a game in a professional engine such as Unity. Though as a team we were not complete novices, much of Unity's powerful tools were foreign to us, making implementation difficult. However, we used this as a learning experience and were much stronger developers by the end of the project.