concepting
The only constraint for this project was that it had to be in 3D. I had never worked on a 3D game before this so it had been an interesting challenge.
Our design mashed up two ideas, roguelites and mail sorting.
When we first decided to put them together, I hadn't realized the potential of the pairing. But the more I thought about it, the more it made sense. Mail is already a versatile word, it conjures of images of packages and letters in all shapes and sizes. The framework of random generation almost feels too natural. Not only that, but by creating an office that had different possible mail slot locations, it could induce tension to make players constantly thinking about what could happen next.
When we first decided to put them together, I hadn't realized the potential of the pairing. But the more I thought about it, the more it made sense. Mail is already a versatile word, it conjures of images of packages and letters in all shapes and sizes. The framework of random generation almost feels too natural. Not only that, but by creating an office that had different possible mail slot locations, it could induce tension to make players constantly thinking about what could happen next.
We went a different route in design. The letters and packages would be split into certain specialties that would modify their behavior and value; and the office would be a static location.
The decision allowed us to focus on 3D physics instead of variable room design programming, which could be done in a 2D game anyways.
To add onto the mail aspect, we decided to have purchasable player and office upgrades, to further differentiate each run and allow for even more modularity to the systems.
The decision allowed us to focus on 3D physics instead of variable room design programming, which could be done in a 2D game anyways.
To add onto the mail aspect, we decided to have purchasable player and office upgrades, to further differentiate each run and allow for even more modularity to the systems.
Programming
I programmed the initial version of the money, round, and upgrade systems for our first playtest before they were overhauled for working with manager classes to make larger scale changes easier.
The purchasable items were programmed by me, with polishing and bug fixing help from the lead programmer.
The trampoline had been fun to figure out. I had made one in a 2D game previously, so adding another dimension to a familiar object was important in my understanding of programming in a 3D space. As I had only programmed U.I or external systems for the game prior to this.
Instead of the trampoline giving a singular directional force, it instead multiplied several of the mail's forces on contact with the trampoline. This allowed the trampoline to function in a way that served the player.
Instead of the trampoline giving a singular directional force, it instead multiplied several of the mail's forces on contact with the trampoline. This allowed the trampoline to function in a way that served the player.
The cart and the printer had been more problematic, requiring more discussion and help from the lead programmer. But, after talking through materials and order of operations, I was able to make the purchasable items.
Proctoring
The players had problems with grabbing the letters and packages, outside of bugs. To this, I suggested that we use a ring to establish the player grab range. Our lead programmer quickly made it, even making the ring change when the player jumped. This, alongside a new upgrade that would increase the players grab range, led to us no longer having any issues with players not knowing how far they could reach.
Simple or easy solutions does not equate to it being a bad design decision, and I'm glad we were able to solve one of the biggest problems of our initial playtest as quickly as we did.