Thanh, Ana, Houston, Zoe, and Asher
ISPS (InterStellar Postal Service) is designed to show the many elements of a functional package delivery business. We hope players learn how speed, accuracy, and money impact the flow of packages through sorting centers and delivery systems before those packages arrive at a receiver’s door.
The game is designed to lead players through a short narrative, two mini games, and a longer development and discovery process that provides a “levels” structure. The narrative introduces our main character, Bebop, an alien who is starting her own postal business, and Cinder, her mentor. Cinder helps the player with tutorials and information throughout play. The first mini game involves sorting “labeled” packages into bins. Each properly sorted package then becomes part of the second mini game, where the player must shoot their sorted packages to receivers from a ship, avoiding obstacles. As players sort and deliver, they earn money, which can be spent on upgrades for each mini game or on research. As players research, they can discover new planets, with more challenging package quotas to meet – expanding their business.
Players’ eventual expansion and success therefore depends on the speed and accuracy of their sorting and delivery, which makes them more money, which allows them in turn to increase their speed and accuracy. This can lead players to an “upward spiral of success” as they have more money to work with and can reduce the difficulty of their mini game experience, just like how real-world package delivery giants like Amazon and UPS increasingly rely on high-tech, expensive systems to manage their enormous shipping networks.
We hope players experience challenge from increasing level difficulty and complexity, discovery as players unlock more packages and areas, sensation from graphical change, mouse/keyboard use, and cute characters, and fantasy from the interplanetary relationships players can build + the story.
Final Game Map:
History of Versions:
Initial Concept:
We first ran a little brainstorming session where everyone took 2 minutes to write down as many interesting systems as they could on post-its. We arranged these by categories on the board and then voted with our whiteboard markers.
From farming to “trash experiences” (which contained both “landfills” and “Hinge”), we settled on package delivery as an area of interest – and also outer space.
We were curious about how the real system of package delivery worked, and excited about creating a cute space version of this/adding a fantastical element.
ISPS is born!
Version 1: Ideas and a Paper Prototype
We immediately became pretty bold about scope. We determined that the core processes of a delivery system included sorting, transportation, and delivery of packages. We wanted the game to be cute, challenging, and fantastical, with fun, simple mechanics and a narrative that built on itself over time (as the system expanded).
Initial simple system mapping, character ideating, mechanic ideating.
Playtest 1 (11/6): Male Stanford student (in class)
For our first playtest, we tested a very tiny paper version of a package sorting game. We wrote symbols on cards and handed them to the player one at a time, who then had to distribute them to the person holding up the appropriate symbol. We introduced a challenge by offering a quota for each “planet” – a particular number of cards needed to be delivered to each person – and a time limit.
Our card “packages”
Our player was more than ready for the challenge! We realized he sorted SUPER fast and immediately we needed to up the quotas/difficulty.
First time: 30 seconds. Only two “descriptors” right now (symbols on cards). Demand: 5 for square, 3 for triangle. He was faster than we thought and sorted in 15 seconds.
We offered him upgrades: sort better (get 2 packages at once), new routes (more symbols), or easier routes (can deliver two packages at once).
He selected “new routes” and so we introduced a new symbol/descriptor (stars)
Second time: 15 seconds (COMPLETED)
3 descriptors: 5 squares, 5 triangles, 3 stars
Our player accidentally gave too many “packages” to the star planet and we introduced a potential punishment for that outcome.
Again, we offered him upgrades: Sort better (See 2 at once), new routes, easier routes. He again selected “new routes” and so we added a fourth symbol (circles).
Third time: 15 seconds (NOT COMPLETED)
4 descriptors: 3 triangles, 3 stars, 4 circles, 5 squares
Did not complete: had 1 square left
Our player’s thoughts:
He was dissatisfied by the last round, as he felt there were not enough packages handed to him in time and it was impossible to win. The upgrades (receive 2, send 2) that were not new routes did not seem to him like an upgrade at all, as most of the difficulty came from seeing, recognizing, and then sorting the symbol on the package.
One solution he proposed was receiving 2 of the same symbol package as a sorting upgrade, because then your brain only has to make one “move” but receives twice as much benefit. He also wanted us to make the goal of not sending extra packages more clear, like reducing wages because you did poorly.
We asked him: how would you feel about automating portions of this but increasing complexity in other tasks?
He said this would be a satisfactory way to move forward, and that he wouldn’t be tired of continuously sorting. He said he would be more interested in route automation alone.
He also suggested having a lot of manipulation, seeing consequences, and adding room to see significant results because of better strategy.
From this playtest, we decided to work on…
- Ensuring each upgrade actually improved the speed or score of players (ex. giving two of the same symbol when the player upgrades to receive two packages at once)
- Having ways to automate parts of each minigame (sorting, transporting, distributing), but always having the option for manual input
- Ensuring each aspect of the system is interconnected so that mistakes in one area affect other areas
- Making win goals clear and punishing the player if they go over or under their goal
- Making upgrades more appealing by adding sensational aspects such as different graphics per upgrade and celebratory noises that play when upgrades are purchased.
Version 2: Envisioning Digital Options
We decided to create 3 mini games that would correspond to the 3 main aspects of sorting, transporting, and delivering.
We drew on several games to come up with these mini games and the overall concept: we thought about Papa’s Pizzeria, a sorting game from Super Mario 64 DS called “Sort or ‘Splode,” Pony Express, Jetpack Joyride, and Crazy Driver.
Initial drawings: sorting out contract ideas, character drawings, and potential upgrades
Playtest 2:
Female Stanford GSE Student, in class
We had our second playtester play two versions of currently existing mini-games in sequence, and described how they would fit into the overall narrative.
First, we had her play “Sort or ‘Splode” as our sorting game:
We noticed she tried to use the keyboard first, so perhaps the keys were more intuitive as a mechanism than the mouse. She also didn’t like the slowness of click and drag as a mechanism for sorting.
Next, we had her play “Jetpack Joyride” as our transport game:
Again, she tried to use the keys to start – we had to explain that the game used the spacebar. She said she had played a similar game before: “It’s probably like ‘Flappy Bird’.”
Finally, we had her play “Crazy Driver” as our delivery game:
She said it was hard to see what the icons are besides the car, which made the game challenging.
We had her draw her own initial map of the postal system, but she got stuck quickly.
She asked: “Why am I moving across space? It’s like game after game after game in one game.” She seemed overwhelmed by multiple mini games. She said she understood the sorting packages, but felt the transportation and delivery were the same, and didn’t understand how they fit into the system.
We asked her: If you had the option out of three processes to upgrade, which would you say would be most helpful?
She offered that for sorting, we could make it so the player had a helper or machine to speed things up. She said that right now, the games felt like they were at a fun and playable level, so upgrades didn’t feel needed to make them easier.
From this playtest, we decided to…
- Cut to two mini games instead of three (combining transport and delivery) to reduce overwhelm and because the final two games were quite similar
- Play around with other options besides click-and-drag for sorting
- Focus on creating clear icons for our delivery minigame
Playtest 3: Male Stanford Student, in class
This playtester played the same mini games as the prior test, but only the first two, as we’d decided to cut the third.
In terms of “choosing an initial contract”, which we thought we would implement at this point, this player wanted more money per package, low initial cash. He played the bomb sorting and jetpack joyride games and was quite successful in each. He was interested in knowing how many sorted packages continued into the transport stage once we incorporated both mini games into our overall narrative.
He said “I’m going on a full on money build” as he selected his contract and upgrades. He also liked the bomb sorting game mechanism with the mouse, as he said the trackpad makes it “ragey” in a good way. He said he would like some hub to come back to, in order to see the big picture of the system and how money was helpful. “I like that idea a lot. It would give me a purpose.”
We asked him… to summarize the whole system, and he said
“I make money, I upgrade my system, I make more money, and I explore new routes to make more money and get more efficient.”
From this playtest, we worked on…
- Keeping the best parts of the mouse-controlled sorting system and hopefully removing the not as fun parts, inspired by the Club Penguin bags of beans game
- Building a hub/summary screen to visualize the big picture
Version 3: Beginning to Create the Digital Game
We started building initial sprites and planning the game’s theme.
Main character sprite (eventually named Bebop)
We decided to build four themed planets (cowboy, water, cat, and garden themed) and have corresponding obstacles for the delivery mini game and packages for the sorting game.
Obstacle sprites
Package sprites
We started to build an initial “hub” and some playable versions of the mini games with some stand-in sprites, but were still in progress.
Playtest 4: Male Stanford GSB Student, in class
At this point we were testing out a new system with “bean counters” and a galaxy shooter.
We also had a new narrative featuring our little alien quitting at Papa’s Pizzeria to start the delivery business (at this stage the alien was named Kirby).
This playtester asked questions about mouse vs keyboard input for both games. He felt the mouse was more natural. He suggested we make it more clear that the minigame is part of a system, not the WHOLE system.
We asked him…what upgrades would you want to make the minigame easier?
He said difficulty is not an issue, but there is no threshold. He suggested that there be a clear goal such as a number of bags/packages dropped.
We also tested a galaxy shooter mini game for delivering packages.
He asked: what is the objective here? He then completed the goal. He said the keyboard is more fun and satisfying, but suggested making the game horizontal for our purposes.
He said it was fun to shoot asteroids, but questioned the purpose relating to the system.
He was also confused on the pizza aspect of Baba’s Bizzeria/our narrative.
From this playtest, we decided to…
- Cut the pizzeria narrative
- Implement package quotas (goal)
- Keep the meteor aspect as it added fun, and try to integrate it with the theme
- Try to closely connect the mini games to the overall system.
We then kept building out the mini games and aimed to have a playable version by our next class.
Version 4: Playable Mini Games
Playtest 5: Out-of-Class Playtesters (Stanford students, 21F and 22M)
As we built out the mini games, we had several people test them out, and received the following feedback:
Sorting game:
- Confused on stack mechanic
- Suggested making movement keys A-D and spacebar to put in bin (instead of mouse)
- Requested tutorial to feel less lost
- Requested summary screen to see what had been done successfully
Galaxy shooter:
- Could the movement be WASD or arrow keys so they can choose?
- When you stop pressing the keys to move, movement should stop instead of keep going
- The game should end when the last package leaves the screen/collides instead of pressing spacebar when it reaches 0, because it ends preemptively right now.
We kept building sprites, including a mentor for our main character and a ship:
Our mentor (Cinder)
Our ship
We also updated our narrative to feature the main character, Bebop, living on the cowboy-themed planet.
Playtest 6: Amy, Sam, and Christina
Christina read over our (long) narrative and laughed a little: “dialogue is funny.” She saw our hub/start screen and was confused as the “start button doesn’t start.” She requested a tutorial.
Between the two games, she jumped to switch mechanisms between the mouse and arrow keys (“Aaah!”). After playing both, she told us some things just weren’t intuitive, which she hoped we would improve with more “UX stuff.”
From this playtest, we decided to…
- Work on the tutorial
- Work on the mechanics for the switch between games
Sam played again with the updated mini games:
“Neewywwwwww” – ship noise from Sam
He wanted the upgrades to work, as he played for a while! He was excited to unlock a new planet. He immediately played the new planet even though he was nowhere NEAR having the amount of money he needed for fuel or the ability to meet the quota (game balance issue).
Finally, Amy played, and implemented some of the new updates:
She increased her hand limit in the sorting game, which ended up just feeling confusing and not helpful to her. She commented that the bottom package should unload first. She wanted more context on why she was playing the mini games, and felt that adding the narrative would make the whole thing more interesting and cohesive. She also wanted a short description of how the system is influenced by research, etc – an understanding of what happens when you update.
She also commented that the primary thing she was keeping track of was what money she had or didn’t, and not really any of the other things.
From this test, we decided to…
- Try to fix the hand limit mechanics/the package unloading
- Add the narrative into the game
- Add more description of the system into the tutorial
We added “receiver” sprites to make the delivery game clearer/to send packages to:
Receivers match themes for different planets
Made those receivers change when a package was delivered to them:
And fixed up the bins for the sorting game with closed and unclosed versions:
Trash on the far left – cowboy bin (far right) is closed version
We wanted the sorting bins to be different from the packages (originally they were the same), and the “closed” sprite to make more sense (when the player mis-sorts a package, the bin closes temporarily).
Version 5: Final Version
In the final iteration of the game, we ended up creating a slice of our overall game goal, in order to get more mechanisms working. We focused on the first planet/first section, so that there was a playable loop with all updates functional and the first version of reputation in place. The final game map – listed at the top of this post – outlines all the elements of our game at this point. We added the tutorial system and got rid of the timer in the tutorial, forcing the player to at least get 5 packages, which would allow them to be able to purchase at least one upgrade at that time.
We unfortunately did not have time to implement the queue mechanic for the sorting game, or descriptions of each upgrade, but tried our best to add as much UI and QOL stuff as possible. We also now have a feedback mechanism on if the player completed the quota or not, assigned reputation so that there is a loop of customer satisfaction feedback, and worked to balance the quotas of the planets so that they are achievable.
For the UI improvements, we eventually moved the “meteors” from the delivery game to just be rocks, as they made more sense to avoid than the themed “meteors” from previously. The ship in the delivery game now also flashes red when it takes damage, making it clearer when the player has struck an obstacle.
While there are more elements we could still polish, we are excited to present ISPS, and hope it has achieved its goals of:
- Representing sorting, delivery, time, money, fuel, reputation, and upgraded equipment as aspects of a postal delivery system’s function
- Including sensation, challenge, fantasy, and a little discovery
- Leading to high job satisfaction and a sense of accomplishment for our little alien Bebop!
Bonus playtest:
After finishing our game, Ana’s siblings got to test it out, and they provided the following commentary:
- (Upon reviewing the updates): “AAADDD LASERS!!!!”
- *incoherent screaming* “WE DID THE QUOTA! TEN BUCKS. What should we get?? What should we get?? LESS GARBAGE” (fighting over which upgrades)
- Voice acting of the characters
- “What happens if you run out of reputation?” (curious question)
- “this art is amazing”
- They all screamed when research was successful
playtest with siblings (video)
We hope they enjoyed ISPS as much as we enjoyed making it.
