Yigithan Guven

We Need Less Demanding, More Minimalist Games

2026-07-17T00:00:00+00:00

Most people I know are still using laptops, computers, and consoles they bought around 2021 or 2022. Their hardware still works, but replacing it has become much more expensive.

AI is not another short crypto rush. It is going to stay, along with its demand for GPUs, memory, and storage. Hardware companies now have customers willing to pay much more than regular players, so I do not think prices will ever return to what we once considered normal.

At the same time, games continue to require more RAM, more VRAM, faster graphics cards, and larger amounts of storage.

I love graphics and rendering technology. I do not want games to stop looking better or using new technology. The problem is that fewer people may be able to afford the hardware needed to experience that progress.

Developers should prepare for this instead of assuming everyone will eventually upgrade.

Efficiency Is Progress</h2>
Games are becoming extremely large while SSDs remain expensive. Even hard drives no longer feel like the simple and cheap solution they once were.
This makes optimisation, compression, texture management, asset streaming, and scalable settings more important. Running the same game on weaker hardware without destroying the visuals should also count as technological progress.
I appreciated the approach taken with Battlefield 6. It did not treat an absurd installation size as unavoidable. It is still a modern and visually impressive game, but storage and optimisation were clearly considered.
Its use of Godot for Battlefield Portal tools is also interesting. The main game is not made with Godot, but seeing the engine used for modding tools in a large production shows that it can be useful beyond small indie games.

Technical Minimalism</h2>
Minimalism does not mean bad graphics or empty games. It means choosing what is actually needed.
Not every texture needs the highest possible resolution. Not every surface needs a realistic reflection. Not every game needs a massive open world. A feature should add something meaningful to the gameplay, atmosphere, readability, or visual identity.
The same idea applies to game design. More mechanics and more content do not automatically create a better game. Every new system brings more bugs, testing, balancing, and development work.
Minimalism means choosing what matters and giving it enough attention.
Strong art direction can often achieve more than raw complexity. This is especially important for solo developers and small teams that cannot compete with large studios through the amount of assets or content they produce.

Trying to Build My Own Framework</h2>
Before choosing Godot, I tried creating my own game framework.
I still like custom engines. I enjoy graphics programming, engine architecture, and having control over the technology.
I especially like Frontier’s engine and the tools they use for creating landscapes and paths. Their tools seem designed around the large environments and simulation games they make. This is one of the biggest advantages of a custom engine. The technology can be built around the actual needs of the game.
However, I quickly realised that building an engine and building a game are separate projects.
A framework needs rendering, asset loading, scene management, debugging, tools, serialization, and platform support. After building all of that, the actual game still needs to be made.
When I looked at experienced solo developers creating custom engines, I noticed that many were mainly building the engine itself. Others had spent years working on their technology or had larger teams behind them than I first thought.
There are exceptions, but doing both is extremely demanding.
I still want to learn graphics and engine development, but I also want to finish a game.

Why I Chose Godot</h2>
Godot gives me a balance between control and productivity.
It is lightweight, fast, and easy to iterate with. I can focus on gameplay systems, balance, level design, UI, and the overall direction of the game without building every basic tool myself.
It is also open source, so I can inspect and extend it when necessary.
Godot works well with the agentic coding tools I use. Its scripts and project files are readable, so I can inspect changes and understand what the agent has done. Agents help with repetitive work, debugging, testing, and faster iteration.
However, I never let AI control the direction of development. I keep the architecture, priorities, and design decisions in my own hands.
Koshy John explains this well in AI Should Elevate Your Thinking, Not Replace It</a>. AI can support the work, but it should not own the thinking behind it.
Godot fits the kind of development I want to do. It gives me enough control to experiment with game technology without turning engine development into the whole project.
I still care about graphics and new rendering techniques. I just do not want to build around the assumption that every player will keep buying more expensive hardware.
I want to learn how to create better looking games without making them unnecessarily heavier. For now, Godot feels like the right place for me to explore that.

Helium Browser Appreciation Post

2026-05-28T00:00:00+00:00

I have been using Helium for almost 8 months and I am loving it. I was a long-time Edge user, but after the slopification started, I went looking for a better browser.

First I tried Zen, it was really good but the performance isn’t the same and it’s especially noticeable on older hardware. I didn’t have fun with Brave and Vivaldi either too much slop, useless pushed features. No, I don’t want a calendar, contacts, RSS feed, crypto wallet, or Copilot in my browser.

Then I found Helium. Pre-configured ad blocking with community filters is such a welcome feature. No fingerprinting option, minimalist, no bloat. I love compact mode, and if I have to deal with too many tabs I switch to vertical tabs then go back to compact mode. Bangs for quickly navigating and searching different sites are great too.

I love minimalist software and Helium really delivers. It is minimal but not lacking — it has only the features that actually matter for browsing, not unnecessary extras like other browsers push.

Being in alpha, issues are expected. I did run into a few at first — sometimes sites triggered Cloudflare bot checks too often, and I even couldn’t access some sites when it happened frequently. That was mostly in the early days though and hasn’t been a problem for months.

More recently I had a gray screen appear after minimizing and restoring the window, but it’s been rare. Even with that, it’s still far better than dealing with bloated browsers.

For wishlist features, I’d love:

An official Fedora/DNF package</li>
Windows auto-updates support</li>
Auto-hide toolbar option</li>

Option to completely remove left/right borders for a cleaner minimal look</li> </ul>

Original Reddit post: View source</a>

I Spent Hours Automating a 0.5 Second Task (And It Was Worth It)

2025-09-16T00:00:00+00:00

You know that bone-deep exhaustion from doing the same tiny task over and over? Yeah, I got tired of manually switching between my Speakers and 3.5mm headphones every time I boot up.
It’s not that I forgot. It’s that I’m lazy and got sick of clicking the same two buttons every single day.
So naturally, I did what any reasonable developer would do: spent an entire evening building an automation script to save myself 0.5 seconds of clicking.
The Problem</h2>
My setup is simple:

Daytime: Logitech 2.1 speakers connected through my display</li>
Nighttime: Headphones for those considerate late-night sessions</li> </ul>
But manually switching got old fast. Boot up at 10 PM and have to switch to headphones. Boot up at 8 AM and switch back to speakers. Every. Single. Time.
Nah, I’m done with that.
The Solution: Peak Developer Behavior</h2>
Built a bash script that runs at login and automatically switches based on time:

10:00 AM - 12:00 AM: Speakers for daytime productivity</li>
12:01 AM - 9:59 AM: Headphones for quiet night sessions</li> </ul> # The core logic is beautifully simple current_hour=$(date +%H) if [ $current_hour -ge 10 ] || [ $current_hour -eq 0 ]; then target_device="$HDMI_DEVICE" # Speakers else target_device="$ANALOG_DEVICE" # Headphones fi </code></pre> The Technical Bits (Because I Went Overboard)</h2> Of course I couldn’t just write a simple script. It had to be bulletproof: Waits up to 45 seconds for PipeWire to initialize (because audio systems are moody)</li> Handles device detection and graceful failures</li> Moves existing audio streams to the new device</li> Logs everything to debug when things inevitably break</li> Uses lock files to prevent multiple instances</li> Shows desktop notifications because why not</li> </ul> The script is way smarter than it needs to be. Classic over-engineering. Was It Worth It?</h2> From a time perspective? Absolutely not. I’ll never recoup those hours. From a “my computer now reads my mind” perspective? Hell yes. Every boot, the right audio device is just there. No thinking, no clicking, no repetitive strain on my clicking finger. That’s the beauty of personal automation projects. They’re rarely about efficiency. They’re about that tiny dopamine hit when your environment just works the way you want. The Code</h2> Threw it on GitHub</a> for anyone else who’s tired of clicking buttons. It’s heavily commented because future me will forget how any of this works. Works on any Fedora system with PipeWire or PulseAudio. Just update the device names for your hardware. What’s the most ridiculous thing you’ve automated to avoid a simple manual task? Please tell me I’m not alone in this madness.
Omarchy: My Fastest and Most Beautiful Dev Setup Yet 2025-09-15T00:00:00+00:00 I recently tried Omarchy, the Arch-based distro made by DHH (creator of Ruby on Rails), and I’m honestly blown away. This isn’t just Arch preinstalled with a few packages — it’s a complete, curated system. Omarchy comes with Hyprland, LazyVim, and an entire development setup ready to go — but what impressed me most is how effortless everything feels. The configuration and setup experience is smooth, consistent, and genuinely enjoyable. And the best part? It’s a single ISO install that sets up a complete development environment, and a keyboard-driven workflow in minutes. You don’t spend hours configuring like you would with vanilla Arch — you reboot, log in, and you’re ready to work. For now, I installed Omarchy on my thinkpad, and I’m not ready to switch my Fedora desktop just yet. Fedora is still my main machine, and I keep Windows around for two things I can’t replace: NVIDIA GPU performance — my RTX 3080 runs at full speed and drivers are far more stable and performant in Windows than on Linux.</li> Microsoft Visual Studio — for some C++ projects, Visual Studio and its build tools are still the most reliable and convenient choice.</li> </ul> My Current Setup. Omarchy even comes with cool screen savers. (Just Ignore the cables i hade to replace one of them recently 😱) Even so, Omarchy might be the most exciting development setup I’ve tried. It feels like a hacker’s dream machine, right out of the box, and I love how easy it is to configure and make my own. By the way, this site you’re reading is built with Zola, the Rust-based static site generator, using the Tabi theme — fast, clean, and perfect for sharing posts like this. Why does the Quest 2 Unity Application open in window mode instead of VR mode? 2022-11-18T00:00:00+00:00 There are several reasons why the Unity application may open in window mode on Meta Quest 2. This issue can be particularly frustrating when updating apps on platforms like Oculus App Lab. If your application is functioning in window mode, consider the following troubleshooting steps: 1. XR Plug-in Settings</h2> Navigate to Edit > Project Settings > XR Plug-in Management in the Unity Editor. Ensure the following settings are configured: Enable “Initialize XR on Startup” for both Android and PC tabs.</li> Check the Oculus option under both Android and PC tabs.</li> </ul> 2. OpenXR Settings</h2> Within the XR Plug-in Management settings, access the OpenXR settings tab. Verify that Oculus Quest Support is enabled in the OpenXR Feature Groups. 3. Target Platform Configuration</h2> Ensure that the Unity target platform is set to Android for Oculus Quest 2 development. Navigate to File > Build Settings > Player Settings and confirm that Android is selected as the target platform. 4. Console Errors</h2> Check the Unity Editor console for any errors related to XR plugins. Addressing these errors can resolve issues with VR mode initialization. 5. Testing with Oculus Link</h2> Consider running your application in Play mode using Oculus Link to test its functionality in VR mode. By following these steps, you can ensure that your Unity application launches directly into VR mode on Meta Quest 2, providing a seamless experience for users.

Yigithan Guven

We Need Less Demanding, More Minimalist Games

Helium Browser Appreciation Post

I Spent Hours Automating a 0.5 Second Task (And It Was Worth It)

The Problem</h2> My setup is simple:</p>

The Solution: Peak Developer Behavior</h2> Built a bash script that runs at login and automatically switches based on time:</p>

Omarchy: My Fastest and Most Beautiful Dev Setup Yet

Why does the Quest 2 Unity Application open in window mode instead of VR mode?

2. OpenXR Settings</h2> Within the XR Plug-in Management</strong> settings, access the OpenXR</strong> settings tab.</p> Verify that Oculus Quest Support</strong> is enabled in the OpenXR Feature Groups.</p> </p>

2. OpenXR Settings</h2>
Within the XR Plug-in Management</strong> settings, access the OpenXR</strong> settings tab.</p>
Verify that Oculus Quest Support</strong> is enabled in the OpenXR Feature Groups.</p>
</p>