This is one of the earliest games I've made when I began to do game development. At that time I didn't have the habit to write devlogs. But now I'm staying on my own, finally have some precious time to myself — no longer running around exhausted by the endless stream of schoolwork. So I think it's a perfect timing to looking back at the games I made, to see if I can learn some lessons from the development process.

1. Where the Idea Start

I've always been a fan of ASMR since I discovered it.  ASMRtists create all kinds of works with vastly different styles — some of them even bold and unconventional. For me, listening to ASMR feels a lot like meditation: during that time, I don’t have to think about anything else and can just focus naturally on the sensory experience — the perfect relaxation after a tough day. Then one day, while watching an ASMR video, I suddenly thought: what if there were a game where players could play around with different trigger items? The design that followed was built upon this simple idea.

2. Mechanic Design

Of course, if the game were only about letting players play around with different ASMR trigger props, the gameplay would feel rather monotonous. So I started thinking about how to make it more engaging by adding other elements.

One simple approach was to enrich the tactile experience of interacting with props—making it feel more like playing a musical instrument. For example, the player could slide the mouse across a microphone prop to produce different sounds depending on the area and speed of the movement, or shake a water bottle by dragging it with the mouse to generate varying sound effects based on rhythm.

However, despite the simplicity of this idea, my limited technical skills made it difficult to realize. This led me to another concept: shifting the focus of the fun toward role-playing as a streamer and interacting with the audience, creating an absurd and humorous simulation experience.

Guided by this idea, I divided the gameplay into two main modules:

1. Allowing players to customize their own absurd streamer avatar (inspired by the rise of the VTuber streaming format).

2. Choosing different triggers based on chat prompts to satisfy viewer requests, while writing humorous chat messages to enhance the entertainment value.

To provide more interactive feedback, the number of viewers in the stream increases as players meet audience demands, gradually unlocking new props.

3. Prototyping

The prototype was developed in Unity (though my main focus was on design rather than programming). The goal of prototyping was mainly to verify the technical feasibility of the game and explore an appropriate visual style.

Since my technical abilities were limited at the time, I needed to test the feasibility of several functional modules. In hindsight, many of them were rather brute-forced implementations. For instance, for displaying and refreshing chat messages, I didn’t use a database; instead, I created each chat line as an image and simply swapped the sprite source via script.

Fortunately, all the features ended up working—but the game became quite difficult to expand later on.

As for the visual style, after some testing I settled on a 2D cartoon aesthetic. To me, this was an economical choice: it didn’t require highly polished artwork, as long as the style remained consistent and the colors harmonized well.

4. Aesthetic

As mentioned earlier, my goal was to create an absurd and humorous gameplay experience. This choice also gave me more creative freedom. For example, I included bizarre streamer avatars like a zombie or a Spider-Man wearing an Iron Man helmet; as the viewer count grows, players can unlock unconventional ASMR triggers like rap or beatboxing (thanks to ASMRtists for the inspiration); and the chat is filled with humorous spam messages for extra fun.

5. Lessons Learned

1. Use prototyping to evaluate the technical feasibility of a design.

2. Refinement and polish in the details can make even simple mechanics engaging.

3. When development capability is limited, aiming for a minimal viable product is always a pragmatic choice.

6. Other

In fact, I made two versions of this game. After completing the first one, I learned about Unity’s visual scripting tool (Bolt) and tried rebuilding the game as a practice exercise, which resulted in a second version.

However, the experience was quite painful — Bolt isn’t well-suited for nested or looping structures, and once the code gets long, the visual scripting graph starts to look like a plate of spaghetti. :(

So I’d only recommend Bolt as a beginner-friendly tool for learning programming concepts — it’s really not practical for larger projects.

Thanks for reading — writing these reflections helps me see my own process more clearly.