Gamerule in Minecraft Bedrock: World Rules Without Mods

7 September 2026 · 9 min read

Vitalij Pobereznik · how we check facts

Gamerule is a built-in switch for world behaviour, and it needs no mods at all. One command changes a rule that applies to the entire world — from whether your inventory drops on death to whether time passes at all.

The “what it toggles” column is basically the rule’s name spelled out. The command page in the documentation gives syntax and a value type, not a description of each rule — so what follows is the logic behind each one, not a rehashed glossary.

Two value types — and why that matters

Rules split into two classes. BoolGameRule accepts exactly two values: true or false. IntGameRule accepts an integer. Microsoft’s documentation records this as two separate syntax lines: /gamerule <rule: BoolGameRule> [value: Boolean] and /gamerule <rule: IntGameRule> [value: int].

The practical consequence is simple. If a rule is boolean, there’s no third state — you either turn the behaviour on or off. If it’s numeric, you need to know the range: each such rule has its own upper limit, and it’s not worth guessing.

One more thing worth knowing before your first command: /gamerule itself sits at the Game Directors permission level, and its “Requires Cheats?” row reads No. So the command page doesn’t set a separate requirement to enable cheats — unlike many other Minecraft commands.

keepinventory and doimmediaterespawn: the cost of dying

Together, these two rules decide how expensive a mistake is. One is about items, the other about time.

The logic behind the choice is this. If your world is for building or for playing with a child, keeping the inventory removes the biggest reason to abandon a world — losing items in lava or in a portal. If you’re playing survival for the sake of survival itself, removing that risk strips the point out of all the preparation: potions, spare pickaxes, hidden chests.

Instant respawn is a separate matter. It doesn’t simplify combat at all — it just removes the death screen. For minigames and quick rounds that’s convenient; for slower survival play it’s not critical.

mobgriefing: between farms and intact walls

This rule turns off mobs’ ability to alter the world around them. It looks like a shield for your builds, but it comes at a cost: plenty of the game’s mechanics also run through what mobs do.

So the choice here isn’t “safer is better” — it’s “what matters more to me.” Want an untouched landscape and clean walls? Turn it off. Running a complex setup where mobs need to interact with blocks? Leave it as is and protect your builds with walls and lighting instead.

pvp: the first rule of a shared world

The rule is boolean, and that’s exactly why it settles the conflict once and for all — at the world level, not through chat negotiations.

You’ll still have things to agree on, just different ones: shared chests, territory, whether it’s fine to tear down someone else’s build. On a world hosted via Realms, where people log in at different times without you around, disabled pvp removes an entire category of arguments.

dofiretick: the quiet killer of wooden towns

Fire in Minecraft doesn’t ask permission. The dofiretick rule switches whether flames keep living on their own once they appear.

Who should turn it off: anyone building tightly with planks and logs, laying out districts with no gaps, placing torches next to walls. Who should leave it on: anyone who wants fire’s actual behaviour — burning, risk, the atmosphere of the Nether’s biomes. It’s worth deciding this before heading into the Nether — the portal and its surroundings give you plenty of ways to die even without fire.

showcoordinates: navigation, not a cheat

The most common argument about this rule is whether it’s “unfair.” The rule doesn’t add resources, doesn’t make you stronger, and doesn’t change the world. It just shows you where you are.

Who actually needs it: people playing with friends who need to explain where to go; people looking for a specific height to mine at; anyone who struggles to orient without numbers on screen. Who shouldn’t bother: anyone who wants the actual feeling of being lost and reading the terrain by landmarks.

dodaylightcycle and doweathercycle: stopping time

This is the one pair where Microsoft’s materials give a direct example of behaviour. The popular commands collection states that /gamerule dodaylightcycle false stops the day-night cycle at whatever time it’s set to. The same list of rules key to development also includes doweathercycle, commandblockoutput, sendcommandfeedback, and commandblocksenabled.

Frozen time is a tool, not a shortcut. You need it when photographing a build and don’t want night falling mid-shot; when constructing something large and don’t want to fend off mobs over and over; when recording video and need consistent lighting across every take. Locked weather works the same way: without rain, shadows and colour stay constant.

Command rules: when chat stops being readable

Three rules from that same list — commandblocksenabled, commandblockoutput, and sendcommandfeedback — aren’t about survival at all. They’re about how much system text you see.

This trio matters as soon as you’re building anything more complex than a door on a lever: a map with mechanics, an arena, an automated system. Command blocks “talk” by default, and with a dozen of them your chat turns into a solid stream of noise. If you’re just approaching builds like this, it’s worth starting with redstone basics first — command blocks run on the same signal logic.

Numeric rules and their limits

Here the main rule is: don’t invent numbers. The documentation explicitly names these values:

Spawn radius is the most intuitive of the three. A value of 0 means the narrowest possible spawn point: every player starts in the same spot. A value closer to 128 spreads spawning across a wide area. For a shared world where you want to meet up right after logging in, a small radius works better.

Random tick speed controls how often the game “touches” blocks that change on their own. The upper limit here sits far above the typical value — 4096 versus 1 — and it’s not a gameplay mode but a testing tool: a way to see how a crop or a planted block behaves without waiting for real time to pass.

The function command limit, capped at 10000, isn’t something an ordinary player needs at all. It’s a rule for people writing function files for their own maps.

How to check the current value

1. Open chat in your world.
2. Type /gamerule followed by the rule’s name — with no value after it.
3. Compare what you see with what you were about to set, and only then change it.

The basis for step two is the syntax itself: the value is shown in square brackets — [value: Boolean] and [value: int] — and square brackets mark an optional argument. What exactly the game prints back isn’t spelled out on the command page — that’s something you check in your own world.

What we’re not claiming

It’s worth marking the edge of what’s actually known here, since a lot of what circulates about gamerule is secondhand.

We’re not claiming that these same rule names and limits apply in Java Edition. The values given here come from the Bedrock documentation, and the difference between the two editions isn’t just about the interface. Check any rule name separately for your edition before carrying it over.

We’re not citing any numbers that aren’t in the documentation. No “optimal” values for randomtickspeed, no “recommended” spawn radii — Microsoft’s page doesn’t offer such recommendations, and a made-up number is worse than none at all.

And we’re not describing gamerule as a way to gain an edge over anyone. It’s a setting for your own world: rules apply to the whole world, not to an individual player, and everyone in it lives under the same conditions. Questions about other people’s servers and how they run them have nothing to do with this command.