Hello World
8/1/2026
After finishing my 9-to-5 job, I usually realize I still have plenty of free time left. I tend to fill it by learning things outside my professional field. Most of the time, these side projects are… kind of dumb. And honestly, they often don’t get finished.
I figured that maybe keeping notes about what I’m building, or at least writing things down, might help me stay a bit more motivated to actually complete them. That’s basically why this blog exists.
I built this blog in just two days, keeping everything as simple as possible (I mean, the post list doesn’t even have pagination yet ~ LMAO). As the blog grows and the number of posts increases, I’ll slowly add more features along the way.
If you’re not a “geek,” or if you’re the type of person who enjoys nitpicking beginners’ coding skills, you might want to skip the boring technical section below.
I Don’t Fully Trust AI-Recommended Tech Stacks
The principle is simple: keep it simple.
But the AI agent I consulted suggested using Supabase to build the entire system from scratch—which feels like massive overkill for a personal blog.
Vue or Nuxt are great, no doubt. But for a blog? Something like Astro feels way more sensible. With SPA-based frameworks, you often need extra steps to make SEO work properly, usually involving SSR. Astro, on the other hand, is static-first, MPA by default, and can still use SSR when needed. It’s perfect if you want to start simple without worrying too much about SEO optimization from day one.
There’s also Astro’s island architecture, which—simply put—lets you use components from other frameworks when you need them (though I probably won’t use that feature for this blog).
Where Do I Store My Writing?
So where do I keep my posts? Do I just write Markdown files directly inside my Astro project?
Of course not.
If I say I’m “blogging,” I want the actual blogging experience. Writing posts inside a code editor completely kills that vibe and honestly makes me less motivated. At the same time, building a full backend infrastructure, setting up databases, wiring APIs, deploying edge functions, felt unnecessarily complex.
After some research, headless CMS became the obvious answer.
Out of many options, I chose Sanity. I wanted a clean separation between the frontend and content management, with full control over my content structure. I can host it myself or not host it at all and just keep things local.
Sanity feels like it has very low vendor lock-in. I rarely need to open their dashboard. The schemas live in my local repo, the output can be rich text, HTML, or whatever I need, and the document structure makes it easy to process or migrate to another platform or my own infrastructure later.
For comments, I use Cusdis.
Why? Same reason as before: keep it simple.
What Will I Write About?
At first, I thought having mixed content wouldn’t be a problem. But imagining myself rereading my own posts later, jumping from game development, to spatial data, to Blender 3D tutorials, felt like riding an emotional roller coaster.
So I decided this blog will mainly focus on game development, with other topics acting more like side dishes.
The game dev content will include:
- Ideas for games I want to build
- The technology I use (like this article)
- Development progress and devlogs
- Occasionally, thoughts about games I play~or don’t play (basically games outside my own projects)
The second type of content is the blog itself: its development progress, features I’m building or planning, and how I envision its future.
Depending on my mood, I might also write about life motivation, yearly resolutions, fitness progress, traveling, or random ideas unrelated to game dev. Those will probably be less frequent… though I can’t really guarantee that.
In the end, reading this blog might feel incredibly boring.
But leaving a comment would definitely motivate me more~
even though there’s no guarantee I’ll approve it. 😛