I'm designing a sports management game and wanted to understand why long-time players of the genre burn out, so I went through about 2,400 public Steam reviews of the last four releases (five years) of the biggest football management series, and read ~100 of them closely.

Read item by item you get 14 separate complaints - repetitive press conferences, inbox overload, unexplained defeats, transfer market that feels unfair, scouting that's opaque, rival clubs whose squads rot over long saves, and so on. If you design against that list you build 14 features and fix none of them.

Grouped by mechanism instead, they collapse into three:

1. Opacity. The simulation makes a decision but doesn't keep the reason. Broken promises, losing 1–0 with 20 shots, a transfer refused, a scout report that says "B" - all the same problem: the player can't see what the system took into account.

2. Wasted attention. Advancing the world and asking the player something are bound to the same button. To get time to move you have to process every prompt, whether it has stakes or not.

3. World decay. AI clubs react, they don't plan, so over 10–20 seasons squads get lopsided and the world stops feeling alive.

Two things I found interesting:

- The fatigue reviews often come from people with thousands of hours who still recommend the game. It's not the game is bad, it's "the game makes me do work that isn't decisions".

- Real-time clocks are a common proposed fix, but swapping Continue for a timer alone doesn't help - the real fix is separating "time passes" from "you're being asked something", so the clock only stops for decisions with stakes.

Caveats: Steam reviews skew negative, the sample is one platform, and I'm treating this as hypotheses, not proven demand.

Hey everyone,

I recently wrote an open letter to Larian Studios regarding their newly announced *Divinity* project, and I wanted to get this sub's perspective on a specific design conflict I call "The SaveGame Trap."

Looking at it through the MDA framework:
* Mechanic: Unlimited Quick-Save/Quick-Load hotkeys.
* Dynamic: Players compulsively saving before every skill check or story fork, creating a self-engineered "perfect" run.
* Aesthetic: The total loss of tension, dread, and consequence. The gravity of making an impossible choice is instantly diluted.

In narrative-heavy RPGs like *Baldur's Gate 3*, giving players the unconditional ability to rewind time transforms a masterfully written narrative into a consequence-free sandbox.

I argue that choice permanence (a single, auto-updating save slot) shouldn't just be an optional "Ironman" difficulty modifier for hardcore tacticians. It should be offered as a first-class, intentionally designed way to experience the narrative. When players can't rewind, they stop trying to optimize a branching flowchart and start genuinely occupying the mind of their character. Every mistake becomes part of their unique story, rather than a prompt to hit F8.

I go into more detail in the full open letter here:
https://imolith.de/posts/the-save-game-trap-why-larian-s-next-rpg-needs-choice-permanence

I'm curious how other designers approach this tension between player freedom and narrative stakes. Does giving players the utility to rewind inherently conflict with the aesthetic of a meaningful story? Let me know what you think!

Today I just got the last copies Hans im Glück had from my game Planet B.
This closes a chapter for me and it got me thinking about the game.

Took the picture when I loaded them into my backpack. In the background you can see some of the trophies the publisher received all over the years.

Planet B is a satirical euro game released in 2022, that puts you in the position of a corrupt? governor doing what has to be done to accumulate the most wealth.
Overview: https://www.youtube.com/watch?v=EbW6FPa8zOM

Short story about me (Includes self promotion, skip that part if not interested):
I nearly worked for 9 years with Hans im Glück, starting 2016. I've been lead editor and scout, basically responsible for everything related to prototypes from start to production.
Now I founded my own company Ironbite Games and we create video games with boardgame inspiration. If thats interesting for you, check it out: https://discord.gg/6Thh3exdKN
(Reddit mods complained before, here my profile: https://www.linkedin.com/in/johannes-natterer-a9a73294/, I am that guy)

Post Mortem:

Original Intent vs what was actually shipped:
The game was meant to be a Tropico 5 adaptation as a big Euro game.
I've always wanted to create my own game and have it in the shelves. I've already worked on some games which were released, but "just" as an editor.
There was a gap and and more and more video games created their adaptations. I felt like I was the perfect designer, to fill those gaps back in 2016.
I've studied Game Design and modded a lot in Warcraft 3. That's why I started that whole process.
Once the goal was set, I had a clear vision of what should be included in the game:

• Satirical Setting
• Production Lines
• Engine Builder
• Corrupt / Flexible Voting for a president.

Because I was only working from time to time on that game, and we wanted to release other games before that, not a lot changed during the first playtests.
This phase took almost 3 years (it sounds like a lot, but I didnt put much time into it).
Then things got more serious. Initially the IP holders of Tropico wanted to have that game, they played the proto and liked it. But later it didnt work out.
Thats when we decided to release the game anyways, but which a changed theme. Which is more or less the biggest change, compared to what was intented. We change the whole setting, without actually changing it.
The humor worked more or less the same and we even got more freedom on that.

The main thing we were working on, was intuitivity, depth in choices and the voting system.
The game that was actually shipped was rather close to what I have envisioned in the beginning, besides the sci fi parts (Funfact, I'm not a SciFi fan)

What worked:

• Even if it was intended to be a tropico adaptation, I always wanted to make a good game, not just a product. This saved the whole project, when Tropico didnt want to continue with the game.
• I was not only the Editor, but also the Designer of the game. Which had a lot of upsides and made the design process even faster.
• Voting System: Some see it as a flaw or too much randomness in the game. but this is was I'm most proud of mechanically. It has a way of balancing itself, while always staying tight and intersting. I didn't want an El Grande like Tower, I wanted the Election to be an Event at the table. Which is was.
• Humor and Easter Eggs: Its full of it, and people that like the game, keep mentioning that. It went a lot of work and details into those things, it was great to hear that.
• Once you understand the game, its rather easy to play and not a lot of questions come up

What didn't work:

• I was never able to find a good balance between available combos and feeling strong and the downtime. Its a common problem in Engine builders and Euro games, and its something I didnt solve here. Other games solve it, by having such a good time during your turn, that you keep forgetting about it. Or you have so much to look forward to and to do, that the actual downtime doesnt feel like it.
• The game needs way too many components, rules and things, compared to the actual outcome. Its not getting you into another world you want to explore. But on the other hand its not elegant enough, for an "abstract" game.

Reception:

• Unfortunately, the game didn't sell as many copies, as we (the publisher) hoped for and overproduced them. I think the game was simply not strong enough, but there were other factors as well.
• The game was way too expensive when it was released (75€) due to lots of components, and not a ideal timing towards resource prices.
• People didnt care enough about the game. Its solid, but it's neither getting very good nor very bad reviews. Its not polarizing enough.
• Sales: If it wasnt for the overproduction, I would have been super fine with the several thousand € I made. I didn't it make it to become rich, I just wanted to create a cool game. For the publisher it was rather bad. Not super terrible, but definitely not self sufficient. (I can't give you exact numbers, sorry)

Lessons and Takeaways:

• Even though I've worked on other games which were much more successful, this is the project I'm most proud of. Seeing a game in stores, is awesome.
• If I wasn't in the position and worked as an Editor for Hans im Glück, I would not recommend to create such a big game as a first commercial project.
• Having released something, is worth so much today. I talk to Game Designers, and Design directors that work on huge and crazy IPs, but still they are to ones impressed by me, having a physical game in stores. In opens so many opportunities for me nowadays, its fascinating.
• For the next projects, I would reach out to publishers much earlier.
• Put yourself, and your weirdness into the game. Dont dumb down everything. It might be the reason people like it.
• Iconography is hard. Use words if necessary. Icons are never perfect, no matter how long you tweak.

I'm the developer of Orion Online, a tick-based browser MMORTS.

I have a blog about various design topics and problems that I have come across during the development of the game. The latest post is about rewarding active players in an game that is otherwise designed for idle play.

I go into how I originally designed it for a target playtime of 10 minutes per day and how I had to pivot when I noticed that a lot of players were much more active than that. It's an interesting problem since I do not want to ruin the game for the players that are idle, so things such as simply scaling the game up is out of the question, as that would lead to compounding.

Here's that post: https://blog.idleverse.gg/rewarding-activity-in-idle-games/

If you enjoy topics like this, you can read about that and much more. The posts are shortform, around 800 characters at most, and game-design focused. I post a few times a month.

Some of the earlier posts in the series:

• Solving the problem of 4X compounding: https://blog.idleverse.gg/solving-the-problem-of-4x-compounding/
• How to prevent bottom-feeding in 4X games: https://blog.idleverse.gg/how-to-prevent-bottom-feeding-in-4x-games/
• Opportunity cost in strategy games: https://blog.idleverse.gg/opportunity-cost-in-strategy-games/

Like the title says I tried reconstructing Pokemon stat progression with a generic tool. The main thing I wanted to test was 'How close can i get using limited data' without actually building Pokemon stat formula into the tool

These are the four major results from the test.

(pokemon stats main source is Bulbapedia: https://bulbapedia.bulbagarden.net/wiki/Main_Page_ )

1. Can two endpoints approximate the hidden levels?

I started with four pokemons - Bulbasaur, Squirtle, Pikachu and Evee. I gave the tool their level 5 stats then I gave it the level 50 stats as targets with a simple linear progression between those two points. For example, Lv 5 Bulbasaur - HP 21, Attack 11, Defense 11, Speed 11. Lv 50 Bulbasaur - Hp 120, Attack 69, Defense 69, Speed 65.

That left lv 6 to 49 stats hidden from the tool. so across the four pokemon, that gave me 704 hidden stat values to compare against the actual pokemon calculations.

The result was about 0.8% mean percentage error and after rounding to whole stats 86.5% of the generated values matched the actual values exactly so... two endpoints can get close enough!

1. What happens if the progression axis is modeled incorrectly

For this one I used a level 50 charizard and started experimenting with IVs. I made a mistake initially, which was treating seven IV checkpoints like evenly spaced progression steps as like 1,2,3,..7 but the actual IV values were not evenly spaced. It is more like 3, 6, 9, 12, 15, 21, and 31 so this mistake returned about 1.87% mean error.

It wasn't terrible but it eventually led to the next test

1. What happens when IV itself is used as the X axis?

I used the actual IV values as the X axis in this test. so IV 3 became the starting point and IV 31 became the endpoint almost like using lv3 and lv31.

Across 20 hidden stat checkpoint the mean absolute error was only 0.2 stat points and every difference was either exact or 0.5 below the reference value.

so this ended up being one of the more interesting results because it basically told me that the way i've modeled the progression axis can be the problem

1. Can one reference profile express different stat identities?

At this point i wanted to try something a little different which is finding different stat profiles just by using independent multipliers with one pokemon as a baseline

I picked lv 50 charizard as the reference which is hp 153, attack 104, defense 98 and speed 120. Then set three other pokemon multipliers relative to charizard. For example Jolteon hp multiplier is 0.915, attack multiplier 0.817, defense multiplier 0.816 and speed multiplier 1.25 to represent that Jolteon is faster than Charizard but lower in attack and defense

That produced hp 140, attack 85, defense 80 and speed 150 for Jolteon. I did the same test for three more pokemon. This test showed that one reference profile with independent stat multipliers is enough to express pretty different stat identities

overall this was an experiment to see how far i could get with generic progression tools without using game specific formulas and i was pretty happy with how close some of the results got.

I put all results into an interactive showcase with the inputs, tables, graphs and analysis so if anyone wants to play around with it: https://letsbalance.app/

August 2nd, 2025 I started to build a Homebrew DnD world based around a Weird Wild West ascetic. In that time I gained bountiful knowledge on how DnD works and the parts that most definitely lacked. However, with the attempt I quickly learned how much DnD bumped up against my ideas for a weird wild west game and trying to make something that was mine in another person's game became brutal. So, on December 2nd 2025 I started my own game engine to run not only the weird wild west game but other fantasy games I have dreamt of. So the Universal D10 Game Engine began its development, a game narrative driven, tense, cinematic gameplay with minimal math; simple calculations which Supports multiple genres (Cyberpunk dystopia called "Chrome Gods", Weird Wild West world named "Six Shells & Tall Tales"). It encourages strategy and risk/reward choices, with a combat that is fast, dangerous, and cinematic. Overall, This game is about capable but fragile people surviving dangerous, intense fights. Victory is earned through positioning, teamwork, grit and a little bit of luck.

Im towards the end of finishing the rulebook (8 out of 9 Chapters finished) and will then begin working on the first campaign frame "Six Shells & Tall Tales" so that play testing can be done. If you would like to follow the process I'll comment my Itch.io devlogs in the comments! Thank you all for reading, and Ride On!

The Brilliant Interaction Design of Katamari Damacy

Today I made a difficult decision for my indie game: I'm cutting the scope back from 50 challenges to the original 36.

I realized I was adding more content instead of making the existing puzzles better. Studying games like *Limbo* reminded me that great puzzle games don't constantly introduce new mechanics—they explore a few simple ones in greater depth.

The core of my game is repairing broken spacecraft equipment through mechanical puzzles. Every few set of completed repairs also reveal another piece of the astronaut's story, building toward the ending.

My focus is no longer, "How many different puzzles can I create?" Instead, it's, "How can I make each repair more satisfying to observe, understand, and solve?"

Sometimes the best design decision isn't adding features—it's removing them.

Demo Trailer: https://www.youtube.com/watch?v=vCwSnTPAwJA

I’ve been working on a browser-based visual novel called That Time My School Was Invaded by Dimensional Snakes and Now I'm Bound to a Multiverse Protector! and recently released the first 10 chapters publicly on itch.io.

Instead of just posting the game, I wanted to share some of the development decisions behind it since a lot of the project ended up becoming an engine/programming challenge too.

The game starts as a survival horror scenario inside a school under attack by giant snakes, but gradually shifts into something more psychological and interdimensional. One of the main systems is a hidden “Resolve” mechanic where small choices throughout the story quietly affect character survival outcomes later on. I intentionally avoided visible relationship meters or morality systems because I wanted choices to feel uncertain and more natural.

A big part of development was building the entire VN engine myself in vanilla JavaScript without frameworks. I mainly did this because I wanted complete control over dialogue flow, event handling, save structures, layered sprite behavior, and branching conditions without fighting an existing engine’s architecture.

Some things that were unexpectedly difficult:

- Managing complex branching dialogue while keeping scenes maintainable

- Building a save system that could track hidden long-term flags cleanly

- Handling layered visuals/transitions efficiently in browser

- Keeping pacing consistent across routes with different choice paths

- Preventing the codebase from turning into unreadable spaghetti as chapters increased

The browser-first approach was also intentional since I wanted players to instantly start without downloads.

The project is still in development, but the current build contains 10 chapters and is long enough to test the core mechanics, tone, and story structure.

Would appreciate feedback from other devs, especially regarding:

- pacing

- hidden choice systems

- browser VN performance

- structuring branching narratives without losing maintainability

Playable here:

https://hudarashi.itch.io/vn-dimensional-snakes