Posts

Showing posts from 2026

Stop Making Platformers First

A lot of indie games start as prototypes. You make something small, it feels fun, someone plays it, and suddenly the idea appears: maybe this could become a real game. That is not a bad thing. My first Steam game, Frogo Jump, also started like this. It was a fun prototype first, and later I turned it into a full commercial game. But this article is not really about prototyping itself. It is about the moment after the prototype. The moment where you decide if this small idea should become a commercial release. In my opinion, this is where many beginner indie developers make the wrong decision, because they only ask if the prototype is fun. They do not ask if the game has a market. Jump to section Prototypes are easy. Commitment is hard. The platform is the market. Stop making platformers for Steam. If you make PC games, study Steam. Make your Steam page early and collect wishlists. Use festivals to get more wishlists. Also remember the cost of releasing....

PlayerPrefs vs JSON Saves in Unity

Image
When I was building Frogo Jump, my first released Unity game, I used PlayerPrefs for things that I probably should not have used PlayerPrefs for. At the time, it made sense to me. I was still learning Unity, and many beginner tutorials used PlayerPrefs whenever they needed to save something. So when I had a problem where I needed to remember a value, my beginner brain went: okay, PlayerPrefs saves things, so I will use PlayerPrefs. It worked, but it was messy. The bigger lesson I learned later is that not all game data is the same. Some data should only exist while the game is running. Some data should stay on the player's device as a setting. Some data is real save data and should be part of a proper save file. Mixing all of that into PlayerPrefs can work for a while, but it makes the project harder to understand and harder to clean up later. View Frogo Jump on Steam The Frogo Jump problem ...

Building a Country Higher or Lower Game

I Built a Country Higher or Lower Game with JavaScript and Country Data I recently built a small browser game called Country Higher or Lower. The idea is simple: the game shows two countries, one population is visible, and the player has to guess whether the other country has a higher or lower population. This project is based on a similar idea to my Pokémon Higher or Lower game, but it feels different in practice. Pokémon stats are fun if you know Pokémon, but countries are much more general. Almost everyone understands the concept immediately. You see two countries, compare them, and make a guess. That is why I think this version works well as a small browser game. It is clean, fast to play, and easy to understand. The player does not need to read a long explanation before starting. The game can be played directly in the browser, and it also works on mobile. You can play the game here: Country Higher or Lower Game The source code is available here: Country Higher or L...

How to Embed a GitHub Pages Project in Blogger

How to Embed a GitHub Pages Project in Blogger One of the most useful things I learned while building small web projects is that you can host a project on GitHub Pages and then embed it directly into a Blogger post or page. This is especially helpful if you are making small tools, browser games, JavaScript experiments, generators, calculators, or interactive pages. Instead of only writing about the project, you can let people try it directly on your blog. For example, I use this workflow for some of my own web tools. I build the project with HTML, CSS, and JavaScript, publish it with GitHub Pages, and then place it inside a Blogger page using a simple iframe. What you need To embed a GitHub Pages project in Blogger, you need three things: A working GitHub Pages project A Blogger post or Blogger page A little bit of HTML knowledge You do not need a complex setup. The main idea is simple: GitHub Pages hosts the actual project, and Blogger displays it inside y...

How to Use APIs in a Web Game (Pokémon Example with JSON Optimization)

I built a simple browser game where you compare two Pokémon and guess which one has higher total stats. The idea is simple: you see two Pokémon, choose the one you think is stronger, and then the game checks the real data. The project started as a small JavaScript game using the PokéAPI. At first, the game fetched new Pokémon data directly from the API during gameplay. That worked, but it also created a scaling problem. Every round needed new API requests, and every player would create more requests. To fix that, I changed the project so the game uses a local JSON file instead. The API is still used, but only once during the data-building step. During gameplay, the game loads the prepared JSON file and runs almost completely locally in the browser. Play the Pokémon Higher or Lower Game View Source Code Overview The earlier random Pokémon generator The first approach: fetching data per round ...

Pokémon Higher or Lower Game in JavaScript (From Generator to Game)

Image
I Turned My Old Pokémon Generator Into a Higher or Lower Game I recently made a small Pokémon Higher or Lower game, and the idea for it actually came from something I built a long time ago. A few days ago I realized that I can embed my GitHub projects directly into my Blogger site. That made me go back and look through some of my older projects, and one of them was my random Pokémon generator. That project is already a few years old, maybe two or three years, but it still works. It was also a good base to build something new on top of, because it already had the basic idea: pick a Pokémon, get data from the PokéAPI, and show it on the page. I wanted to make something simple and fun. Not a big project, not a full game with lots of systems, just something small that I could finish quickly and embed on the blog. The idea that came to mind was a classic Higher or Lower game. It fits really well with Pokémon because every Pokémon has stats, so you can compare them in a way th...

CD-R vs CD-RW: What’s the Difference and Which Should You Use?

When you want to start burning your own CDs, you will quickly come across two types of discs: CD-R and CD-RW. At first, CD-RW sounds like the better option because it can be reused. But for most people, especially if you want to make music CDs, CD-R is usually the better choice. The main difference is simple: a CD-R can only be burned once, while a CD-RW can be erased and rewritten multiple times. That makes CD-RW more flexible, but it also comes with some downsides. What is a CD-R? CD-R stands for Compact Disc Recordable. It is a write-once disc. Once you burn data or music onto it, the disc cannot be erased and used again. A CD-R uses a photosensitive dye layer inside the disc. When the burner writes to the disc, the laser changes parts of that layer and creates differences in reflectivity. A CD player or computer drive can then read those differences as data. Canon has a good technical explanation of this process. They describe CD-Rs as using an organic dye layer, whe...

Are CDs Making a Comeback? Why Physical Music Feels Personal Again

Image
Lately I’ve been getting more into Y2K stuff again. Mostly the aesthetic, some fashion, but also the general feeling from that time. One thing that keeps showing up in that world is CDs. Old CD players, stacks of blank discs, burned playlists, shiny cases, handwritten tracklists, and people showing their collections. It reminded me of how normal it used to feel to make your own CDs. You would choose songs you liked, burn them onto a disc, maybe write something on the cover, and suddenly it felt like a real object. I had not thought about that in years. So I started wondering: are CDs actually making a comeback, or do they just feel interesting again because everything digital has become so temporary? Are CDs really coming back? I do not think CDs are suddenly replacing streaming. Streaming is still the easiest and most common way to listen to music. You open an app, search for a song, and it is there instantly. But I also do not think CDs feel complet...