Graffiti Club

Post Mortem

My capstone project was created via Unreal Engine with a team of seven: Curtis Harbin, Brandon Lee, Austin McGee, Timothy Ruth, Herbert Jerald (HJ) Sado, Nathan Sears, and Ryan Shipwash. We had four months to create our own levels and combine them into a playable game. We had little to no limitations for our creative vision. Our long-term goal was to produce a playable 3D game that could be published for others to play. The following are what went right and what went wrong with this capstone project.

Art By: Herbert Jerald (HJ) Sado

What Went Right

Core Mechanic: The Shield

We were able to come up with a fun and dynamic core mechanic early in the game's planning stage. We originally had about 7 mechanics that we wanted to add a radial menu for the player to use throughout each level of the game. We decided to focus on one and base the game around it. The overall choice was to make a Shield that could transform into a Trampoline upon throwing it into a wall. I had prior experience with a mechanic similar to this, so it was both fun and easy for me to not only implement it but improve upon it each month.

Checkpoint System

I used a similar Checkpoint System from a previous project for Graffiti Club and improved it. I added a text that popped up whenever the player changed their current checkpoint. This helped the players to familiarize themselves with each level. The Checkpoints change to the color blue when the player activates them, green when they've been visited before, and red when they've yet to be visited.

Enemy A.I. & Pathfinding Manager

I wanted the enemies in the game to be able to navigate their way to any point in the game, so I created a Pathfinding System. This system allows them to move around or over walls that would otherwise block them from chasing the player or returning to their patrol area. This Pathfinding System can be applied to other objects in the game, such as NPCs.

Swerve Industries Level

My Swerve Industries level consists of three puzzles that the player completes to collect three Spray Paint Cans. Each puzzle uses the core Shield mechanic. There are instructions throughout each area to let the player know how to complete each puzzle. There's also visual and audio feedback to let the player know that they're progressing throughout each puzzle.

Teamwork & Communication

I got to communicate a lot with my team throughout the 4 months that we had. We had impromptu meetings almost every day. We went over any feedback or ideas we had to share about the game and each other's levels. We were able to get a lot of mechanics and level design done because we were able to share our ideas via text or voice chat at a fast pace.

What Went Wrong

Lack of Documentation

We used Confluence initially to layout the design of the game. After that, any new mechanic that we added to the game came without any further documentation. This meant that the only person on the team who knew how to implement a specific mechanic would be the one that made it. Documenting new mechanics would've saved the team a lot of time asking each other how they work. For example, I added a state machine to the game but never documented how to use it, so I was the only one using it.

Disconnected Levels

Our original idea for level progression was to have all of the levels in the game take place inside the same city area. That way, the player can see future levels out in the distance. This could've made them motivated to complete their current level and move on to the next. It would've also been nice to see each level from the view of the Hub World. We ultimately decided to separate not only the locations of our levels but also the themes of each level.

Narrative over Gameplay

We discussed the narrative of the game before coming up with a core mechanic. We should've created the core mechanic first, and then write the narrative around the core mechanic. Instead, we have a game whose narrative is about graffiti, where the core mechanic is a shield. It's hard to connect these two elements of the game, and it would've been easier had either the narrative or gameplay been changed to fit the other.

Solo Level Playtesting

Whenever we playtested a level, it was mostly to test a new mechanic that we added. Because most of the mechanics that we add are tailored to our assigned level, we'd mostly only playtest our own levels. We should've playtested each other's levels a lot more than we ended up doing. For example, I found a handful of bugs from one of my team member's levels that I could've found way earlier, had I playtested it earlier.

Puzzle Repetition

My level has three puzzles, each focusing on a different part of the core mechanic. One of the puzzles involves carrying an item from a conveyor belt to an assembly bin. This is repeated at least three times with no difference between the three instances. I should've added more interactions to the assembly bins. For example, different types of enemies could spawn each time an assembly bin is filled, to provide more player engagement.

Conclusion

I gained new experience with using Unreal Engine to this scale. I got to improve the mechanics that I've implemented in the past and try out new systems that I've never created before. I completed a lot of my tasks during the first half of the project's development, so it was difficult for me to make new tasks afterward and stay productive. I'm proud of the non-linear design of my level and I'd like to improve some of its puzzles and player interactions post-development.