MDMA Fishyheist

*Init*

## Game Vision
Admittedly, putting the vision in this document was more so an act of laziness, but I thought it'd be a model to try out in the future & it is much more convenient scrolling around one txt than going from one to another.

While it's an incredibly inconvenient process, I value journaling & how it can be useful on the long term.


Current Pillars:
1. Difficult, slippery yet fun and understandable controls with high skill ceiling that allow for precision and skill for top players.

2. Placing & Nurturing moments of goofs, mistakes and miscommunications, and optimizing those moments.

3. Smooth level design that keeps you engaged, in learning, is clear and understandable yet requires calculation.

Current design & process goals:
- GAME: Make a fun multiplayer game with the fish prototype. So far the prototype is fun to play with, but a little tough to control for newbies. I've weighed the pros & cons of Co-op vs. Race and I'm going with Co-op, but what I need a fun level structure now.
- GAME: The game should be frustrating but fun, lighthearted, and allow for some stupidity. Goofs, mistakes, miscommunications, and other forms of fun moments nurtured or directly placed by the game design will be part of the game's core.
- GAME: The character should be very fun & responsive to play with, even if slightly floaty at the beginning. The skill ceiling will be high, and there will be things to learn about the character, and later on down the line ambitious/unorthodox plays will be rewarded.
- GAME: The game's spirit is chaotic yet sometimes precise or goofy, and will be funny yet adventurous / unpredictable- trying to harness social elements into the game design. The word Chaotic is as good as you can get boiling it all down to just one word.
- GAME: The Target Audience should be very big tent, as in preferring a diverse coverage of players over a dedicated, more targeted one.

- PROCESS: Expand on the TTF Model (Toy/Target Audience/Fantasy) whether on the inside or the outside (as in adding more to the model or expanding its current forms), and find new ways to expand the process.
- PROCESS: Find & innovate ways to get playtesters. There is no set goal with this, but I want to discover new methods to get people to give feedback on my games. I recently watched a video that says you should always get feedback and make prototypes as soon as possible.
- PROCESS: Always leave the game in a "finished" state. Try to sign off each day with the assumption the game is playable. I saw this in a Jonas Tyroller video and a friend recommended this idea to me, so why not?

- WORK ETHIC: Produce something that will avoid the overscope. I've read recently to always scope with the assumption everything takes twice as you'd think it does. Outside of Doctor Drag my other two games (Dictatorship Simulator & Cinemadness) both fell very short of their initial goals.
- WORK ETHIC: Get 20 hours of development over the span of 5 days in this. The goal isn't to make a game that took a lot of time to make, but rather, the ability to split my time and still provide strong working hours. My best works have previously come under heavy intensity, but at the expense of other things in life. I still have my personal projects, my portfolio, and in the future things could get a lot more hectic.

## Entry April 25th, 2025
Created this little document, I'm exploring how MDMA works and other processes to make the most out of my Game Design process.

Began tweaking the characters to make things more forgiving. This is more me messing around with the engine rather than trying to create a viable product.

I'm right now working on the design process and thinking of what the game's structure should be made of. A simple level structure by the end of the day isn't necessarily possible but simply getting an idea and trying to prove its practicality will be good.

## Entry April 26th, 2025
A bit late. But I got distracted today watching the football.

The game's TTF prototype & 3 Pillars initial phases are complete. The prototype has taken a more advanced shape now, being split into 3 sections (Expressiveness, Responsiveness, and Mastery) and each section having a few subsections which will represent the playful stuff.

I like the idea of players working towards a bank heist. It's badass, it's goofy, and it has a lot of room for precision (& dumb) plays. The Target Audience is very wide cast, it's a co-op game but I can imagine all sorts of players being into this sort of thing. The lack of online play, because this is merely a Uni project, is a natural consequence of the game.

The pillars & vision were updated a bit. I lagged somewhat on this process, but I'm glad to get it out the way.

## Entry April 27th, 2025
Big day ahead, we're going to be working on prototypes, understanding what the early (early in dev, not early in game) level designs should contain, and potentially develop a level gimmick or two.

I spent yesterday & today asking what skill metrics & design methodologies can be used for the level design. Some of the answers I came up with:

Skill Metrics:
- Positioning & Timings
- Deceleration
- Rotations
- Thinking Speed
- Control/Swerve

Current Methodologies:
- Dribbling Styles (Inspired by football, of course)
- Emotional Flow
- Pacing (Breather rooms? High intensity sections?)
- Ability to give less advanced players a way out, without making an obvious second path to take.
- Feelings of precision, control, speediness, in movement character, should all be prioritized. These traits are consistent with all potential images the player might have of the character, all across our target audiences.

Of course, keep in mind these only concern the spike & block levels I'm working on at the moment. Gimmicks will be introduced sooner once we understand the game a little better.

Now those astute enough will be able to tell most of those methodologies will target players who play the game at an advanced level, and don't understand newbies & less advanced players very well. That is okay, we'll cross that bridge when we get to it.

After writing down some skill metrics, design questions and also design quirks, I'm now making levels, but also I'm now asking, what's the difference between a simple fun 2 player experience and a 1 player experience with the same game, without directly mentioning the fact that its 2 player? The simple rule in this research was no coming up with gimmicks. We just have spikes & blocks and must work with those. Gates, Ropes, other ideas will only be introduced later on down the line. The goal was to see what's between the area of multiplayer and singleplayer.

I used Wii Party's minigames which offer a wide variety of 1-pair minigames, and also looked at other top games. I've made some interesting observations here:

1. The decision making process over who goes where, in its own, is multiplayer core. So we're already in the right territory with this game design
2. Adding some questions over timing, who goes first? Do we run into each other at the same time? Etc
3. Collective pressure, as in both players working at the same time to achieve something.

Level 1 complete, on to levels 2 & 3. On Level 2, I designed an all-spikes level, where one teammate stays back and has to hold on mid air, while the other goes through a somewhat forgiving but challenging course. Adjusting the gap's size to be harder or easier was not very fun, but I tried to be speedy with some of my design executions. If it looks ugly, it's fine. It won't be in the final game. If for whatever reason it is, they'll understand why it got there. This course challenges everything, really, but I thought that's a bad thing.

Near the end of the course of RakPrototype2, you have to zig-zag through a small section to press up a button. I considered that deceleration might not be something every player has mastered, so I added a little wall to avoid getting players killed. It's bouncy, which means it can still kill you in ways, but it's forgiving. I'm also using the fish's rotated body as a way to measure gaps. If it's slightly bigger than the fish pointing up, this means it's a good horizontal section that's not difficult to beat, but still gets you on your feet. I'm trying to experiment with other gap sizes measured with the fish's body.

RakPrototype3 is much simpler. The level is easier (maybe harder? Depends on who's playing) but it is more focus on its atmospheric goals. The fun of the elasticity & movement where you run through the track was a lot of fun. I liked the idea of giving the movement a "drifting" feel, and also the idea of two players agreeing on one going all the way while the other stays. These moments challenge dynamics, either reinforcing them or shedding doubt upon them. This is my favorite out of the 3 prototypes.

I've noticed a lot of the movements in the first 2 levels felt stealthy, so we were in the right territory in a way with those two levels.

I also added RakPrototype4. Now this one is much simpler, focusing on atmospheric goals, and is very easy in difficulty. Let's see where we go from here.

Now on to introducing gimmicks. I've added gates- a system where you must hover over an area to keep another gate somewhere else on the screen open. The game has a lot of uses for this, for example, in one prototype level, I made it so that if you stand on a button, you must stay on it for a while, hovering over the spikes & under them, so you don't get destroyed. Another is in level 5 where players go through a Gotta Have It gate sequence. You must slide through a set piece, while your team mate waits, sometimes hovers, and you're working hard.

These waiting sections are awesome. For many reasons, sometimes they introduce pressure & stakes into a game, other times they create a "waiter" role which is something you consider in the planning process of your plays, and just simply put more synergy between our two players. It's as simple as that actually- synergy.

Prototype level 5 is almost a straight copy of level 1, but expands on the initial vision- one player stalls inside or outside the gate, and the other tries to get to the key. Level 6 is a bit more complicated. There's a Gotta Have It sequence, almost expecting the two players to be equal. Of course, they're not equal. And this level shouldn't be introduced so early on. But it's my prototype levels and I play with the expectations of the player, not you.

Level 7 is a bit more simple. One player is going to stay at the bottom of the screen hovering below & above a pit of spikes, while the other runs through gates to help their teammate go through the checkpoints. The catch? The gates are similarly colored. This could either mess with people's brains, or just be dumb design. But it's an experiment worth doing, I like sections where one person communicates with another going through a completely different experience. How will you say what shade of purple you need pressed? What are the odds of the player messing this up? I try 2 different techniques to break the player who's going to be on the upper half of the screen, but the playtesters can make a joke out of this section and I wouldn't be shocked at all.

One thing I learned today? Look for stuff that inspires you. There's always going to be a hint of inspiration somewhere if you lose faith in a project. Design concepts get me excited, and a few had me trying things out.

For tomorrow, I hope to have at least 3 levels (12 sequences) finished, a rope gimmick where two characters are tied together and must work around it, and some art assets complete. I have no idea how the conversion process from Prototype Level to Final Level will look like, but I'd imagine a 3rd gimmick is something to be looked into. Maybe even a 4th. These aren't very difficult to make. Once that is done, we'll have a playable game. And from there we can add everything else- game juice, hats (which I really want), etc.

## Entry April 28th, 2025

I began work on the rope gimmick & assembling notes I made for my game's level and mechanic design processes. Since I do not have those anywhere public outside of my journal here, I made the decision to be generous enough as to put it here.

OLD implies something still relevant, but already established in design.

These ideas, gathered from asking basic questions in the planning processes & other game researchs, will help me design things like my rope mechanic.

Mechanic Design:
- Consider visual clarity
- Funny death styles/fail screens
- Think of ways to make players block each other? I want players shouting at each other.
- Timing elements? Things that make you have to time your movements? These are forms of challenges, and can be combined with our skill metrics to push things to their limit
- Mechs that complicate the calculus of your movements? Like an ice mechanic or something?

OLD- Mechanics that allow players to work in sync are cool, and fill in the spaces between our level design ideas that keep it together in a multiplayer project
OLD- Prevent players from going past gates if theyre doing something wrong

Level Design:
- Tight comboing / Allow for chances for players to look badass or dynamic
- Blur communication (colors of gimmicks? rope strains?)
- Challenge poor players when theyre in teams with top players, but allow top players to bruteforce through it sometimes
- Think of ways to make players block each other?
- Structure challenges in ways players can recognize patterns, and break those patterns occasionally
- Variation in tempo, depending what part of the game we are in?
OLD- Use frustrating responsibility sharing

Game Polish:
- Allow more badassery/exaggerated swagger in game juice/polish. Even if players like the goofy elements, the "too big for your boots" stuff is cool, and make it correspond to your movements.
- Hat & Paintjob color between levels could be cool?
- The fish & heist elements need to be spelled out. This is crucial.
- Some edge case strats?

#Entry April 29th, 2025
Journaling during clutch (not crunch) time is an extreme sport, but one I'm ready to do. First thing I'm doing is cutting levels down from 5 sections to just 4. Cutscenes will serve as
intervals.

I lost 4 hours in the morning chasing a bee around. I used the time to instead go grocery shopping, try to find ways to shoo it, but it seemed to survive, although from what things look like right now it has left my room.

Heist 1: Tutorial, this will introduce players to new concepts, and introduce gates in the final level. It's not easy though! We will get a few deaths out of you. Coordination will hardly be needed, but you will still need to communicate to win- who goes where, etc.
- Introduce players to concept & controls first
- Establish some dynamic, lets say one checkpoint is tougher to get than the other?
- Then introduce the skill metrics at a forgiving but competitive level

Heist 2: Gates, players must coordinate together to go through these levels.
- This one will get a raise out of newbies, but will be a little forgiving

Heist 3: Ropes, this one is the hardest, and what it sacrifices in planning it makes up for in coordination.
- This one will be brutal

Heist 4: Ice, this will be the final heist, and will kind of have a payoff for our characters story wise?
- This one will have a learning curve, but will not be the hardest of the heists.

For prototype10, I found it would be interesting to add variation in camera sizes. Smaller camera is simpler, but potentially overwhelming- if that makes any sense.

The game plan, in just 3 hours, currently looks like:
- Wrap up level design (16 levels)
- Add win conditions- Level 4s only need one collision
- Menu Setup (Get this done and your MVP executable should be finished)
- Add cutscene intervals
- Add game art
- Add customization elements, if possible (would be super cool for sure...)
- Do an early round of playtesting

With segment 1's design:
Both sides have a decent canvas to practice rotations & thrustings

Left side:
- Positioning & Timings
- Deceleration
- Rotations

Right side:
- Positioning & Timings
- Deceleration
- Rotations
- Thinking Speed

This also can re-purpose Gate level 1 as a nostalgia element? Like, you're here playing the first level, but it's harder now! This is an advantage of stretching material out, in a way- force shoving short term nostalgia.

#Entry May 2nd, 2025

While it's a bit late to make a fresh reflection, I have wrote down my general observations of how people played games, what went right, what went wrong, the initial design goals & what they evolved into, and what was picked up from all of this.

Off the bat I do think this is my best experiment so far this semester. The difficulty was brutal, but deaths were forgiving, and I suppose it attracted a certain niche of players- all things I will go into in a second. But being able to make a complete game, almost entirely bug free, is a relief. Week 1 was rushed out the door, Week 2 had issues with the frame rate (which could have been fixed with just two lines of code! But it's no problem), Week 3 was a joker, Week 4 was a prototype that I was ashamed of from the start. Of course time mismanagement was an issue, but it's important to go into what measures I took to counter this, which will be discussed later in this entry.

Let's begin with the game's difficulty. The game was bug free, the menu buttons worked, although a how to play section would've been useful? I like players formulating their own learning experiences rather than being told what to do. WASD+Arrow Keys was a straight forward sequence, but pressing R to restart level was a feature in the game that was useful to address one small bug I can go into later.

The first level's zigzag segment was brutal. I don't know why I imagined players would instantly know they should jitter-tap to adjust their positions. Of course the early levels were rushed out the door (Idea was to make interesting later levels first, then build up to them near the end- as I was taught to professionally do) but it's still something that could've been better with more playtesting.

There are some small issues- the hitboxes weren't buggy but were poorly placed (one of them was a pixel above one of the players landing spot in the very first level- which was very stupid), players can sometimes go out of the screen in some levels where I forgot to place borders- also a stupid bug.

But we also have to talk about the good. The game was hard, but I've noticed almost everyone got into a flow state. This was a success and something I've never achieved before in any of the Playtest Evenings- I usually always end up with one hand on the Unity editor and the other scratching my head. This time I didn't just have a functional game, but one that players really enjoyed.

The controls were fun off the bat. Players had fun messing around- colliding with each other, with blocks, et cetera. Level 2 was so much easier than Level 1. People were desperate to beat
levels, they occasionally drifted into fun player dynamics, which means the mission of trying to figure out the difference between a singleplayer game and a multiplayer game, minus the player count, is something I progressed in.

The game also attracted certain niches of players. Some players just kept trying to beat the first level and trying to discover new strats to do it, then they went to the 2nd level and were shocked how easy it is. Some players cracked the whole thing in one go- I never played Geometry Dash but somebody played the game and cited he has 600 hours on it and I was like oh, okay, and he absolutely decimated everything, running & ripping through the levels.

The use of a lot of Unity default content- physics, body materials, et cetera, all paid off. This was in a way a tribute to the Gardening class we took, and how we explored the concept of Game Material.

Let's look at the initial goals I set up in the first entry.


- GAME: Make a fun multiplayer game with the fish prototype. So far the prototype is fun to play with, but a little tough to control for newbies. I've weighed the pros & cons of Co-op vs. Race and I'm going with Co-op, but what I need a fun level structure now.
This was a success, the two-player dynamics were not entirely concrete but the level design & what varied dynamics I tried to set up did work.

- GAME: The game should be frustrating but fun, lighthearted, and allow for some stupidity. Goofs, mistakes, miscommunications, and other forms of fun moments nurtured or directly placed by the game design will be part of the game's core.
Yes, these happened a lot- in the forms of clashes, plan-pivoting, frustration, et cetera.

- GAME: The character should be very fun & responsive to play with, even if slightly floaty at the beginning. The skill ceiling will be high, and there will be things to learn about the character, and later on down the line ambitious/unorthodox plays will be rewarded.
This worked, although I'm not too sure how players could have pushed the game to edge-case scenarios. I feel this isn't something I explored, but as a positive, if I did it would've ended up unnoticed. In a way I can appreciate that I managed to allow for different gameplay styles between noobs & pros.

- GAME: The game's spirit is chaotic yet sometimes precise or goofy, and will be funny yet adventurous / unpredictable- trying to harness social elements into the game design. The word Chaotic is as good as you can get boiling it all down to just one word.
Sure- it worked.

- GAME: The Target Audience should be very big tent, as in preferring a diverse coverage of players over a dedicated, more targeted one.
It had a lot of success with more advanced players, and newbies thought the controls were fun. One person cited it as the "good type of sadomastic", which is in the right territory. A lot of people just wanted to feel the controls and thought the game was addicting although the design was evil. This isn't too far from the original vision- I wanted players to need 9 or 10 deaths to reach the first level, but on average that number was double or triple and on one instance two players reached 80 deaths.

- PROCESS: Expand on the TTF Model (Toy/Target Audience/Fantasy) whether on the inside or the outside (as in adding more to the model or expanding its current forms), and find new ways to expand the process.
It works right now. The model doesn't need much expansion, although time constraints should be considered.

- PROCESS: Find & innovate ways to get playtesters. There is no set goal with this, but I want to discover new methods to get people to give feedback on my games. I recently watched a video that says you should always get feedback and make prototypes as soon as possible.
This is the first failure among the goals here. I did not establish a proper playtesting process- I got some friends to play the early prototype but that's as good as I could've gotten. I had ideas to get more outside testers, but it's not all gone to waste. It's truly a shame because I do think what little issues we had holding us from achieving the difficulty goals could've been neutered here.

- PROCESS: Always leave the game in a "finished" state. Try to sign off each day with the assumption the game is playable. I saw this in a Jonas Tyroller video and a friend recommended this idea to me, so why not?
This is partially achieved, although some of the game's core mechanics- death counter & win zones, were only implemented with 2 hours to the deadline (The original death counter only worked per-level). This was a huge mistake, but still, I did appreciate that players in some of the beta testing phases were setting up their own goals and understood the levels immediately.

- WORK ETHIC: Produce something that will avoid the overscope. I've read recently to always scope with the assumption everything takes twice as you'd think it does. Outside of Doctor Drag my other two games (Dictatorship Simulator & Cinemadness) both fell very short of their initial goals.
Starting as soon as the theme was announced was a good idea. As a developer one of my top skills is shooting prototypes out quickly. I got a prototype out quickly and people loved it.

- WORK ETHIC: Get 20 hours of development over the span of 5 days in this. The goal isn't to make a game that took a lot of time to make, but rather, the ability to split my time and still provide strong working hours. My best works have previously come under heavy intensity, but at the expense of other things in life. I still have my personal projects, my portfolio, and in the future things could get a lot more hectic.
I did good, although I did some mistakes entirely managing the time here. I think there's not much to be said because I'd have to repeat myself.

All in all, this was a success, but I can't romanticize it too much. I couldn't get some of my later in-game goals:
- Adding cutscenes
- Adding customization
- Adding game art

They would've been great to include in the game. But still, nothing to be ashamed of here. The game's scope was a week. Time management could've been better- I procrastinated a bit at some periods, but that's just the nature of things.

If there's one piece of advice to be shared from this experience here, it's to always seek inspiration. Planning too much that you have no room to put something inspiring. Plan something, make it, refine it, then plan more. Find inspiration between this process inside & outside of the planning process.

There's something in the planning process that gets me excited & fired up. To plan everything in one go is to get all the excitement out the way in one design session, and to get all the excitement out the way in one design session is a bad idea, simply planning the TTF, then planning+executing+refining consistently is a much more inspiring, Agile process.

As you were.