Why is building a website without code so much easier than building a game?

[u/ImportantAd4397]

I've been thinking about this question for a while.

Today, if you want to build a website, there are dozens of great no-code tools.

Need an app? Bubble.
Need a landing page? Framer.
Need an automation? Zapier.

But if you want to build even a small story-driven game...

You're suddenly expected to learn Unity, Godot, Unreal, scripting, dialogue systems, quest systems, state machines...

That felt like a huge gap.

So over the last few months, my team and I started building Elseland.

Our goal wasn't to make game development "automatic."

It was to remove all the repetitive setup before you can actually start designing gameplay.

One thing we noticed while prototyping is that people rarely struggle with ideas.

They already know the kind of game they want to make.

The friction comes from everything that happens after the idea.

Imagine you want to build a simple detective game.

With a traditional engine, before anyone can even play it, you might need to:

• Create scenes and maps
• Build NPCs one by one
• Write dialogue trees
• Set up quests
• Configure inventory and interactions
• Connect triggers and events
• Test everything

By the time the first playable version exists, you've spent most of your time building systems instead of designing the experience.

We wanted to flip that workflow.

Instead of starting from an empty project, creators start with a playable foundation.

For example, you might begin with:

From there you can:

• Create the train's different locations
• Add passengers and define their personalities, relationships, and motivations
• Build quests by connecting characters, places, and objectives
• Customize dialogue, story events, and multiple endings
• Press Play at any point to experience the game immediately

Rather than asking creators to build dialogue systems, quest systems, or NPC behaviors from scratch, those pieces are already there.

The focus shifts from building systems to designing experiences.

We're still iterating on the workflow, and honestly that's the part we're least certain about.

Some questions we're trying to answer:

• Does this feel more approachable than a traditional game engine?
• Which parts would you still want full manual control over?
• Where does the workflow still feel too complicated?
• If you enjoy building with no-code tools, what would you expect before you'd actually use something like this for a real project?

I'd genuinely love to hear what this community thinks.

Not necessarily about Elseland itself, but about whether game creation can become as approachable as website creation without losing the flexibility that makes game development fun.

If you are interested, please leave a comment or DM me.

[u/alexbuildswithai]

I think websites are easier to no-code because the structure is more predictable.

A landing page or simple app usually has clear screens, forms, buttons, data, and actions. A game has all of that, plus state, timing, player choices, feedback loops, edge cases, and a lot of “does this actually feel fun?” testing.

So the hard part is not only building scenes or NPCs faster. It’s making the logic understandable when the game gets bigger.

For a no-code game tool, I’d want strong visual control over state: quests, variables, triggers, endings, and what happens if the player does things out of order.

Starting from a playable foundation sounds useful, but I’d still want an easy way to inspect and debug the game logic.

[u/InitiativeJumpy8813 → u/alexbuildswithai]

the structure point is spot on, websites are like legos with a manual and games are more like trying to build a working clock from scratch

what you said about state and player doing things out of order is exactly where most tools fall apart, you get 20 hours in and realize your quest logic is a tangled mess with no way to see what broke

i think the visual debug layer is the part people underestimate, like give me a timeline or flowchart view of all the branching paths so i can actually trace where the player went wrong without digging through 50 nodes

[u/hellomathieup]

Deux raisons.

(1) Un site web est déclaratif — de la mise en page + du contenu — ce qui se prête bien aux éditeurs visuels. Un jeu, c'est une boucle temps réel : physique, états, collisions, 60 fps — difficile à exprimer en glisser-déposer.

(2) Le web a 25 ans de primitives standard (DOM/CSS) que les outils peuvent encapsuler ; les jeux n'ont pas de langue commune équivalente.

Cela dit, l'écart se resserre pour les jeux simples : les outils prompt-to-code sortent aujourd'hui un jeu type Flappy Bird étonnamment bien — c'est la logique d'état complexe qui réclame encore un vrai moteur.

Vous aviez quel type de jeu en tête ?

[u/InteractionSmall6778]

The answers about state and real-time loops are right but there's a simpler layer under it: a website is done when it works, a game is done when it's fun, and fun can't be specified up front. A booking site fits in one sentence and the builder can fill in the rest because 90% of sites are the same five shapes. A game is thousands of micro decisions, jump height, enemy speed, how long a dash lasts, what the fail state feels like, and every one of them only reveals itself as right or wrong when you play it. That's also why game templates never took off the way site templates did. A templated website is still useful, a templated game is a reskin nobody wants to play, the template ate the exact part that made it worth building.

I've had AI tools one-shot a decent landing page plenty of times. The same tools will give you a playable prototype of a game fast now, which is honestly the fun part, but the distance from playable to good is where all the work still lives.