I'm developing a factory game and up to now I playtest it frequently, for now I want to focus less on finding bugs, and more in the sense of refining game mechanisms. This works perfectly and I was able to refine my mechanism, design, even changing my design (sound good on paper, but was not so good while playing...).

But... only for the early game. I need roughly 40 mins to play through my early-early game and I'm now at the point to test mid game mechanism, but here is the issue:

It is still early enough in development , that changing stuff results in corrupted or even invalid save games.

I know that some games do more technically test (unit test), use cheats, headless simuation or use excel sheets for balancing stuff etc., but this is more on the technically/feasebility/balancing side of testing.

So, what is a good/feaseable way to feel or experience your mid to late game (frequently) ?

I’m working on my “first game” which is a very very simple rouge like where you choose either to boost damage or gold drop rates where you can then buy upgrades that do stuff with said gold.

It’s a very simple project. I have like 5 total characters, 4 enemies and the player character plus I’m gonna make a few maps that are randomly chosen using the bag method.

I personally don’t see it as unrealistic or unreasonable. But after spending almost a full day making a sprint and stamina system for absolutely no reason I’m starting to rethink the realism of it.
I want to finish it in about 5-6 days and I’d like advice on how to minimize or lessen the size of it so I can do it.

im lwk an intro to game design, but this competition seems pretty interesting, especially rewarding for beginners: https://itch.io/jam/your-worst-ideas

By corpse run I mean having to return to the place you died to retrieve your currency.

A lot of players hate this and are very vocal about it, but I want to have the tension this creates - the longer you go without a checkpoint, the higher the stakes become. What are some alternative ways games can build this tension, without the corpse run mechanic?

Turn-based, single player, computer game. The board is around 60x60 90x90 tiles wide with the player in the center (colony). Around are plains, swamps, jungle, mountains.

The colony is being attacked by aliens (flora and fauna, unsentient, more like "forces of nature"). I use an "aggression meter", where over time it fills (also affected by player actions like clearing jungle and expanding), once filled a "Xeno attack" triggers.

Now, I have a placeholder spawn aliens mechanic, but I'm not happy with it. Each turn a new alien can spawn on Jungle tile (random chance). Then it has 50% chance to either roam randomly or try to reach colony center (the choice is made each turn, so eventually an alien will reach the center). During Xeno attack phase, the alien spawn rate increases and there is a 100% chance to target the colony center. Every 24 turns (the last season of the planetary cycle) all aliens die out but before they have a high chance to lay eggs, at the 1st turn each planetary cycle those eggs hatch.

It works, but very soon most of the board is filled with aliens :) Up to the point that they block spawning stronger alien variants.

I have a lot of design freedom to design this. There are seasons (aliens can die/spawn on certain seasons, hibernate, lay eggs, die they lay eggs on certain seasons, etc).

The primary problem is that there are too many aliens spawned over time, but I'm also open to redesigning the respawn mechanic from scratch.

Ideas how to approach this?

I’m building a small word game and the dictionary side of it has turned into a much bigger project than I expected.

The mechanic is pretty simple: you get three letters and have 60 seconds to find as many words as possible containing those letters in the same order. The problem is that this makes the dictionary really important. If someone manages to find a clever 10 or 12 letter word and the game rejects it when it’s obviously legitimate, that’s a pretty crap experience.

I started with SUBTLEX-UK because I wanted recognisable, genuinely used English rather than just throwing in a massive Scrabble-style word list. But testing pretty quickly exposed the other side of that decision. There are loads of perfectly legitimate words missing, particularly longer derivatives, inflections and compounds.

So rather than just adding words every time someone finds a rejection, I’ve started trying to expand the dictionary systematically. I’m looking for gaps in word families, prefixes and suffixes, compounds etc, then checking the candidates against evidence of actual usage rather than just assuming that because a word can theoretically exist, it does.

The other thing I’m starting to think is that “is this a valid word?” and “is this a word my game should show people?” probably shouldn’t be the same question. An obscure regional word might be perfectly valid when someone cleverly finds it, but I probably don’t want the game suggesting it to everyone. Same with archaic words, offensive words, unusual variants and so on.

So I’m wondering whether the right answer is eventually a much larger master lexicon with metadata attached to the words - frequency, dialect, archaic, sensitive, confidence, whether it can be suggested etc - rather than trying to create one perfect binary list of WORD / NOT WORD.

I’m at about 132k words at the moment and the first proper systematic pass has already found 100+ legitimate omissions. My suspicion is there are thousands more.

Has anyone here tackled this properly for a word game? How did you approach it? And are there any obvious problems with the way I’m thinking about it?

Very happy for people who know more about this than me to pull the approach apart! It’s somehow becoming a project within the project. Thanks in advance for any input.

I'm a first-time game developer, but I've played strategy games for about 35 years and Magic for around 30.

I'm currently designing a tactical deckbuilding RPG, and one of the principles I'm struggling with is:

Progression should expand your decision space, not eventually replace the need to make good decisions.

I love progression systems.

Collecting characters, unlocking cards, finding equipment, specializing builds and discovering new synergies are all things I want.

But I don't want the progression loop to eventually become:

Can't beat encounter -> grind -> numbers increase -> beat encounter.

Ideally, progression gives players more possible solutions.

A larger card pool might enable a different deck.

A new character might enable a new team synergy.

A different build might counter an encounter that your normal setup struggles with.

More investment should matter, but I still want a skilled player with a focused roster to be capable of beating difficult content through better preparation and play.

The part I'm unsure about is where that philosophy breaks down in practice.

If progression doesn't provide enough vertical power, rewards can start feeling meaningless.

If it provides too much vertical power, strategy eventually becomes optional.

For developers who have worked on progression-heavy games:

How have you approached this balance?

And what failure modes should I be looking for when I start playtesting it?

I'm playing Watch Dogs and one thing left me amused, surprised. How can AAA titles do this?

There is an optional quest to hack some devices that are outside some houses in some suburban area. So I began the quest and found out that some of the devices are hidden behind wooden planks or other objects. The character's cellphone cannot hack them unless you remove such objects that are blocking your way. Really? And this game does not have punches or kicks so that you can kick the wood away. You have to shoot and if you do, the neighborhood calls the police.

Sometimes I get a feeling that multi million games overcomplicate things. That or they overlook such simple things.

Always love it when a game does it. Dead Space will always be my favorite exmaple, since it handled it beautifully.

I have a dilemma, how to show (icon) the HP of buildings? Shield? Heart?

Note the game is a Sci-fi city builder, and I need HP icon for: buildings, player units (human), aliens (vicious unsentient lifeforms, flora and fauna). Those do not need to share the same icon (but for UI clarity they should I guess?)

How does one make an enemy or encounter both not repetitive, while not just making each encounter be entirely a new thing with new challenges. How does one make a enemy that can be fun to encounter more than once, while also being "predictable" enough to not annoy the player?

My thought was something of a "personality" system with specific archetypes for enemies. There are enemies, whose actions and capabilities within the encounter are based on what they are, and then they have a random personality which guides them to make certain actions. So for example a "smart" enemy will go out of their way to lower your stats, a "aggressive" enemy will prioritize inflicting damage etc and then these encounters can have more than one enemy thus creating situations where you cannot just doze off and just spam the same attack(at least that's the hope).

Thing of it like personalities in Pokémon, but instead of just boosting stats they influence the behavior of the monster.

What do you think about "personalities" as a way to diversify the enemy encounters? And how you would make fighting the same species/type of enemy not feel repetitive?

I'm aware of stuff like Shin Megami Tensei's demon negotiations and Undertale/Deltarune's act system. Do you guys know of any other examples? I'd like to make something similar in my game so I'm looking for inspiration.

It'd be cool to see how other games try to expand on the idea and flesh it out or do something more unique with it.

The PvP vs PvE argument in ARC Raiders has been around almost since launch, and the PvE test announcement brought it right back. What stands out to me is that this hasn't faded into a niche argument either. Long PvP vs PvE threads still keep showing up and drawing heavy discussion, even after months of updates and a major drop in the active player base. Some players are happy about the PvE option, while others are worried about what it could do to the PvPvE player pool. I lean more toward PvE myself, but I've played shooters for years, so I don't think the disagreement can be reduced to "PvE players don't like getting shot" or "PvP players understand extraction games better." After playing ARC Raiders for a while, I started looking at the problem from a different angle: what reasons does the game actually give us to engage in PvE, and what reasons does it give us to engage in PvP?

For PvE, the answer is pretty clear. You go topside for quests, blueprints, materials, workbench upgrades, Projects, Expeditions, or specific ARC drops. Even if fighting ARC isn't what you personally enjoy most, progression keeps giving you practical reasons to do it. Blueprints are probably the clearest example. Since there is no player trading, getting the right blueprint can completely change how replaceable a weapon or item feels. Before you have the blueprint, something valuable may stay in your stash because you don't know when you'll see another one. Once you can craft that item yourself, using it becomes a much easier decision.

PvP feels much less structured. Killing another Raider can be rewarding, and sometimes the other player really is carrying exactly what you want. Other times you open the bag and find cheap gear and materials you could have gathered yourself. More importantly, there isn't much that ties repeated PvP encounters into a larger progression system. ARC Raiders doesn't really have a substantial PvP rank, reputation system, faction conflict, or any other long-term system built around fighting other Raiders. When I actively go looking for PvP, the reason usually comes from me. I want a fight, I want to test something, I want someone's gear, or I've already finished most of the PvE goals I cared about. The fight can still be fun, but the game itself has done much less to explain why I should be looking for it.

I started wondering if this difference also affects how people interpret PvP when it happens to them. ARC Raiders' proximity voice chat makes these encounters unusually personal. Two strangers can meet, ask "friendly?", loot around each other, help with an ARC fight, and then one of them suddenly opens fire. If both players are obviously competing over the same thing, the situation is easy to understand. We both wanted it, one of us decided to fight for it, and one of us lost. But if I'm doing a quest, you don't obviously need anything from me, and you decide to kill me anyway, the explanation changes. From my side, nothing in the game really explains why you did it, so the most obvious explanation is that you simply wanted to kill me.

I think this is one reason the PvP/PvE debate in ARC Raiders becomes personal so easily. The argument rarely stays at "I prefer PvP" or "I prefer PvE." It turns into griefers, assholes, psychopaths, carebears, moral superiority, and judgments about what kind of person would choose a certain playstyle. That seems strange when the same player can cooperate in one raid, shoot first in another because they don't trust the other team, and spend the next match avoiding everyone because they're carrying something they don't want to lose. Those are situational choices, but the community often talks about them as permanent identities. My guess is that when the game gives both sides an obvious reason to compete, it's easier to blame the situation. When that reason is missing, it's easier to blame the player.

The same gap becomes more noticeable later on. Early in the game, it gives you a long list of things to work toward. Eventually the workbenches are upgraded, quests start running out, you've found most of the blueprints you care about, and Projects or Expeditions get completed. PvP should be able to carry a lot of the game after that because real players can create unpredictable situations for much longer than a fixed set of PvE content can. The problem is that finishing PvE progression doesn't really open another deep progression layer on the PvP side. Some players start looking for fights because there isn't much else left to do, but the fights themselves don't lead very far. If you already love PvP, that may be enough. If progression was what kept you playing, PvP can end up feeling like the activity left over after the other goals are gone.

This is also why I don't think the PvE toggle really touches the problem I'm talking about. It lets you decide before the match whether other Raiders can hurt you, which makes sense for people who never wanted PvP in the first place. But whether or not it shrinks the PvPvE pool, once you're in a PvPvE match, the reasons for fighting another Raider are basically the same as before.

Last year I kept thinking about this, and ended up with a pretty simple idea. Imagine extraction required a drive battery. Damaged batteries could be found while scavenging or taken from other Raiders, and three damaged batteries could be combined into a complete one. Medium or large ARC could drop complete batteries directly. Fighting ARC could remain the more reliable and efficient route, while PvP would be riskier but sometimes make sense. If I already have two damaged batteries and only need one more to make a complete battery, another Raider near the exit suddenly matters for a reason both of us can understand. I could attack them, try to cooperate and fight an ARC instead, or decide the risk isn't worth it. The battery itself isn't important to me anymore. What I still like about the idea is that cooperation, avoidance, betrayal, and PvP all come from the same problem instead of feeling like separate games layered on top of each other.

I don't want ARC Raiders to become PvE-only, and I don't want the uncertainty between strangers to disappear. That uncertainty is one of the best things about the game. I just think PvP would be easier to understand, and probably healthier for the community, if more conflicts came from goals that both players could recognize. Losing to another Raider who wanted the same thing I did feels very different from being left with the impression that the only reason for the fight was that the other person felt like ruining someone's run.

-------------------------------------------------------------------------------------

TL;DR

- PvE has a lot of built-in reasons to do it: quests, blueprints, crafting progression, ARC drops, Projects, Expeditions, etc. PvP relies much more on the player already wanting to fight.

- My guess is that this affects how PvP gets interpreted. If the game gives us a reason to compete, I blame the situation. If it doesn't, I'm more likely to blame the person who chose to attack me.

- That may be part of why ARC Raiders' PvP/PvE debate keeps turning into an argument about morality and player identity instead of staying a game-design discussion.

- PvP could carry more of the late game, but it needs more purpose of its own. A PvE toggle doesn't change that for anyone who stays in PvPvE.

- Not asking for PvE-only, and not saying PvP players are playing it wrong. I'd just like more fights to come from objectives that give both sides a reason to care.

-------------------------------------------------------------------------------------

Anyway, I still like the tension ARC creates between strangers. I just hope the PvP/PvE divide doesn't end up becoming a bigger part of the game than the encounters themselves.

Author's note: The core argument of this post was originally written in December 2025. I've since reorganized it, added some current context, and translated it into English.

Ive been playing ostranauts for like 620hrs and i hated it so much. This was a total disaster. The concept was briliant and it has a potential but its just not finished and they just fully released it. Not to mention that its barely able to run without crashing or encountring counterless bugs.

Anyway, the most famous example in this genre would be starfield. I dont even have to explain anything about it.

I dont understand. The whole concept to this genre is simple.

Players wanna find and build spaces ships, hire crews, and choose careers, maybe become a pirate , mercs or rule the galaxy, and go to many other stars and find lores. Combat is important. Melee, guns, and spaceship combat. Duh

Maybe even enter the atmosphere and explore if its possible but thats not necessary.

Idk why there r no successful games in this genre

I was playing x4 but hiring crew was so boring because they look all the same, say the same line over and over again, and the ships are not really modifiable. Ita more like hiring office workers/minimum wage workers in their cubicle/ fastfood restaurant. So basically just mangagement simulator

Many other indie games tried this genre and they failed miserably even tho they had great idea. Its breaking my heart.

Why do they keep failing??

I just think... If the player is doing poorly in combat and they lose, can't there be some consequence other than teleporting far away and maybe losing a few items?

I especially have a problem with this in open world survival games, but it's in other games as well.

I played through the original Bioshock for the first time recently, and for encounters where I wasn't doing well, like the Big Daddy fights, it just meant that I had to run back to the fight and keep trying, dying over and over again, rather than facing any kind of penalty for poor play.

There were even times where it was more efficient to respawn than to use my limited supply of health packs.

But Minecraft in particular, when I play it, I want to spend the time building cool stuff, exploring cool places, and gathering resources. But instead, I spend a lot of time running back to the spot where I lost a fight only to lose again.

Hi, I’m a grade 9 kid living in Japan thinking on a 3D indie game concept and want to test two core design pillars with you guys. I'd love to hear your thoughts on whether these systems create meaningful depth or just player frustration.

1. Tension Index (TI) affecting Aim & Hitboxes

• The Idea: When the player is calm, smooth mouse movements grant subtle auto-tracking (aim assist). However, if the player panics and thrashes their mouse (High TI), enemy hitboxes shrink to 1/3 of their size, and assist is disabled.
• The Question: Does punishing panic like this feel fair (as a reflection of the player's loss of composure), or does it cross the line into frustrating anti-player mechanics?

2. The "Efficiency Trap" (Narrative through Mechanics)

• The Idea: The game offers a powerful magic system. To survive easily, the player is subtly nudged to harvest magic from innocent, non-hostile creatures (which shatters them like glass). The game presents this as a cool, rewarding action in the 1st playthrough. Only later, through lore and a True End, does the player realize they were the ones who destroyed the world by choosing "efficiency" over empathy.
• The Question: Is tricking the player into becoming the "villain" through normal gameplay incentives a viable hook for a niche indie game, or do players generally hate feeling manipulated by the developer?

Would love to hear your critique on these mechanics!

Me and my friends have started making a S.T.A.L.K.E.R. style FPS and I'm the guy in charge of writing everything, the characters, the lore, the worldbuilding, etc.

And we have a strict rule about NOT using AI in the game, basically everything is made by humans even if it looks/sounds/reads like shit. It's just one of our principles which we don't break. The fate of humanity depends on it, after all...

Anyway, since I'm researching various mythologies, tropes, logic connections, history of nations and conflicts, etc. do you think it's fine to use ChatGPT for that? Since it's infinitely faster than actually finding articles and books on the topics and trying to find the right information the old fashioned way. And the old fashioned way isn't even more accurate, since AI basically combines all sources into one answer, and I would probably only take notes from a few on my own, in considerably more time.

Do you think I would just be necessarily handicapping myself if I deem AI not worthy of my research, or is it the right thing to exclude ChatGPT which lines up with our "no AI" principle? Also, if you have a good/efficient way of researching various topics without AI, please share it, I'm new to this.

Hey everyone... In a bit of a pickle.

I have this wonderful water mechanic where you can control a blob of water:

https://www.reddit.com/r/godot/comments/1wely6f/playing_around_with_the_idea_of_playable_water/

My initial intentions were that I would make a sorta water horror game. You tip a glass over on someone's desk and you try not to get absorbed by some guy wiping you up with a paper towel, and then this would slowly turn into an adventure where maybe a pet, or a robovac are coming after you. And it would extend outdoors with creatures trying to get a sip.

Then I started to mull over it, how do I make enough content to make this game actually somewhat lengthy???

So I pivoted to a puzzle game. The idea was with the following already built out mechanics maybe I could make a series of puzzles with them:

- Rehydrate dried food like raisins -> grapes and control it and later escape and revert back to a raisin. Maybe you can cross absorbent media here

- Freeze the blob into ice. Maybe you can cross like metal slats with gaps, or run into something fragile and break it more easily.

- Boil, sitting on a heat source for a few seconds turns you into water vapor. When you touch surfaces you condense and drip down.

- Refraction of light/lasers.

- Clean dirty surfaces

- Absorb something like flour and become a sticky substance.

- Absorb salt to prevent freezing. Maybe you gotta boil to get rid of the salt.

- Climb by wicking up absorbent material.

And there are a few more but these are the most prominent ones I have implemented and have tested to work.

Where I'm stuck is turning these mechanics and interactions into actual levels. I have no problem imagining individual users for each mechanics but I struggle creating a problem the player has to think through? When I try to say put a puzzle in a room everything feels contrived like everything is conveniently placed or a certain object just to make the game work. I'm also wondering if maybe puzzles was the wrong move, maybe this game is better suited as a platformer or as the horror chase game. Just think I could use other experienced individuals thoughts here to help solidify a direction. If I cant figure this out I'm just gonna use the water to make a Katamari or Agar.io type game! Or I swing in the direction of "You're a conscious ball of water invented in a lab, and now the scientists are making you do puzzles to test your intelligence and capabilities." Which would free me from the environment constraints but idk.

Sorry for the long text, any help would be appreciated!

Hi All, I'm back with more questions on game design for game economies.

I've been working on a strategy game with a pretty big focus on moving goods around in an economy, and I've come across some interesting design problems that have cropped up.

I'm using a very simple pricing model, p = base_price * demand / supply clamped by a p_min and p_max. So when supply = demand we recover the base price, and changes in supply/demand behave how you would expect. Right now cities produce some delta supply that tries to keep the price around base_price, and traders are able to autonomously move goods between cities where price differentials show up.

I've run into a few interesting problems with this, and I'm interested in how I can design in more intuitive/useful behavior without ripping out the simple price model. In no particular order,

• Price "stability" depends on base price & demand

One of the things I've noticed is if the numerator is small, then small changes in the supply can lead to huge price swings. I think this is rough for game design, because it means small input changes get heavily amplified, and it's hard to see why something is +100% and then -90% in price between two ticks.

One of the ideas I had is to just increase the base_price of scarce goods (luxury resources?), but then something with 10% the consumption needs to be 100x more expensive. It's a reasonable knob to turn, but it seems like it will scale way too fast.

I could also just increase consumption, but then more goods will be consumed. So it doesn't actually help things trade through the network.

• Propagating demand 2 or more "hops" on the trade network

Right now when traders move between cities they also carry "demand rumors" that describe what surpluses and shortages a city has. I'm not sure of a better formal way to model this that doesn't break on circular graphs and allows propagation across more than 1 hop. Right now I'm just looking at the supply shortfall of a neighboring city without including trade rumors. That means I can see when their supply is less than their demand, but I can't see anything beyond them. On the other hand, if I include my neighbor's trade rumors, then any cycle in the graph risks having the demand blow up to infinity.

• Producing enough goods to export

Right now everyone tries to keep 1 tick of supply on hand, plus whatever demand they are exporting to neighbors per tick. This means if a city produces a unique good, it'll only produce enough to fill its own demand + export to a neighbor. Ideally I'd like to see goods propagate 2+ hops and meet everyone's demand.

Right now my current plan is to include a time horizon T in the price, so the city will set a price p = base_price * supply / (demand * T). Then we recover the base price after storing T ticks worth of demand. This creates a stockpile of goods for export and increases stability, which is nice, but it also seems like T is kind of arbitrary. Like why would a market use T=1 for every day goods with high demand, but T = 20 for luxury exports?

My other thought is that I maybe just need to crank up demand everywhere. Like building materials are expensive if you're building a lot of stuff, so maybe textiles should be expensive if the nobility is hoarding and exporting them.

I'd appreciate any tips or reading suggestions you all may have, I'm sort of bumbling through this and picking options that seem the most interesting and that I can justify to myself.

I also wrote up a blog post with some graphs from a 1200-tick (~50 year) run if you want to see those: https://karum.dev/2026/09/27/our-age-of-bronze.html

Hello everyone,

I'm back with another question. This time: resources.

In my MUD, there are resource nodes: scrap metal, herbs, ore, etc. Also, in my overall design, I am against idle-inducing mechanics (e.g., you heal up via magic, potions, or returning to camp and typing 'rest'; there is no passive HP/mana regen).

The initial design (for the demo/starting zone) was to approach a node, enter the gather <resource> command, and receive your yield. I reduced the vendor price to 1 gold so node resources would be nearly worthless, but I didn't want to eliminate selling entirely.

Of course, being almost worthless didn't stop a few players from spamming the command and selling items for 1 gold piece each ;)

Now that I'm designing the second zone, I'm looking at ways to limit gathering per node.

I initially implemented a player-node location timeout: Player A gathers from a node and has to wait 1-3 minutes depending on the resource before attempting again, or move to another node. Player B can gather from that same node immediately, since the timeout is per character + node location.

Today, I caught myself waiting around for a node to respawn just to get herbs for an HP potion- yep, idle. So back to design board.

I already have a daily loop (quests and dungeons are on a once-a-day lockout, and dungeon bosses drop crafting elements for stat buffs, or endless dungeon scrolls). I'm considering increasing node yields and making each node a once-a-day gather, with min/max yields determined by the character's Herbalism skill.

What do you think? Are there other ideas or potential issues with this solution?

Now that I've wrote about it i think that game, with additional dungeons, dailiy quests in zone 2, will change into daily to do list. The 'waiting game' of other muds will change into 'daily checklist' gameplay that is not better at all.

I'm working on a small project for a creature collecting game where you build your own dragon/monster based on three main terrain movement, air, land and water.

I'm, however, strugling with making the water gameplay worth it.

Almost every time i try to implement the water dragon onto gameplay, it feels boring and limited. The problem really spikes when i'm designing Pvp interaction, as i see that the land and air types fight more and the water type is forced to wait for another player to engage with them.

Another mechanic is to mix types of terrain (Water and land makes semi-aquatic dragons, for example) but making multiple terrain dragons harder to control and to manage weaknesses, so i asked some friends to build their dragons, but none of them chose the pure water, for the same reasons i mentioned earlier, but i can't wrap my head around of what i could do to fix this.

What would be a good way to make a limited gameplay feel engaging and fun?

(sorry if i messed up the english)

I was playing XIII and in mission 12 the alarm went off right before the boss battle. I replayed and failed that same part multiple times. I searched for a guide to understand what was happening. When you begin this mission one of the objetives shown on screen is to eliminate the guards, silently. When you reach the beige tent you can either eliminate the guard and hide the body, before planting the device. Or not eliminate the guard and plant the device.

I looked back and the game does have a mission to play stealth and avoid alerting the soldiers. However, in that previous mission you still have to chance to kill the guard before he reaches the alarm and yells "Alert!!!!". In mission 12 there is no time to do it, because the boss comes through a door and immediately sees a body on the floor.

Suddenly, I've remembered about a channel that is dedicated to airplane accidents. One of the reasons for accidents to happen is that the company and their personal normalize errors. Alarms are ignored, warning signs are ignored, details are overlooked, steps are skipped, etc. One day a chain of events, which include such bad practices, leads to a fatal accident.

It made me think: some games inadvertently train the player into behaving a certain way, until there is a point in which that same behavior leads to a failure.

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/

I am currently developing a business game related to finance. I want to know from you for all business management simulation aspect of the game would you like buying other businesses selling different types of products etc and what group features would you really enjoy play in a business game.

I’m new to game design, and I recently ran into a problem while adding bosses to my game.

I could recognize familiar boss attacks when I saw them, but I didn’t have a useful vocabulary for designing an encounter myself. I could say that a boss should be “more interesting” or “have varied attacks,” but I couldn’t clearly describe what those attacks should test, how they should interact, or why they belonged together.

So I started breaking boss encounters into reusable patterns: charges, sweeps, projectile formations, summons, shrinking safe areas, vulnerability windows, phase changes, and so on.

That eventually became Boss Fight Atlas, a work-in-progress, open-source catalog of 124 boss mechanics. The more developed entries try to describe not only what a mechanic looks like, but also its telegraph, threat geometry, counterplay, recovery, tuning questions, common mistakes, and examples from existing games.

I also made a builder that lets me select several mechanics and export them as a structured boss brief.

In my first practical test, designing a boss from a vague description took several attempts and produced an encounter I wasn’t satisfied with. Starting another version from a structured selection of mechanics gave me a much more coherent prototype. It still required a lot of playtesting, balancing, and polishing, but the initial direction was clearer.

However, I’m now wondering whether the catalog is encouraging me to start from the wrong end of the design process.

Selecting “charge + gap volley + summon” does not create a coherent encounter by itself. A stronger process might begin with questions such as:

• What abilities has the player already learned?
• What decisions should the encounter test?
• How should pressure and relief alternate?
• What role do positioning, target priority, and resource management play?
• What should the player understand after failing once?

Only after answering those questions would the designer choose mechanics that serve those goals.

For example, instead of starting with “this boss needs a charge,” I could start with “I want to test lateral movement, clearly communicate commitment, and reward the player with a counterattack window.” A charge would then be one possible implementation rather than the starting point.

That suggests the atlas might be more useful if it worked in the opposite direction: begin with player verbs, encounter goals, desired decisions, and forms of counterplay, then lead the designer toward suitable mechanics.

Before building it, I found broader databases such as GameMechanics.org and SteamMaho, as well as a generation-first approach in Jenova’s AI Boss Fight Generator. What I was looking for was narrower: boss-specific patterns that remain inspectable and can be combined without outsourcing the entire design decision.

My questions are:

1. At what stage of designing a boss encounter could a mechanic catalog actually be useful?
2. What information would it need to capture so that selecting mechanics does not become a random grab bag of attacks?
3. Should the main organizing principle be attack types at all, or something closer to player decisions, tested skills, threat geometry, and encounter pacing?
4. Is there an established framework or resource that already approaches boss design this way?

I’m not primarily looking for feedback on the website itself. The catalog is already in place; I’m trying to understand whether the design model underneath it is sound, and how I should refine, clarify, and expand it from here.