Orange Goose — Game Site

Team

Team Journal

Milestone 5 — Beta

During this milestone, our team focused on refining the game into a more complete Beta build by expanding content and improving core systems. A major achievement was the design and implementation of the second level, which builds on previously introduced mechanics while increasing complexity and encouraging stronger coordination between the Maker and the Mover. We aimed to ensure that the difficulty scaled naturally, giving players a sense of progression without overwhelming them.

Level design iteration for the second level in the beta build

We also introduced an interval-based reward system to improve player engagement. Instead of only rewarding players at the end of a level, this system provides feedback at key moments throughout gameplay, helping maintain motivation and reinforcing progress. In addition, we implemented hotkeys for the Maker’s controls to make interactions faster and more intuitive. This change allows the Maker to respond more efficiently during gameplay, improving the overall flow of cooperation.

Dialogue system implementation

Another key addition was an anti-cheat stun feature, designed to prevent players from exploiting unintended mechanics. This helps preserve the integrity of the level design while still allowing for creative problem-solving.

Anti-cheat stun feature implementation

Moving forward, we plan to add level 3, continue polishing gameplay systems, improving visual cohesion, and refining the overall player experience as we prepare for the final stages of development.

Milestone 4 — Alpha

In this phase of development, our team focused on transitioning our prototype into a more structured Alpha build and establishing a clearer visual and gameplay direction for the project. Compared to earlier iterations, this milestone allowed us to bring together our level design, visual identity, and interface systems into a more complete version of the game. The goal was to ensure that the cooperative gameplay loop between the Mover and the Maker was functioning within a structured level layout.

For this milestone, different members of the team worked on different aspects of the project. Eva, Ekam, and Victor focused on the level design, developing a linear level structure made up of individual “screens” that gradually increased in difficulty, allowing us to introduce mechanics step-by-step and implement early skill gates. Ryan focused on the UI development, particularly improving the “Show Controls” panel to help players better understand how to place and rotate platforms. At the same time, Ally worked on establishing the visual direction of the game and creating the Mover sprite sheets, which give the character clearer movement and animation.

Level design iteration for the alpha build
UI and visual development for the alpha build

For the next milestone, our team will focus on improving the controls and expanding the gameplay mechanics. One change we plan to implement is adding keyboard inputs for the Maker, allowing objects to be placed and rotated more efficiently than the current mouse-only controls. We also plan to introduce additional mechanics, such as anti-gravity platforms, to expand the puzzle possibilities. Moving forward, we will continue refining the balance between the Maker and the Mover to ensure both players remain engaged, while also adding more feedback elements such as dialogue between the hacker and the character to guide players during more difficult puzzles.

Milestone 3 — Refined Game Development Document

In this phase of development, our team focused on verifying whether our novel game idea had a functional loop based on data collected through our playtest sessions. We had Ryan and Ekam work on the core systems of our prototype, Victor and Ally to host external playtest sessions, and Eva to organize and update the GDD based on each of our findings. Although our prototype did have some slight clarity issues due to lack of visual aid, it was clear that our game’s core is a sufficient game loop that we can build on. The playtesters we had during this week’s lab all enjoyed the experience of working through the puzzles with the tools they were provided.

Functional Flowboard for Export to: Reality Functional Flowboard for Export to: Reality

For our next milestone, our team will focus on deciding what type of style and identity we want our game to encompass and delivering on what needs to be done in the upcoming 4 weeks. What we have right now is a game with many fun mechanics to play around with but not much depth into what sort of direction we want our game to lean into.

Since our next deliverable will be our alpha code, ironing out what needs to be done within the coming weeks will be a major consideration to ensure our game has the key systems and visuals are polished up within the upcoming 4 weeks. For level design, this may be “How could we expand the length or utilize doors to have the players run through the same area but in different ways?”. For menus, “How could we organize the tools in a way such that it will be easy to reuse in later levels with minimal updates?”. For assets, “What type of background do we want our character and world to run on based on the puzzles we have designed?”. The answers to these questions will help unify our team’s ideas and speed up our development process as a result.

Milestone 2 — Game Development Document V1

This milestone, we created our Game Development Document. Victor was in charge of creating our Functional Flowboard for the structure of the game. Ekam was in charge of documenting the Primary Gameplay Mode, with its Core Loop, Resolution Type, and Smart Depth. Ally, our artist, was in charge of character design. Ryan was in charge of a Concept Shot for the Core Loop, showcasing an example run of a level and creating visual representations of key environmental elements. Eva was in charge of the story and narrative flowboard.

For our flowboard, we documented the gameplay of both the maker and the mover. We talked about both players’ inputs and navigation. When designing our game, we had to manage two different player mechanics to fit into one main core loop. While both players perform different actions, their resolution is the same: to beat the level through coordination and communication.

Functional Flowboard for Export to: Reality

For smart depth, we identified two additions to make things more interesting. While initial levels might seem shallow to ease the player into the mechanics, more capability modifiers will be added to be used to solve puzzles. Eventually, levels will become more complex as more modifiers are added, adding depth to progressing levels. One specific example we discussed was the anti-gravity modifier to platforms, where the maker can pause gravity on platforms. The player would need to decide how to best use this mechanic to solve the puzzle. Another smart depth mechanic we discussed was a star system for levels, like in games such as Overcooked or Angry Birds. Casual players can get through levels by just one-starring each of them, but those who want to master the game mechanics will want to replay previous levels for better times or complete optional objectives, perhaps with the new capability modifiers they earned in later levels they didn’t have before.

We designed our two protagonists: the mover and the maker, to work with each other. We did not want our mover to feel bored while the maker tries to figure out how to aid them, and we did not want our maker to feel bored while the mover does combat or platforming, so we added combat. While the maker solves puzzles, the mover will need to fight. While the mover does platforming, the maker can stun enemies to give the mover more space.

For an example playthrough of a level, we discussed a “weight” item. At first, the maker would use the weight to weigh down buttons for the mover to go around. However, a eureka moment the player can have is using the weight to catapult the mover with some platforms.

After our presentation, we found that we need to address how the core loop is experienced by the two different players. We also need to make sure the smart depth is felt by both players, so neither role feels too shallow. Both roles need to be complex enough that it would be too difficult to control both of them with one player, but not too frustrating that players would not enjoy the game.

Milestone 1 — Project Proposal

For the first milestone of game development, we focused on ideation and settling on a solid concept. After throwing a bunch of ideas around, Ally came up with a game mechanic where a player could directly manipulate the game world and we loved it. We thought of a game that would combine genres, namely puzzle and platformer, and wondered how we could add our own twist to it. Existing games such as Super Mario Maker, Ultimate Chicken Horse, Portal, Keep Talking and Nobody Explodes, and It Takes Two came to mind, but we wanted something different.

A screenshot of our figma brainstorming session where we discussed ideas for our game. There are various notes and sketches on the whiteboard

The main motivator towards creating our game was to have real-time interactivity and teamwork between 2 players, so we came up with the idea that each player would be operating within a different genre of game, 1 as puzzle player or “Maker” and 1 as platformer or “Mover”. For narrative, we thought it would be interesting to make a meta-narrative explanation for the mechanic, so we imagined our premise as such:

Victor's Week 1 Sketch

A computer player and a video game character work together to overcome the limits of code and escape the digital world!

Our initial vision for the game, tentatively titled Export To: Reality, is that players will have to progress through 4 different levels themed around the inner workings of a computer’s software and hardware. Each level will have different moving parts and collectibles that will ultimately result in a puzzle/platformer hybrid. The goal is for players to “escape” the game, and we want to target casual to midcore players that like both/either genre with a focus on cooperative play.

World concept sketch 1 World concept sketch 2 World concept sketch 3 World concept sketch 4
Player character sprite concept NPC character sprite concept NPC character sprite concept
Core loop of puzzle solving diagram
Core loop of puzzle solving
Core loop of combat diagram
Core loop of combat

We were pleased to know that Rick Brown, a veteran of the gaming industry, thoroughly enjoyed our concept as we presented it during greenlighting presentations and was a fan of it being a “cool, weird idea.” We’ll probably want to lean into this more with our concept, to make our game something truly unique and memorable.

Some criticisms and things we’ll have to address going forward are:

  • How to balance the difference in mechanics and controls for 2 players, to make sure both roles are equally as fun/engaging
  • A good tutorial and careful thought towards how to guide the players towards which elements are interactable
  • How the screen will be shared between players (split screen, shared screen)
  • Making a lasting first impression that will hook players in with the concept