Mobile Word Game Development
Word games are a genre where main technical complexity lies not in graphics or physics but in dictionary work and word search algorithms. Incorrect dictionary implementation—and game works incorrectly on 15% of devices due to encodings, or freezes checking 8-letter word.
Dictionary base: storage and search
For Russian word games, dictionary ranges from 100,000 to 500,000 words. Storing as string list in List<string> and doing .Contains()—O(n) search, 500ms on weak Android. Unacceptable.
Correct structure: Trie (prefix tree). Word search is O(k) where k is word length, usually 3–15ms on any device. Additionally, Trie allows finding all words with given prefix—needed for hints and autocomplete.
Compact implementation in Unity via Dictionary<char, TrieNode>. Serialization to binary format (MessagePack or custom)—loading 300K word dictionary from binary takes 200–400ms vs 2–3 seconds from JSON.
On Android: StreamingAssets with async loading via UnityWebRequest.Get (mandatory, direct File.Read doesn't work from APK). On iOS: standard Resources.Load or Addressables.
Encodings and Unicode
Cyrillic in Unity is UTF-16 strings, works correctly. Problems start with character work: е (Cyrillic) and ё (yo)—different characters, but players often confuse. Need normalization: on е input, check both variants in dictionary. Also: uppercase via char.ToLower() with CultureInfo.GetCultureInfo("ru-RU")—not ToLower() without arguments.
Letter input UI
For scramble and crossword-type games—custom keyboard from Button components on Canvas, not system. Gives full layout control, haptics (Handheld.Vibrate() on Android, UIImpactFeedbackGenerator via iOS plugin), tap animation.
Drag-to-select for Wordsearch and anagrams: IPointerDownHandler, IDragHandler with GraphicRaycaster.Raycast iteration over points between previous and current finger position on each IDragHandler.OnDrag call.
Timeline: word game with one mode and 100K word dictionary—6–10 weeks. With multiple modes, daily missions, multiplayer—3–5 months.