Courier X and the Worst Stop Ever is a first person puzzle game where the player takes on the role of a random courier delivering a package to a wizard. The player must navigate the wizard's home using a strange table and dioramas of rooms to change the layout of the house. Different rooms hold different puzzles and the player must solve them to find the mailbox and finally deliver the package so they can go home!
Players: Single Player Controller: Mouse and Keyboard
I was on something of double duty on this project. Programming was my main task when working on my own. I worked on every script in the project at some point. I handled functionality on all levels, most chiefly I was working on the functionality that creates the illusion that the rooms each door leads to was changing. But more memorable for me was acting as a producer. This was a bit more than just being elected a project lead, Members of every discipline came to me for tasks on this one and I spent more of my time in class meeting others than I did working. Any time a noticeable shift in the direction of the project came it was through me.
The game evolved into a sort of "Surreal but Silly" feel offering magic and mystery as well as some humorous elements as well. As Evidenced by the cardboard cutout of our antagonist "Greg the Wizard."
Myself (Programming/Production/Design), Joshua Duffy(Art), Melina Espinosa(Art), Matthew Herrick(Art), Johnny Bell(Art), Joshua Whittom(Design), Chris Bokowy(Sound), Alex Riak(Music)
I got to be a real producer on this project. Decisions for all disciplines would go through me. I would spend whole six hour class times Meeting with art then sound then design then professors for help with programming and career advice. After meeting with design to decide what puzzles we wanted in the project I would pass to art what objects we would need to create the piece and to sound what effects would accompany it then get to work on prototyping it myself. I felt like a real lead this time, that meant success and failure of the project was on my shoulders. While so many meetings got to be tiring at times and I tended to be nervous whenever things got behind, I have never felt so proud of my contribution to a group work.
Highlights And Comments
It was a weird day for me when Alex got so excited about the core mechanic of our game and asked "So who is in charge here?" I then looked around the room to see all eyes on me. I didn't really ask to be in charge in any way but I was always first to speak when a question came up about what we should do and the original concept was mine so I guess the team decided for me. I tried my best to be inclusive of other's input though and would hold off making significant decisions about the game's direction until I could pitch it to the group first. While I tried to live up to the position as best I could, I know a few decisions held the game back that I wish I had thought of from the beginning.
We had started the project on a weird idea. Most of our team had decided that Aegis Colony was not the type of game we wanted to be training ourselves to make, the only member who was terribly adamant on continuing it was no longer in our class so we were looking for something to make. I was inspired by a Brackeys tutorial about seamless portal effects and the game Kraven Manor by Demon Wagon Studios. I liked the idea of the room-switching mechanic and wanted to produce a game that uses it in other interesting ways, preferably not a horror title. The piece was initially intended to have much greater use of the room switching mechanic as a necessity for completing puzzles and finding hidden areas. However a few setbacks pulled the project away from what it was originally envisioned as.
The Core mechanic we started with is the Switching table in the middle of the Grand Hall. Moving the dioramas of rooms on the center table changes where the doors of the actual hall lead.
The portal effect managed our little illusion but not without work. This was the chiefest of our setbacks. We had to dial back the scope surrounding a fix that was expected to take about a day or two and instead took two whole weeks. The tutorial for the portal effect really only was intended to work in one specific way and didn't account for needing to turn or change the player's velocity in any way. Ultimately my lack of experience with vectors in unity worked against me and making the offsets and bypassing the standard player controller's direction and movement overrides took much longer than expected. Since we didn't know what limitations the solution would bring we held off on creating many new rooms or puzzles and that set us back much more than it should have.
After two weeks of computer problems and puzzling, even looking at a screenshot of the script meant to be edited whenever my device was having trouble running the game, I finally figured out the changes that needed to happen to make the player face and move properly when going through the portals and we were back on track.
In the end we needed to dial our scope back quite a bit, but it made for a surprisingly comfortable finish for most. We were struggling to even find things for art to do in the last few days and it made for an easier finals week for most of us. The project is about finished now and plays like a five-minute demo. It is a very interesting exploration into a core mechanic and breathing life into a concept that I have been working to create for a while. I a quite proud of it and excited to see how the world responds.