Tuesday, May 12, 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.

Prototyping is one of the most fun parts of game development. You test a mechanic, you move a character around, you add a few objects, and suddenly something works. It feels alive. It feels like a game. This is why prototyping is so important. You learn fast, you test ideas, and you can find out if a mechanic feels good before you build a whole world around it.

But the prototype itself is not the hard part. The hard part is commitment. Most people do not fail because they cannot make a prototype. A lot of people can make prototypes. They fail because they do not know what to do after that. They do not know if the prototype is worth finishing, if the game has a market, or if the platform they are aiming for even wants this kind of game. And sometimes stopping is the right decision.

Not every prototype has to become a full game. Not every fun idea has to become a commercial product. Some prototypes are just learning projects. Some are experiments. Some are useful because they teach you something, not because they should be sold. I still think you should make prototypes. Make a lot of them. Even make platformers if you want to learn. Platformers are great for learning movement, physics, level design, collision, camera systems, and game feel. But learning projects and commercial games are not the same thing.

The platform is the market.

Before you commit to a commercial game, you need to understand the platform you are aiming for. A game is not just a game. A game on Steam is different from a game on mobile. A game on Nintendo Switch is different from a game on itch.io. A game on Epic Games is different from a game on Steam. The platform is not just the place where you upload the game. The platform is the market.

Different platforms have different players. They have different expectations, different buying habits, different genres that work better, and different ways of discovering games. If you make a commercial game, you need to know where that game belongs. You need to know who it is for. You need to know how people will find it. This is the part I did not understand enough when I made Frogo Jump. I thought more like a developer. I made something fun, and then I tried to release it. But I did not think enough about the platform, the audience, the genre, or the market before committing to it.

Stop making platformers for Steam.

If your goal is to make your first commercial game for Steam, then in my opinion, stop making platformers. I know this sounds harsh. I also made a platformer. Frogo Jump is a precision platformer. So I am not saying this from the outside. I made the same decision. But after releasing a platformer on Steam, I would not recommend it as a first commercial release.

Platformers are oversaturated. Puzzle games are also oversaturated. Every day, many games release on Steam, and so many of them are platformers or puzzle games. We do not need more. Even if your platformer is good, people still have to find it. And that is the problem. If there are too many similar games, being good is not enough. Your game can be fun and still disappear.

This is not just a feeling either. How To Market A Game has written a lot about genre choice on Steam, and one of the big lessons is that the genre you choose is already one of your biggest marketing decisions. In one article, Chris Zukowski points out that platformers are hard to market on Steam and that the platformers that do better often have another stronger genre attached to them, like roguelike or metroidvania. In another analysis, puzzle and platformer games are described as some of the least performant genres, while the number of puzzle games and platformers had increased. You can read more about that here: More evidence of which genres Steam shoppers love to play and here: What the hell happened in 2025?.

In my opinion, Steam players do not really like platformers that much. They like other types of games more. They buy other types of games more. They get more excited about other types of games. Of course, there are successful platformers. Of course, there are amazing platformers. But that does not mean platformers are a good first commercial choice for an unknown solo developer on Steam. The problem is not only quality. The problem is visibility.

I understand why so many beginner developers make platformers anyway. Platformers are easy to start. There are many tutorials for them. If you learn Unity, one of the first things you often build is a character that runs and jumps. You use the physics engine, you add collision, you place platforms, and suddenly you have something that feels like a game. Platformers are also familiar. Most game developers are gamers. Many of us grew up with platformers. We know how they work. We understand jumping, enemies, checkpoints, coins, levels, and bosses. So it feels natural.

Puzzle games have a similar problem. They look manageable. You can make them with simple graphics. You can focus on the mechanic. They seem like a good solo developer genre. But easy to start does not mean easy to sell. This is the trap. The genre that is easiest to prototype is not always the genre that makes the most sense commercially.

I am not saying platformers should never exist. I like platformers. I made one. You can still make one if that is what you really want to make. But then you need to think about the right platform. From what I have heard, platformers may work better on Nintendo Switch than on Steam. That makes sense to me. Nintendo has a different audience. Platformers fit better into that ecosystem.

But releasing on Nintendo is not as simple as uploading a game to a store. You need developer access and platform approval. Nintendo says that the Nintendo Developer Portal is for all Nintendo developers, regardless of size or experience, and that registering for the portal and downloading tools is free. But Nintendo also says that development hardware still has to be acquired and that more information about that is inside the portal. You can read Nintendo’s own FAQ here: Nintendo Developer Portal FAQ.

If you use Unity, like I do, there is another thing to think about. Unity says that for Nintendo Switch development, you need to register as a Nintendo developer, apply for the closed console platform, get the platform support add-on, test on platform hardware, optimize the game, go through the platform testing process, and release. Unity also says that you need an active Unity Pro subscription or a Preferred Platform license key from the platform holder to access these specific build modules. You can read Unity’s own page here: Unity for Nintendo Switch.

This is why I would not call Nintendo the easiest option for a solo developer like me. Maybe platformers fit better there, but you still have to deal with approval, tools, hardware, licensing, testing, certification, and the extra work of supporting a console platform. So yes, maybe platformers can work better somewhere else. But then you have to plan for that from the beginning. If you make a platformer and your only real plan is Steam, then I think you should seriously reconsider it.

If you make PC games, study Steam.

If you make PC games, Steam is the platform you have to understand. You can release on other platforms too. You should not ignore itch.io, Epic Games, GOG, or other stores. They can still be useful. They can bring extra sales, extra visibility, or another place where people can find your game. But if your game is a PC game, Steam is probably still the main target.

This means you have to study Steam. You have to understand how Steam pages work, how wishlists work, how tags work, how festivals work, how demos work, and what kind of games Steam players actually want. A useful website for this is How To Market A Game. The main lesson I take from that site is that marketing does not start after the game is finished. Marketing starts with the type of game you choose to make.

Steam is not magic. Steam can help you, but it cannot save a game that nobody wants to click on. It cannot magically make an oversaturated genre easy. It cannot fix a game that has no clear audience. Steam is a powerful platform, but you still need to bring the right game to it.

Make your Steam page early and collect wishlists.

If you know that your prototype is becoming a real commercial game, make your Steam page as early as possible. Do not wait until the game is almost finished. Do not wait until release month. Do not finish the whole game and then suddenly think about marketing. Make the page early.

You do not need the full game. You need enough to show what the game is. You need footage, screenshots, a good description, and a clear idea. As soon as you can show the core of the game, the Steam page should exist. Steam itself says that it is useful to put up a coming soon page once you are far enough to show screenshots and describe the core of your game. You can read more about this in the official Steamworks page about Steam marketing tools.

The reason this matters is wishlists. On Steam, wishlists are one of the most important numbers. A wishlist is not a sale. Not everyone who wishlists your game will buy it. Some people wait for discounts. Some people forget. Some people wishlist too many games and never buy most of them. But without wishlists, your launch is much weaker.

Wishlists give your release a starting point. Steam explains that players who wishlist your game can receive notifications when the game releases or when it has a qualifying discount. That means your launch is not just you posting into nothing. You have a group of people who already showed interest before release. You can read more about this in Steam’s official page about wishlists.

This is why you need to collect wishlists before launch. You need social media. You need a demo if possible. You need festivals. You need people to see the game before it comes out. If you launch with no wishlists, you are basically hoping that people randomly find the game on release day. That is not a strategy.

Use festivals to get more wishlists.

Festivals are one of the best ways to get real exposure and more wishlists. There are many game festivals during the year. Some are on Steam. Some are outside of Steam. Some are for specific genres, countries, themes, or communities. If your game fits a festival, you should try to apply.

When I look at the statistics for Frogo Jump, the biggest wishlist increase came from Games Made in Germany. It still was not enough to make the game successful, but it showed me that festivals can actually move the numbers. Festivals are useful because the audience is already looking for games. That is different from posting on social media, where most people are not actively searching for a new indie game to buy.

Steam Next Fest is probably the biggest festival target for many indie developers on Steam. But you can only participate in one Steam Next Fest with a game, so you need to choose the right one. Steam says titles may only participate in one Next Fest, the base game store page has to be public, and the game needs a publicly playable demo by the time Next Fest begins. You can read the official rules here: Steam Next Fest documentation.

In my opinion, you want to enter Steam Next Fest with as many wishlists as possible. How To Market A Game also recommends doing the last Steam Next Fest before launch, because visibility scales with the number of wishlists you have going into it, and because your demo should already be tested and polished before the event. You can read more here: Frequently asked questions about Steam Next Fest.

Steam Next Fest can be huge, but it is not a magic button. It works best when you already prepared the game, the Steam page, the demo, the screenshots, the trailer, and the marketing. Then the festival can multiply what is already there.

Also remember the cost of releasing.

Releasing a game also costs money. On Steam, you have to pay the Steam Direct fee. At the time of writing, Steam lists this as a 100 dollar fee for each new app you want to distribute. You can read the official Steamworks page about the Steam Direct fee.

And that is only one part. Steam also takes a cut from your revenue. After that, you still have taxes. You might also have asset costs, tool costs, music costs, localization costs, trailer costs, or other expenses. So when you sell a game, the full price is not the money you keep. This is another reason why the genre decision matters. If the game has a very low chance to sell, then even small costs become harder to justify.

When should you commit to a prototype?

This is the real question behind the article. When should a prototype become a commercial game? In my opinion, not just because it is fun. Fun is important, but it is not enough. You also need to know the platform, the audience, the genre, the competition, and the marketing path.

Before you commit, ask yourself who the game is for, where these players will find it, if the genre works on the platform you are aiming for, if the genre is oversaturated, if you can show the hook in screenshots or short videos, if the game can get wishlists, and if there are festivals where the game fits. These questions are not as fun as prototyping. But they are important.

What I learned from Frogo Jump.

I do not regret making Frogo Jump. It was my first released Steam game, and I learned a lot from it. I learned how to finish a game, how to release on Steam, how wishlists work, how festivals work, how hard marketing is, and how different a finished product is from a prototype. You can find the game here: Frogo Jump on Steam.

I also collect my games, browser tools, and coding experiments on Kami Media. If you want to see more of my projects, you can check out my project page here: Kami Media projects.

That experience was valuable. But if I could go back, I would not choose a platformer as my first commercial Steam game. I would still make the prototype. I would still use it to learn. I would still have fun with it. But I would think much harder before turning it into a commercial release.

That is the message of this article. Make prototypes. Learn from them. Have fun with them. But when you decide to make a commercial game, stop thinking only like a developer. Think about the market too.

Sources and useful links

at No comments:
Labels: ,

Friday, May 1, 2026

PlayerPrefs vs JSON Saves in Unity

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

Frogo Jump has an overworld map. On that map, there are level dots. The player moves between those dots, and when the player enters one of them, the game loads the actual level scene.

Frogo Jump overworld map showing level dots used to enter different levels

The important part is what happens afterward.

If the player leaves the level and returns to the overworld, they should come back to the same level dot. Otherwise, the overworld would load again and the player could appear at the start of the map instead of the place they came from.

So the game needed to remember the last overworld position before loading the level.

As a beginner, I solved this with PlayerPrefs. I saved the position before entering the level, then loaded it again when the overworld scene came back.

Technically, this can work. But the problem is that this position was not really permanent save data. It was not a setting either. It was just temporary scene transition data.

I did not need to write that value permanently to the player's device. I only needed to carry it from one scene to another while the game was still running.

What PlayerPrefs are actually for

PlayerPrefs are useful, but the name already tells you the intended use: player preferences.

Unity describes PlayerPrefs as a class that stores player preferences between game sessions. It can store strings, floats, and integers. That makes it useful for small local values like volume settings, fullscreen mode, language choices, or other simple settings.

Settings are also usually device-specific. If I play a game on my desktop PC and set the music volume to 30%, I do not necessarily need that exact setting on another device. Maybe my laptop speakers are quieter, so I want a different volume there.

That is a good use case for PlayerPrefs. The value is small, local, and simple.

But game progress is different. Checkpoints, unlocked levels, inventories, collected items, quest states, and save slots are not just preferences. They are part of the player's progress. That kind of data should be handled more intentionally.

PlayerPrefs are also not always easy to inspect like a normal save file. Depending on the platform, Unity stores them in different places. On Windows, for example, PlayerPrefs are stored in the Windows Registry. On WebGL, Unity uses the browser's IndexedDB. That is fine for preferences, but it can become annoying when you accidentally use PlayerPrefs for the wrong kind of data and then need to reset or debug it.

Unity also notes that PlayerPrefs are stored locally without encryption, so they should not be used for sensitive data.

Source: Unity PlayerPrefs documentation.

The better solution for temporary scene data

For the Frogo Jump overworld position, I would not use PlayerPrefs today.

I would use a GameManager that stays alive between scenes. In Unity, this is commonly done with DontDestroyOnLoad. Unity's documentation explains that scene loading normally destroys current scene objects, but DontDestroyOnLoad can preserve a root object during scene loading.

That is useful for this kind of problem. The data does not need to be written permanently to the device. It only needs to stay available while the game moves from the overworld scene into a level scene and then back again.

Many projects use a singleton-style GameManager for this. The point is not that every project must use one giant manager for everything. The point is that one persistent object can hold small pieces of temporary state while scenes change.

A simple GameManager for this problem could look like this: 

using UnityEngine;

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    public Vector3 LastOverworldPosition { get; private set; }
    public bool HasLastOverworldPosition { get; private set; }

    private void Awake()
    {
        if (Instance != null && Instance != this)
        {
            Destroy(gameObject);
            return;
        }

        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void SetLastOverworldPosition(Vector3 position)
    {
        LastOverworldPosition = position;
        HasLastOverworldPosition = true;
    }

    public void ClearLastOverworldPosition()
    {
        HasLastOverworldPosition = false;
    }
}

Before loading a level from the overworld, the game could store the current position like this: 

GameManager.Instance.SetLastOverworldPosition(player.transform.position);

When the overworld scene loads again, the player can be placed back at that position: 

if (GameManager.Instance.HasLastOverworldPosition)
{
    player.transform.position = GameManager.Instance.LastOverworldPosition;
}

This is not a full save system. It is not supposed to be one. It is just a clean way to pass temporary data between scenes.

That distinction matters a lot.

Source: Unity DontDestroyOnLoad documentation.

Temporary data, settings, and real save data

The mistake I made was not simply “using PlayerPrefs.” The mistake was treating every kind of data as if it belonged in the same place.

The overworld position in Frogo Jump was temporary data. It only mattered because the player moved from the overworld scene into a level scene and then back again. It did not need to survive forever. It did not need to be part of a save slot. It just needed to survive a scene change.

Settings are different. A music volume setting should still be there after closing and reopening the game. It makes sense for that to be stored locally on the device.

Real save data is different again. If the player unlocks World 3, finishes Level 12, collects an item, or reaches a checkpoint, that is actual progress. That should be stored in a proper save system, not scattered across random PlayerPrefs keys.

The simple mental model is this:

PlayerPrefs are for local preferences. GameManagers are useful for temporary runtime data. JSON save files are better for structured game progress.

Once I understood that separation, save systems started to make much more sense.

Why JSON is better for real save data

If I were building Frogo Jump again, I would separate real progress into a structured save file.

A JSON save file is a common way to do that in Unity because it lets you define a structured data object and convert it into a text-based format. Unity's JsonUtility can convert objects to JSON and back again, as long as the data follows Unity's serialization rules.

Instead of having many separate PlayerPrefs keys, you can create a class that represents the save file. 

using System;
using System.Collections.Generic;

[Serializable]
public class SaveData
{
    public string currentWorld;
    public int highestUnlockedLevel;
    public int coins;
    public List<string> collectedItems = new List<string>();
}

This is easier to understand than spreading the same data across many keys. 

PlayerPrefs.SetInt("Coins", coins);
PlayerPrefs.SetInt("HighestUnlockedLevel", highestUnlockedLevel);
PlayerPrefs.SetString("CurrentWorld", currentWorld);

The PlayerPrefs version is not automatically wrong for a tiny prototype, but it becomes messy as the game grows. With a JSON save file, the save data has a shape. You can see what belongs to the save. You can create save slots. You can delete a save file. You can back it up. You can later connect it to a cloud save system if the game needs that.

That does not mean every game needs a giant save system. A small arcade game might only need a high score. But once a game has worlds, level progress, checkpoints, items, or unlocks, a proper save structure becomes much cleaner.

Sources: Unity JSON Serialization manual, Unity JsonUtility.ToJson documentation, and Unity JsonUtility.FromJson documentation.

What should be cloud saved?

Cloud saves are another reason why it helps to separate data early.

Steam Cloud is designed to store game files on Steam's servers so players can log into Steam and access their saved games from another computer. That makes it useful for real progress data, like save slots, unlocked levels, completed worlds, collected items, or other important player progress.

But that does not mean every local setting should be treated like cloud save data. A laptop and a desktop PC can need different resolution settings, graphics settings, or audio volume. Those are local preferences, so keeping them local often makes sense.

That is why I would not think of PlayerPrefs as “bad.” I would think of them as local preference storage. The problem starts when PlayerPrefs become the place where everything goes.

Source: Steamworks Documentation: Steam Cloud.

The rule I would use now

If I were building Frogo Jump again, I would separate the data like this.

Music volume, fullscreen mode, resolution, and language would go into PlayerPrefs because they are local settings.

The overworld position before entering a level would go into a singleton GameManager because it is temporary scene transition data.

Completed levels, unlocked worlds, collected items, coins, and checkpoint progress would go into a structured save file, probably JSON for a small Unity game.

If I later added cloud saves, I would sync the real save files, not every local preference.

This is the main lesson I took from the mistake: saving data is not just about storing a value somewhere. It is about understanding how long that value should exist and what kind of data it really is.

Final thoughts

PlayerPrefs are useful. I just would not use them as my whole save system anymore.

For a beginner Unity project, it is very tempting to put everything into PlayerPrefs because it is easy and many tutorials show it early. I understand why I did it in Frogo Jump. I needed a solution, and PlayerPrefs gave me one quickly.

But after finishing a real game, I can see the problem more clearly. The better approach is to separate temporary data, local settings, and permanent progress from the beginning.

That makes the project easier to debug, easier to reset, and easier to expand later.

Related

Frogo Jump: My first finished Unity game

View Frogo Jump on Steam

View all projects

Sources and further reading

at No comments:
Labels: ,
Subscribe to: Posts (Atom)

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 ...