Pik N Pop
Roles: Project Lead Senior Programmer Designer
I contributed in three distinct roles on Pik N Pop. As Project Lead I was responsible for creating the pipeline, prioritizing development of assets, and setting all deadlines. As the sole Programmer I wrote all of the code in UE4 Blueprint. As a designer I developed the systems that delivered balanced gameplay. I also created tools that enabled our team to iterate quickly.
Project Objective
Pik N Pop was a class project made in 8 weeks by four people. The project objective was to create a proof of concept with only greybox assets.
Outcome
As a team we set a number of stretch goals that pushed us and the product well beyond the original objective. We chose to create an Alpha version, tackle Co-op gameplay balance, and deliver an artistic vision. Pik N Pop went through numerous iterative changes that delivered on all of our team goals within the 8 weeks.
Key Contribution
Although I played various roles, one of my main innovations was the enemy spawn system using structs and arrays. This system played a key role in our ability to test and rapidly iterate the enemy spawn which is the core challenge in the game. By breaking down spawns into Rounds, Rounds into Waves, and Waves into Groups there was a clear and simple way for other designers to make changes. By offloading the spawning to each spawner with a unique ID it alleviated the need for each spawner to have it's own arrays. This made sure that only a single array in the GlobalDataActor needed to receive designer input.
I created a similar system for the various ammo types. The game has four ammo types, each with four different upgrades. I developed a single ammo Struct and then an array of that Struct for each ammo type with an indice for each upgrade. Designers only had to access four arrays instead of 16 actors with distinct data sets to make system wide changes. This enabled quicker testing as upgrades could be tested and changed within minutes and the values visually compared on screen simultaneously.
As a designer I believe that the best way to find balance is through testing and play. Knowing that we had little time to create and test the game, I purposefully created these systems to reduce the time required to iterate while making sure there was enough flexibility for the inevitable, unforeseen changes. It was these systems that enabled us to make large informed decisions about the games design in the short period we had.
To learn more about all of the systems I built, the pipeline, and my decisions as a designer please click below to read the blog: