How we built LocoStory: a geolocation game that actually brings people closer

The product we set out to build

LocoStory came out of many rounds of a popular place-guessing game. We played it a lot, with the team and with friends - and reached a conclusion that became the foundation of the whole product: that playing it together does not actually bring us any closer. We had a good time, but we got up from the game knowing exactly as much about one another as before it.

In our view that is a waste. Shared time should bring people closer, build a team - and in remote work, where loose relationships do not form on their own by the coffee machine, an occasion like that is especially valuable. We asked ourselves a simple question: what does guessing a random point on the other side of the world have to do with building a team? The answer was: nothing.

Remote work sharpens the problem. In an office, relationships form in passing - over coffee, in the kitchen, on a break - and remotely those chances simply disappear. Teams try to recreate them with shared games and social events, but most of those are either stiffly forced or fun yet empty. A game of guessing random places falls into that second category: pleasant to play, only nothing of that fun lands in the relationships.

We saw a real need in this, not just our own frustration. Distributed teams look for ways to build bonds, and the market mostly offers them artificial team-building or plain entertainment with no deeper effect. The space in between - fun that also genuinely brings people closer - was empty. That was the opportunity.

So we set out to build a game that genuinely builds relationships, rather than just passing the time. The place-guessing mechanic itself is great - it draws people in and is real fun. Only its social potential is wasted. It was enough to flip one assumption for that same shared time to start bringing people together, not just entertaining them.

Shared time should bring people closer. Guessing a random point on the other side of the world does not - so we built a game that does.

Below, how that observation became a game: the mode where players hide their own places, and the machinery beneath it - real-time synchronisation that stays fair to everyone in the room whatever their connection is doing.

What a place-guessing game is

For clarity it is worth explaining the mechanic itself, because everything rests on it. In a place-guessing game a player is dropped into a random spot in the world and sees it from street level, in a Street View panorama. They can look around and move, and from the available clues - road signs, the language on them, architecture, vegetation, the position of the sun, car brands - they try to work out where they actually are.

When ready, they drop a pin on the world map at the spot they believe matches what they see. The closer to the true location they land, the more points they score. It is a deceptively simple loop that can hold a player for hours: it combines the detective satisfaction of reading clues with real knowledge of the world, and each round is a small puzzle set in a real place.

What makes the mechanic addictive is the combination of two pleasures at once. One is the detective satisfaction of reading the world - from small clues a player forms a hypothesis and sees how close they got. The other is learning in passing: after a few rounds a person starts recognizing countries by their vegetation or the style of their signs, and is surprised how much of the world they know. It is a good, worthwhile loop - it seemed a shame to leave its social potential unused.

Its popularity is no accident. People like to feel they understand the world, and this game gives them a small, instant confirmation of it every time they land close. It is that "I knew it!" thrill that turns one round into ten - and it was that thrill we wanted to keep, adding to it what was missing.

It is worth noting the low barrier to the mechanic itself. To start, a player needs no skill at all - it is enough to look around and try. And at the same time the skill ceiling is high: the more someone plays, the subtler the clues they notice. That is a rare quality of good fun: easy to start, hard to stop, and always something to get better at.

It is also worth adding that it can be played at very different levels of engagement. One player treats it as casual entertainment for a few minutes, another as a sport where every point counts. LocoStory leaves room for both, because good fun is the kind where everyone sets for themselves how hard they want to try.

It is on this mechanic - observe, move, guess, score for accuracy - that LocoStory builds, and which it re-values. We kept what is good in it and changed the one thing that decides whether playing together leaves anything behind.

Shared time should bring people closer

At the heart of LocoStory is the belief that time spent together should build a relationship, not just pass. A classic game of guessing random places is enjoyable but socially empty: after an hour of shared fun the players know nothing more about one another than before. There is competition, some laughter too, but no trace is left on how well the players know each other.

The oldest mechanism for bringing people closer that we know of is at work here: the story. People bond through the stories they tell one another, not through numbers on a scoreboard. LocoStory simply wraps that truth in a game - instead of asking someone to talk about themselves, it gives them a place that starts the story for them, and fun that makes the rest want to hear it.

It shows best in contrast with classic team-building. Forced team-building often fails because it tries to bring people closer on command - "and now tell everyone something interesting about yourself." LocoStory takes the opposite route: it does not make anyone open up, it creates a situation where sharing something personal is a natural part of the fun. Opening up comes on its own, because it is built into the game, not bolted on beside it.

So we asked: what would make exactly that same shared time start connecting people? The answer turned out to be simple - the content has to be made personal. If the places in the game are not random but belong to specific people and say something about them, each round stops being an anonymous puzzle and becomes a small window into someone's life.

It is a small shift of assumption, and it changes everything. The same mechanic, the same time, the same thrill of guessing - but a completely different social outcome. Instead of parting after the game with the same distance as before, people leave it knowing something new about each other. That was the point from the start.

The mode that builds relationships: sharing a place that matters

LocoStory's flagship mode flips the classic game in one point: instead of the game picking a place at random, a person does. Each player chooses a place that means something to them and that they want to share - the yard of their childhood, a spot from an important trip, a favorite cafe, the place of a first date. The other players, moving through Street View, try to guess where it is.

In practice it looks like this: before a round one of the players secretly picks their place, and the others are dropped into it and search for it in Street View. The tension rises, because everyone wants to land the closest - and when the round ends and the place is revealed, its author says what it is. It is exactly this moment, repeated round after round, that makes all the difference.

The guessing is still the game - it is what gives the tension and the fun. But the real point is what happens around it: when the place is revealed, its author tells why this one in particular. And suddenly a round of the game turns into a story, and the other players learn things about each other that no forced conversation about "interesting facts about yourself" would ever draw out.

Importantly, sharing here is safe, because it happens on each person's own terms. Nobody has to tell anything they do not want to - each person decides how much they reveal about a given place. One will only say "that is my childhood yard", another will tell the whole story. That voluntariness makes the game work for a team that is only just getting to know each other, just as well as for a group of close friends.

The effect can be surprisingly strong. It happens that after a single evening's play, people on a team know more about each other than after months of work meetings. Not because the game forces them to, but because it gives a natural pretext to show a piece of themselves - and the other side does not interrogate, it searches and guesses. It is a rare combination: deeper acquaintance without the awkwardness that usually comes with it.

Every hour of playing like that genuinely brings people closer, because it is woven from small, personal stories. That is exactly the difference we were after: the same guessing loop, but with content that belongs to the people at the table. The game becomes a pretext for getting to know each other, and getting to know each other happens along the way, over good fun - which is how it works best.

The other ways to play

Around this idea we also built modes that give the joy of the classic game, because not every moment has to be deep team-building - sometimes it is simply about good competition. So LocoStory includes several ways to play, all built on the same engine.

There is a solo mode, the classic guessing of random locations alone, for someone who just wants to sharpen their eye and test their knowledge of the world. There is live clash - traditional real-time play with friends, where players guess random places together and compete for points. It is a familiar, proven format, only played in the company one actually feels like.

We also noticed that people sometimes want to compete over how well they know a particular place or city. Say a group was together in New York and wants to see who finds their way around Manhattan better. In LocoStory they can drop a pin in Central Park, set a radius, and within that circle the game picks places to guess. Local knowledge - which no one has any reason to learn beyond having been somewhere - turns into a friendly rivalry and another pretext for playing together.

The pin-and-radius mode turned out to be surprisingly flexible. The circle can be narrowed to a single neighborhood or wrapped around a whole city, testing knowledge of a home area or of a place a group visited together. Each time the game fits the places it picks to the area the players themselves marked out - and again, what is personal becomes the content of the fun.

Taken together, these modes form a spectrum: from purely social sharing of places, through classic competition, to a test of local knowledge. A group can start with light fun and end in a fierce duel over who knows their own city better - without leaving one game. That range is what makes LocoStory fit a team's first shared evening and their hundredth alike. The common denominator across all the modes stays the same: the real world as the board, and people playing together. Only whose places are being guessed, and how fierce the rivalry is, changes - and that is enough for one game to serve very different moods of one group.

How we approached the build

This build opened with a product decision rather than a technical one: working out what would make the shared time actually worth something. That was a product decision, not a technical one, but without it all the rest would be just another clone of a familiar game.

Only with that foundation did we take on the hard technical core: real-time play that stays consistent and fair for all players, and entry simple enough that someone can play right after clicking a link, without creating an account. These two things decided whether the game could realistically be used in a group, so we settled them first.

Front-loading the risk also buys an early verdict on the idea itself. Had fair, consistent real-time play turned out to be unaffordable, far better to learn it in week one than after every mode had been built on top of it. Clearing the project-killers first is what makes a promised deadline keepable.

From here the write-up tracks the build: why people play together at all, then the hard core of real-time play, then the work of dropping the barrier to entry to zero.

Real-time game state for 2-8 players

The hard technical core of LocoStory is real-time play. All the players in a room - from two to eight - have to see the same game state at the same moment: the same round, the same place being guessed, the same time on the clock, the same scores. A game where everyone sees a slightly different version of reality simply falls apart.

The difficulty comes from many players acting at once. Someone drops a pin, someone else is still looking around, someone is running out of time - and the game state has to stay consistent across all of them at once, with no situation where two people see contradictory scores or a different stage of the round. Keeping one shared truth about the play, updated live for everyone, is the core of this part of the work.

It is worth stating concretely what that state is. It is not a single number - it is the current round, the place being guessed, the ticking clock, the pins already dropped by individual players, the scores, and in turn-based modes the order of turns too. Any of these can change at any moment for any player, and everyone else has to see that change consistently and at once.

On top of that come events that must be resolved unambiguously even though they arrive at the same time. Two players drop a pin in the same instant; someone's time runs out exactly as they submit an answer. The game has to have one consistent understanding of what happened and in what order, so that the outcome is the same for everyone, and does not depend on whose click arrived first on a faster connection.

The range of two to eight players matters technically too. It is a size where every participant is active and visible, and the number of simultaneous actions to reconcile is real but manageable. Designing consistent state for such a group is a different task than for a crowd of spectators - here everyone is a player whose moves immediately change the picture of the game for the rest.

Designing this so that it feels instant and never drifts out of sync is much harder than it looks. It is exactly the kind of engineering a player does not notice when it works - the game just plays smoothly and everyone is on the same page - and that is glaringly obvious the moment the state desynchronizes.

Fairness: latency and consistency

In a competitive real-time game, fairness is everything. No one can have an advantage or a disadvantage just because their connection is faster or slower. The result should turn on how well someone guessed, not on how fast their connection is.

A simple example captures it well. The clock counts down to the end of the round, and two players submit an answer just before time - one on a fast connection, the other on a slow one. If the network delay alone decides whose pin "made it", the player with the worse connection loses not because they guessed worse, but because they connected worse. That is exactly the unfairness that has to be removed.

It means the clock, the moment the answer is revealed and the scoring all have to be consistent for everyone, no matter where each person sits or how good their connection is. Reconciling that with the nature of a network, where data reaches different people at slightly different times, takes deliberate decisions about what is resolved and when - so that the outcome is fair, not dependent on ping.

The solution is to have that one shared place decide what counts, rather than the browser of the fastest player. When a round ends, when an answer is accepted, how points are scored - those decisions have to be made consistently for the whole room, on rules that are the same for everyone. Only then does the competition measure skill, not the quality of a connection.

There is also the reality of imperfect connections. Someone drops out of the game for a moment and comes back, someone's browser freezes mid-round. The shared state has to withstand it: a player who returns should immediately see the current situation, not the one from before they disconnected. Designing play to survive such small failures without spoiling the fun for the rest is part of what separates a game people can actually play from a technical demo.

In the end it is about trust in the result. Players will accept a loss if they believe they lost fairly - but a single suspicion that the connection, not the skill, decided can spoil the whole competition. So the rulings had to clear a higher bar than consistency: they had to feel fair to everyone at the table, which took considerably longer to get right.

Moving through the world: maps and Street View

The game world in LocoStory is the real world, available through maps and Street View. Players move through panoramas, look around, follow clues and return to the map to drop a pin. It is an integration that has to be smooth, because the whole play rests on free, instant movement through real places.

Wiring this into the game cleanly - so that it is fast, responsive and does not break the rhythm of play - was a challenge of its own. Smoothness translates directly into fun here: a game where the world loads in stutters, or moving around is sluggish, stops drawing people in, however good the idea for the modes.

Basing the game world on an external maps service is also a decision with consequences. It has to be wired in so that it works fast and predictably, and at the same time the play has to be designed with its limits in mind - because what a panorama shows, and where a player can walk, sets the bounds of what the game can offer. Reconciling our own game logic smoothly with the behavior of an external service is part of this work that a player never sees.

There is also a particular charm in it: the entire game board is the real world. Any place someone has ever been can become a round - from an alley in a home town to a beach from a vacation on the other side of the globe. That unlimited board means the game does not run dry, because there are as many places worth sharing as there are people playing.

The world as a board has its cost, too: real places are uneven. Not everywhere can be walked, not everything is equally covered by panoramas, and some corners look confusingly alike. Designing the play so that these unevennesses of the real world do not spoil the fun but become part of the challenge was one of the smaller but important elements of this work.

That unpredictability has its upside, too. Since the board is the real world and the places are chosen by the players themselves, no two rounds are the same, and the game's content renews itself, because it comes from the experiences of the people sitting at it. It is one of the reasons a game like this does not get old as fast as a closed set of levels: as long as there are new people and new places they want to share, there is something to play. For the product it means a healthy dynamic - the more people play, the richer the game becomes for the next ones.

Private rooms on a code

LocoStory is played in private, code-protected rooms, not with random people from the internet. It is a deliberate choice that follows from the game's purpose: since the point is to bring specific people closer - a team, a group of friends - play has to happen in company that invites itself.

We deliberately gave up matchmaking players from across the internet. In a game whose goal is to bring specific people closer, playing with strangers would miss the point - and would open the door to all the problems that anonymous play with strangers brings. A private room on a code keeps the fun where it has value: among people who chose to be there.

Creating and joining a room is simple: someone creates a room, shares a code, the rest come in. That simplicity is not accidental - the fewer steps between the idea of "let's play" and the moment everyone is in, the greater the chance the game actually happens, rather than getting stuck on the logistics.

The room size - from two to eight people - is not accidental either. It is the range in which everyone gets a turn to speak and show their place, and the play does not dissolve in a crowd. A smaller group favors the conversation the game is meant to spark, and the upper limit keeps everyone a participant rather than a spectator.

Playing without an account

A person can enter a room as a guest, with no signup - just click a link. It seems a small thing, and in a social game it decides everything. If, in order to play, everyone first has to create an account, confirm an email and think up a password, half the group will never join - they will drop off at the first signup screen.

Removing that barrier is the difference between a game people actually play together and one they only mean to play "some day". Guest entry means that seconds separate clicking the link from being in the game, not a form. For a product whose entire value arises when a group gathers, it is one of the most important decisions we made.

Building this well is not as simple as it sounds, though. A guest has to be able to fully take part in real-time play, have their identity for the duration of the game and their own score, all without a permanent account underneath. Reconciling a zero barrier to entry with full participation in the game took thinking through who is who in a room when, formally, they are no one.

Guest entry does not close the door on those who want to stay longer, either. A guest who enjoys the game can create an account later and keep their history - but that is their choice, made after the product has already won them over, not a condition set before the first round. Order matters: value first, then any commitment.

Open to everyone in the browser

LocoStory runs in the browser, so anyone can join from any device without installing anything. For a spontaneous social game that is a necessity: the moment a group feels like playing is fleeting, and every obstacle - downloading an app, installing, permissions - is a chance for the enthusiasm to fade before everyone is ready.

The web makes the "let's play now" barrier as low as possible: a link, a click, the game. That accessibility, combined with guest entry, is two sides of the same decision - to have nothing stand between the wish for shared fun and its start. In a product that lives on people gathering together, lowering that barrier is a feature as important as the game modes themselves.

The browser brings its own challenges, too. Smooth real-time play, with maps and panoramas, has to work across different devices and different levels of hardware, from a powerful laptop to a phone. Keeping the same good experience across such a wide range of conditions is part of what makes "just click and play" actually work for everyone, not only for the best-equipped.

Behind all of it stands one principle we followed in every decision: nothing may stand between a group and the start of the fun. An account, an install, configuration - each such obstacle is a moment where someone drops off, and with them the group for whom the whole game makes sense. A disproportionate share of the effort went into things whose only purpose is to get out of the players' way.

What this build shows about how we work

Cloning a place-guessing game is a straightforward piece of work. Keeping eight people on one consistent truth, resolving two clicks that arrive in the same instant, and making sure nobody can blame a loss on their connection - that is where the engineering actually sits, and none of it is visible in a screenshot.

Eight people and one shared clock is not something anyone verifies alone at a desk. The synchronisation had to be exercised by real browsers on real connections, deliberately degraded, because a race condition that needs two humans clicking in the same instant will never surface in a unit test. That is also why the person testing was not the person who built it: reproducing the failure takes more hands than one author has.

Multiplayer games have a reputation as one of the harder things to do well, precisely because they combine everything at once: real time, many users, an imperfect network and high expectations of smoothness. That LocoStory simply works - that eight people click at once and the game stays consistent and engaging - is itself proof that we have this kind of engineering well rehearsed.

The game itself is incidental to what this demonstrates. What carries over is shared state that stays consistent while a whole group acts on it at once, an outcome nobody can attribute to latency, and a session that survives a browser dropping out mid-round. Collaborative editors, live dashboards and trading screens all need exactly that.

What we would tell another team

For anything where people act together in real time - games, collaboration tools, group products of any kind - five things worth settling early.

• Ask why people do it together. Copying the mechanic is the easy part. The real value comes from understanding what a group genuinely wants from shared time - and designing for that, not for the mechanic alone.
• Consistent real-time state is the core, not an add-on. When many people act at once, everyone has to see the same truth at the same moment. Plan for it from the start - bolting it on later usually means a rewrite.
• Fairness against latency decides competition. If the connection, not skill, co-decides the result, players stop trusting the game. Design what is resolved and when, so that ping never wins for anyone.
• Drop the barrier to entry to zero. In a product for a group, every extra step before starting is people who will not join. Entry with no account and no install can decide whether the group even begins.
• Smoothness is part of the gameplay. If the game world loads in stutters, the best idea for the modes will not save the experience. Responsiveness is a feature, not cosmetics.

None of these can be retrofitted, which is what makes them worth settling before the first sprint. Consistent shared state in particular is not a feature added later - it is an assumption baked into how every other part of the system gets written.

Frequently asked questions

Is LocoStory your own product, or did you build it for a client?

It is our own. We came up with it, designed it, built it and shipped it ourselves. We show it because it is proof of what we deliver, and we build for clients the same way.

Could you build a real-time multiplayer product?

Yes. LocoStory synchronizes game state in real time for several players at once, and the same approach works for any product where people act together at the same moment.

How do you keep gameplay in sync and fair across different latencies?

We design the state so that all players see the same game at the same moment, and the outcome does not depend on who has the faster connection. In a competitive game, fairness against latency is a requirement, not a detail.

Can the product work without creating an account?

Yes. In LocoStory a person can join a game as a guest, with no signup - just click a link. For a social product, removing the account barrier is the difference between a game people actually play together and one they only mean to.

Can you integrate maps and Street View, or a similar service?

Yes. The game world is the real world, which players move through in Street View panoramas. Wiring that integration smoothly into the gameplay was part of the project.

Do we own the code and the accounts?

Yes. You own the code, the repositories and the accounts. We can hand everything over to your in-house team whenever you need it, with no lock-in.