I'm in the mood to tell a little behind-the-scenes story about the complex technical journey of a seemingly simple interactive video player and how it works today. This article will be split into two parts: a history lesson and an overview of the current technical architecture.

This piece will focus on the process of identifying and solving problems, and how we used architectural design to reorganize business requirements and create sensible abstractions. For me, this is a record of a chapter in my life; for you, the reader, I hope it can be inspiring.

If I asked you "Who are you?", you might tell me your name. If I asked again, you might tell me your gender, your profession, your hometown, your hobbies. But what if I asked a third time? Most people would probably call me crazy and walk away, but perhaps some would begin to seriously discuss who they really are.

You may not have explicitly asked yourself "Who am I?", but you've probably been curious about it. Some people, to satisfy this curiosity, turn to astrology and fortune-telling to understand their past and future. Others take psychological tests, trying to distill personality into symbols.

These are all good approaches—I'm somewhat familiar with them myself. But after experiencing them firsthand, I always felt their answers were bland, unable to satisfy me. So I thought, maybe this time I should do something serious about it.

This is a topic I have discussed at length with NovaDNG. We have had many debates and fantasies about it. Just a few months ago, we decided to turn those wild ideas into reality. Rune, a project aimed at recreating the essence of Zune using modern technology stacks, was kicked off.

In fact, I've attempted to develop a player more than once, but my limited technical skills and overly picky technical taste led to two or three abandoned projects. However, with the emergence of powerful models like GPT and Claude, building a "space rocket" is no longer an unattainable dream. If you’ve read the development report of Alice Run!, you should have an idea of how astonishingly these large language models can solve development problems.

Riding this wave, I embarked on a nearly frenetic development journey over the past few months.

During the May Day holiday, I started tinkering with some quirky stuff again. This time, I built a motion-controlled visual novel system powered by Joy-Con controllers and PC.

This project actually began two years ago. I've played many "motion games" on the Switch, and they're all fun. However, none achieved my ideal of "controllable aerobic exercise," so I thought, why not make one myself? In fact, I had a very successful "weight loss experience" once in my life.

During a winter break in middle school, a chubby kid who couldn't do any sports successfully flattened his protruding belly and became a genuine "skinny monkey." The method was incredibly simple: run in place while watching TV, one hour a day, for a whole month. When I put on clothes at the start of the new semester, I discovered that all the "fat" on my body had disappeared.

It all started with a bet between my classmate and me at home - who would collapse first from running in place for an hour. The process wasn't tiring at all, just pure sweating. This was probably the first time in my life that exercise triggered endorphin release and gave me a sense of "happiness." Since there was no uncomfortable "gasping for breath" feeling, I stuck with it.

Using a web technology stack to draw GUI has basically become a recognized solution with the most balanced cost-effectiveness. Whether it's desktop, mobile, or even the operating system you're using, there's an abundance of WebView. This "trend" started blowing a decade ago (counting on fingers—) when I was still a college student. Intel created something called XDK, and IBM even tailored its own embedded WebView engine called CrossWalk (although it's no longer maintained).

After so many years of development, developing hybrid applications with a web technology stack on mobile is still a very troublesome thing. There are two main reasons for this situation. On the one hand, Chromium itself is highly coupled with the Android system (there are some APIs in Android specifically for Chromium), the internal engineering practices are chaotic, and it's extremely difficult to trim. On the other hand, Android itself is highly fragmented, and various "developing countries" and "self-researched" "OS" will also cause trouble in various ways, such as the notorious MIUI, whose built-in browser seems to follow rules but pretends to be a higher version browser, and some community ROMs cut off some browser APIs for unknown reasons.