Polyverse Game Trailer
Game Description | Project Information | Main Roles |
Polyverse is a 2D procedurally generated endless platformer where players have the unique ability to switch dimensions to traverse as far as they can. | Platform: PC and Keyboard Engine: School's Proprietary Engine, C Scope: 4 months, 4 members | Game and Level Designer Producer Programmer 2D Artist |
GAME DESIGN
Why this genre?
I was deeply interested in how procedurally generated games like Cookie Run and Binding of Isaac are designed, so I pitched the idea for a cute procedurally generated platformer after considering its suitability:
Design wise, we can cater to a wide audience and reference from many successful games. Production wise, it suited our limited scope and had the potential for expansion.
Reference
We chose Cookie Run Ovenbreak as the main reference for Polyverse as it caters to a wide audience, and has a high retention rate with its variety of events and game modes.
Cookie Run Ovenbreak Gameplay Screenshot
Key mechanic: dimension switching
There are platforms created across 2 dimensions in Polyverse. Aside from jumping, players swap dimensions if the next platform is in the other dimension. This mechanic makes Polyverse stand out from other platformers.
To represent each dimension, I chose blue (winter) and orange (summer) for accessibility (e.g. players with colour blindness.)
Polyverse Split Screenshot of Winter and Summer Dimensions
Theme
Compared to Cookie Run Ovenbreak that has a fun food theme that also ties in to its story, Polyverse pales in comparison. The theming in Polyverse holds a great opportunity for improvement; if I could do it again, I would definitely add more environmental storytelling.
LEVEL DESIGN
Procedural generation
As the level designer and procedural generation programmer, procedural generation was my main challenge. I tackled it by breaking it into parts:
Part 1: All platforms jumpable. Randomize platform positions within limitations of player variables, e.g. min/max jump height and acceleration.
Part 2: Add challenge. Randomize obstacles spawned with constraint variables, e.g. maximum obstacles on screen.
Part 3: Dimension switching. Spawn platforms in the other dimension with increasing frequency.
Part 4: Balance overall game difficulty. Tweak existing variables.
To make balancing and debugging easier for my teammates and myself, I used only parameters (no hardcoded values) in the algorithm.
Playtesting
We conducted playtests using different methods like observation, survey, and game data depending on the goal of the playtest.
With the knowledge that a common player frustration with procedurally generated games is the "unfair generation randomness" that can even cause players to drop a game, a recurring focus we had was on how players lost and their following reactions.
Playtest Observation with Corresponding Game Data
PRODUCTION
As the producer, I plan and track the project's scope and tasks, and ensure that the project is in sync with the game vision. I use scrum methodology and hold regular stand-ups which allows me to adjust the project scope based on my team's output and ship on time.
Being the producer meant that there were times where I had to make tough decisions. For example, in our final month of development, we originally planned to spend 2 weeks on polish and 2 weeks to expand on the flight feature (allowing players to traverse into a third dimension, the sky) which we were all very excited for.
However, I noticed that there were a lot of improvements that could be made based on the latest playtest feedback which I felt would bring great value to the game. After a team discussion, we unanimously decided to cut the expansion and spent the last month on polish and marketing - which yielded great results!
Phase Production Plan Document
