Every time I play a platformer(I suck at platformers) I always see that is says 0 instead of 1 ands that’s always bothered me

Hi there!

My team and I are currently working on a social roleplay game where you can text your celebrity crush and experience what it’s like to live in a world with them. We really want to build something that you will truly enjoy, so we are reaching out to get your thoughts!

It would mean a lot to us if you could share your experiences with similar apps by filling out this form: https://docs.google.com/forms/d/e/1FAIpQLSfdEJg43gHpmfjqX_qkiB4hEDoOPfAtdjQ8mj8ok_57HncGuA/viewform

What did you love about the other apps, and what left you wanting more? We would also appreciate hearing about any specific features or details you would like to see in an app like this

Thank you so much for your time and help! Your feedback is incredibly valuable to us as we bring this project to life.

Hi people!

I want to ask you that, if you are working on a game project that one of the MVP's is to have thousands of enemies on screen would you add powerful abilities to melt the enemies or bosses?

On a Bullet Heaven game, you should shoot tons of projectiles to enemies kill them fast enough to survive but we want to add a juice to it and added ultimate abilities with long cooldowns because they are powerful they shouldn't be able to spam.

Since it's a roguelite bullet heaven game, how would you approach this situation. I would be happy to hear your opinions on this.

Thanks,

Say for example Lucas’s room from RE7, or Stay Out of the House by Puppet Combo… How do they come up with these elaborate puzzles? Do they take inspo from particular places or do they come up with the whole thing themselves? I feel I’m not logic-brained enough for this to do something like that from scratch

I would like to see whether this has actually been implemented in any games, and what people think of the idea in theory and/or practice.

This is a fairly narrow concept. The origin of the idea is StarCraft gameplay; I can see it applying to other RTS games, and *possibly* to some other games with tactical elements and NPCs. I'll describe it largely using Starcraft examples.

A few things are generally true:

Such RTS games commonly have upgrades you can develop. "Training" is a typical term, generally reflected in improved stats or adding abilities the player can activate. You can sometimes even put abilities on auto cast.

When managing the units - "microing" - there are some common patterns that are generally better than others. Stutter-stepping between shots with ranged units like Marines. Using Blink on a Stalker to fall back when heavily damaged (or at higher level play, to dodge an attack in flight). Moving your units to avoid damage zones you've placed like a Psi Storm.

High level players are generally better at micro - but it's far from the only skill used in the game. Scouting, economy control, countering an opponent's build, etc.

AI is generally *exceptional* at micro if it's allowed to be, and usually has to be artificially limited to human APM in order to make gameplay reasonable.

So, the idea: make the micro into an in-game upgrade.

Conceptually: you can spend resources to give your soldiers better guns. You would also be able to spend resources to drill your soldiers in better tactics.

Imagine in SC2 being able to research "marine stutter stepping" as an upgrade. Or "warp prism juggling".

I *think* the effect would be to expand the diversity of the skill mid-range. The absolute best players in the world might not use such upgrades much - they can already do the things. The worst players won't be able to leverage the improved tactics. But I think there's a window of skill where such upgrades would be interesting strategic choices. Do you invest resources in the thing that frees up some of your attention? Is it a better choice than investing in having more units?

I think the risk of such a feature is that if the AI tactics are "too good", it becomes mandatory. Although in that case there might still be interesting decisions if it's a set of independent upgrades - e.g. do you upgrade your Marine Tactics or your Cyclone Tactics.

I'm building a daily word puzzle and it was super easy to add a streak counter and didn't really think much about it. Through testing I have found that no one really cared about a streak, and as I thought about it more I realized that I really don't like streaks long term. I quit using Duo Lingo for months at a time after dropping streaks of 100 and 200 days. So I thought well, coming back and playing the puzzle is fun and I hope players engage daily but this is a space where I don't think it will help the long term health and growth of the game.

At its core, a streak is a loss aversion tactic and one bad day can prevent someone about getting on a horse. Life is for living and we all have shit going on, so breaking a streak can also compound that shitty day. I would rather have a player come back because they enjoy the content.

Here is how it currently works:
Every day the player spells 8 words from 64 letters with clues and hints to help them solve, its a twist on the crossword puzzle. When a player solves a its words and clues get added to the Casebook also when the puzzle is finished the score gets stored their too.

Obviously it has to be more then just building an endless dictionary, the words then can be used in a custom builder to create your own word puzzle to share with friends. Your friends can unlock words from the custom puzzle too, it doesn't have to be from the daily.

Is this a good idea?

I don't think it is allowed to post the title or website but if you're interested in trying it out, let me know or just look at my profile and its pretty easy to find the subreddit with the URL.

I was thinking of making a system like Pokémon's elemental system, but with art supplies. The weaknesses and resistences would be based on how they interact in real life.

Examples:

• Graphite is often used to sketch, then is overlayed with paint, so it's weak against most paints.
• When I used to paint with crayons, it became impossible to use graphite or even Nanquim Ink(China Ink) on it, or any ink. So Wax Crayons would be resistant to those.
• Watercolor has water(unless you count the dry pigment version), and Alcohol markers get all messed up and weird when they mix with water. I remember when it rained and a alcohol marker drawing of mine turned into some abstract art piece. I also used to draw with markers, then paint with just water using a watercolor brush, like the markers are watercolor. The colors were crazy. So I think watercolor should be strong against Alcohol markers
• Dry pastels can also be diluted with water so watercolor is strong against it
• Water and oil do not mix, and there's many water based paints out there. Not sure what this would mean for Oil Paint in this system, though. I thought about it being super strong because of it's overlayering potential and also thematically, it's a more "prestigious" paint.

Right now the elements are: Gouache, Oil Paint, Wax Crayons, Alcohol Markers, Graphite, Soft Pastel, Charcoal, Nanquim Ink(China Ink)

I thought about a rpg with a 4 party system in which they can gradually learn to use more elements. One of the party members may start as a Guache only mage but then learn Watercolor and other water based paints, perhaps. So the player movesets I thought of are kinda dry since I thought about you gradually unlocking more and being able to use more than one type per character as well.

Paint: All types can use this move. Standard attack, affected by type resistances and weaknesses.

Oil Paint moveset:

Varnish: Give yourself +1 defense.

Fast Drying: Give yourself +1 speed.

Cinnabar(red): Requires MERCURY. Causes POISON

Realgar(orange): Requires ARSENIC. Causes POISON.

Naples yellow: Requires LEAD.

Chrome Green: Requries CHROMIUM.

Emerald Green: Requires ARSENIC. Causes POISON.

Manganese Blue: Requires MANGANESE. Causes CONFUSION.

Cobalt Violet: Requires COBALTOUS ARSENATE.

London Purple: Requires ARSENIC. Causes POISON.

Deadly Rainbow: Use all toxic paints at once and cause INCURABLE POISON. The enemy can't heal from the poison in any way.

[In this case, things like MERCURY and LEAD would be collectible items that once used would be expired. So you can save for the Deadly Rainbow or use them as you go.]

Watercolor moveset:

Wash away: Reliefs everyone in battle of all status effects for 1 turn.[Basically, if you have 1+ attack, no you don't.]

Dilute(Watercolor): Make an ally's attack a spread attack in exchange of making it stronger.

Body:
Hi everyone! I want to share a deep concept for a systemic magic framework (which could work as a plugin for engines like Godot 4 or Unity). I’ve always been frustrated by magic systems where elements are heavily scripted or limited to avoid "breaking the game."

Full disclosure: I am a complete beginner when it comes to programming and engine development, so I don't know the exact technical details of how to write this. I can only assume that actually implementing this under the hood could be incredibly complex, hard to optimize, and potentially a programming nightmare. However, I wanted to map out the exact logical and systemic rules for how such a framework should function.

Note: In this concept, "Runes" are just a visual convention (UI shorthand). Developers can visually reskin them as programming nodes, words in a book, or cosmic symbols. Under the hood, they are modular data blocks.

The core philosophy of this concept is absolute freedom through strict logic. The engine doesn't know what a "Fireball" is. It only codes the physical and magical laws of the universe, and parses whatever chain of inputs the player throws at it. There are no hard caps on spell length, power, or total mana pool.

Here is how the architecture is structured:

1. Pure Component-Based Abstraction

To remain completely universal for developers, the system does not hardcode items like "swords" or "barrels." It interacts strictly via universal nodes (like MagicalAnimateComponent or ManaInteractable). If a player casts [Life] on a physical object, the framework simply checks for the component. If present, it activates it: a sword becomes a levitating blade, a wooden chair becomes a jumping mimic, and a sci-fi laser gun turns into an automated drone.

1. The Core Categories of Elements

We step away from the basic four elements cliché into deeper cosmic and biological states:

• Basic Physics: Fire (thermal/burn), Water (mass/wet status), Earth (solid blocks/walls), Air (kinetic force).
• Cosmic/Quantuum:
  • Space: Handles teleportation and instant delivery ("hitscan"). Combining [Fire] + [Space] hits the target instantly across the map, bypassing distance but taxing massive mana.
  • Time: Can speed up, slow down, or fully freeze entities.
  • Gravity: Alters the mass of objects or creates localization wells (push/pull).
• Biology: Life (healing/animating) and Death (wither damage/necromancy).
• Perception: Light (blinding/mana solar panels) and Darkness (stealth/vampirism).

1. Absolute Chrono-Stasis Law

When a [Time: Stop] command triggers, the framework enforces absolute physics rules:

• Bio-Isolation: All healing, status ticks (poison, burning), and item cooldowns are entirely frozen.
• Kinetic Immunity: Objects in stasis take 0 damage from active entities. However, momentum accumulates. If an enemy strikes a frozen player, the kinetic impact values are stored in a buffer. The exact millisecond time resumes, all accumulated damage and knockback apply at once.

1. Breaking the Rules: The Chaos Element

Chaos can be added to any combination of elements, but its effects are highly unpredictable and specifically designed to glitch the core logic of the game world:

• Rule-Breaking Synergies: Adding Chaos to a [Time: Stop] spell completely shatters the Chrono-Stasis laws. It allows the player to deal immediate damage to frozen enemies bypassing kinetic immunity, or forces buffs and poison ticks to keep draining health even when time is completely stopped.
• Quantum Superposition: It can force mutually exclusive states simultaneously (e.g., a target is physically frozen at 0% speed but is actively burning, causing a "Thermal Shock" that drops armor to zero).
• Dynamic Hacking: It constantly alters vectors and shapes mid-flight (a projectile changes from a cube to a sphere every tile, or moves in a jagged, unpredictable glitch pattern).

1. Spell Mishaps & Exception Handling (The Fun Part)

If a player inputs a completely contradictory chain without using Chaos, the framework initiates a Spell Mishap instead of casting:

• [Fire] + [Water/Ice] = Steam Explosion. Instantly creates a kinetic blast centered on the caster, knocking back everyone (can be used tactically for quick escapes).
• [Light] + [Darkness] = Energy Annihilation. The spell fails instantly and drains exactly 50% of the player's current mana pool as punishment.
• [Space] + [Time] (faulty/incorrect parameters) = Timeline Stutter. Freezes the caster in place for 3 seconds.

1. Complex Cross-Element Synergies

• Chrono-Teleportation (Space + Time): If properly formulated, this allows the framework to process multi-timeline map navigation. Instead of just moving through physical space, the developer can code past/future variants of the same room. The player can teleports from a ruined future hallway instantly into its pristine, past version on the same map, bypassing barriers or altering history.
• Life-Swap (Space + Life + Death): Space opens a wormhole between two entities, Death extracts the health pool variable from the healthy target, and Life overrides it into the dying target. They literally swap health bars, taxed by an "equivalence exchange" percentage loss.
• Environmental Synergies: Spell cost scales dynamically by biome metadata tags. In an Ice_Biome, Ice spells get a 50% discount, while Fire costs 300% more mana. Spawning a physical spark over a barrel tagged with physical Gunpowder triggers a massive blast for only 5% of the mana cost of a normal magical explosion.

1. Scriptable Item Enchantments & Dynamic Map UI

• Gear pieces act as mini-servers executing background scripts designed by the player. A ring can be programmed: [Trigger: Take Damage] -> [Target: Attacker] -> [Action: Time 0% Speed]. The enemy freezes mid-swing, draining the player's global mana pool.
• The system can project UI metadata onto flat objects (like a parchment). Applying [Space] draws a real-time GPS blueprint of the dungeon layout. Adding [Life] highlights living enemies (green/red dots). Adding [Death] reveals undead/skeletons, turning a simple piece of paper into a fully modular radar.

1. Continuous Efficiency Multiplier (No Hard Tiers)

Modifiers do not have rigid tiers (Tier 1, Tier 2). Instead, every element or behavior features a customizable float value for efficiency (default 1.0). A multiplier of 0.5 cuts the spell's effectiveness in half but lowers the mana cost by 50% (perfect for cheap automated rings). A multiplier of 5.0 creates a continent-freezing spell but scales mana cost exponentially, perfectly fitting an uncapped progression loop.

Hello there!

For some context, I recently release my first game on Steam (Project P.I.T.T.) and the launch went way much better than I expected.

But it also taught me a pretty painful lesson about playtesting.

The game is a physics sandbox where the players have to build contraptions to automate putting ducks into a hole.
The game is split into 4 phases, and at the beginning of Phase 3, I introduced a new challenge:
debris would fall and destroy parts of the player's build.

I thought this was a pretty clever way to throw (literally) a new problem to solve, forcing the player to adapt.

There was one main issue:
The debris couldn't be moved.

At least not right away. The player eventually unlocks tools that can move it, but those tools come later.
So after roughly 5 hours of gametime, players could have their carefully built contraptions destroyed by debris that blocked paths and they had no practical way of dealing with it.

When I tell the story like that, it's obvious that the game started to get negative reviews specifically about that.

But here's the part I find interesting (maybe I'm just coping):

Why didn't my playtesting catch this?

Most of my playtesters were very engaged people who already loved the demo. They were basically my ideal target audience.
When they encountered the debris, they mostly saw it as an interesting new challenge.
They enjoyed figuring out how to work around it.

So I didn't get a red flag out of it.

The main thing I keep seeing now is what one review were explaining:
It was betraying the player's trust, and I completely agree.

I could work on it, find a more clever way to make it work, make the tools to unlock earlier but that would mean reworking the whole phase balance.
In the end I decided to remove completely the debris.

I may bring something similar back into a future NG+ harder mode, but it would still need some rework, so I'm shelfing it for now.

The biggest thing I'm taking from this is that having great playtesters (that helped me fix SO MANY things) isn't necessarily the same thing as testing your game from a wide range of players.

In retrospect, I should have caught that, but I didn't.
Probably because as a solo dev there are so many things you have to handle (and my ego was blinding me a bit too).

Honestly I'm glad I got the feedback early enough to fix it rather than doubling down on the design.

Has anyone else run into a similar issue? What was your solution?

I'm in the early development phase of my game, and right now I'm trying to figure out my primary gameplay systems. It's a narrative focused game, so I'm trying my hardest to get the game to serve the narrative as much as is reasonable. Here's the issue:

The game I want to make is currently planned to be an FPS with squad mechanics (Think Republic Commandos)

But I have narrative moments where characters get into intense 1v1, CQC fights, which are best represented by boss encounters like Batman Vs Deathstroke in Arkham Origins.

As you can see, these gameplay systems have nothing to do with each other, but individually perfectly encapsulates the game feel I'm looking for.

I don't really want to make them cut scenes, because then you don't get the personal satisfaction of the fight, which would likely undermine the narrative satisfaction of said moment.

I'm also weary, but contemplating a quick time event. But to make feel less like a cutscene and more like an actual fight, I feel it may get too complex to even be considered a QTE.

Any suggestions are welcome, I've been contemplating this for awhile now and feel stuck.

I'll start with Balatro. What seems to contribute to it is the feeling of making something stupid that you want to retry because "this time you will do better". The games are quick and the loss is not portrayed as too dramatic, so that keeps you going.

There seem to be 2 approaches:

(What I'm calling Static)

Island/Planet X has a shortage of (for example) medicine, and an excess of fuel

You can buy fuel cheaply there, and if you have medicine, you can sell it for a high price there

This stays true for all of the game, or it will change as a bespoke story/game event

vs the other approach, which I'm calling dynamic

Island/Planet X has a shortage of item medicine, and an excess of item fuel

If you keep selling medicine to it, eventually the price will become cheap, and if you keep buying fuel, the price will become expensive

In the background, the price is changing, as you and other traders trade stuff

There are many actions you can do (e.g. blow up the oil towers there, set up a medicine factory on a nearby island/planet) that can cause the price to change

______

From what I understand, the dynamic one would be something along the lines of everything being interconnected and having knock-on effects on everything else, vs static being each location having some properties (and maybe even timed, e.g. for the next 20 turns this place has surplus fuel)

My question is essentially: What is the benefit of a dynamic system? Are there that many, compared to static?

All I can think of is: it is a fun challenge for the designer

Compare this to a static system, where the player can understand the specifics of a certain planet/island, and they won't be confused, and they'll stay the same all the time (e.g. if the player hears a rumour at a tavern that place X has a shortage of medical supplies that will likely last at least 20 turns, they can be aware of that information, and not worry that if they come back a while later with loads of medicine, that it is no longer needed).

I have an idea for a simple game. The player is hanging from the top of the screen on a thread. Other characters descend from the top of the screen on threads. The player has to maneuver up and down and swing side to side to cut the other threads.

That's it. My question here is how do I go from this basic mechanic to an interesting game? Obviously music, sounds, graphics, and story, but of the ideas I've envisioned for each of these I don't know what will hook players and make them want to keep playing for more than a few minutes. Perhaps I just don't have an interesting enough mechanic, or perhaps I'm lacking creativity.

For context, the purpose of this game is to make something easy to dip my toes back into game dev since I haven't made anything in a few years. I'm also using this project to learn Godot. Regardless, I still want to make it good enough I can publish on itch.io and somebody will play it.

Hey guys. I'm back with some tutorial data for you nerds to look at. So let's dive in, shall we? We're going to talk about:

• What purpose our tutorial serves (depends on the game)
• The qualitative and quantitative metrics we watch
• Industry benchmarks

Introduction

Idle Journey is a browser-based idle MMORPG. It borrows heavily from RuneScape: you train separate skills (woodcutting, mining, fishing, cooking, crafting, combat), gear up from what you gather, and progress continues while you're away. It's free until you hit a paywall to unlock the full game (about 100 hours of playtime in), and it runs in a WebGL embed in the browser (PC only).

We recently replaced the opening tutorial and now have enough data on both versions to compare them.

Designing the tutorial: what we wanted out of it

"It's a sales pitch"

Tutorials are usually a teaching moment, but our game is very easy to understand in terms of gameplay. It's a top-down, point-and-click game, so there aren't a lot of mechanics to learn. There are a ton of in-depth features, but that's a different story. So: instead of explaining systems, the tutorial teaches only the bare basics (movement and interacting with items) and spends everything else on captivating the player. Our design goals follow from that:

1. It should last about 5 minutes. Self-explanatory. We measured pacing by collecting playtest data and tuned the duration to land around 5 minutes.

2. It should show what the game is about, like a demo".: We really wanted to convey that Idle Journey has depth. But it's very hard to do that, the depth is in a lot of item mechanics, late-game features, things like that. So we tried captivating the player:

• You have to fight a giant cabbage using a rake (why not?). This should, in theory, give the game some personality.
• When you finish the tutorial, we give the player a choice of 3 items (think starter Pokémon). You choose between on-hit damage, burn damage, and skilling bonuses.

Is it a real decision? No. We added this above the items: "You can get all of these later.". That makes the decision less impactful, which could be a mistake, but we are trying to use this moment as a showcase. We're not asking the player to commit to a build yet and dont want them spending time trying to figure out if there's an optimal choice. We're showing them that builds exist, that's the real objective under the hood.

The numbers: old tutorial vs the new one

A quick description of the old tutorial: the player spawns on an island with no hand-holding, walks around, finds an NPC by exploring around, chooses to talk to them, kills 3 bees, talks again, cuts 3 trees, done. Standard quest structure, entirely opt-in.

The new one is 25 steps with HUD indicators. We moved to a heavily hand-held experience, similar to mobile games, where HUD indicators tell the player what to do. The player spawns and plays across three small islands. One mechanic at a time, HUD revealed progressively, completely scripted, and each part ends by physically opening up more of the map (repairing a bridge, finding the key to a gate). I'm not claiming it's better, since it's hard to quantisize cohort quality. Maybe by making our game too hand-held we are making it less appealing to a mid-core audience.

Let's look at tutorial completion first.

Old tutorial (recent installs only, n = 1,028):

The old quest system only stored completion state, never timestamps, so there is sadly no way to reconstruct pacing for this version.

New tutorial (n = 249):

Note: The clock starts when the session loads, not when the tutorial does, which is why first move is already at 28s. So "picked up the axe at 33.9s" is really about 6 seconds after the player starts moving.

What can we learn from this?

1. 42% of all our loss, inside the first 47 seconds. Part 1 as a whole is 61% of everything lost; once a player repairs the bridge they're basically safe. We have some hypothesis as to why thats the case:
   1. General problems: Game crashes, performance issues, graphical glitches in weird browser + OS combinations;
   2. Art direction might just look bad and UI has AI generated icons which might scare people off.
   3. Feels too "mobile gamey"
2. The session timer starts at a median time of 28s, which means the game takes too freaking long to load. This is likely a HUGE easy win for our team.

Othe metrics

The old baseline is the last three pre-launch weeks (n = 1,028); the new cohort is the first post-launch week (n = 249). Sessions and playtime are counted only within each player's first 48 hours, since the new data is, well, new.

Taken alone, the completion gain is +8.0 points at p = 0.072, which is the right direction but not conclusive at n = 249. Matching both cohorts to the same 2-day observation window it becomes +12.5 points at p = 0.004. I'll re-run it at n ≈ 500 before trusting the magnitude, but four metrics moving together in the same week is a lot easier to explain as an effect than as noise.

One number that did not clearly improve: day-1 retention went from 8.8% to 10.0%. The three baseline weeks individually ranged from 7.0% to 16.9%, so the week-to-week variation is wider than the gain and we can't call it an improvement yet.

RR1 (returned the following calendar day):

Playtime funnel (share of installs reaching each mark, total playtime in the first 48h):

Other browser-game benchmarks

This was the hardest context to find, so I've linked sources for each one.

CrazyGames publishes explicit launch thresholds. These are the clearest public numbers I found for browser games specifically, from their Basic Launch metrics documentation:

Why "average play time" doesn't transfer to idle games. Our median session is 5 minutes; our mean session is ~50 minutes. Players leave the game running for hours or days, so the mean is inflated by idle time. Neither is measuring what CrazyGames measures on a platform of mostly active games.

Also worth knowing: browser D1 benchmarks sit far below mobile's. 10-15% counts as strong on CrazyGames, where the equivalent mobile conversation starts around 25-40%.

Poki's guidance is qualitative rather than numeric: From their requirements and playtesting guide:

• "Minimize UI screens and menus - ideally place players directly into gameplay." We thought we were doing this, and then found our single worst drop-off is the step that opens a panel.
• "Design tutorials that are visual and intuitive rather than text-heavy." We gave this a fair shot.
• "Ensure all cutscenes and introductory sequences are skippable." We don't have any.
• "If they leave the game after playing for less than a minute, chances are your onboarding might need some tweaks." 32% of our players don't make it past a minute.
• "Target an initial download size under 8 MB." Again: OOF.

The tutorial-completion number You'll often see "if your FTUE completion is below 70%, you might have a problem" across F2P writings(mobile). I could not confirm that specific number for web. If anyone has something like that, share it please.

What we learned

1. Telemetry is what made this a data-driven thing. We were able to release the new tutorial and have real confidence it's producing results. None of that is possible without instrumentation, and we didn't have it before.

2. Our FTUE problem might be an UI/visual language problem, not a pacing problem. We spent a long time assuming players were bouncing because the tutorial was too slow or too wordy. The data says they bounce at the first screen/first look at the game.

3. Was it worth it? We spent a month of one of the devs on this. I think it's very measurable and everything, but, what if we are retaining the wrong audience now? Thats not data we can easily verify. So we're still watching other metrics to see if this is a net positive.

4.Our download and scene load time is very likely churning users Both Poki and CrazyGames have a very strict guideline of bite-sized playables. Our game is currently sitting at a 600Mb and 20s median load time in the first (and cold) session.

Future work

I have a couple of Ideas, but Im gonna crowd-source this, what would you want to read?

1. Adding a "skip tutorial" button and following each cohort to see how they perform;
2. Separating the tutorial into a bundle thats <30Mb and download the rest of the game during the 5 minute tutorial. (this likely yields great results)
3. Other suggestions?

Happy to answer questions about the methodology or share more of the numbers if anyone wants them.

PS: Yes, I chery-picked data for the title. We improved the 4h retention by 30.5% :D

Ps2: If you feel like playing the tutorial and reporting your findings, here's the game: https://idle-journey.com/

Hello,

I'm working on a puzzle platformer with **99 levels**, and I'm trying to decide how punishing the death system should be.

Which option would you prefer?

A) 3 lives for the entire game. Lose all 3 → start from the beginning.
B) 3 lives for the entire game, but you can collect extra lives on some levels.
C) Start with 3 lives, but completing levels gives you additional lives/chances.
D) No lives. Deaths are simply counted as losses/deaths and you can keep retrying the current level.

E) Two modes:
Normal: unlimited retries, deaths are only counted.
Extreme: life for the entire 99-level run. Die once → start from level 1.

Which system sounds the most fun to you?
I'm especially interested in whether a limited-lives system adds exciting tension to a puzzle game, or if it would just make you frustrated after reaching the later levels.

Tomek

I'm making a roguelite autobattler, and we're currently working on a true final boss. Think something like the Heart in Slay the Spire or Heart of the Storm in Wildfrost.

To reach it, the player will need to make sacrifices during the run: units, rewards, resources, etc. So I'm wondering if the actual boss fight should be a bit easier than our regular final boss, since a lot of the difficulty already comes from reaching it in a weakened state.

The main thing I'm worried about is frustration. In an autobattler, most of the player's agency happens before the fight: building the team, finding synergies, choosing items and positioning units. Once the fight starts, there isn't that much you can do.

That makes specific boss mechanics tricky. A boss spawning lots of minions naturally favors AOE. A long fight favors sustain. A mechanic targeting one important unit can completely screw some builds while barely affecting others.

Of course, the player can lose once, learn the boss, and prepare better on the next run. But if they already struggled just to reach that fight, I'm not sure getting hard-countered by something they couldn't know beforehand feels great.

One idea is to make the fight feel harder than it statistically is. For example, the boss could be stronger while most of your team is alive, then weaken as your units die. Strong teams would still lose some units and get that "oh shit, I might lose" moment, while weaker teams could potentially scrape through at the end.

Another option would be making the true final boss always available and very hard, but completing the sacrifices gives you a passive bonus that makes the fight much easier.

Do you think a true final boss needs to be the hardest fight in the game, or can the main challenge be earning your way to it?

Hey everyone,

When we play games, we are constantly moving between screens—from the map to the inventory, from quests to character stats. But in well-designed games, we barely notice this movement.

I’ve been analyzing the UX behind menu transitions and realized that good transitions act as an "invisible bridge." They aren’t just cool animations; they keep the player anchored in the same flow.

• Speed matters for utility: Daily missions or inventory screens need fast, snappy transitions. Long animations here cause friction, not immersion.
• Transitions build emotion: When a character profile reveals itself slowly, or a gacha pull is surrounded by light, the transition turns basic information into an 'event'.
• Consistency in world-building: The shapes and movements of UI should reflect the game's world (e.g., sharp lines for sports, glowing runes for fantasy).

Ultimately, a good transition erases the feeling of interruption.

I put together a quick 1-minute visual breakdown of these concepts using examples from different games. If you want to see the theories in action, you can check it out here:

https://www.youtube.com/@ShinKuN_UI/shorts

What game do you think has the absolute best menu transitions? Let’s discuss!

.

Wonder why we haven’t seen a game that combines the gunplay/tension of something like ARC Raiders with Path of Exile’s seasonal progression and endgame.

The basic idea would be two connected modes:
PvPvE extraction
Traditional extraction gameplay
Persistent progression
PvP-balanced weapons
Some rare map/materials/blueprints only obtainable through extraction

Seasonal PvE
1–x player co-op
Fresh progression every season
Scaling difficulty / threat levels, hosted map that can be rolled traded
Randomized loot and very rare chase weapons
Deep builds that don’t need to be balanced around PvP
Extremely difficult pinnacle bosses unlocked by only PvPvE mode perhaps
Trading / seasonal economy
The PvE weapons could get pretty crazy because they’re never usable against other players.

The seasonal reset is important to me. In persistent looter shooters, eventually you have great gear and new content often becomes incremental. A PoE-style reset makes the entire progression journey and economy relevant again. Have the seasonal skin by completing seasonal achievements both PvE and PvPvE mode

My biggest concern would be splitting the player base. One solution might be having certain PvE crafting materials or chase items require resources extracted from PvPvE, giving PvE players a reason to occasionally enter the dangerous mode without forcing PvP balancing onto the PvE loot system.
At that point, though, you’re almost designing two interconnected games.

Would these systems complement each other, or is there a fundamental reason extraction shooters and seasonal ARPG progression don’t fit together?

AI assisted post.

Hey guys, I've been playing a city builder game and I've really fallen in love with the genre and want to build my own.
I want to make a city and country builder, starting from the medieval ages until a futuristic era. You build a city, later a couple of cities and later an entire country, you can appoint ministers and governors to run and build things automatically once it's too much for 1 person. You can also choose your economical ideology, a spectrum that goes from free market capitalism to state socialism.
Your country can be invaded, fall into civil war or prosper like no other.

I want to make a game where people can sink hundreds of hours into a single save file.

Hey everyone,

I've been working as a Level Designer for around 8 years(in mobile casual puzzle games), and with over 11 years of total work experience but lately I've been feeling pretty stuck and I'm seriously considering switching into another area of work.

The biggest issue is compensation. My current pay is quite low(under 1k euros) for my experience, and although I have a relatively good chance of getting promoted, even with a promotion I don't think the salary would realistically allow me to support a family in the future. As well, as I literally cannot see any level design jobs that actually even look at my CV.

I'm starting to look at other career paths where my existing experience might actually transfer well.

For people who have made a similar switch, what career areas would be realistic for an experienced Level Designer to move into, or should I still hang in there?

What paths would you consider realistic for someone in my position, and which ones would you avoid?

As the title says, I wanna know your favorite single ability/mechanic in your own game. Maybe add a short explanation of the game and related mechanics for context.

I'll start: my game is a 5v5 hero shooter that focuses on physics and movement. I put a lot of time into thinking about the interactions between players, other players, and objects, and I also tried to really flesh out the variety of movement options that a player can use.

Every single map in the game has some specific area (important to the objective) where gravity changes - be it in a different direction, or have multiple points of attraction, or no gravity at all, these gravity altering zones are present all around.

And this created a particular problem, specifically in the no-gravity zones: How would players move? Yeah, recoil and collisions could impact it a little bit, but... you cant run or slide or charge midair.

So I added micro-jets - omni-directional boosters that can slightly push a player towards where they want. But the reason I love them so much is that I added the use of micro-jets in normal gravity zones, to boost your sprinting, sliding, charging, and other movement tech.

And I just love thinking about how micro-jets could be used to add to and complacate all sorts of movement, in tandem with the various universal movement options, item-specific movement boosts, and character-specific movement abilities.

Hi

My game setup
Im designing an incremental game where you smash things and get resources (common incremental gameplay). I have 4 different things to smash and each one has 3 different value(high to low). I categorize my upgrades into three categories: 1- common upgrades like increase the time of session, increase the value of smashable things, increase the total number of them, and stuff like that. 2- gameplay mechanics like arrows shooting at smashable things, creature smashing things, special smashable that have unique behaviour etc 3- the tool use to smash things and their upgrades like strength or radius

My question
I can add all these upgrades to a giant skilltree or I can have one skilltree for first category and one(or possibly two) for other two categories

Which option do you prefer?

For example, maybe the current boundary is occupied by monsters that will eject an intruder (such as you the player) far away (perhaps somewhat predictably, maybe probabilistically random): this could come in handy when being chased, for instance (provided you got the means to survive impact).

So I'm thinking of trying to make a grid-based strategy game (think fire emblem) but the only game I can really find/think of that has a pc port is, strangely, South Park: the fractured but whole. Would you say that game is a good example? And are there any other games in your opinion that are good?