Mobile word game: where word validation breaks
Word validation in the game breaks down before the interface does. The dictionary does not cover word forms — a player places a valid plural noun, and move validation rejects it.
The game does not fall apart after that, but trust in the rules is lost: from then on the person plays cautiously or leaves for an app that accepts more words.
The second failure point is responsiveness on long chains. Board logic must check the word, intersections, bonus squares, and scoring in fractions of a second, while iterating over a word list at each letter causes noticeable lag on long placements.
A prefix tree and inflection rules remove the problem: search goes through branches rather than the entire array, and highlighting options remains instant.
The third source is connectivity. A player's move validation sent to the server is lost during a disconnection, and the game diverges: one player's word is accepted, the other's is not.
Numbered moves and the full position state save the day — after reconnecting, the app resends the unconfirmed move and receives the current board.
Dictionary bottlenecks usually lie outside the search code: there are no inflection rules for the language, no separate set of proper nouns, no lexicon filter.
All of this is exposed by live players, not tests, and is closed by a set of dictionaries that update without releasing a new version of the app.
A mobile word game rests on three things: dictionary completeness, word validation speed, and game integrity during a connection drop. We explain how each of these areas is addressed in our work.
Dictionary and responsiveness in the game: what changes after rework
The dictionary stopped being a monolith held entirely in device memory. We split it into a prefix tree of the frequency core and loadable layers of rare words: move validation runs against the local structure, so responsiveness does not depend on connection quality. The dictionary size has grown several times over.
The weak point was word-form recognition: a player entered "run", "runs", "ran", but only one form was accepted, and the move was lost.
Now input is reduced to a lemma using a morphological model verified against data from the Russian National Corpus — the share of correctly recognized words grew from two-thirds to almost full.
Move response speed changed radically: previously every word went to the server and waited for validation; now the decision is made on the device. A move is confirmed the moment you touch it, and the network is needed only to synchronize the game result.
Game stability rests on a move log: it is written step by step, and when connectivity drops in the subway or an elevator, the session is restored from the last confirmed move. Recovery time is a few seconds instead of recreating the game and losing progress.
We separately closed the class of failures that generated the most support requests: dictionary desynchronization between app versions and double-counted moves.
The dictionary version and validation rules are recorded in the game itself, the server only reconciles the result — the share of completed games has grown noticeably.
Options for dictionary assembly and move validation: comparing approaches
A player experiences move validation as interface responsiveness: if the response lags, the letter "does not place" and the person thinks the app is broken.
That is why the validation mode is chosen before development starts — moving from a dictionary in the build to server-side validation means rewriting the rules layer and rebuilding the dictionary itself.
Technical alternatives
| Option | When it fits | Limitations of the approach |
|---|---|---|
| Local dictionary in the app | Single-player game, offline mode, early prototype | Build weight grows with the dictionary; the word set is available on the device, and updates only come with a new app version |
| Server-side move validation | Multiplayer, rating, tournaments, protection against rule substitution | Every move depends on the connection channel; on a weak network the interface waits for a response, and the server bears the load for all games |
| Hybrid scheme | Multiplayer and offline in one app | Two sources of rules are synchronized by version; dictionary divergence breaks the game, and support burden is higher |
| Ready-made game module | Standard rules, launch in a short time | Rules and dictionary are limited by the vendor's capabilities; custom modes and custom scoring are almost impossible to extend |
How it is chosen in practice
The choice comes down to three questions: whether there is online play and rating, whether offline is needed, and how much the game's language differs from the standard one. For single-player games, a dictionary in the build is enough — this is the easiest path to support.
As soon as there is an opponent and a shared score, validation moves to the server, while the local dictionary remains a fallback for offline.
Work stages: from dictionary analysis to build handover
The order of stages here is not a formality: the dictionary and move rules determine the state structure and how many simultaneous games the server can handle. That is why we first fix the game model in schemas and only then write code. Each step ends with a build that can be installed on a device and played in a game.
-
Game logic audit. We examine the prototype or third-party code: how the board is built, words are validated, and points are awarded. The output is a list of bottlenecks and a decision on what to reuse and what to rewrite.
-
Dictionary data schema. We split the dictionary into a prefix tree: word validation and hints run without full iteration. We separately describe language sets, letter weights, and dictionary updates without rebuilding the app.
-
Move rule configuration. We fix move validation, timings, letter replacement, and game completion conditions. Separately — conflict resolution when players move at the same time.
-
Game synchronization and multiplayer. The server computes state: the client sends a move and receives confirmation with the updated board. We design for connection loss and return to the game with the same score.
-
Game testing. We run the dictionary through automated tests, play games against bots, and check rare cases — mixed languages, disputed combinations, simultaneous moves. A load test shows how many sessions a node can handle.
-
Project handover. We deliver the repository with history, builds, data schemas, a description of the rules, and the update release procedure. We train the team: from local launch to troubleshooting game failures.
Delivery scope: data schemas, move rules, documentation
Delivery is not only the assembled app. At acceptance, we hand over a set of artifacts that make it possible to develop the game without us: structure descriptions, regulations, access, and documentation. Below is what exactly ends up in the customer's hands.
- Game core data schema — dictionary, levels, profiles, progress, game history: fields, types, indexes, relationships between tables. Plus migrations to extend the structure without losing user data.
- Move and scoring rules — what counts as a valid word, how disputed combinations are resolved, and how the game behaves during a connection drop and resubmission of a move.
- Dictionary update procedure — the format of the addition file, the order of validating new words, and versioning of sets so that already started games do not break.
- Content moderation rules — name and chat filters, a stop-word list, the moderator's procedure, and a log of decisions for each case.
- Service and environment schema — where the game server, storage, and queues are deployed, how access is issued, and how secrets are stored.
- Project documentation — architecture description, local launch and build, update release procedure, and rollback to the previous version.
- Access and rights — repositories, admin panels, analytics, and app store accounts are registered to the customer.
Delivery scope is fixed before work starts and checked item by item at acceptance — no "we'll add it later."
Case study: metrics before and after core rework
What the metrics showed before rework
The core was built for a quick prototype: the dictionary loaded in full, and move validation recalculated available options from scratch every time.
On mid-range devices, response stretched to one and a half seconds, the share of correctly recognized words stayed at 71%, and roughly every ninth game ended with a support request — most often a complaint about a "stuck" move.
Players left before the final: the share of completed games did not rise above 46%, and second-day retention was 21%. For a word game this is critical: a game is short, and one stuck move costs the entire match.
What we changed and what the result was
We split the dictionary into a prefix tree and keep the hot part in memory, and we calculate move validation incrementally — only across changed cells.
Multiplayer game state was moved to Redis with a short key lifetime: the opponent's move arrives by event rather than being pulled by polling once per second. The same word validation rules work offline, so local play does not diverge from server logic.
After the rework: word recognition — 99%, move response — tenths of a second, share of completed games — 78%, second-day retention — 34%. Support requests fell sixfold per thousand games, and server load at the same number of players dropped by half.
How does server-side move validation differ from local validation?
Local validation performs move validation on the device: the word is checked against the dictionary in the app's memory, and the response is instant. Server-side move validation does the same on the service side — the device sends a move and waits for a verdict. This choice affects not only interface responsiveness but also who owns the truth in the game.
The client is an untrusted environment: everything in the build is eventually extracted — the dictionary, letter values, combination rules. If word validation lives only on the device, protection against hints relies on code obfuscation.
A server-side arbiter exposes only the verdict for a specific move, and it cannot be used to reconstruct either the dictionary or rare words.
The server-side option has its own trade-off: a round trip to the service is added to every move, and on a weak connection the game "sticks." Support complexity also grows — redundancy, request limits, and separate capacity for tournament load.
Working without a connection requires an offline mode with a move queue and subsequent state synchronization, where conflicts are resolved by the rules, not by whose move arrived later.
In practice, a hybrid is used. Local validation serves single-player games and interface highlighting — a move feels instant, while the server remains the arbiter in multiplayer and rating.
State synchronization is built on numbered moves: the server accepts a move, rejects the conflicting one, and broadcasts the confirmed state to all participants.
The rules are kept in one shared module with tests; otherwise the client and server diverge in word interpretation and players get different answers for the same move.
Technical concerns: dictionary, latency, updates
Before starting, the customer checks not the game mechanics but the decisions that are expensive to change later: how the dictionary is updated, what responsiveness is like on weak devices, how much work a second language adds, and how the game is ported to a second platform. These are architectural forks — they define the data structure and scoring rules.
Below are answers to what is most often asked during the evaluation stage.
Will the dictionary have to be updated together with the app?
No. The dictionary is a separate data set with its own version: the game pulls the current one and stores it locally, so additions are released without a new app build. A player without a network uses the last downloaded set, and rollback to the previous one is done in one step.
What about response lag on a weak device?
Move validation runs on the device itself: the dictionary is loaded into memory at launch, word lookup does not wait for the network, so highlighting and touch response do not depend on connection quality. The server participates only in reconciling game results.
How much work does a second language add to the game?
The dictionary and rules are moved into separate configurations and do not touch the scoring logic. Adding a language means connecting a word set and interface translation, not rewriting the game; the next language follows the same scheme.
How does porting to a second platform work?
The core logic is a shared module; only input, payment, and notifications are implemented separately. The second platform does not turn into a second project: the game core is ported rather than written from scratch.
Who is responsible for word moderation?
A move that is not in the dictionary is not accepted, and unacceptable combinations are filtered out by a separate filter — it updates without releasing a build. Disputed moves go into a log, so moderation rules are refined based on real cases.
Discussing the task: what we will need from you and how the work will proceed
So that the project estimate is based on facts rather than guesses, one substantive conversation and a small set of inputs are enough.
There is no need to prepare a technical specification in advance — describe the idea and show what already exists: a prototype, mockups, old code. We will analyze the mechanics, propose a reasonable scope for the first version, and come back with an estimate and work plan.
What we will need from you:
- Game mechanics: which modes are needed (single-player game against the dictionary, duel on one device, online matches) and how points are calculated.
- Dictionary base: languages, size of the word set, what to do with disputed and rare words, whether server-side move validation is needed.
- Platforms and audience: phones and tablets, whether offline mode is required, whether progress synchronization between devices is needed.
- Access and materials: app store accounts, existing mockups, a domain for the server side, current code or prototype, if any.
- Constraints: desired timelines, store requirements for content and age ratings, integrations with analytics and payments.
- Who makes decisions: the person who will approve disputed points on game rules and interface.
The first step is task analysis and a reverse work plan: what we do each week, where the approval points are, and what goes into the first build. Describe the task in a convenient form — we will come back with an estimate and plan.