igb120-tracy

[igb120-tracy]

Week 13

Assignment 3 Postmortem. Final Reflection: Wrapping Up Storm the Core

Now that our prototype for Storm the Core is done, I’ve been thinking a lot about the whole process what went well, what didn’t, and what we learned as a team.

One of the most useful takeaways from Game Design Workshop was how Fullerton talked about the “essential experience.” That really stuck with us. From the beginning, we wanted players to feel like they were piloting a nimble but underdog spaceship through chaos making fast decisions, adapting, and upgrading to survive. That idea helped guide nearly every mechanic the team created.

Chapter 8 on playtesting also shaped our approach. It reminded us that playtesting isn’t just something you do at the end it should be built into your process. We didn’t always hit that perfectly, but it gave us a strong framework for gathering feedback and trying to think like a player, not just a designer.

What I’d Change About the Way We Worked

Honestly, I wish i had created our own assets and started proper playtesting earlier. We had big ideas, but by the time we were ready to test them, it felt like we were rushing to make fixes and the game wasn't polished yet.

What I’d Change About the Game Itself

In the prototype, sometimes it felt like the difficulty jumped too quickly, especially in the first few sectors in my opinion. Some players might find it a little difficult controlling the bullets. If we had more time, I’d make the early game a little more forgiving and build the intensity more gradually like Fullerton suggests with “ramping challenges” to keep players engaged without overwhelming them.

Also, our UI and navigation could’ve used clearer visuals. Some players didn’t immediately understand what the game was or what the sectors meant, and the direct waves of enemy spaceships took away from the excitement of exploration.

Well making Storm the Core was equal parts fun and chaotic. We stretched ourselves some things worked better than others, i think my group members put in a lot of effort into the game mechanics. More than anything, I learned how important it is to build with the player in mind, keep things flexible, decided on the aesthetic earlier and test early and often. Sharing the files and assets were a pain, there were overwrites and loss of assets. If we keep that in mind for future projects, I know we’ll keep getting better.

[igb120-tracy]

Week 12: 

Assignment 3 Iteration and Changes

This week, our team focused on iterative design changes following internal evaluation and preparation for structured playtesting (as guided by Game Design Workshop, Chapter 8). Although we're still awaiting full external feedback, we’ve already begun adjusting our game’s scope and narrative structure to better align with gameplay goals and production constraints.

Iteration Based on Practical Constraints

We realized that our original scope risked overcomplication and diminished player clarity. In response, we made key adjustments:

Narrative Simplification: Instead of allowing players to forge completely unique paths, the game now begins with a fixed starting point—one of four spiral arms on a strategic star map. This decision reduces narrative ambiguity while still offering variety and replayability through procedurally generated sectors.

Goal Reframing: While the core objective remains defeating the main enemy, we revised the journey’s narrative and structure to enhance clarity and thematic focus. This also aligns with Fullerton’s principle of ensuring coherence between gameplay and storytelling.

These changes reflect a playcentric mindset: we prioritized player understanding, navigational flow, and manageable complexity. According to Fullerton, iteration should focus on strengthening the core mechanics and essential experience, which in our case meant emphasizing clear progress toward the final boss while maintaining engaging moment-to-moment gameplay. And we are currently preparing for formal playtesting. We plan to establish specific goals for testing, focusing on player navigation and upgrade clarity, and design structured feedback forms to capture actionable insights. This playcentric approach ensures our next iteration will be grounded in authentic player experience.

Update:

Worked on the start scene and linking the scenes. Then put in buttons, added animations using tween and sounds. We encountered complications with shared files missing assets. Different opinions on the overall aesthetic of the game.

[igb120-tracy]

Week 11: 

This week, our team focused on refining the core gameplay systems of Storm the Core through collaborative ideation and internal playtesting—an approach rooted in Fullerton’s playcentric design process.

Design Decisions Guided by Playcentric Thinking

Inspired by Fullerton’s emphasis on player experience as the driving force in design, we shaped our gameplay mechanics with iterative player feedback in mind:

Movement System: We implemented a physics-based drift mechanic, balanced with gameplay-friendly friction. This speaks to Fullerton’s idea that rules should support the “essential experience” — here, the sensation of navigating hostile space with precision and weight.

Combat Loop & Pacing: Each sector is a confined combat arena where players face enemy waves. Between sectors, “checkpoint zones” provide a moment of rest and reflection, including access to upgrade shops. These intermissions reflect Fullerton’s concept of balancing challenge and reward to maintain flow and engagement.

Reward & Progression Design

Our team introduced an XP system where defeated enemies drop physical XP objects. This encourages active player movement and decision-making, echoing Fullerton’s principle of providing meaningful player choices. XP can be spent on stat upgrades and consumables, giving players long-term goals and reinforcing the core loop.

Playtesting Outcomes & Next Steps

In alignment with Fullerton’s process of rapid prototyping and testing, we gathered informal feedback that highlighted:

Satisfaction with the ship movement and combat “feel”

There was no narration or anything of that sort, so it was a waste of the game lore we thought off. Definitely need to work on how players can grasp the concept of the game.

No UI was set up. No direction in once started.

Next week, we plan to implement a more formalized playtest with defined testing goals and feedback forms.

[igb120-tracy]

Week 10: 

Assignment 3 | Team Formation | Storm the Core Pitch

This week marked the start of our group collaboration for Assignment 3. We decided to pursue a top-down, single-player, PvE space shooter titled Storm the Core. The player pilots a lone spacecraft through a procedurally generated galaxy, beginning at one of four spiral arms. Each sector dynamically transforms into either a battlefield, market, or challenge zone—injecting variability and emergent gameplay into each run.

Application of Game Design Concepts

Our initial elevator pitch integrates several key game design principles discussed in class and readings. The procedurally generated sectors are inspired by roguelike progression systems, promoting replayability and unpredictability—aligned with Salen and Zimmerman's concept of "meaningful play" through dynamic feedback loops.

Our team aims to validate our minimum viable product (MVP) by focusing on:

Responsive space combat: Prioritizing tight controls and Newtonian-inspired movement physics for immersion.

Enemy waves and reward systems: Implementing tactical, skill-based combat where progression is tied to in-game performance—a nod to "flow theory" (Csikszentmihalyi).

Upgrade loop: Between battles, players can enhance their ship, creating a sense of agency and investment (aligned with pacing and player retention strategies).

Simplified star map: Acts as a metaphor for narrative progression, reinforcing the goal of reaching the galactic core.

Reflection on Design Decisions:

Our early discussions emphasized player autonomy, strategic variety, and narrative immersion. We debated on the core mechanics of the game. I guess we found it a challenge to maintain balance and coherent difficulty curves. (referencing Schell's “Rule of Elegance”).

This phase of development has already sparked meaningful debate on game balance, difficulty scaling, and feedback clarity, which we will continue to refine through iterative playtesting in coming weeks.

[igb120-tracy]

Week 9

From the feedback i recieved on my A2, i need to work on:

clear goal for the game

the system of collecting coins and increasing familiarity defeated the purpose of the game as a relaxing game.

I got the feedback that the coin mechanic is odd; (it seems like the players have to choose between using the coins to look cool to improve their experience or using it to have a free continue. That choice seems to be at odds with the goal of relaxation. It's also not completely clear: is the goal of the game to get all familiarity levels to max?)

Changes to make:

changing the design of the game, the goal of the game. It seems that i had way too many gaols for a relaxing game. So i decided to remove the letter delivery system. Now It will just be Dialogues between the player and the NPCs. I will keep the letters as a part of the options within the dialogue. The coins will be counted as scores and the letters will also be counted as scores. One coinn will be counted as 100 points. It should be shown as one point system on the upper left side of the screen.

Simplify the game, create only one goal and that is collect as many coins as you can. Develop additional scenes/levels. Put in additional checkpoints, make the enemies do more damage.

[igb120-tracy]

Week 9

Assignment 2 Final Design. These were my one sheet and one page for the game. Made a lot of tweaks. Added additional features and actions.

[igb120-tracy]

Week 8

Problems: 

the gameplay felt plain

repeated movement and actions

Mails delivery system got stuck, no clear reset. 

What helped: Fullerton (Ch. 5 – System Dynamics). I mapped the input/output feedback loop and noticed gaps in consequences. The player didn't really die in any sense so the enemies had no real purpose of being in the game. The ax did no real damage to the player. There was no real health system. The idea of coins to familiarity didn't quite go along with the goal of the game as a relaxing game. - Added checkpoints now that the player can actually die

[igb120-tracy]

Week 7

Issues: 

Players found the map quite small as I only had one scene background with moving clouds.

No clear reason to collect items besides “because they’re there”

No such thing as endgame.

Process Changes i need to make: I jumped to working on the aesthetics before securing the gameplay loop, and working on the game mechanics. Next time I’ll focus on loop logic before trying UI. (Ch. 6 – Conceptualization). I only focused on the assets and never really got to fully work on the game logic. If it works it works?

Probably need to broaden the map. However, I will only be focusing on this one map that i've already got for now. Will get a bigger map after figuring out the game logic first.

Changes to make: If the player doesn’t collect the mails quickly, the mail vanishes. Adds urgency without breaking theme.  Deciding if I should change the goal of the game or keep it (boring?) more relaxed gameplay for the player.

[igb120-tracy]

Week 6

Progress so far:

Created basic player character (mushroom courier), side-view platformer movement, and added 2 test NPCs with simple “Coins” collection system. Challenges: Balancing movement to feel lively. Also trying to make the forest feel “alive” with simple assets. Next Steps: Add more NPCs. Floating platfroms.

Reflecting on my first full build, here's what I found: 

What worked: 

Atmosphere: Players liked the cozy music and visual style 

Mechanics: Mail pickup/delivery loop felt simple but effective sometimes 

Feedback: Sound and UI made the system understandable once explained 

What didn’t work: 

No onboarding or tutorial; players were confused at first, i didn't add any context to the game and just expected players to understand what to do.

Slimes clashed tonally with the cozy theme (they felt aggressive)

The mail delivery system kept flickering, it looked like it worked once or twice. 

Development process changes needed: I need to spend more time storyboarding or mapping the user journey before implementing enemies. I jumped too quickly into adding “challenge” without checking if it served the game’s emotion. (Fullerton, Ch. 6 on Conceptualization). 

Design change ideas: Change the slime behavior: make them mail thieves instead of attackers. That would reinforce the theme of service and kindness rather than danger. Maybe they can steal letters, forcing the player to chase them. 

Fullerton’s Ch. 8 (“Prototyping”) reminded me to keep the first version simple and test one mechanic at a time. I skipped few features for now to focus on moment-to-moment gamplay. 

[igb120-tracy]

Week 5

Title: Mushroom Mail v1 Postmortem 

Big change in concept i think A more simple?, Achievable gameplay.

“Mushroom Mail pick up” – A Platformer Prototype. In Short, "MM"

Elevator Pitch

Mushroom Mail or MM is a cozy platformer where you take on the role as a mushroom Collecting and Delivering letters (Similar ot coins) to forest creatures. Go on mini adventures through platforms, avoid slimes, and jump across platforms to reach your destination,(your customer/ forest friends). The relaxing music, warm colours, and environment of the game invites players (Ghibli fans) or anyone wanting to try a relaxing game to take a break and spread joy, one letter at a time.

What is your gameplay? A platformer focused on more relaxed movements—running and jumping with a mushroom character (Mimi) and delivering letters to NPCs(forest creatures).

The environment of the game allows players to experience a certain level of familiarity and a stress-free gameplay. The reward systems of the game will keep the players engaged with a sense of contempt. The delivery quest content adds purpose to the game .

Who is the target audience? Ages 9+ Perfect for fans of "Animal Crossing". With cozy aesthetics.

What is the player’s role? The player is a little mushroom tasked with delivering letters between forest animals while avoiding slimes and mild environmental challenges.

How will you motivate the player? How will you reward them? Positive dialogue from NPCs if i could add that. Coins collected after completing mini quest. I am also thinking about adding visual upgrades for the character.

What genre is the game? Cozy platform. The name of the game is subject to change with changes in the game. Still thinking.

What is the setting of the game? A peaceful forest filled with giant flowers, hollow tree houses, mossy stones, and animal neighbors.

Inspirations

Visuals: Studio Ghibli’s My Neighbour Totoro,

Music: Lo-fi beats, forest ambient soundscapes, and wind chimes.

Games: Animal Crossing

Emotions: Calm, kindness, curiosity.

Player Experience Goals

Seed of this gameplay: Emotional Palette.

Players should feel calm, curious, and uplifted. A sense of familiarity. Controls should feel smooth and not so stressful (not so easy either), with simple jumping and running mechanics. Light challenge in navigating platforms and finding delivery recipients. A single-player, focused around helping others and forming connections with NPCs(maybe coins could add up and form connection bars).

Again Postmortem + Reflections

The core concept is not bad. Visuals of the game created a comforting sense. It appealed well to Ghibli Studio fans.

The idea of using NPC happy coins as rewards made players interested in the game.

Soft sound effects added a lot of atmosphere with minimal effort.

I only had my ideas out on paper first. Debating on drawing an original character or using assets from online

The game needs a more original character. Getting the forest to feel “full” without cluttering the screen was hard.

What’s next:

Adding game mechanics

Smoother coin collection system

Keep on adding forest creatures.

Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games.

[igb120-tracy]

Week 4

Playtesting and Building World Atmosphere 

With basic mechanics in place, I moved onto aesthetic elements and tested the first full loop of gameplay: 

Collected mail from villagers 

Delivered it to the post office 

Earned coins points

Encountered slimes while platforming 

I asked a friend to play a test build. Key feedback: 

No obvious instruction for controls or mail mechanics 

Didn’t understand how familiarity was tracked or where it is.

Liked the atmosphere and relaxing tone 

In response, I added: 

On-screen prompts. A dialogue system with yarn

Sound cues for mail collection and delivery 

Visual familiarity tracker in the post office 

Reading Fullerton’s Ch. 7 on Playtesting helped structure this session. I followed the “observe without explaining” approach and asked open-ended questions afterward. The test also made me reflect on how I define success—my game isn’t about scoring, but building connection. 

[igb120-tracy]

Week 2-3

Title: Mushroom Mail – A Cozy Platformer 

Mushroom Mail is a 2D platformer where players take on the role of Mimi, a mushroom-shaped character trying to find belonging in a peaceful forest village. Mimi delivers mail to villagers, earns familiarity points, and customizes their look using coins earned through helpfulness. 

Genre: Cozy Platformer 

Primary Mechanics: Jumping on platforms, delivering mail, earning familiarity points, occasional enemy dodging 

Setting/Style: Soft pixel-art forest village with animated backgrounds and a chill lo-fi soundtrack 

Audience: Fans of low-pressure, casual games with narrative flavor. Targeted toward ages 10+. 

Thematically, Mushroom Mail draws from the feeling of being an outsider trying to integrate into a community. It's not about winning but growing. 

This pitch ties to Fullerton’s Ch. 2, which discusses player experiences. Specifically, I focused on emotion, challenge, and interaction. The idea of familiarity points borrows from feedback loop models: players receive positive reinforcement for their helpful actions. 

Exploring GDevelop + Early Mechanics 

This week was my first dive into GDevelop. I followed tutorials but also went beyond the basics to start shaping Mushroom Mail. Here's what I need to work on: 

Set up sprite animations for Mimi’s idle, walking, and jumping states 

Made platforms that float up/down once triggered 

A pop-up mail icon over villagers' heads 

Linked ‘ENTER’ key to collect mail requests (a little ambitious)

Biggest learning curve: getting the collision masks to behave correctly, especially on moving platforms. GDevelop’s event logic is easy to grasp, but combining timed behaviors and interactions gets tricky. 

Reflection: Fullerton (Ch. 4) helped me think of my game in terms of systems, how mechanics and player goals are formally expressed. Designing the floating platforms required thinking about space, rules, and procedures. 

[igb120-tracy]

Week 2 I could't get the player to fall

Platformer Elevator Pitch

GDevelop Experimentation

Brainstorming:

Characters are rather simple. I haven't thought much about possible characters. All ideas that actually pop up are out of my ability. I am thinking of a game similar to super mario, i think that is quite feasible with what i have right now.The main player just runs to get to the checkpoint while the enemy/slime kinda blocks the way out, more like making it difficult to reach the next check point. Too ambitious.

The overall concept is a simple non time consuming game.

Rewards on completing the game = a simple animation (victory/completion ceremony) I plan on sticking to old gameplay styles

Rule:

Just don't fall off the platforms and kill/ stomp onto the slimes to not get killed, i am thinking 5 health bars that regenerates after completing a level. Well a level will have 5 checkpoints.

The player would need to collect certain amount of coins to complete the level, the player is unable to collect the amount of coins required to pass onto the next level at a checkpoint : the player will have ot play the level again, going over the same route again to collect the remaining coins.

The typical environment of the game should :

A nostalgic game type,

Old cartoonish backgrounds. Inspo:

●Title - Coin check (will probably change it later on)

A simple game with a nostalgic theme with a familiar gameplay.

My character can finally fall. It was just the spacing between the platforms. I find my concept still challenging to create. It is quite hard to put what i saw on tutorials into my own work.

[igb120-tracy]

Week 1

A supposit introductory. Hi!

I am Tracy.

I'm actually studying creative arts. I am majoring in Animation and I choose Game design as my second major. I've always been interested in games and animation since childhood, it is a great part of my identity (not really, i just wanted to sound dramatic..I don't know). I think at these two go hand in hand. I actually gave up on drawing and overall stopped creating anything. I took this course..unit just to push myself into doing what i think i can see myself enjoy doing later in life. I have always liked the idea of open-world games and concepts. I enjoyed the Arcane series and a lot of AAA games, Stardew Valley.. I am interested in game character and concept design. Game lore?...something that i find myself always absorbed into.