Ally's Journal
Ally's Journal
Week 1 (Jan 15): Game Proposal
In this milestone, our team moved from an initial design question: “what if instead of manipulating the character, you manipulate the game world itself?” into a more defined co-op game concept. We decided that the most interesting way to realize this idea was through asymmetrical co-op, where one player focuses on movement/platforming while the other focuses on editing or influencing the environment. From there, we locked in the overall direction: the game will be a 2D platformer co-op experience with clear role differences, and the fun comes from coordinating what each player can do. We also decided to have four game worlds to structure the player’s progression and keep the experience feeling fresh over time, and each world represents a different “layer” of a computer/system. We established the general vibe and gameplay possibilities for each world.
My main contribution for this milestone was creating the look of the game world. I wanted to figure out what the game world should look like and how it should work. This way our idea becomes something that we can try out and test. I made plans for what the game world should look like, and I drew sketches to show the look and feel of the levels. I worked on the direction for the four worlds by deciding what each one should look like and what should appear in it. For example, I planned a classic retro fantasy-style game world, a messy desktop world where platforms are file folders and hazards are pop-up ads, a darker “kernel” world where platforms look like strings of code, and a hardware world with electrical hazards and cooling fans that affect movement. I made sure each world includes the important things a platformer needs, like platforms, hazards, and clear objects that players can interact with.
I also designed and drew some possible player and NPC character visuals to show our character art direction in a retro pixel-art sprite style.
One of the problems I identified is that we need to find a way to balance our asymmetric design so it doesn’t create an engagement imbalance which can cause one player to feel like they’re doing most of the “fun” work while the other is mostly assisting or waiting. In the next milestone, we should define specific responsibilities for both roles and design the gameplay so each player has frequent, meaningful actions. We can also explore role-switching between levels or checkpoints so both players get a chance to experience both roles. Another problem is that we need to figure out how interactable elements will be presented in the game. For the next milestone, we should make it clear which parts of the environment are interactable by clearly distinguishing editable vs. non-editable objects, so players don’t get confused. Possible solutions include using outlines for interactable objects, particles or pulsing effects when something is editable, hover states for Maker-controlled elements, and sound cues when edits succeed or fail.
Week 3 (Jan 29): Game Design Document
For this milestone, our team pushed the GDD forward by locking down what the primary gameplay mode is and how the two-player co-op loop actually functions in moment-to-moment play. We clarified the Maker vs. Mover interaction model as a shared screen, 2D side-scroller and wrote out the challenges and actions for both roles so the loop is readable as a repeatable cycle instead of a vague “co-op platformer” idea. The Maker’s responsibilities are framed around creating paths, disrupting enemies, and manipulating UI/world elements to solve designed obstacles, while the Mover focuses on traversal, combat, and environmental interactions to progress toward the exit. We also strengthened our progression framing by defining how players “win” by unlocking dev back doors and moving through them, and how the system ramps up difficulty to support replay and mastery.
My contribution to this milestone focused on documenting design decisions that directly support “why the loop is compelling” and “how the roles stay meaningful. I analyzed our gameplay through Don Norman's three levels of design to ensure we're building compelling engagement. I wrote how our loop should feel engaging at a visceral level through immediate responsiveness and clear audiovisual feedback, such as the Maker’s “ghost” platform preview and placement confirmation, and the Mover’s movement/combat feedback that makes actions feel punchy and controllable. For the behavioral level, I explained why the loop should be satisfying to master: the Maker works with limited resources and timing-based support, while the Mover must execute traversal and combat decisions under pressure, creating skill expression through coordination and risk–reward tradeoffs. For the reflective level, I connected replay motivation to the fantasy of “escaping a system” through dev backdoors and the sense of competence that grows when players learn each world’s rules and solve challenges more efficiently together.
In the Protagonist and Antagonist section, I documented the Mover and Maker as distinct gameplay roles with complementary responsibilities and clarified how the “system defenses” function as the antagonist layer through hazards, enemies, and gating systems that force meaningful cooperation. I also created concept art sketches showing different poses and movesets for each character to visualize how their movement and abilities would function in gameplay. In addition, I researched and analyzed how split-screen and shared-screen formats work in similar co-op games to help our team choose a screen layout that keeps gameplay clear and fun for our asymmetrical roles.
Reflecting on the last milestone, the biggest design risk for our game is the role clarity and balance: if the Maker’s actions come across as occasional “assists,” the experience could become Mover-centered. We already have mechanics that support Maker agency, but next milestone we should test whether the Maker feels like they are making meaningful decisions consistently, not just reacting. To do this, we should prototype 2–3 puzzles where the Mover cannot progress without the Maker actively choosing between different supports, then observe whether the Maker stays engaged throughout instead of waiting for moments to help. In addition, there is a concern about whether our game truly requires two players, so next milestone we should run a “solo viability” test: have one person operate both roles by switching between controls and see if it feels equally smooth or efficient, if it does, that’s a sign our puzzles and timing pressure aren’t demanding enough cooperation.
Week 6 (Feb 12): Prototype & Playtest
During this milestone, our team developed a playable prototype and conducted multiple playtest sessions to evaluate our core loop. We designed a tutorial level that introduces players to the asymmetric co-op mechanics and built a platform layout that clearly showcases our main gameplay structure. Through playtesting, we were able to confirm the necessity of cooperation between the Maker and the Mover, as well as identify which UI elements more effectively communicate player goals and available actions. Based on player feedback, we iterated on the prototype and adjusted certain interaction flows to improve clarity and pacing.
My main contribution during this stage was organizing and supporting the playtesting process. I arranged the playtest sessions, observed player behavior, and documented both verbal feedback and gameplay patterns. Instead of focusing only on what players said, I paid attention to how they interacted with the level, such as where they hesitated, overused mechanics, or misunderstood affordances. After collecting the data, I summarized key issues and proposed areas for improvement, including gaps in the onboarding process and inconsistencies in how the UI communicates player intention. These insights helped guide our team discussions and informed the adjustments we made to the prototype after testing.
One major area that still needs improvement is our UI clarity. During playtesting, we noticed that players sometimes relied too heavily on the platform-placement mechanic even when it was not necessary. In the early part of the tutorial, certain gaps require the Maker to place a platform in order for the Mover to progress. However, once players learned this mechanic, they tended to continue placing platforms in later sections where jumping alone was sufficient. Instead of experimenting with movement, players defaulted to the learned behavior, which suggests that our level design and visual cues may unintentionally encourage over-reliance on a single mechanic. This revealed an important design challenge: players are forming strong mental models based on early tutorial experiences. Moving forward, we need to explore ways to signal alternative solutions more clearly, such as adjusting spatial layout, modifying jump distances, or introducing visual affordances that encourage experimentation rather than repetition. Refining the balance between guidance and player discovery will be a key focus for the next milestone. Another area for improvement is the visual identity of the prototype. Currently, many elements still rely on placeholder assets, which makes it harder for players to understand the intended tone and world context of the game. As we move forward, we need to begin integrating more representative in-game assets to support both immersion and readability. Establishing a clearer visual language will likely improve player understanding of interactive objects and reinforce the cooperative dynamic between the two roles.
Week 8 (Mar 5): Alpha Milestone
During the last milestone, our team focused on transitioning our prototype into a more structured Alpha build, where the core mechanics, level structure, and visual identity began to come together into a more cohesive gameplay experience. The team worked on refining the cooperative loop between the Mover and the Maker, ensuring that both players actively participate in solving puzzles and navigating the environment.
My main contributions during this milestone focused on visual direction, character design, and player guidance systems. I worked on defining the visual identity of the game and creating assets that support both gameplay clarity and world atmosphere. First, I developed the visual direction for the Mover character, designing a cute broken robot pixel art style that fits the theme of an abandoned technological environment. The game world was envisioned as a ruined dungeon-like system with mechanical elements, dust, and old infrastructure, creating a playful but slightly mysterious atmosphere. I also created the Mover sprite sheets, which define the character’s animations for idle, running, and jumping. The character follows a 128x128 pixel scale, with multiple frames used to produce smooth movement animations that fit the platforming mechanics of the game. These sprite sheets are designed to be imported into Unity using grid slicing so they can be easily converted into animation states.
In addition to character design, I contributed to visual player-leading systems. This involved designing visual cues that communicate interactable elements in the environment. For example, spikes visually signal danger, platforms appear stable and jumpable, and color-coded buttons correspond to specific mechanics. These visual cues help players understand gameplay interactions without requiring explicit tutorial text.
One problem I identified during this milestone is that visual clarity and gameplay communication still need improvement. While the visual design establishes a clear aesthetic direction, some gameplay elements may still be difficult for players to immediately recognize during playtesting. For example, players may not always understand which objects are interactive or how certain mechanics connect to each other. Another challenge is maintaining balance between visual style and gameplay readability. If visual details become too complex, they may distract players from important gameplay cues such as hazards, objectives, or interactable elements. For the next milestone, I suggest focusing on stronger visual hierarchy and feedback systems. Important gameplay elements should stand out more clearly through color contrast, animation, or lighting effects. Additionally, the team could continue refining environmental cues and UI feedback so that both the Maker and the Mover can easily understand what actions are possible at any moment. By improving these visual communication systems, the game can become more intuitive while still maintaining its artistic identity.