The First 30 Seconds​

The first impression matters more than I thought.

When players launch Whisker 2, they see:

1. Title screen (clean, cozy aesthetic, soft music)
2. "Start" button (big, obvious, can't miss it)
3. Fade to Level 1 (no long loading screen)

I learned from Murder Mystery that complicated menus lose players. Whisker 2's start screen has 3 buttons total:

• Start
• Settings
• Credits

That's it. No achievements menu. No stats. No tutorial select. Just "Start" and you're playing.

The Tutorial Problem​

I hate tutorial levels. They're boring and players skip them anyway.

But I also playtested with people who had never played Whisker 1, and they were completely lost without explanation.

My solution: The first level IS the tutorial, but it doesn't feel like one.

Level 1 design:

• Only 2 customers
• Only 1 recipe to learn (sandwich)
• Only 3 ingredients visible
• Customer patience timer is super generous (90 seconds)
• Visual hints appear contextually

// Tutorial hints appear based on player action, not forced dialogue
if (playerNearIngredient && !hasPickedUpIngredient) {
    ShowHint("Click to pick up ingredient");
}

if (playerHasIngredient && playerNearCustomer && !hasServedCustomer) {
    ShowHint("Click customer to serve");
}

Players learn by doing, not by reading text boxes.

The Difficulty Curve​

This was the hardest part to balance.

Level progression in Whisker 2:

The pattern:

• Introduce new mechanic → Give practice level → Increase difficulty
• Never introduce 2 new things at once

I learned this from watching playtests. When I had "oven + combos" in the same level, people got overwhelmed and quit.

Mid-Game Pacing​

Levels 3-4 are the "comfort zone." Players understand the basics and are starting to feel competent. This is where the game needs to feel satisfying, not stressful.

I added what I call "flow moments":

• When you serve 3 customers in a row without mistakes
• When you trigger a combo
• When you finish a level with time to spare

These moments needed to feel GOOD, so I added:

• Sparkle particle effects
• Encouraging voice lines from customers
• Score multiplier visual feedback
• Upbeat music variations

The code for "flow state" detection:

private int consecutiveSuccessfulServes = 0;

public void ServeCustomer(bool wasCorrect) {
    if (wasCorrect) {
        consecutiveSuccessfulServes++;
        
        if (consecutiveSuccessfulServes >= 3) {
            EnterFlowState();
        }
    } else {
        consecutiveSuccessfulServes = 0;
        ExitFlowState();
    }
}

private void EnterFlowState() {
    // Visual feedback
    backgroundParticles.SetActive(true);
    
    // Audio feedback
    music.pitch = 1.1f; // Slightly faster, more energetic
    
    // Gameplay bonus
    scoreMultiplier = 2f;
}

The Challenge Ramp​

Levels 5-6 are where I want players to feel challenged but not frustrated.

The key difference:

• Challenge: "This is hard, but I can do it if I play better"
• Frustration: "This is impossible and I don't know why I'm failing"

How I design challenge:

1. Clear failure reasons
   When you lose, you know why (ran out of time, wrong order, missed ingredient)

2. Observable improvement
   You can see yourself getting faster each attempt

3. Player control
   Losses feel like YOUR mistakes, not random bad luck

4. Achievable goals
   Finishing the level is hard but not impossible

I playtested Level 6 about 15 times with different people. The goal was: 70% of players should beat it within 3 attempts.

Too easy → Boring
Too hard → Frustrating
Just right → 2-3 attempts, then satisfaction when you win

The Ending​

This might sound small, but the ending matters.

When you beat Level 6, Whisker 2 shows:

1. Victory screen with final score
2. All the customers you served (little character icons)
3. "Thank you for playing!" message
4. Credits with wholesome music

I wanted players to feel accomplished, not just "oh it's over."

I added a little detail: The final customer gives you a thank-you note that says "You're the best chef ever!" with a hand-drawn heart.

One playtester said this made her smile. That's exactly what I wanted.

Designing for Return Players​

Some people play Whisker 2 multiple times. For them, I added:

Score attack mode (unlocked after first completion)

• Same levels, but trying to beat your high score
• Leaderboard (local only, no online)
• New challenge modifiers (2x customers, half time, etc.)

Accessibility options (available from start)

• Adjust customer patience timers
• Toggle combo system on/off
• Adjust movement speed
• Colorblind mode for ingredients

These don't affect the core game, but they let different players enjoy it their way.

What I Learned About Player Experience​

Every moment teaches players something.

• First 10 seconds → Is this game for me?
• First minute → How do I play?
• First level → Am I good at this?
• Mid-game → Am I improving?
• Late-game → Can I master this?
• Ending → Was this worth my time?

Designing these moments intentionally makes the difference between a game that's just "okay" and a game that people actually remember.

The technical implementation matters. The mechanics matter. But the player's emotional journey through the game matters most.

That's what I think about now when I design: Not just "what can the player do," but "how should the player FEEL?"

The Original Design​

For Whisker 2, I wanted a cooking system where you could combine any ingredients in any order to make custom dishes. Players would experiment and discover recipes.

The design doc in my head:

• 20+ ingredients
• Infinite possible combinations
• Players create their own recipes
• Customers request specific dishes

This sounded amazing and creative.

The Programming Reality​

Then I tried to implement it.

// My first attempt
public class CookingSystem : MonoBehaviour {
    public List<Ingredient> availableIngredients;
    
    public Dish CreateDish(List<Ingredient> ingredients) {
        // How do I check if this is a valid dish?
        // How do I know what the customer wanted?
        // How do I give feedback if it's wrong?
        
        // ...this is going to be way more complicated than I thought
    }
}

The problems became obvious fast:

Problem 1: How do I validate "correct" dishes?

If players can make anything, how does the game know what's a sandwich vs what's garbage? Do I hardcode every possible combination?

if (ingredients.Contains(bread) && ingredients.Contains(cheese)) {
    return "Sandwich";
} else if (ingredients.Contains(flour) && ingredients.Contains(sugar)) {
    return "Cake";
}
// ...repeat for 100+ combinations?

That would be nightmare to maintain.

Problem 2: How do customers request custom dishes?

If dishes are freeform, I can't show a picture of what they want. I can't say "I want a sandwich with cheese and lettuce" because that assumes sandwiches exist as a concept.

Problem 3: How do players learn recipes?

With no recipe book, players would just throw random ingredients together hoping something works. That's not fun—that's frustrating.

The Constraint-Driven Redesign​

I stepped back and asked: What's the smallest system that still feels creative?

The answer: Predefined recipes, but with customization options.

New design:

• 6 base recipes (sandwich, cake, soup, salad, pizza, pasta)
• Each recipe has 2-3 required ingredients
• Each recipe has 2-3 optional ingredients for customization
• Customers request a base dish, sometimes with specific extras

This was way simpler to program:

[System.Serializable]
public class Recipe {
    public string dishName;
    public List<Ingredient> requiredIngredients;
    public List<Ingredient> optionalIngredients;
}

public Dish CreateDish(List<Ingredient> playerIngredients) {
    foreach (Recipe recipe in availableRecipes) {
        if (HasAllRequired(playerIngredients, recipe.requiredIngredients)) {
            Dish dish = new Dish(recipe.dishName);
            dish.AddExtras(GetOptionalIngredients(playerIngredients, recipe.optionalIngredients));
            return dish;
        }
    }
    return null; // Invalid dish
}

private bool HasAllRequired(List<Ingredient> playerIngredients, List<Ingredient> required) {
    foreach (Ingredient req in required) {
        if (!playerIngredients.Contains(req)) return false;
    }
    return true;
}

Why the Constrained Version is Actually Better​

At first, I was disappointed. The original infinite-possibility system felt more "creative" and "ambitious."

But the constrained version had huge advantages:

1. Players could learn the system

With 6 base recipes, players learned them fast. After 2-3 levels, they didn't need to think about "what makes a sandwich." They just grabbed bread, cheese, and lettuce automatically.

2. Customization still felt meaningful

"Make a sandwich" → You choose what goes in it
"Make a sandwich with tomatoes" → You have to remember to add tomatoes

This gave players agency without overwhelming them.

3. The code was maintainable

Adding a new recipe meant creating one Recipe object. Not rewriting the entire validation system.

4. I could add tutorial hints

if (customer.wantsExtraIngredient && !dish.HasExtra(customer.wantedExtra)) {
    ShowHint("The customer wanted extra " + customer.wantedExtra.name + "!");
}

With freeform dishes, I couldn't give feedback like this.

5. The game felt more focused

Instead of "figure out what's possible," the game became "master these recipes and serve them fast." That's a clearer, more satisfying challenge.

What This Taught Me About Design​

Programming constraints aren't limitations—they're design tools.

When I hit a programming wall, it's usually because my design is too vague or too complicated.

The constraint forced me to ask:

• What's the core experience I want?
• What's the simplest version that delivers that experience?
• What can I cut without losing what matters?

Now when I design a system, I prototype it in code early. Not to "lock in" the design, but to find out if it actually works.

The Process I Use Now​

1. Design the ideal version
   (What would this look like with infinite time and perfect code?)

2. Write pseudocode or a rough implementation
   (What are the actual technical challenges?)

3. Identify the constraints
   (What's hard? What's repetitive? What's fragile?)

4. Redesign around the constraints
   (What's a simpler version that solves the same problem?)

5. Test if the simpler version still feels good
   (Did I lose something important?)

Usually, the simpler version is better anyway.

Examples from Other Systems​

Oven Timer System

Original idea: Players manually control temperature and time
Programming constraint: That's a lot of UI and state management
Better design: Click to start cooking, done automatically after fixed time
Result: Still satisfying, way easier to implement

Customer Patience System

Original idea: Patience decreases based on real-time clock
Programming constraint: What happens if player pauses? What if frame rate drops?
Better design: Patience decreases based on game ticks, not wall time
Result: More predictable, works the same on any device

Ingredient Placement

Original idea: Drag and drop ingredients anywhere on counters
Programming constraint: Collision detection and state management nightmare
Better design: Click ingredient → Click counter → Automatically placed in grid
Result: Faster to play, easier to code

The Lesson​

Good code makes good games. Good games make good code.

I used to see programming as the "technical part" after design. Now I see them as the same thing.

The best designs are the ones that are simple to implement, easy to maintain, and clear to players. Programming constraints help me find those designs.

When something is hard to code, it's often a sign that the design needs another pass.

The Idea​

I wanted Whisker 2 to have a day/night cycle with weather that affected gameplay. The idea was:

• Sunny days: Normal gameplay
• Rainy days: Customers arrive slower but stay longer
• Nighttime: Fewer customers but higher tips

I thought this would add variety and strategy. Players would adapt their approach based on the weather.

I even made a mood board with cozy rainy cafe aesthetics. I was so excited about this feature.

The Implementation​

I built the entire system:

public class WeatherSystem : MonoBehaviour {
    public enum WeatherType { Sunny, Rainy, Cloudy }
    public WeatherType currentWeather;
    
    public float timeOfDay = 0f; // 0 = morning, 1 = night
    
    void Update() {
        timeOfDay += Time.deltaTime * 0.1f;
        if (timeOfDay >= 1f) timeOfDay = 0f;
        
        UpdateLighting();
        UpdateWeatherEffects();
    }
    
    void UpdateLighting() {
        float lightIntensity = Mathf.Lerp(0.3f, 1f, timeOfDay);
        RenderSettings.ambientIntensity = lightIntensity;
    }
    
    void UpdateWeatherEffects() {
        if (currentWeather == WeatherType.Rainy) {
            customerSpawnRate *= 0.7f;
            customerPatience *= 1.3f;
        }
    }
}

I added:

• Particle systems for rain
• Dynamic lighting that changed over time
• Different background music for each weather type
• UI indicators showing current weather
• Modified customer AI for weather-based behavior

It took me two full weeks of work.

The Problem​

When I finally tested it in a full gameplay session, I noticed something horrible:

I had no idea why I was failing.

When I lost, I didn't know if it was because:

• I played badly
• The weather made it harder
• The time of day changed difficulty
• My strategy was wrong

The weather system added randomness, but not the good kind. It just made the game feel unpredictable and confusing.

Even worse: The lighting changes made it harder to see ingredients. At night, I kept grabbing the wrong items because everything looked darker.

When I Realized It Had to Go​

I showed the game to my friend who had played the earlier version. She said:

"This is cool but... I liked it better before. It feels more stressful now and I can't tell why."

That's when it hit me: The weather system wasn't making the game more fun. It was making it more complicated.

The core loop of Whisker 2 is:

1. See customer order
2. Grab ingredients
3. Cook
4. Serve
5. Feel good when customer is happy

The weather system disrupted that loop without adding anything meaningful to it.

Why I Think I Made This Mistake​

Looking back, I think I added weather because:

1. It sounded impressive. "Dynamic weather system" sounds way cooler than "you serve food to customers."

2. I saw it in other games. Stardew Valley has seasons. Animal Crossing has weather. Those games feel cozy, so I thought weather would make my game feel cozy too.

3. I wanted to show off technically. Implementing a weather system felt like "real game development" compared to just making a simple cafe game.

But I forgot the most important question: Does this make my specific game better?

The Decision​

I spent two weeks building it. Deleting it felt horrible.

But I did it.

I commented out all the weather code and played the game again. Immediately, it felt better. Clearer. More focused. The core loop worked again.

What I Learned​

Not every cool idea belongs in every game.

Weather works in Stardew Valley because the game is about planning around seasons. Weather works in Animal Crossing because the game is about living in a world that changes.

But Whisker 2 is about fast-paced cafe management and making customers happy. Weather just got in the way.

The lesson isn't "weather systems are bad." It's: Every feature needs to serve the core experience, or it's a distraction.

Now when I want to add a feature, I ask:

1. Does this make the core loop better?
2. Or does it just make the game more complicated?
3. Am I adding this because it serves the game, or because it sounds cool?
4. If I remove it, does the game get worse?

Sometimes the hardest thing as a developer is recognizing when your favorite idea doesn't actually fit the game you're making.

I still have the weather code backed up. Maybe someday I'll make a game where it belongs. But for Whisker 2, letting it go was the right choice.

What I Designed​

I added a combo system where if you served ingredients in a specific order, you'd get bonus points. I thought this would add depth to the gameplay and reward skilled players.

The system worked like this:

1. Pick up bread → Pick up cheese → Pick up lettuce = Sandwich Combo! (+50 points)
2. Pick up flour → Pick up sugar → Pick up eggs = Cake Combo! (+100 points)

I implemented it with a simple queue system:

private Queue<string> ingredientQueue = new Queue<string>();

public void PickupIngredient(string ingredientName) {
    ingredientQueue.Enqueue(ingredientName);
    
    if (ingredientQueue.Count > 3) {
        ingredientQueue.Dequeue(); // Only track last 3 ingredients
    }
    
    CheckForCombo();
}

private void CheckForCombo() {
    string[] currentCombo = ingredientQueue.ToArray();
    
    // Check if it matches any combo patterns
    if (IsCombo(currentCombo, sandwichCombo)) {
        score += 50;
        ShowComboText("Sandwich Combo!");
    }
}

What I Expected​

I thought players would:

1. Notice the combo text appearing
2. Experiment with different ingredient orders
3. Learn the patterns
4. Optimize their ingredient pickup routes

I was imagining players speedrunning to get perfect combos.

What Players Actually Did​

During the first playtest, literally nobody mentioned combos. Zero people.

I asked: "Did you notice the combo system?"

Most people said: "What combo system?"

A few people said: "Oh, I saw some text flash but I was focused on the orders."

Why I Think That Happened​

After watching people play, I realized three problems:

Problem 1: The feedback was too subtle The combo text appeared for 1 second at the top of the screen. But players were looking at:

• The customer orders (center-right)
• The ingredients they were picking up (bottom)
• The oven timer (top-right)

Nobody was looking at the top-center where combo text appeared.

Problem 2: The reward wasn't obvious +50 points sounds good to me as the designer. But players had no idea if that was a lot or a little. The score was just a number that went up.

Problem 3: Players were already overwhelmed During early levels, players were still learning:

• Where ingredients are
• How to use the oven
• How to serve customers
• How to manage time

Adding "also learn combo patterns" on top of that was too much.

What I Changed​

Change 1: Made feedback impossible to miss​

I moved the combo text to follow the player character and made it way bigger:

private void ShowComboText(string comboName) {
    GameObject comboPopup = Instantiate(comboTextPrefab, playerTransform.position + Vector3.up, Quaternion.identity);
    comboPopup.transform.SetParent(playerTransform); // Follow player
    
    TextMeshPro textComponent = comboPopup.GetComponent<TextMeshPro>();
    textComponent.text = comboName + " +50 Points!";
    textComponent.fontSize = 8; // Much bigger
    
    // Animate it floating up
    StartCoroutine(FloatAndFade(comboPopup));
}

Change 2: Made the reward tangible​

Instead of just points, combos now:

• Gave you +5 seconds on the customer timer (something players actually cared about)
• Made a satisfying "ding!" sound
• Showed sparkle particle effects

Change 3: Delayed the introduction​

I removed combos from the first 3 levels entirely. Players learned the core loop first. Then level 4 showed a tutorial message: "Try picking up ingredients in order for bonus time!"

Change 4: Simplified the combos​

Instead of 8 different combo patterns, I reduced it to 3 common ones that matched the most frequent orders. This made them easier to learn and players naturally did them while fulfilling orders anyway.

The Result​

In the second playtest:

• 80% of players mentioned combos without me asking
• Several players actively tried to trigger them
• One player said "Oh that's why the sparkles happened!"
• Average scores went up because people got more time bonuses

What I Learned​

Design hypothesis ≠ player experience.

Just because I understand a mechanic doesn't mean players will notice it, care about it, or figure it out.

The most important lesson: Watch people play. Don't just listen to what they say—watch what they actually do.

Players told me the game was "fun" but they didn't engage with combos at all. If I had only done surveys instead of observation, I would have thought the combo system worked fine.

Now before I add any mechanic, I ask:

1. Will players even notice this exists?
2. Is the feedback clear and immediate?
3. Is this teaching them too many things at once?
4. What's the smallest version of this I can test?

Testing your assumptions is the difference between "I think this is good" and "I know this works."

Movement Feel​

One of the biggest things I learned was how much small details matter for movement. In Whisker 2, I spent a lot of time tweaking how the player moved around the kitchen.

At first, I just used Unity's default character controller settings. The movement worked, but it felt sluggish. When I tried to pick up ingredients quickly, the character would take too long to start moving or stop.

// Original movement - felt too slow
void Update() {
    float horizontal = Input.GetAxis("Horizontal");
    float vertical = Input.GetAxis("Vertical");
    
    Vector3 movement = new Vector3(horizontal, 0, vertical);
    transform.Translate(movement * moveSpeed * Time.deltaTime);
}

I ended up adding acceleration and deceleration instead of instant movement. This made it feel more responsive.

// Improved movement with acceleration
void Update() {
    float horizontal = Input.GetAxis("Horizontal");
    float vertical = Input.GetAxis("Vertical");
    
    Vector3 targetVelocity = new Vector3(horizontal, 0, vertical) * moveSpeed;
    currentVelocity = Vector3.Lerp(currentVelocity, targetVelocity, acceleration * Time.deltaTime);
    
    transform.Translate(currentVelocity * Time.deltaTime);
}

The difference seems small in code, but in gameplay it made the character feel way more responsive.

Feedback Systems​

Another thing I learned was that players need constant feedback. Every action should have a visual or audio response.

In Whisker, when you picked up an ingredient, the original version just made the ingredient disappear and appear in your hand. But during playtesting, people said they weren't sure if they actually grabbed it.

I added:

• A small "pop" sound effect when picking up ingredients
• The ingredient briefly scales up before moving to your hand
• A subtle particle effect

These tiny details made players feel way more confident about what they were doing.

Pacing and Difficulty​

The hardest thing to balance was difficulty. I wanted Whisker 2 to be challenging but not frustrating.

Originally, customer patience timers were the same throughout the whole game. But that meant either early levels were too easy or later levels were impossible.

I ended up using a curve for patience:

• Early customers: 60 seconds to complete order
• Mid-game customers: 45 seconds
• Late-game customers: 30 seconds

But I also added ways to earn back time, like perfect ingredient combos giving you +5 seconds.

Why Cozy Games Are Different​

Working on Whisker taught me that cozy games have different feedback rules than action games. In Sharpshooter, missing a shot felt punishing. But in Whisker, I wanted mistakes to feel like opportunities to learn, not failures.

That meant:

• No instant game-overs
• Customers get disappointed but don't rage-quit
• You can recover from mistakes
• Visual feedback stays positive and encouraging

What I Think About Now​

When I start a new game now, I ask:

• How should movement feel? Fast? Heavy? Floaty?
• What's the main action the player does? How can I make that feel satisfying?
• What feedback does the player need to feel confident?
• What's the pace? Frantic? Relaxed? Tense?
• How do I want failures to feel?

These questions help me design mechanics that actually feel good to play, not just technically correct.

The first version of the Bakery would be the centerpiece of the original Whisker game that was created during COSMOS. I would later renovate it to work with the new features I had for Whisker 2. It would be reworked the third time when I added in my two new levels.

The progression of the layout for the Bakery level would become increasingly complex over time in order to accommodate all the new mechanics, at first what we wanted to add and now what I want to add. The first Bakery was made only to feature the mechanics for cooking, talking with customers, and delivering the pastries. The second version would expand on this by adding in the feature to open and close appliances, and in a refrigerator. The layout for the walls were reworked to make it more realistic by scaling down them and adding in little sprites that fleshed out the environment.

The third version of the Bakery was made with the idea of making it more cohesive with the other levels. Initially, the other levels were made with the idea of expanding the scope of the game and it would do that well; But, it became apparent that the scope was not out of reach of the second version of Bakery. This time the Bakery was reformed to have its own unique feature and the layout was changed to be more similar with the other levels in order to have more cohesiveness. This time the Bakery would be made into two areas: a kitchen and a separate customer section. The expanded Bakery reduced the clutter in version 2 and made the layout more clear.

I am still working on Whisker 2, but one of the funnest aspects was being able to add in these new levels and still being able to work on the old ones.

The problem started when I switched the art. The reason why I wanted to switch the art was because I felt like the art didn't fit the style of the game anymore now that it was under my art direction.

However, when I tried to add in the new assets, my character kept on sinking into the ground a little. At first, I thought it was because I had forgotten to adjust the colliders. But, even after adjusting it, it didn't work.

Afterwards, I checked various different things that could have led to my character sinking into the ground: changing the pivot point, looking through the code, increasing the collider.

After a long bit of changing things and seeing it not work, I researched a little into the problem and it turned out that all I had to change was the height in the character controller. One simple problem took me 45 minutes of debugging.

But, I learned that sometimes the best way to fix a bug is to look up the problem. Game development once again proves to me how I have to continue learning and I can't wait to learn more.

For the past few projects, I have mainly relied on Unity asset store for my models, but watching my teammates make art for Whisker inspired me to create my own assets. Soon, I booted up Krita and started drawing.

I wanted Whisker 2 to have characters that were more humanlike so I decided to make a human chef with unicorn features. I chose a unicorn specifically because they are one of my favorite animals and I thought it would be nice to be able to bring them into my game.

But when I added them into my levels, they stood out and not in a nice way. One of the big problems with the new character was that their dull, pastel color scheme didn't match with the vibrant environment. I received some feedback from my friends who also found that the color palette didn't work, but also they thought that the numerous hair strands were distracting.

I realized that the biggest reason for why this design failed was because I made it in a vacuum. It would have looked nice by itself, but it wasn't cohesive with the actual game it was for.

So I got to work, this time I used a more warm color palette that fit the vibe of Bakery much more. I would make a new design, but this time they were fully human and more vibrant. I made a third version after this mainly to reduce the darkness of the hair, but to also polish the design more. Even so, I really enjoyed being able to create my own assets.

I felt like it really allowed me to understand the more artistic aspects of game development and I hope to be able to make my own 3D models in the future too!

First Design

Second Version

Final Design

The original Whisker only had one unique environment due to time constraints, but this time I was free to add in more. The first addition I wanted to add was a gardening level because this was one of the biggest features that was brought up at the initial discussions, but never made it to reality. However, I felt that two levels would have been odd, this is a little ironic, and so I added in one more level based on the beverage mechanic: a cafe.

Although initially these were just ideas from our brainstorm session, I made it into a full-fledged design. These two designs were to be different from the bakery level and have its own mechanic and aesthetic. This was different from the initial ideas during COSMOS as it expanded these mechanics that were only originally meant to be additional features into their own levels.

For the gardening level, I changed it into a farm after thinking about how I could portray the carefree, relaxing nature of being outside and tending to your plants. I expanded the level so that it could encapsulate the feel of freedom.

The cafe level was meant to go in the opposite direction: it was to be more elegant and sophisticated. I wanted this level to have some sort of sleek stylishness so I used more muted colors and designed the level to be more rigid, but also have the level be more organized.

Although these levels are very different from the initial ideas that formed them, the current version expands the game more.

One of the best parts of Unity is how many different things you can do. To this day, I still find myself learning new things about the engine. One of examples of this is the UI system. It offers so many different kinds of UI components like buttons, sliders, toggle buttons, and others. This made it very daunting at first.

When I made my first original game Murder Mystery game, one of the hardest parts was getting the UI to scale correctly. At the time, I didn't know that there was a specific feature to lockdown the size instead of having it scale based on different screen sizes. My first attempt was overly cluttered as well. Instead of using only a couple of Canvas, I made a new canvas for every single UI tool I used. Nevertheless, it was still very fun to experiment with the UI system. Murder Mystery game's clue mechanic relied solely on toggles and the interrogate feature worked because of buttons. The story-based nature of the game meant I used a lot of buttons which ultimately allowed me to learn so much about the UI system.

One of coolest things, in my opinion, was my confetti win screen. After the player guessed the murderer correctly, they would be displayed a rainbow confetti particle system, a congratulatory message, and two buttons: restart or quit. This game was the first time I added in a start screen and a win screen which were both very cool.

My UI journey would be temporarily put on hold while I was working on my Sharpshooter because it didn't really require as much UI as my previous game.

But when I started working on my new infinite runner, I continued to improve my UI skills. This time I carried over the start screen and end screen features of Murder Mystery and expanded it. My new start screen featured the ability for the user to select the gender of the player and the level they wanted to play. I added in a slider that tracked the user's progress in getting enough points to move to the next level and finally figured out how to prevent the UI from shifting in size.

These skills would then be applied to Whisker.

But, it was really Whisker 2 that I expanded my UI knowledge again. This time new development was adding in a pause panel and a settings panel.

The experience at COSMOS made me realize that UI wasn't just for visual flair, but to improve user accessibility too!

This was a big issue that I wanted to fix as soon as possible because it prevented the game from flowing at all and allowed me to check up on potential other errors because I couldn't interact with the customers.

I originally thought that the problem had to do with the code so I spent a significant amount of time combing through it to try to find the bug. I did change some of the code such as reducing the mouse click to only function as the control for giving the customers food instead of also allowing for food to be dropped(I had a new key for that now, Q.)

It took further investigation and shifting my focus from the code to the actual implementation itself to realize that the true cause of my problems was I had accidentally linked the script to both the parent object and the child object specifically meant to handle this. The problem came primarily because of me linking it to the parent object as it disabled the colliders.

Nevertheless, I was able to fix it and learned the important lesson that bugs don't always come from code when it comes to game development.

The UI for Whisker was very limited. For starters, it didn't have a level menu that allowed the player to go back to the main menu which became very apparent in the last COSMOS-wide playtest as I would have to restart the game every time someone new came to play it.

Consequently, my first addition for my UI improvement plan was just adding in a pause button. From there, I added in a pause menu that allowed for the player to adjust the settings or return to the main menu.

The biggest change came when I decided to create a settings panel for the first time. I wanted to add settings in order to make my game more user-friendly and professional. Currently, the settings are composed of a volume slider and a fullscreen toggle.

In the future, I would like to add in keyboard changes and an original design for the cursor. I have always known UI to be an important part of game design, but it wasn't until learning more of game design that I realized its purpose: to improve user accessibility.

Whisker

Whisker 2

Before we started, our instructors went over the instructions for running a playtest. We were told not to interfere at all with the playtesting process in order to get an authentic player experience. As the person with the most knowledge on how Whisker worked, I ran the playtests.

In the first round of playtests, our professors or our fellow clustermates could come and try out our games. I was personally very excited to show my game now that it was a complete prototype. However, almost as soon as they started playing, errors popped up. The game barely worked which surprised me as I had played through the game myself with almost no problems. The most glaring flaw was the lack of a tutorial: I had forgotten to include the details on how to play the game.

The playtest provided valuable input on my game and so by lunch time, I was already reworking my game. This time I made sure to include a written tutorial which would be given to the player through the dialogue, adding invisible walls, and minor fixes to improve the gameplay flow.

The second round of playtests were more successful, but I realized from this how much more I needed to learn!

Before we started producing our game for the final project, I was working solo to create a new game. I spent the first two weeks creating a new fighting game: zombie-smack. This game would be a zombie survival game where waves of zombies would come and attempt to harm the player. The player would be able to pick up rocks, and different types of sticks.

When we began creating our projects, I wanted to first see what I could reuse for my project to spend up development for the first playtest in 3 days. I wanted to make sure that I had a working prototype as soon as possible because my previous game development experience taught me that it takes a long time to make new code and how one error can break your game for days.

I immediately got to work redesigning my zombie-smack which was already a redesign of sharpshooter into Whisker. I borrowed the player mechanics: the player movement script was all good, but especially the throwing mechanic. This script allowed me to have my player be able to pick-up ingredients and throw them into different things. I readadjusted the code to make it so that the ingredient wouldn't fly so far away.

I changed the enemies to customers and by doing this I was able to get the player to pick-up an ingredient, make some sort of food with it, and serve it to a customer.

Sharpshooter

Zombie Smack

Whisker

But, it wasn't plausible for all the features we wanted to be included in a game that we only had 10 days to make. As a result, I used my previous game development knowledge to work with my teammates to group our ideas into a specific concept that was also doable with our timeframe.

Here are some of the ideas that were suggested, but never made it. We originally wanted the game to have a garden because the plot would involve someone stealing from it. Nevertheless, we couldn't do it because we hadn't even fleshed out a single level yet. Another feature would have been beverage orders. This didn't meet the cut because it would need much more art assets.

Although there were a lot of great features that didn't meet the cut, it did help our group finish our project much faster. We were the only group that consistently met our deadlines which gave us the time to polish our game.

Even though it was hard to say goodbye, it was definitely for the best.

Although the system worked well, I felt like I could try to spice up the original formula. This time I used a premade map and instead procedurally generated powerups and obstacles to form a path. This time I could explore more with my infinite runner paths as they no longer needed to be straight, but could be curved, uphill, downhill, and in a cave.

In the future, I would like to experiment more with map design because the new map I used wasn't something I made. But, I still feel that changing the map was a good choice because it allowed me to experiment more with the mechanics of my game.

For a bit of context, I originally followed a tutorial on how to make a first-person shooter in Unity; before, I decided that I wanted to make my own game. From there, I changed the theme of my game from sci-fi and futuristic which was based on the original tutorial to a green plain covered with hills, trees, a house, ice, water, more ice, and also a design entirely based on my own ideas. This was when I decided I should change my enemy sprite from a robot to a bird. I chose a bird specifically because I felt like my open green space should have an enemy that was down-to-earth, more natural, and maybe even a little silly since my game was in low-poly.

I found a free bird model off of the Unity asset store. It was a brown bird and had some animations for moving and flying. The bird enemy gave me more options for how the enemy would move as well. Because they had a flying animation, I felt it would be a great opportunity to spice up the attack patterns. I changed the code to allow the bird to fly around, circle around you, and try to peck at you when they got close enough.

The bird change may have been just a simple model switch, but it was the start of my independent game development journey.

I quickly suggested that we make a murder mystery game for our project to my two other teammates and it was settled. I was very excited to use Unity for our project. It was originally supposed to be a game where you had to find a culprit except the murderer was randomized so that each time it would be someone different.

We originally planned for five different NPCs that could be the suspect and the possibility of you, the player, also having a chance to be on the other side. However, the plan quickly proved overtly ambitious so we had to scale down to 3 NPCs. Nevertheless, we were able to keep the core mechanic intact.

Overall, for my first group and original game, Murder Mystery is truly one to remember!

The first game I made was an infinite runner which centered on a King who ran through medieval inspired road chunks. The game was a simple infinite runner that followed a tutorial, but it was really inspiring to be able to make such a complete product in only about 2 weeks of time. I felt so accomplished to see my work transform into something so tangible.

It was great that I could also add in my own flair to the game. I changed up the road chunks and worked on the post-processing.

Overall, the game was just one game, but it would inspire me to create my next one.