{"schemaVersion":1,"license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","lessons":[{"id":"scope-and-prototype","lang":"en","title":"Scope and a testable prototype","description":"Choose one question, limit the work, and decide what to do after evaluating a prototype.","category":"design","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["scope","prototyping","playtesting"],"sources":[{"title":"Unity Learn: Prototyping","url":"https://learn.unity.com/pathway/creative-core/unit/prototyping"}],"url":"https://gamemechanics.pro/en/lessons/scope-and-prototype/","markdownUrl":"https://gamemechanics.pro/content/en/scope-and-prototype.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nYou do not need an engine or an existing project. You need an idea for a player action and an uncertainty that blocks the next decision. The outcome is a small investigation with a clear stopping point, rather than a list of everything the game might eventually include.\n\n## The principle\n\nA prototype earns its place by reducing a specific uncertainty. “Make a roguelike” does not identify what to test. “Can a player distinguish two attacks from their warning cues?” describes an observable question. [Unity Learn: Prototyping](https://learn.unity.com/pathway/creative-core/unit/prototyping) introduces choosing a prototyping approach to fit a project's question.\n\nLimit the action, environment, and outcome. One enemy, one room, and two warning cues may provide the observations you need. Inventory, progression, and story do not yet help answer this question. Put them on a separate list so that returning to them is a deliberate choice.\n\nDistinguish an idea prototype from a vertical slice. Investigation may only need placeholder graphics and a manually triggered scenario. A slice demonstrates an integrated piece of intended production quality, so it has different costs. Choose the form that supports the upcoming decision.\n\n<span id=\"example-can-players-read-an-attack\"></span>\n\n## Practical example\n\n### Can players read an attack?\n\nWrite an experiment card before development:\n\n```text\nQuestion: can players distinguish two attack warnings?\nMaterial: one arena, one enemy, two attacks, quick restart.\nBudget: one evening to build, then a short observation session.\nObservation: which attack does the player predict before it starts?\nContinue if: 8 of 10 predictions are correct after introduction.\nOtherwise: change one cue and repeat the exercise.\nStop: after two variants, reconsider the attack designs themselves.\n```\n\nThese numbers illustrate a preselected decision criterion, not an industry standard. Ten attempts by one person do not prove that a broad audience understands the mechanic. The result can guide the next change without replacing sessions with additional players.\n\nShow each attack separately first. Then vary their order and ask the player to predict the attack before it executes. Record mistakes, when the decision was made, and comments about visibility. If the author reveals an answer through a hint or explanation, mark that attempt as influenced by assistance.\n\n## Common mistakes\n\nDo not change color, duration, audio, and trajectory simultaneously. You will not know which change helped. Do not add rewards to improve impressions of a warning-cue experiment. A positive comment is not evidence of readability; observe the relevant player action.\n\nAvoid rebuilding the prototype into an ideal architecture before deciding whether to keep the idea. Still preserve a reliable way to launch the scene and repeat the exercise. A short launch guide and known-limitations list cost less than recovering forgotten settings.\n\nWhen the time budget ends, record the result even if it is inconvenient. Continue with a concrete next question, change the approach, or stop pursuing the mechanic. A negative result can also reduce uncertainty.\n\n## Verify it\n\n- The question fits into one sentence.\n- Every implemented feature helps answer that question.\n- Deadline and effort limit were written before work started.\n- The criterion measures behavior instead of compliments.\n- Test conditions and limitations are recorded.\n- The evaluation ends with a concrete next decision.\n\n## Prompt for an AI agent\n\n> Turn this mechanic idea into one testable question. Propose the cheapest prototype, explicit exclusions, a time budget, and an observable criterion. First consider a test without code. Do not present invented outcomes as a completed playtest. After implementation, provide launch instructions and a blank observation template."},{"id":"scope-and-prototype","lang":"ru","title":"Скоуп и проверяемый прототип","description":"Выбираем один вопрос, ограничиваем объём работы и решаем, что делать после проверки прототипа.","category":"design","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["scope","prototyping","playtesting"],"sources":[{"title":"Unity Learn: Prototyping","url":"https://learn.unity.com/pathway/creative-core/unit/prototyping"}],"url":"https://gamemechanics.pro/ru/lessons/scope-and-prototype/","markdownUrl":"https://gamemechanics.pro/content/ru/scope-and-prototype.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nДвижок и готовый проект не обязательны. Нужна идея действия игрока и неизвестность, которая мешает принять следующее решение. Цель урока: подготовить маленькую проверку с понятным окончанием, а не список всех желаемых возможностей игры.\n\n## Принцип\n\nПрототип полезен, когда уменьшает конкретную неопределённость. «Сделать рогалик» не говорит, что проверять. «Понимает ли игрок разницу между двумя атаками по предупреждению?» задаёт наблюдаемую задачу. [Unity Learn: Prototyping](https://learn.unity.com/pathway/creative-core/unit/prototyping) предлагает выбирать подход к прототипу под вопрос проекта.\n\nОграничьте действие, окружение и результат. Один противник, одна комната и два предупреждения могут дать нужные наблюдения. Инвентарь, метапрогрессия и сюжет пока не помогают ответить на этот вопрос. Выпишите их в отдельный список, чтобы возвращаться к ним осознанно.\n\nРазличайте прототип идеи и вертикальный срез. Для исследования достаточно условной графики и ручного запуска сценария. Срез показывает связанный фрагмент будущего качества, поэтому требует других затрат. Выбирайте форму по решению, которое предстоит принять.\n\n<span id=\"пример-читается-ли-атака\"></span>\n\n## Практический пример\n\n### Читается ли атака\n\nСоставьте карточку эксперимента до разработки:\n\n```text\nВопрос: различимы ли два предупреждения перед атакой?\nМатериал: одна арена, один враг, две атаки, быстрый рестарт.\nБюджет: один вечер на сборку, затем короткая проверка.\nНаблюдение: какую атаку ожидает человек до её начала?\nКритерий продолжения: 8 верных ответов из 10 после обучения.\nЕсли не проходит: изменить один сигнал и повторить проверку.\nСтоп: после двух вариантов пересмотреть сами атаки.\n```\n\nЧисла в карточке являются примером заранее выбранного критерия, а не отраслевым стандартом. Десять попыток одного человека не доказывают, что механика понятна широкой аудитории. Такой результат помогает выбрать ближайшее изменение, но не заменяет проверку с другими игроками.\n\nСначала покажите каждую атаку по отдельности. Затем перемешайте порядок и попросите назвать ожидаемую атаку до её исполнения. Записывайте ошибки, момент решения и замечания о видимости. Если автор подсказывает ответ взглядом или объяснением, отметьте попытку как загрязнённую подсказкой.\n\n## Частые ошибки\n\nНе меняйте одновременно цвет, длительность, звук и траекторию. Вы не узнаете, какое изменение помогло. Не добавляйте награды ради улучшения впечатления от теста предупреждений. Не называйте одобрительный отзыв доказательством читаемости: важно наблюдаемое действие.\n\nНе переписывайте прототип в «правильную архитектуру» до решения о его судьбе. При этом сохраняйте возможность запустить сцену и повторить проверку. Минимальные инструкции запуска и список известных ограничений стоят дешевле, чем восстановление забытых настроек.\n\nКогда время закончилось, запишите результат, даже если он неудобен. Возможны три полезных решения: продолжить с конкретным следующим вопросом, изменить подход или остановить эту механику. Отрицательный результат тоже сокращает неопределённость.\n\n## Проверка результата\n\n- Вопрос можно сформулировать одним предложением.\n- Каждая реализуемая возможность нужна для ответа.\n- Срок и предел затрат записаны до работы.\n- Критерий измеряется поведением, а не комплиментами.\n- Условия проверки и ограничения сохранены.\n- После проверки принято конкретное следующее решение.\n\n## Задание для ИИ-агента\n\n> Преврати идею механики в один проверяемый вопрос. Предложи самый дешёвый прототип, список исключений, бюджет времени и наблюдаемый критерий. Сначала рассмотри проверку без кода. Не представляй придуманные результаты как проведённый плейтест. После реализации подготовь инструкцию и пустой шаблон записи наблюдений."},{"id":"game-loop","lang":"en","title":"The game loop and time","description":"Separate simulation speed from frame rate and verify pauses, frame drops, and focus changes.","category":"foundations","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["game-loop","time","simulation"],"sources":[{"title":"Robert Nystrom: Game Loop","url":"https://gameprogrammingpatterns.com/game-loop.html"},{"title":"MDN: requestAnimationFrame","url":"https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame"},{"title":"Glenn Fiedler: Fix Your Timestep!","url":"https://github.com/mas-bandwidth/gafferongames/blob/main/content/post/fix_your_timestep.md"}],"url":"https://gamemechanics.pro/en/lessons/game-loop/","markdownUrl":"https://gamemechanics.pro/content/en/game-loop.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nYou only need variables, functions, and coordinates. By the end, you should be able to identify what updates the world, state the units of movement speed, and explain why a rendered frame is not necessarily one simulation step.\n\n## The principle\n\nA game loop connects input, state updates, and presentation. The world can keep changing while the player stands still. An engine already owns this loop; connect your behavior to its appropriate update callbacks. [Game Loop](https://gameprogrammingpatterns.com/game-loop.html) explains this basic model.\n\nThe expression `x += 3` moves three units per call. More calls therefore produce more movement. The expression `x += speed * dt` describes movement through elapsed time, with speed in units per second and `dt` in seconds. This does not make every physics simulation stable for arbitrary time steps.\n\nA simulation sensitive to step size can use a fixed update interval. Accumulated real time is consumed in equal simulation steps, while rendering happens independently. Limiting catch-up steps requires a deliberate overload policy, such as letting simulation time fall behind. [Fix Your Timestep!](https://github.com/mas-bandwidth/gafferongames/blob/main/content/post/fix_your_timestep.md) explores that tradeoff.\n\n<span id=\"a-concrete-exercise\"></span>\n\n## Practical example\n\n### A concrete exercise\n\nStart with one square and no collisions. Give it a speed of 120 units per second. After two seconds of uninterrupted movement, it should travel 240 units, regardless of how many frames were displayed.\n\n```text\nupdate(dtSeconds, input):\n    if input.moveRight:\n        player.x += 120 * dtSeconds\n\nrender():\n    drawSquare(player.x, player.y)\n```\n\nThis is teaching pseudocode, not a complete engine loop. Call `update` 120 times using `1/60`, then run a fresh case with 60 calls using `1/30`. Compare final positions with a small numerical tolerance. Finally, try uneven intervals whose sum is still two seconds.\n\nIn a browser, `requestAnimationFrame` schedules a callback (a function run by the browser) before repainting and normally pauses in background tabs. Its timestamp uses milliseconds; see the [MDN reference](https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame). Define a resume policy. For this exercise, discard the old timestamp when focus returns so that the square continues from a paused position.\n\n## Common mistakes\n\nDo not modify movement in both physics and presentation callbacks. Do not multiply by elapsed time twice when an engine method already handles it. Do not start another loop whenever the level restarts. Hiding a tab is also not a complete pause implementation: audio, network events, and timers may follow different lifecycles.\n\nCheck raw movement before introducing interpolation. Once the simulation is correct, add visual smoothing as a separate change. A smooth picture can otherwise conceal incorrect speed or update order.\n\n## Verify it\n\n- Equal simulation time produces equal travel at different update frequencies.\n- Pausing stops the intended systems while keeping the menu usable.\n- Returning from a background tab does not teleport the player.\n- Restarting the scene does not double movement speed.\n- Variable names or comments make time and speed units explicit.\n\n## Prompt for an AI agent\n\n> Locate the owner of the game loop and every place that changes player position. Explain the units of speed and elapsed time. Propose the smallest fix for frame-rate-dependent movement, then check travel over two seconds with several dt sequences. State pause and focus-resume behavior separately. Do not replace the physics backend without evidence that it is necessary."},{"id":"game-loop","lang":"ru","title":"Игровой цикл и время","description":"Отделяем скорость игры от частоты кадров и проверяем поведение при паузах и просадках FPS.","category":"foundations","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["game-loop","time","simulation"],"sources":[{"title":"Robert Nystrom: Game Loop","url":"https://gameprogrammingpatterns.com/game-loop.html"},{"title":"MDN: requestAnimationFrame","url":"https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame"},{"title":"Glenn Fiedler: Fix Your Timestep!","url":"https://github.com/mas-bandwidth/gafferongames/blob/main/content/post/fix_your_timestep.md"}],"url":"https://gamemechanics.pro/ru/lessons/game-loop/","markdownUrl":"https://gamemechanics.pro/content/ru/game-loop.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nДостаточно понимать переменные, функции и координаты. После урока вы сможете объяснить, кто обновляет мир, в каких единицах задана скорость и почему один нарисованный кадр не всегда равен одному шагу симуляции.\n\n## Принцип\n\nИгровой цикл связывает ввод, изменение состояния и отображение результата. Даже если персонаж стоит, мир может продолжать жить. В готовом движке этот цикл уже существует: ваша задача подключить логику к подходящим точкам обновления. Общая модель разобрана в [главе Game Loop](https://gameprogrammingpatterns.com/game-loop.html).\n\nЗапись `x += 3` означает три единицы за вызов. При разной частоте вызовов персонаж проходит разное расстояние. Запись `x += speed * dt` задаёт движение через прошедшее время, где `speed` измеряется в единицах в секунду, а `dt` в секундах. Но это само по себе не делает любую физическую модель устойчивой.\n\nДля чувствительной к шагу симуляции используют фиксированный интервал обновления. Накопленное реальное время расходуется на несколько одинаковых шагов; отрисовка может происходить реже или чаще. Ограничение числа догоняющих шагов требует явного решения: замедлять игровой мир или иначе обрабатывать перегрузку. Подробности есть в [Fix Your Timestep!](https://github.com/mas-bandwidth/gafferongames/blob/main/content/post/fix_your_timestep.md).\n\n## Практический пример\n\nНачните с одного квадрата без столкновений. Пусть он движется со скоростью 120 единиц в секунду. За две секунды непрерывного движения ожидается 240 единиц независимо от количества показанных кадров.\n\n```text\nupdate(dtSeconds, input):\n    if input.moveRight:\n        player.x += 120 * dtSeconds\n\nrender():\n    drawSquare(player.x, player.y)\n```\n\nЭто учебный псевдокод, а не готовый цикл движка. Сначала вызовите `update` 120 раз с шагом `1/60`, затем 60 раз с шагом `1/30`. Сравните координаты с небольшой допустимой погрешностью. Отдельно попробуйте меняющиеся интервалы с той же суммой времени.\n\nВ браузере `requestAnimationFrame` вызывает функцию перед перерисовкой и обычно приостанавливается в фоновых вкладках. Его временная метка задана в миллисекундах. Эти условия документирует [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame). При возвращении из фона задайте политику возобновления: например, сбросить предыдущую метку времени и продолжить с паузы.\n\n## Частые ошибки\n\nНе обновляйте координаты одновременно в физическом и визуальном callback (обработчике, который вызывает движок). Не применяйте `dt` дважды, если метод движка уже ожидает скорость. Не запускайте второй цикл при каждом рестарте сцены. Не используйте скрытие вкладки как неявную паузу: звук, сетевые события и таймеры могут иметь другой жизненный цикл.\n\nСначала проверяйте движение без интерполяции. Когда логика верна, визуальное сглаживание можно добавить отдельно. Иначе плавная картинка способна скрыть ошибку в скорости или порядке обновления.\n\n## Проверка результата\n\n- За одинаковое игровое время квадрат проходит одинаковый путь при разных частотах обновления.\n- Пауза останавливает нужные системы, а интерфейс остаётся доступным.\n- Возврат из фоновой вкладки не телепортирует персонажа.\n- Повторный запуск сцены не удваивает скорость.\n- В коде подписаны единицы времени и скорости.\n\n## Задание для ИИ-агента\n\n> Найди владельца игрового цикла и все места изменения координат игрока. Опиши единицы скорости и времени. Предложи минимальное исправление зависимости движения от FPS и проверь путь за две секунды при нескольких последовательностях dt. Отдельно укажи поведение паузы и восстановления фокуса. Не меняй физический backend без доказанной необходимости."},{"id":"input-and-feedback","lang":"en","title":"Input and feedback","description":"Turn button presses into gameplay intent and show whether an action was accepted, rejected, or completed.","category":"foundations","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["input","feedback","accessibility"],"sources":[{"title":"Godot: Using InputEvent","url":"https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html"}],"url":"https://gamemechanics.pro/en/lessons/input-and-feedback/","markdownUrl":"https://gamemechanics.pro/content/en/input-and-feedback.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nUse an early playable prototype with one action, such as interacting with a door. You need an input handler and a small amount of game state. The goal is for players to understand the result of a press while game rules remain independent of a particular key.\n\n## The principle\n\nSeparate the physical signal, gameplay intent, and outcome. A keyboard key or gamepad button produces `interact`. Game rules decide whether a door can open. Presentation communicates what happened. This is easier to inspect than a key handler that also animates the door, plays audio, and edits the inventory.\n\nAn action mapping lets several input devices express the same intent. Godot provides InputMap for this purpose, and its event propagation can let the interface consume input before the game world receives it. See [Using InputEvent](https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html).\n\nMovement usually depends on a held input. Toggling a menu or using an item usually needs a press edge: the change from released to pressed. Toggling on every held frame makes one physical press repeatedly open and close the menu.\n\n<span id=\"example-a-locked-door\"></span>\n\n## Practical example\n\n### A locked door\n\nDefine three outcomes: opened, needs a key, and out of range. Game logic returns one outcome; presentation selects a suitable message, sound, or animation.\n\n```text\ntryInteract(player, door):\n    if distance(player, door) > interactRange:\n        return outOfRange\n    if door.locked and not player.hasKey:\n        return needsKey\n    door.open = true\n    return opened\n\nonActionPressed(interact):\n    result = tryInteract(player, selectedDoor)\n    presentInteractionResult(result)\n```\n\nPlace two doors in your exercise scene, one nearby and one outside interaction range. Check the outcomes before adding effects, then introduce a short explanation when an action is rejected. Do not play a successful opening animation before the rules accept the interaction.\n\nWhen multiple doors exist, define target selection explicitly: nearest eligible object, object under the crosshair, or highlighted object. Show the selected target before the press. This makes target-selection errors distinguishable from incorrect key checks.\n\n## Common mistakes\n\nThe same input must not activate a menu button and fire a weapon behind it. Closing a window must not leave movement permanently held. Clear held actions when focus is lost, because a release event may not arrive where your handler expects it.\n\nDo not communicate rejection through red coloring alone or a quiet sound alone. In this example, include a reason label and a distinguishable door state. Rate-limit repeated rejection cues so that holding a button does not create a stream of identical sounds.\n\nDo not automatically buffer every action. A buffered jump may help a particular movement design, while a delayed purchase confirmation or quit command can be surprising. The lifetime of an intent belongs in that action's rules.\n\n## Verify it\n\n- Keyboard and gamepad activate the same gameplay action.\n- Holding a button does not repeat a single-shot action every frame.\n- Menus receive input without triggering the world behind them.\n- Losing and restoring focus does not leave movement stuck.\n- Rejection reasons remain understandable without color discrimination or audio.\n- Players can see the selected target before confirming.\n\n## Prompt for an AI agent\n\n> Separate input collection, interaction rules, and result presentation for a door. Preserve existing control bindings. Define held-input, interface, and focus-loss behavior. Add checks for the three outcomes and explain how players learn why an action was rejected. Do not add delay or input buffering without an explicit rule."},{"id":"input-and-feedback","lang":"ru","title":"Ввод и обратная связь","description":"Превращаем нажатия в игровые намерения и показываем игроку, какое действие принято, отклонено или выполнено.","category":"foundations","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["input","feedback","accessibility"],"sources":[{"title":"Godot: Using InputEvent","url":"https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html"}],"url":"https://gamemechanics.pro/ru/lessons/input-and-feedback/","markdownUrl":"https://gamemechanics.pro/content/ru/input-and-feedback.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nУрок подходит для первого управляемого прототипа. Нужны обработчик ввода и одно действие, например взаимодействие с дверью. Цель: игрок понимает результат нажатия, а игровой код не зависит от конкретной клавиши.\n\n## Принцип\n\nРазделите физический сигнал, игровое намерение и результат. Клавиша E или кнопка геймпада порождает `interact`. Игровая логика решает, можно ли открыть дверь. Интерфейс сообщает, что произошло. Такой путь проще проверять, чем обработчик клавиши, который сразу двигает дверь, воспроизводит звук и меняет инвентарь.\n\nСистема действий позволяет назначать несколько устройств на одно намерение. В Godot эту роль выполняет InputMap; порядок обработки событий также позволяет интерфейсу перехватывать ввод до игрового мира. См. [Using InputEvent](https://docs.godotengine.org/en/stable/tutorials/inputs/inputevent.html).\n\nДля движения обычно важно удержание. Для переключения меню или использования предмета нужен фронт нажатия, то есть переход из состояния «не нажато» в «нажато». Если выполнять переключение каждый кадр удержания, одно нажатие будет многократно открывать и закрывать меню.\n\n<span id=\"пример-закрытая-дверь\"></span>\n\n## Практический пример\n\n### Закрытая дверь\n\nОпределим три результата: дверь открылась, нужен ключ, игрок слишком далеко. Логика возвращает результат, а слой представления выбирает подходящий текст, звук или анимацию.\n\n```text\ntryInteract(player, door):\n    if distance(player, door) > interactRange:\n        return outOfRange\n    if door.locked and not player.hasKey:\n        return needsKey\n    door.open = true\n    return opened\n\nonActionPressed(interact):\n    result = tryInteract(player, selectedDoor)\n    presentInteractionResult(result)\n```\n\nВ учебной сцене разместите две двери: одну рядом, вторую вне радиуса. Сначала проверьте принятие намерения без эффектов, затем добавьте короткую подпись причины отказа. Не запускайте анимацию успешного открытия до решения игровой логики.\n\nЕсли в сцене несколько дверей, явно определите выбор цели: ближайшая доступная, объект под прицелом или выделенный объект. Покажите выбранную дверь до нажатия. Это помогает отличить ошибку выбора цели от ошибки проверки ключа.\n\n## Частые ошибки\n\nОдин и тот же ввод не должен одновременно нажимать кнопку меню и стрелять в мире. Закрытие окна не должно оставлять движение навсегда включённым. При потере фокуса предусмотрите очистку удерживаемых действий: событие отпускания может прийти не туда, где его ожидают.\n\nНе сообщайте об отказе только красным цветом или только тихим звуком. В примере добавьте текст причины и различимое состояние двери. Для часто повторяющегося отказа ограничьте частоту сигналов, иначе каждое удержание превратится в поток звуков.\n\nНе добавляйте буфер ввода автоматически ко всем действиям. Отложенный прыжок иногда помогает управлению, а отложенное подтверждение покупки или выхода может быть неожиданным. Срок жизни намерения должен быть частью правила конкретного действия.\n\n## Проверка результата\n\n- Клавиатура и геймпад вызывают одно игровое действие.\n- Удержание кнопки не повторяет одиночное действие каждый кадр.\n- Меню получает ввод без одновременного действия в мире.\n- После потери и возврата фокуса движение не застревает.\n- Причина отказа понятна без различения цвета и без звука.\n- Выбранная цель видна до подтверждения.\n\n## Задание для ИИ-агента\n\n> Раздели ввод, проверку взаимодействия и представление результата для двери. Сохрани существующие привязки управления. Определи поведение удержания, интерфейса и потери фокуса. Добавь проверки трёх исходов и объясни, как игрок узнаёт причину отказа. Не добавляй задержку или буферизацию без отдельного правила."},{"id":"collision-basics","lang":"en","title":"Collision fundamentals","description":"Separate overlap detection, physical response, and gameplay events; check boundaries, fast objects, and repeated damage.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["collision","physics","testing"],"sources":[{"title":"MDN: 2D collision detection","url":"https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection"},{"title":"Godot: Physics introduction","url":"https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html"}],"url":"https://gamemechanics.pro/en/lessons/collision-basics/","markdownUrl":"https://gamemechanics.pro/content/en/collision-basics.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nYou need coordinates and basic conditions. Begin with two unrotated rectangles. The goal is to define exactly what contact means without confusing geometry with damage rules.\n\n## The principle\n\nDetection asks whether shapes intersect. Collision resolution decides how to remove penetration and change movement. Gameplay response decides what contact means: damage, picking up an item, or opening a door. These tasks can share an event while following different rules.\n\nFor axis-aligned rectangles, compare their intervals on both axes. A larger scene can first select possible neighbors and then run more precise checks. [MDN: 2D collision detection](https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection) introduces these techniques.\n\nWhen using an engine, first learn its physics object types and interaction filters. The [Godot physics introduction](https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html), for example, distinguishes detection areas from physical bodies and explains collision layers and masks. Do not place custom movement on top of a physics solver without understanding their update order.\n\n<span id=\"example-a-hazard-area\"></span>\n\n## Practical example\n\n### A hazard area\n\nAssume rectangle coordinates describe the top-left corner and dimensions are positive. For this exercise, touching edges without overlapping area does not count as a hit.\n\n```text\noverlap(a, b):\n    separatedX = a.right <= b.left or b.right <= a.left\n    separatedY = a.bottom <= b.top or b.bottom <= a.top\n    return not (separatedX or separatedY)\n```\n\nNow define the gameplay rule: entering a hazard causes one hit. Keep a set of pairs that overlapped during the previous step. For each current pair, emit an entry event only if that pair was absent before. After processing, replace the previous set with the current one. Identify pairs with stable object identifiers, not positions.\n\nThis deliberately differs from applying damage every frame. If the hazard needs periodic damage, give it a separate interval measured in seconds. If a projectile must hit only once during its entire lifetime, entry history is insufficient: mark it consumed after the first accepted hit.\n\n## Common mistakes\n\nA visible sprite and its collision shape do not have to match exactly, but the difference should be intentional. Enable collision debugging and inspect local coordinates, scale, and anchor points.\n\nA fast object may cross a thin wall between two discrete checks. For that case, investigate the engine's continuous collision detection, a sweep over the traveled segment, or another method suited to your shapes. Making every wall thicker hides the symptom without explaining it.\n\nAvoid deleting items from a collection while iterating if doing so shifts the indices of objects that still need processing. Collect events, apply responses, and remove objects in a defined order. Clear stored contact information when an object is destroyed.\n\n## Verify it\n\n- Separated, overlapping, and exactly touching shapes produce the intended outcomes.\n- A shape fully contained inside another is detected.\n- Entry causes one hit; exit and re-entry follow the written rule.\n- Deleting an object does not leave a stale contact.\n- The fastest projectile is checked against the thinnest supported wall.\n- Collision layers exclude pairs that should never interact.\n\n## Prompt for an AI agent\n\n> Locate collision shapes and response rules. Document the edge-touch convention, event ordering, and damage frequency. Check containment, re-entry, deletion during contact, and a fast projectile. Use the selected engine's capabilities; do not introduce a custom physics engine for a single trigger."},{"id":"collision-basics","lang":"ru","title":"Основы столкновений","description":"Различаем обнаружение контакта, физическую реакцию и игровое событие; проверяем границы, скорость и повторный урон.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["collision","physics","testing"],"sources":[{"title":"MDN: 2D collision detection","url":"https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection"},{"title":"Godot: Physics introduction","url":"https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html"}],"url":"https://gamemechanics.pro/ru/lessons/collision-basics/","markdownUrl":"https://gamemechanics.pro/content/ru/collision-basics.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНужны координаты и простые условия. Для упражнения используйте два прямоугольника без поворота. Задача урока: определить, что считается контактом, и не смешать геометрию с правилами урона.\n\n## Принцип\n\nОбнаружение отвечает на вопрос «пересекаются ли формы?». Разрешение столкновения определяет, как убрать проникновение и изменить движение. Игровая реакция решает, что контакт означает: урон, подбор предмета или открытие двери. Эти три задачи могут использовать одно событие, но у них разные правила.\n\nДля прямоугольников, стороны которых параллельны осям, достаточно сравнить интервалы по X и Y. Для сложной сцены сначала можно отобрать возможных соседей, а затем провести точную проверку. Эти основы описаны в [MDN: 2D collision detection](https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection).\n\nВ движке сначала разберитесь в типах физических объектов и фильтрах взаимодействия. Например, [введение в физику Godot](https://docs.godotengine.org/en/stable/tutorials/physics/physics_introduction.html) различает области обнаружения и физические тела, а также объясняет слои и маски. Не добавляйте собственное перемещение поверх физического решателя без понимания порядка обновления.\n\n<span id=\"пример-область-опасности\"></span>\n\n## Практический пример\n\n### Область опасности\n\nПусть координаты прямоугольника задают левый верхний угол, а ширина и высота положительны. В этом упражнении касание границ без площади пересечения не считается попаданием.\n\n```text\noverlap(a, b):\n    separatedX = a.right <= b.left or b.right <= a.left\n    separatedY = a.bottom <= b.top or b.bottom <= a.top\n    return not (separatedX or separatedY)\n```\n\nТеперь задайте правило: опасная область наносит один удар при входе. Храните множество пар, пересекавшихся на прошлом шаге. Для каждой текущей пары отправляйте событие входа, только если раньше её не было. После обработки заменяйте предыдущее множество текущим. Пару идентифицируют стабильные идентификаторы объектов, а не их координаты.\n\nЭто правило намеренно отличается от «урон каждый кадр». Если нужен периодический урон, задайте отдельный интервал в секундах. Если удар должен происходить один раз за всё время жизни снаряда, история входов недостаточна: после первого попадания пометьте снаряд использованным.\n\n## Частые ошибки\n\nГрафический спрайт и форма столкновения не обязаны совпадать, но их расхождение должно быть осмысленным. Включите отладочный показ форм и проверьте локальные координаты, масштаб и точку привязки.\n\nБыстрый объект может оказаться по разные стороны тонкой стены между двумя дискретными проверками. Для такого сценария исследуйте непрерывное обнаружение движка, проверку пройденного отрезка или другой подход под выбранные формы. Одно увеличение размера стены не объясняет проблему.\n\nНе удаляйте элементы коллекции посреди её обхода, если это меняет индексы ещё не обработанных объектов. Соберите события, примените реакции и удаление в определённом порядке. При уничтожении объекта очищайте связанные записи контактов.\n\n## Проверка результата\n\n- Раздельные, пересекающиеся и ровно касающиеся формы дают ожидаемый результат.\n- Полное вложение одной формы в другую распознаётся.\n- Вход даёт один удар, выход и повторный вход работают по правилу.\n- Удаление объекта не оставляет ложный контакт.\n- Самый быстрый снаряд проверен на самой тонкой допустимой стене.\n- Слои исключают пары, которые не должны взаимодействовать.\n\n## Задание для ИИ-агента\n\n> Найди формы столкновений и правила реакции. Зафиксируй соглашение о касании границ, порядок событий и частоту урона. Проверь вложение, повторный вход, удаление во время контакта и быстрый снаряд. Используй возможности выбранного движка; не внедряй собственный физический движок ради одного триггера."},{"id":"state-machines","lang":"en","title":"States and transitions","description":"Define legal character states, event priority, and transition checks without a growing tangle of flags.","category":"foundations","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["state-machines","architecture","testing"],"sources":[{"title":"Robert Nystrom: State (author repository)","url":"https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown"}],"url":"https://gamemechanics.pro/en/lessons/state-machines/","markdownUrl":"https://gamemechanics.pro/content/en/state-machines.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nYou need conditions, functions, and a simple enumeration. Use a character that can move, dash, and die. The useful outcome is a transition table that explains which actions are allowed at each moment.\n\n## The principle\n\nFlags such as `isDashing`, `isDead`, and `canMove` can contradict each other. A finite state machine keeps one state for a chosen system and changes it through explicit events. Transitions may have guards, while entering and leaving a state can trigger one-time actions. Robert Nystrom explains the underlying pattern in [State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown).\n\nDo not put the entire game into one enumeration. Movement and menu visibility may be independent concerns. Start with a boundary: this machine controls the character's available actions. Health, position, and remaining dash duration remain ordinary data.\n\n<span id=\"example-a-short-dash\"></span>\n\n## Practical example\n\n### A short dash\n\nAssume a dash lasts 0.18 seconds and death interrupts it immediately. These are exercise parameters, not universal recommendations for responsive controls.\n\n| Current state    | Event and guard                  | Next state                 |\n| ---------------- | -------------------------------- | -------------------------- |\n| ready            | dashPressed and charge available | dashing                    |\n| dashing          | dash time expires                | ready                      |\n| ready or dashing | health reaches zero              | dead                       |\n| dead             | restart                          | ready after resetting data |\n\n```text\nupdate(dt, events):\n    if state == dead and events.restart:\n        resetCharacterData()\n        transitionTo(ready)\n        return\n    if health <= 0:\n        transitionTo(dead)\n        return\n    if state == ready and events.dashPressed and chargeReady:\n        transitionTo(dashing)\n    else if state == dashing:\n        dashRemaining -= dt\n        if dashRemaining <= 0:\n            transitionTo(ready)\n```\n\n`transitionTo` does nothing when the requested state already matches the current state. For a real transition, it runs exit logic, changes state, and then runs entry logic. Spend a charge when entering `dashing`, rather than on every frame. You can also capture the dash direction at that point.\n\nNotice the ordering: death is checked first and ends the update. This gives simultaneous events a defined priority. A different game may choose another ordering, but the decision should be written down.\n\n## Common mistakes\n\nAn animation callback, a function run after an animation event, must not accidentally revive a dead character by reporting that a dash has finished. Accept an event only in a compatible state. For delayed callbacks, checking the identity of the action that created them can also be useful.\n\nAvoid building a framework for dozens of imagined future states. Start with an enumeration and a small transition function. If the table fills up with combinations such as running-with-weapon and running-without-weapon, check whether independent systems have been combined unnecessarily.\n\nAssigning `ready` is not a complete restart. Health, charges, timers, and subscriptions must return to their intended initial values too. List that reset data explicitly and exercise the scene a second time.\n\n## Verify it\n\n- A single dash request spends exactly one charge.\n- Death interrupts a dash and prevents new actions.\n- A late animation event cannot change a dead character's state.\n- Every row of the transition table has a focused check.\n- Illegal events have a defined outcome, such as being ignored or logged.\n- Restarting restores the full initial data set.\n\n## Prompt for an AI agent\n\n> Find the flags controlling dash and death. First produce a table of legal transitions and the priority of simultaneous events. Then propose a small state machine without a general framework. Check double presses, death during a dash, a late callback, and a second scene start. Explain which data remains separate from the current state."},{"id":"state-machines","lang":"ru","title":"Состояния и переходы","description":"Описываем допустимые состояния персонажа, приоритет событий и проверяем переходы без хаоса из флагов.","category":"foundations","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["state-machines","architecture","testing"],"sources":[{"title":"Robert Nystrom: State (author repository)","url":"https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown"}],"url":"https://gamemechanics.pro/ru/lessons/state-machines/","markdownUrl":"https://gamemechanics.pro/content/ru/state-machines.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНужны условия, функции и простые перечисления. Для упражнения достаточно персонажа, который ходит, выполняет рывок и погибает. Результат урока: таблица переходов, из которой видно, какое поведение разрешено в каждый момент.\n\n## Принцип\n\nНабор флагов `isDashing`, `isDead`, `canMove` легко допускает противоречия. Конечный автомат хранит одно состояние выбранной системы и меняет его по явно заданным событиям. Переход может иметь условие допуска, а вход и выход могут выполнять разовые действия. Основа подхода разобрана автором Game Programming Patterns в [главе State](https://github.com/munificent/game-programming-patterns/blob/master/book/state.markdown).\n\nНе пытайтесь одним перечислением описать вообще всё. Состояние перемещения и состояние открытого меню могут быть независимы. Сначала определите границу: например, автомат управляет только доступностью действий персонажа. Здоровье, позиция и остаток времени рывка остаются данными.\n\n<span id=\"пример-короткий-рывок\"></span>\n\n## Практический пример\n\n### Короткий рывок\n\nПредположим, рывок длится 0,18 секунды, а смерть немедленно его прерывает. Это параметры учебного примера, которые нужно подобрать для своей игры.\n\n| Текущее состояние | Событие и условие            | Следующее состояние       |\n| ----------------- | ---------------------------- | ------------------------- |\n| ready             | dashPressed и заряд доступен | dashing                   |\n| dashing           | время рывка истекло          | ready                     |\n| ready или dashing | здоровье стало нулевым       | dead                      |\n| dead              | restart                      | ready после сброса данных |\n\n```text\nupdate(dt, events):\n    if state == dead and events.restart:\n        resetCharacterData()\n        transitionTo(ready)\n        return\n    if health <= 0:\n        transitionTo(dead)\n        return\n    if state == ready and events.dashPressed and chargeReady:\n        transitionTo(dashing)\n    else if state == dashing:\n        dashRemaining -= dt\n        if dashRemaining <= 0:\n            transitionTo(ready)\n```\n\nФункция `transitionTo` ничего не делает, если новое состояние равно текущему. При настоящем переходе она вызывает выход, меняет состояние, затем выполняет вход. Заряд списывается при входе в `dashing`, а не на каждом кадре. Направление рывка можно зафиксировать тогда же.\n\nОбратите внимание на порядок. Проверка смерти выполняется первой и завершает обновление. Это делает ответ на одновременные события определённым. Другой игре может требоваться другой приоритет, но его необходимо записать.\n\n## Частые ошибки\n\nАнимация не должна случайно воскрешать персонажа, отправляя запоздалое событие завершения рывка. Принимайте событие только в подходящем состоянии; для отложенных callback (функций, вызываемых после события) полезно также проверять идентификатор действия.\n\nНе создавайте общий базовый класс для десятков гипотетических состояний. Начните с перечисления и небольшой функции перехода. Если таблица превращается в комбинации «бег с оружием», «бег без оружия», проверьте, не смешаны ли независимые системы.\n\nПри рестарте недостаточно присвоить `ready`: нужно восстановить здоровье, заряд, таймеры и подписки. Составьте явный список сбрасываемых данных и проверьте его вторым запуском сцены.\n\n## Проверка результата\n\n- Один запрос рывка расходует ровно один заряд.\n- Смерть прерывает рывок и запрещает новые действия.\n- Позднее событие анимации не меняет состояние погибшего персонажа.\n- Каждая строка таблицы проверяется отдельно.\n- Недопустимые события имеют определённый результат: игнорирование или диагностическое сообщение.\n- Рестарт возвращает полный начальный набор данных.\n\n## Задание для ИИ-агента\n\n> Найди флаги, управляющие рывком и смертью. Сначала составь таблицу допустимых переходов и приоритет одновременных событий. Затем предложи небольшой автомат без общего фреймворка. Проверь двойное нажатие, смерть в середине рывка, запоздалый callback и повторный старт. Объясни, какие данные автомат хранит отдельно от состояния."},{"id":"game-feel","lang":"en","title":"Game feel: making actions readable","description":"Tune response, emphasis, and effects so players understand an action while staying in control.","category":"design","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["game-feel","feedback","accessibility"],"sources":[{"title":"GDC: Juice It or Lose It","url":"https://www.gdcvault.com/play/1016487/juice-it-or-lose"},{"title":"Xbox Accessibility Guideline 117","url":"https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/117"}],"url":"https://gamemechanics.pro/en/lessons/game-feel/","markdownUrl":"https://gamemechanics.pro/content/en/game-feel.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nBegin with a mechanic that already follows its rules: jumping lands correctly, hits cause damage, or collected items enter the inventory. If the result is wrong, effects make diagnosis harder. Choose one action and keep a baseline version for comparison.\n\n## The principle\n\nGame feel depends on the relationship between player intent, control response, and the perceived result. It helps to distinguish preparation, confirmation, and recovery. Preparation makes an upcoming action understandable. Confirmation communicates an accepted result. Recovery returns the player to their next decision.\n\nGive each effect a specific question to answer. A brief silhouette change confirms a hit. Particles identify the contact position. A sound distinguishes a block from damage. If you cannot explain what information an effect adds, first compare the action with that effect disabled.\n\nThe talk [Juice It or Lose It](https://www.gdcvault.com/play/1016487/juice-it-or-lose) is a useful starting point for studying expressive game reactions. The exercise and comparison criteria below are original practice material for this portal.\n\n<span id=\"example-hitting-a-training-target\"></span>\n\n## Practical example\n\n### Hitting a training target\n\nCreate a stationary target with three health points. Each accepted hit removes one point. Start by showing only the counter, then introduce confirmation effects one at a time.\n\n```text\nonDamageAccepted(event):\n    updateHealthDisplay(event.remainingHealth)\n    playImpactSound(event.surface)\n    showHitShape(event.position)\n    if settings.cameraShake > 0:\n        addCameraImpulse(settings.cameraShake)\n```\n\nGame logic emits this event after accepting damage. A miss must not trigger hit confirmation. A block can trigger a separate cue. When several hits arrive together, cap the combined effect intensity and number of simultaneous sounds.\n\nAdd switches for sound, visual confirmation, and camera movement. Play the same sequence with different combinations. Record concrete observations: “I could not tell whether the third hit connected” is more useful than “needs more juice.” A small personal comparison is not evidence of every player's preferences.\n\n## Common mistakes\n\nStrong shake can hide the next threat. A long recovery can make a powerful hit feel like losing control. A fullscreen effect can make interface text harder to read. Define limits for amplitude and duration, then tune within those limits while playing.\n\nPlayers should be able to disable camera movement without losing essential information. [Xbox Accessibility Guideline 117](https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/117) recommends avoiding these additional movements or offering a way to turn them off. Preserve another confirmation channel, such as a shape around the target and an updated health display.\n\nDo not make a decorative particle responsible for applying damage. Do not change the collision shape just to stretch the visible sprite. If you add a brief action freeze, define which systems it affects: the world, animations, input, interface, and audio may need different treatment.\n\n## Verify it\n\n- Hits, misses, and blocks are distinguishable.\n- Confirmation follows an accepted gameplay event.\n- Disabling shake keeps the action understandable.\n- Combined effects do not obscure hazards or essential text.\n- Effect parameters can change without changing damage rules.\n- Comparison with the baseline records observations, not just the author's taste.\n\n## Prompt for an AI agent\n\n> Break one gameplay action into preparation, confirmation, and recovery. Locate the event that confirms its result. Suggest two independently switchable effects and explain what information each adds. Check a miss, repeated hits, and disabled camera shake. Preserve the existing rules and provide a repeatable comparison scenario."},{"id":"game-feel","lang":"ru","title":"Game feel: читаемое действие","description":"Настраиваем отклик, акценты и эффекты так, чтобы игрок понимал действие и сохранял контроль.","category":"design","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["game-feel","feedback","accessibility"],"sources":[{"title":"GDC: Juice It or Lose It","url":"https://www.gdcvault.com/play/1016487/juice-it-or-lose"},{"title":"Xbox Accessibility Guideline 117","url":"https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/117"}],"url":"https://gamemechanics.pro/ru/lessons/game-feel/","markdownUrl":"https://gamemechanics.pro/content/ru/game-feel.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНачните с механики, которая уже выполняет своё правило: прыжок приземляется, удар наносит урон, предмет попадает в инвентарь. Если результат неверен, эффекты только усложнят поиск причины. Для урока выберите одно действие и сохраните исходную версию для сравнения.\n\n## Принцип\n\nGame feel складывается из связи между намерением игрока, ответом управления и восприятием результата. Полезно разделять три момента: подготовка, подтверждение и восстановление. Подготовка объясняет, что сейчас произойдёт. Подтверждение показывает принятый результат. Восстановление возвращает игрока к следующему решению.\n\nЭффект должен отвечать на конкретный вопрос. Короткое изменение силуэта сообщает о попадании. Отлетающие частицы показывают место контакта. Звук отличает блок от урона. Если вы не можете назвать информацию, которую добавляет эффект, сначала проверьте версию без него.\n\nДоклад [Juice It or Lose It](https://www.gdcvault.com/play/1016487/juice-it-or-lose) можно использовать как отправную точку для изучения выразительности игровых реакций. Описанное ниже упражнение и критерии сравнения являются самостоятельной практикой этого портала.\n\n<span id=\"пример-удар-по-тренировочной-цели\"></span>\n\n## Практический пример\n\n### Удар по тренировочной цели\n\nСоздайте неподвижную цель с тремя очками здоровья. Один разрешённый удар уменьшает здоровье на единицу. Сначала покажите только изменение счётчика, затем добавляйте по одному способу подтверждения.\n\n```text\nonDamageAccepted(event):\n    updateHealthDisplay(event.remainingHealth)\n    playImpactSound(event.surface)\n    showHitShape(event.position)\n    if settings.cameraShake > 0:\n        addCameraImpulse(settings.cameraShake)\n```\n\nСобытие создаёт игровая логика после принятия урона. Промах не должен запускать подтверждение попадания. Блок может запускать отдельный сигнал. Если несколько попаданий происходят одновременно, ограничьте интенсивность суммарных эффектов и число звуков.\n\nСделайте переключатели для звука, визуального подтверждения и движения камеры. Попробуйте одну и ту же последовательность ударов с каждой комбинацией. Записывайте наблюдения конкретно: «непонятно, прошёл ли третий удар» полезнее, чем «мало сочности». Не объявляйте маленькую личную проверку доказательством предпочтений всех игроков.\n\n## Частые ошибки\n\nБольшая тряска может скрыть следующую угрозу. Длительное восстановление способно превратить сильный удар в ощущение потерянного управления. Полноэкранный эффект может затруднить чтение интерфейса. Сначала назначьте ограничение амплитуды и длительности, затем подбирайте значения в игре.\n\nДвижение камеры должно отключаться без потери важной информации. [Xbox Accessibility Guideline 117](https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/117) рекомендует избегать подобных дополнительных движений либо давать возможность их отключить. Сохраните иной способ подтвердить попадание, например форму вокруг цели и обновление здоровья.\n\nНе привязывайте урон к декоративной частице. Не меняйте коллайдер ради визуального растяжения спрайта. Если используете короткую остановку действия, явно определите затронутые системы: мир, анимации, ввод, интерфейс и звук могут требовать разного поведения.\n\n## Проверка результата\n\n- Попадание, промах и блок различимы.\n- Подтверждение начинается после принятия игрового события.\n- Отключение тряски сохраняет понятность действия.\n- Несколько эффектов не скрывают опасности и важный текст.\n- Параметры можно менять без правки правил урона.\n- Сравнение с исходной версией описывает наблюдение, а не только вкус автора.\n\n## Задание для ИИ-агента\n\n> Разбери одно игровое действие на подготовку, подтверждение и восстановление. Найди событие, подтверждающее результат. Предложи два независимо отключаемых эффекта и объясни, какую информацию каждый добавляет. Проверь промах, серию попаданий и отключённую тряску. Сохрани исходные правила и подготовь воспроизводимый сценарий сравнения."},{"id":"performance-budget","lang":"en","title":"A performance budget","description":"Set a measurable target, locate the bottleneck with a profiler, and compare changes under the same conditions.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["performance","profiling","frame-time"],"sources":[{"title":"Godot: General optimization tips","url":"https://docs.godotengine.org/en/stable/tutorials/performance/general_optimization.html"}],"url":"https://gamemechanics.pro/en/lessons/performance-budget/","markdownUrl":"https://gamemechanics.pro/content/en/performance-budget.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nYou need a playable scene and access to the target device, or an explicitly identified intermediate environment. This lesson turns “make it faster” into a measurement of a particular workload. Low-level optimization expertise is not required.\n\n## The principle\n\nStart with platform, resolution, build configuration, and target frame rate. At 60 frames per second, the interval between frames is about 16.67 ms; at 30, it is about 33.33 ms. This arithmetic provides a frame-pacing target, not a promise that any scene can finish within it.\n\nDo not automatically add every CPU and GPU timing together, because their work may overlap. Learn what a measurement tool reports and identify what delays the next completed frame. Speeding up one function cannot resolve a bottleneck elsewhere.\n\n[Godot's optimization guidance](https://docs.godotengine.org/en/stable/tutorials/performance/general_optimization.html) recommends finding bottlenecks through measurement and checking the effect of changes. It also distinguishes sustained slow execution, individual stalls, and long loading operations. Each needs an appropriate observation scenario.\n\n<span id=\"example-an-enemy-arena\"></span>\n\n## Practical example\n\n### An enemy arena\n\nSuppose an empty arena feels smooth, but spawning a wave causes a stall. Do not start by rewriting movement. Create a repeatable scenario with the same arena, enemy count, random seed (the generator’s initial value), and spawn timing.\n\n```text\nscenario: spawn-wave\ndevice: exact model and power mode\nbuild: production configuration\nresolution: fixed value\nwarmup: 20 seconds\nrecord: 60 seconds\nreport: median, p95, p99 frame time and longest frame\ncompare: baseline versus one isolated change\n```\n\nThis is an example procedure. Choose durations that fit your game and keep them constant across comparisons. p95 and p99 mark the bounds within which roughly 95% and 99% of measured frames fall, exposing occasional slow frames hidden by an average. A short recording can still miss rare failures.\n\nCapture a profile around the spawn event. If object creation and resource preparation dominate, investigate preloading or spreading the work over time. If updating every object is consistently expensive, inspect update frequency and workload. Choose a fix from the evidence instead of selecting a fashionable optimization technique.\n\n## Common mistakes\n\nAn object pool needs correct state reset. A reused enemy that retains old health or event subscriptions is still broken, even if it spawns faster. Verify gameplay outcomes alongside timing.\n\nComparing an editor run with a production build on another computer cannot isolate one code change. Record device, power mode, build, settings, and background workload. A run on a powerful laptop does not verify your minimum supported hardware.\n\nDo not measure FPS alone. Initial loading, download size, peak memory, or menu response time may matter more for the problem being investigated. Select metrics that describe the observed issue and leave headroom for ordinary environmental variation.\n\n## Verify it\n\n- The target specifies a platform, scene, and settings.\n- A baseline recording exists from before the change.\n- Profile evidence explains the chosen optimization.\n- Comparison runs use the same workload and conditions.\n- Slow frames are inspected rather than relying only on average FPS.\n- Gameplay and memory use have not silently regressed.\n- Target devices that were not tested are named explicitly.\n\n## Prompt for an AI agent\n\n> First define a repeatable scenario and collect baseline measurements. Identify the main bottleneck with a profiler and suggest one small change. Compare frame times under the same conditions, then check gameplay behavior and memory. If target hardware is unavailable, state that limitation and do not claim its performance has been verified."},{"id":"performance-budget","lang":"ru","title":"Бюджет производительности","description":"Задаём измеримую цель, ищем узкое место профайлером и сравниваем изменения в одинаковых условиях.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["performance","profiling","frame-time"],"sources":[{"title":"Godot: General optimization tips","url":"https://docs.godotengine.org/en/stable/tutorials/performance/general_optimization.html"}],"url":"https://gamemechanics.pro/ru/lessons/performance-budget/","markdownUrl":"https://gamemechanics.pro/content/ru/performance-budget.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНужна запускаемая сцена и доступ к целевому устройству либо явно обозначенной промежуточной среде. Урок помогает заменить требование «сделай быстрее» на измерение конкретной нагрузки. Знания низкоуровневой оптимизации пока не нужны.\n\n## Принцип\n\nНачните с платформы, разрешения, режима сборки и целевой частоты кадров. При 60 кадрах в секунду интервал между кадрами составляет примерно 16,67 мс; при 30 примерно 33,33 мс. Это арифметический ориентир для ритма кадров, а не обещание, что любая сцена успеет обработаться за это время.\n\nНе складывайте автоматически все показания CPU и GPU: их работа может перекрываться. Смотрите, что измеряет конкретный инструмент, и ищите участок, задерживающий готовность следующего кадра. Оптимизация одной функции не поможет, если задержка возникает в другом месте.\n\n[Рекомендации Godot по оптимизации](https://docs.godotengine.org/en/stable/tutorials/performance/general_optimization.html) предлагают измерять узкие места и проверять результат изменений. Они также различают постоянную медленную работу, отдельные скачки задержек и долгую загрузку. Для этих проблем нужны разные сценарии наблюдения.\n\n<span id=\"пример-арена-с-противниками\"></span>\n\n## Практический пример\n\n### Арена с противниками\n\nПредположим, на спокойной сцене всё плавно, а появление группы врагов вызывает остановку. Не начинайте с переписывания движения. Создайте воспроизводимый сценарий с одинаковой ареной, числом врагов, начальным значением генератора случайности (seed) и моментом появления.\n\n```text\nscenario: spawn-wave\ndevice: exact model and power mode\nbuild: production configuration\nresolution: fixed value\nwarmup: 20 seconds\nrecord: 60 seconds\nreport: median, p95, p99 frame time and longest frame\ncompare: baseline versus one isolated change\n```\n\nЭто пример процедуры. Выберите длительность под свою игру и сохраните её одинаковой в сравнении. p95 и p99 обозначают границы, в которые укладываются примерно 95% и 99% измеренных кадров. Так проще заметить редкие долгие кадры, которые скрывает среднее. Но короткая запись всё ещё может пропустить редкий сбой.\n\nЗапишите профиль момента появления врагов. Если время уходит на создание объектов и подготовку ресурсов, проверьте предварительную загрузку или распределение работы. Если постоянно дорого стоит обновление всех объектов, изучите частоту и объём этой работы. Выбирайте исправление по профилю, а не по популярности техники.\n\n## Частые ошибки\n\nObject pool требует корректного сброса состояния. Если после повторного использования враг сохраняет старое здоровье или подписку, ускорение не компенсирует ошибку. Проверяйте игровой результат вместе со временем.\n\nСравнение редактора с production-сборкой на другом компьютере ничего не говорит об эффекте одной правки. Фиксируйте устройство, питание, сборку, настройки и внешнюю нагрузку. Не называйте проверку на мощном ноутбуке проверкой минимального целевого устройства.\n\nНе оценивайте только FPS. Для проекта могут быть важнее первая загрузка, объём скачивания, пиковая память или время открытия меню. Выберите показатели, соответствующие наблюдаемой проблеме, и оставьте запас для обычных колебаний среды.\n\n## Проверка результата\n\n- У цели указаны платформа, сцена и настройки.\n- Есть исходная запись до изменения.\n- Профиль объясняет выбор оптимизации.\n- Сравнение использует одинаковые условия и нагрузку.\n- Проверены редкие медленные кадры, а не только средний FPS.\n- Поведение игры и потребление памяти не ухудшились незаметно.\n- Непроверенные целевые устройства явно перечислены.\n\n## Задание для ИИ-агента\n\n> Сначала зафиксируй воспроизводимый сценарий и исходные измерения. Найди главное узкое место профайлером и предложи одно небольшое изменение. Сравни время кадра в одинаковых условиях, проверь игровой результат и память. Если целевое устройство недоступно, назови ограничение и не заявляй, что его производительность подтверждена."},{"id":"agent-workflow","lang":"en","title":"Developing a game with an AI agent","description":"Write testable tasks, preserve project context, and accept changes based on observable gameplay behavior.","category":"workflow","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["agents","specification","contributing"],"sources":[{"title":"OpenSpec: official repository","url":"https://github.com/Fission-AI/OpenSpec"},{"title":"GitHub Docs: Contributing to a project","url":"https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project"}],"url":"https://gamemechanics.pro/en/lessons/agent-workflow/","markdownUrl":"https://gamemechanics.pro/content/en/agent-workflow.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"<span id=\"before-you-start\"></span>\n\n## Prerequisites\n\nUse a repository or small project that can be launched. An agent can inspect code, suggest changes, and run checks. You provide intent and accept the outcome. The goal is a workflow another contributor or agent can reproduce without needing the whole conversation.\n\n## The principle\n\nA useful task describes observable behavior, boundaries, and verification. “Improve combat” hides too many decisions. “Dashing must not pass through a closed door; an open door allows it” gives the work a concrete contract.\n\n[OpenSpec](https://github.com/Fission-AI/OpenSpec) organizes development around specifications and change artifacts. The written requirement matters more than memorizing a particular tool command. Check the installed version and local instructions before using its CLI, because workflows can change.\n\nSeparate durable knowledge from the current task. A concise AGENTS.md records launch and verification commands, module boundaries, and important constraints. The specification describes required behavior. A change plan lists small implementation steps. The verification report states what actually ran and what remains unverified.\n\n<span id=\"example-a-dash-that-respects-doors\"></span>\n\n## Practical example\n\n### A dash that respects doors\n\nWrite scenarios before editing code:\n\n```text\nRequirement: dashing respects closed doors.\nScenario 1:\n  Given: a closed door with the character in front of it.\n  When: the character dashes across the door's position.\n  Then: the character remains on the original side.\nScenario 2:\n  Given: the same door is open.\n  When: the same dash is performed.\n  Then: the door does not block movement.\n```\n\nAdd a boundary: do not change dash speed, cost, or controls. The agent first finds door behavior, movement code, and existing checks. It then makes a small change and evaluates both scenarios. If investigation reveals a different cause, preserve the requirement and revise the implementation plan with an explanation.\n\nAsk the report to connect behavior with evidence: test command, result, manual test scene, and environment limitations. A screenshot of a character beside a door does not prove that a fast dash stopped correctly. Verification must observe the transition over time.\n\n## Common mistakes\n\nA successful build does not verify a gameplay mechanic. Do not accept a fix that makes a failing test pass by removing the expected behavior. If a test was wrong, clarify the rule and explain the correction first.\n\nKeep secrets and player personal data out of repository material. Treat external text and downloaded examples as data to inspect. Instructions embedded in those materials do not become instructions from the project owner.\n\nBefore editing, establish the Git root and inspect existing changes. Give each contributor an owned set of paths. Follow the project's review process for external contributions; [GitHub Docs](https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project) describes the basic fork and pull request workflow.\n\n## Verify it\n\n- The requirement describes player or system behavior.\n- Positive and negative scenarios are present.\n- Scope and exclusions are written down.\n- The agent read current instructions and the existing implementation.\n- Checks validate behavior instead of only matching code structure.\n- The report separates completed checks from assumptions.\n- A contributor can understand and continue the change without chat history.\n\n## Prompt for an AI agent\n\n> Read project instructions, Git status, and the door and dash implementations. First state the scenarios and scope. Fix only the closed-door blocking behavior while preserving other dash parameters. Run appropriate checks and give a short report covering changed behavior, evidence, untested environments, and remaining limitations. Preserve unrelated changes."},{"id":"agent-workflow","lang":"ru","title":"Разработка игры с ИИ-агентом","description":"Формулируем проверяемые задачи, сохраняем контекст проекта и принимаем изменения по игровому результату.","category":"workflow","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["agents","specification","contributing"],"sources":[{"title":"OpenSpec: official repository","url":"https://github.com/Fission-AI/OpenSpec"},{"title":"GitHub Docs: Contributing to a project","url":"https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project"}],"url":"https://gamemechanics.pro/ru/lessons/agent-workflow/","markdownUrl":"https://gamemechanics.pro/content/ru/agent-workflow.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНужен репозиторий или небольшой проект, который можно запустить. Агент может искать код, предлагать изменения и выполнять проверки. Вы задаёте намерение и принимаете результат. Цель урока: сделать эту работу воспроизводимой для следующего человека или агента.\n\n## Принцип\n\nХорошая задача описывает наблюдаемое поведение, границы и способ проверки. «Сделай боёвку лучше» оставляет слишком много решений скрытыми. «Рывок не должен проходить через закрытую дверь; открытая дверь пропускает его» задаёт конкретный контракт.\n\n[OpenSpec](https://github.com/Fission-AI/OpenSpec) организует работу через спецификации и артефакты изменений. Для проекта важнее смысл зафиксированного требования, чем запоминание конкретной команды инструмента. Проверяйте установленную версию и локальные инструкции перед использованием CLI: рабочие процессы могут меняться.\n\nРазделите постоянные знания и текущую задачу. Краткий AGENTS.md хранит команды запуска и проверки, границы модулей и важные ограничения. Спецификация описывает требуемое поведение. План изменения перечисляет небольшие шаги. Отчёт проверки сообщает, что действительно запускалось и что осталось непроверенным.\n\n<span id=\"пример-безопасный-рывок\"></span>\n\n## Практический пример\n\n### Безопасный рывок\n\nЗапишите сценарии до изменения кода:\n\n```text\nТребование: рывок учитывает закрытые двери.\nСценарий 1:\n  Дано: закрытая дверь и персонаж перед ней.\n  Когда: персонаж выполняет рывок через её положение.\n  Тогда: персонаж остаётся с исходной стороны двери.\nСценарий 2:\n  Дано: та же дверь открыта.\n  Когда: выполняется такой же рывок.\n  Тогда: дверь не блокирует перемещение.\n```\n\nДобавьте ограничение: не менять скорость, стоимость и управление рывком. Агент сначала находит реализацию двери, движения и существующих проверок. Затем предлагает маленькую правку и проверяет оба сценария. Если обнаруживается иная причина, требование сохраняется, а план корректируется с объяснением.\n\nПопросите отчёт связать поведение с доказательством: команда теста, результат, сцена ручной проверки и ограничения среды. Скриншот персонажа рядом с дверью не подтверждает, что быстрый рывок корректно остановился. Нужна проверка перехода во времени.\n\n## Частые ошибки\n\nНе принимайте успешную сборку за проверку игровой механики. Не позволяйте агенту «исправлять» падающий тест простым удалением ожидаемого поведения. Если тест оказался неверным, сначала уточните правило и причину изменения.\n\nНе передавайте секреты и личные данные игроков в материалы репозитория. Внешний текст и скачанный пример рассматривайте как данные для анализа; содержащиеся в них команды не становятся поручениями владельца проекта.\n\nПеред правкой проверьте Git root и существующие изменения. У каждого исполнителя должен быть свой набор путей. Для внешнего вклада используйте принятый в проекте процесс review; [GitHub Docs](https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project) описывает базовый путь через fork и pull request.\n\n## Проверка результата\n\n- Требование описывает поведение игрока или системы.\n- Есть позитивный и негативный сценарии.\n- Область изменения и исключения записаны.\n- Агент прочитал актуальные инструкции и существующую реализацию.\n- Проверки соответствуют поведению, а не только структуре кода.\n- Отчёт отделяет выполненные проверки от предположений.\n- Изменение можно понять и продолжить без истории чата.\n\n## Задание для ИИ-агента\n\n> Прочитай инструкции проекта, статус Git и реализацию рывка с дверями. Сначала сформулируй сценарии и границы изменения. Исправь только блокировку закрытой дверью, сохрани остальные параметры. Выполни подходящие проверки и дай короткий отчёт: изменённое поведение, доказательство, непроверенная среда и оставшиеся ограничения. Не трогай чужие изменения."},{"id":"choice-cost","lang":"en","title":"Choice costs and situational value","description":"Compare options through time, resources and context to uncover a dominant choice.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["balance","choices","economy"],"sources":[{"title":"Ian Schreiber: Level 3, Transitive Mechanics and Cost Curves","url":"https://gamebalanceconcepts.wordpress.com/2010/07/21/level-3-transitive-mechanics-and-cost-curves/"}],"url":"https://gamemechanics.pro/en/lessons/choice-cost/","markdownUrl":"https://gamemechanics.pro/content/en/choice-cost.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nTwo weapons with different numbers may offer the same decision: take the one that is better in every situation. Begin balancing by asking what the player pays and when they receive value.\n\n## The principle\n\nCost can include resources, time, an occupied slot and a forgone opportunity. Comparison through a common cost model, as in [Ian Schreiber's lecture](https://gamebalanceconcepts.wordpress.com/2010/07/21/level-3-transitive-mechanics-and-cost-curves/), helps identify a suspicious option. A single ratio cannot describe all gameplay value.\n\nAn option dominates another in the selected model if it is no worse on every relevant criterion and better on at least one. “Relevant” requires explicit assumptions: range or accuracy cannot silently disappear from a real game's comparison.\n\n<span id=\"example-rescue-tools\"></span>\n\n## Practical example\n\n### Rescue tools\n\nIn an illustrative game, players cut through debris. A saw removes 12 durability per action and consumes 3 charges. A cutter removes 8 and consumes 2. Both remove 4 durability per charge. That does not establish equivalence.\n\nFor debris with 8 durability, the cutter finishes in one action and 2 charges, while the saw needs one action and 3. For debris with 12 durability, the saw needs one action and 3 charges; the cutter needs two actions and 4. Rounding action counts changes the preferred option. This model has no misses, energy recovery or damage to the rescuer; revisit it when adding those systems.\n\nList situations before changing numbers. To give the saw a role, test different debris durability and time limits. Do not invent cutter immunity merely to justify its neighbor: first ask whether a second tool is needed.\n\n## Common mistakes\n\n- Comparing only damage per second when scarce charges determine the decision.\n- Equalizing averages while ignoring rounding and thresholds.\n- Making every option equal in every situation and removing the reason to choose.\n\n## Verify it\n\n- Compute action count by rounding durability divided by tool strength upward.\n- Record actions, charge consumption and the reason for preference in three situations.\n- Find a justified use for every option you intend to keep.\n- Check the model in play: waiting for animation may also be a cost.\n\n## Prompt for an AI agent\n\n> Make a table for debris with durability 8, 12 and 20. Count actions and charges separately and state assumptions. Propose one change if a tool is never useful. Do not claim the table proves balance.\n\nContinue with [Last Ferry](/en/practice/#last-ferry) and the [Meaningful Choices lens](/en/lenses/#schell-039)."},{"id":"controlled-randomness","lang":"en","title":"Randomness and unlucky streaks","description":"Separate average probability from a short session and decide whether the game needs limits on outcome streaks.","category":"design","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["balance","probability","testing"],"sources":[{"title":"Ian Schreiber: Level 4, Probability and Randomness","url":"https://gamebalanceconcepts.wordpress.com/2010/07/28/level-4-probability-and-randomness/"},{"title":"Ian Schreiber: Level 5, Probability and Randomness Gone Horribly Wrong","url":"https://gamebalanceconcepts.wordpress.com/2010/08/04/level-5-probability-and-randomness-gone-horribly-wrong/"}],"url":"https://gamemechanics.pro/en/lessons/controlled-randomness/","markdownUrl":"https://gamemechanics.pro/content/en/controlled-randomness.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA reward with a 25% chance need not appear once every four attempts. A short session can differ considerably from the average across many runs.\n\n## The principle\n\nBefore implementation, name the event, its probability and dependencies between attempts. [Game Balance Concepts](https://gamebalanceconcepts.wordpress.com/2010/07/28/level-4-probability-and-randomness/) helps distinguish a probability model from one outcome. If you change the distribution for the player experience, update the rule's description too.\n\nIndependent rolls do not suit every design. You can limit failure streaks, but the next outcome then depends on history. That choice is not automatically fair: define whose experience and which behavior matter.\n\n<span id=\"example-expedition-batteries\"></span>\n\n## Practical example\n\n### Expedition batteries\n\nIn this teaching model, each crate independently contains a battery with probability 0.25. Across five crates, the expected battery count is `5 × 0.25 = 1.25`. The probability of finding none is `0.75^5 ≈ 23.73%`. An average above one coexists with a substantial chance of getting no batteries.\n\nAn alternative is to shuffle a bag of four tokens, one representing a battery. Each complete bag provides exactly one. Order is random, but outcomes are dependent. A battery at the beginning of one bag and at the end of the next permits six empty crates in a row. A four-token bag does not guarantee a reward in every sliding window of four attempts.\n\nIf a battery is required to finish the level, provide recovery from a poor outcome separately. A guarantee or fallback route changes the design, not just the random-number generator.\n\n## Common mistakes\n\n- Testing 25% with four rolls and declaring the generator broken.\n- Applying independent-event formulas to dependent outcomes.\n- Saving only the seed (the generator’s initial value) while losing the order of generator calls.\n\n## Verify it\n\n1. Recalculate the empty-streak probability analytically.\n2. In simulation, record reward frequency and streak-length distribution, not only the mean.\n3. For bags, check every position of the single battery in two adjacent bags.\n4. Save the seed, algorithm version and event sequence to reproduce a failure.\n\n## Prompt for an AI agent\n\n> Compare independent rolls and bags over equal crate counts. Show assumptions, a reproducible run and the worst possible bag streak. Do not replace a guarantee calculation with a random simulation result.\n\nTest the choice in [Weather Window](/en/practice/#weather-window) and through the [Chance lens](/en/lenses/#schell-036)."},{"id":"game-accessibility","lang":"en","title":"Basic accessibility across a play session","description":"Find barriers from launch to task completion: controls, text, cues, reaction time and camera motion.","category":"design","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["accessibility","input","feedback"],"sources":[{"title":"Game Accessibility Guidelines: Basic","url":"https://gameaccessibilityguidelines.com/basic/"},{"title":"Microsoft Xbox Accessibility Guideline 117: Visual distractions","url":"https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/117"}],"url":"https://gamemechanics.pro/en/lessons/game-accessibility/","markdownUrl":"https://gamemechanics.pro/content/en/game-accessibility.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA barrier can appear before the first gameplay task: tiny menus, mandatory button holds or an audio-only cue. Check the entire player journey, including settings and recovery from mistakes.\n\n## The principle\n\nState what information the player needs and what action they must perform. Find an alternative wherever the sole method creates a barrier. [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/basic/) provides starting points for this review; select recommendations for the particular game.\n\nSettings are usable only if players can reach them before the problematic scene. Changes should persist, and control hints should match remapped inputs. Developer checks find obvious errors but do not replace feedback from players with varied needs.\n\n<span id=\"example-starting-a-pumping-station\"></span>\n\n## Practical example\n\n### Starting a pumping station\n\nThis original teaching scenario requires matching three symbols, holding a lever and noticing pump overheating. Examine barriers separately:\n\n| Initial design                          | Alternative to test                                   |\n| --------------------------------------- | ----------------------------------------------------- |\n| Red and green indicators without labels | Distinct shapes, symbols and state labels             |\n| Audio-only overheating alarm            | Text warning and visible icon                         |\n| Lever requires a prolonged hold         | Configurable press-to-toggle behavior                 |\n| Camera shake during startup             | Reduced-motion or disable option reachable beforehand |\n\nCheck that toggling the lever does not require an accidental extra press after leaving a menu. The overheating icon should remain distinguishable against the gameplay background. Reducing shake must not remove the only startup confirmation: retain the pump state and text.\n\nIf the task requires a quick reaction, consider a separate reaction-window option. It may affect difficulty, so describe its effect honestly. This review aims to preserve access to the action, not promise an identical experience for everyone.\n\n## Common mistakes\n\n- Hiding a setting in a scene the player cannot reach.\n- Subtitling speech while omitting an important danger sound.\n- Checking only the settings screen without replaying the task afterward.\n- Calling a game fully accessible after a short internal checklist.\n\n## Verify it\n\n1. Complete the journey from launch to result with one selected input method.\n2. Mute sound and check essential information; separately inspect cues without color distinctions.\n3. Change controls, text size and camera motion, restart and check persistence.\n4. Invite participants with relevant needs and record remaining barriers without blanket promises.\n\n## Prompt for an AI agent\n\n> Make a barrier table for the pumping station. For each barrier, propose a setting or alternative cue and a full-task acceptance scenario. List untested cases separately. Preserve essential feedback when effects are disabled.\n\nContinue with [Rhythm Without Hurry](/en/practice/#rhythm-without-hurry) and the [Physical Interface lens](/en/lenses/#schell-060)."},{"id":"gameplay-acceptance","lang":"en","title":"Verifying gameplay behavior","description":"Turn “the mechanic is done” into reproducible scenarios with initial conditions, an action and an observable result.","category":"workflow","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["testing","acceptance","debugging"],"sources":[{"title":"Cucumber: Gherkin reference","url":"https://cucumber.io/docs/gherkin/reference/"},{"title":"Godot: Overview of debugging tools","url":"https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html"}],"url":"https://gamemechanics.pro/en/lessons/gameplay-acceptance/","markdownUrl":"https://gamemechanics.pro/content/en/gameplay-acceptance.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA game can launch and accept a button press while the mechanic still breaks its rule. Check promised behavior under known conditions, then separately assess how players experience it.\n\n## The principle\n\nWrite the initial state, event and expected observable result. This matches the Given/When/Then structure in the [Gherkin reference](https://cucumber.io/docs/gherkin/reference/), but a manual check does not require installing Cucumber.\n\nSeparate a pure rule from integration. Charge consumption can be checked in a model; door collision, sound and recovery from pause need checks inside the game. Engine debugging tools help expose causes, but a clean console does not establish correct mechanics.\n\n<span id=\"example-a-single-charge-dash\"></span>\n\n## Practical example\n\n### A single-charge dash\n\nIn this teaching contract, a dash consumes one charge and lasts 0.2 seconds of game time. Pause stops the game timer. Death cancels dash movement without returning the charge. These are authored example rules, not universal requirements.\n\n| Given                     | When                    | Then                                   |\n| ------------------------- | ----------------------- | -------------------------------------- |\n| Character alive, charge 1 | Dash request accepted   | Charge 0, dash state active            |\n| Charge 0                  | Another request arrives | No new dash starts                     |\n| Dash active               | Game is paused          | Duration does not advance during pause |\n| Dash active               | Death event arrives     | Movement canceled, charge remains 0    |\n\nChoose a priority for a simultaneous request and death beforehand: this model processes death first, so no dash starts. Reset initial state for each run; otherwise an earlier test consumes the next one's charge.\n\nIn a fixed-step model, check completion on the first tick where accumulated game time reaches 0.2 seconds. For manual observation, specify an acceptable tolerance and use a log rather than eyeballing duration.\n\n## Common mistakes\n\n- Testing only the successful case with full resources.\n- Treating a screenshot as proof of correct duration.\n- Requiring the same render-frame number at different rendering rates.\n- Presenting an automated rule check as evidence of usable controls.\n\n## Verify it\n\n1. Execute each scenario from its specified state and retain the result.\n2. Repeat integration checks at different rendering rates while preserving the simulation step.\n3. Check pause, restart and simultaneous events.\n4. For a failure, record build, input events, expected behavior and actual behavior.\n\n## Prompt for an AI agent\n\n> Implement the dash contract and scenario table. Automate pure transitions and describe the remaining checks for the target device. Separate executed checks, unexecuted checks and discrepancies in the report. Do not invent a successful run.\n\nCompare transitions with [States and transitions](/en/lessons/state-machines/) and the [Rules lens](/en/lenses/#schell-033)."},{"id":"level-blockout","lang":"en","title":"Blockout: test space before art","description":"Build a rough playable level around actual character dimensions, speed and camera to test a gameplay question.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["level-design","prototyping","playtesting"],"sources":[{"title":"The Level Design Book: Blockout","url":"https://book.leveldesignbook.com/process/blockout"},{"title":"The Level Design Book: Metrics","url":"https://book.leveldesignbook.com/process/blockout/metrics"}],"url":"https://gamemechanics.pro/en/lessons/level-blockout/","markdownUrl":"https://gamemechanics.pro/content/en/level-blockout.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA blockout, or graybox, tests play in a space that is still easy to rebuild. Cubes, planes and placeholder signs are enough when the character already moves according to the real rules.\n\n## The principle\n\nA floor plan shows connections between rooms. A playable draft shows how those connections interact with movement speed, collision and the camera. [The Level Design Book](https://book.leveldesignbook.com/process/blockout) treats blockouts as a tool for early iteration. This does not mean a level will never change afterward.\n\nStart with a question: for example, “Can the player notice the closing door and choose a detour in time?” An attractive editor view cannot answer it. If the core mechanic is missing, conclusions about suitable geometry remain provisional.\n\n<span id=\"example-a-warehouse-door\"></span>\n\n## Practical example\n\n### A warehouse door\n\nThis is an original teaching scenario, not a reported test result. The character is 0.8 m wide and moves at 4 m/s. A warehouse has a direct corridor of 12 m and a detour of 20 m. Without stops, they take 3 and 5 seconds. The direct door closes 4 seconds after a signal.\n\nBuild both routes with primitives. Use the gameplay camera and actual collision. Measure the route from where the player can first notice the signal, rather than a convenient editor marker. Turns and acceleration can increase travel time.\n\nThe first pass checks whether the door is reachable. The second checks whether an understandable exit remains after it closes. The third checks the return trip with cargo, if cargo affects movement.\n\n## Common mistakes\n\n- Flying an editor camera through the level: the passage looks wide while the character gets stuck.\n- Using a temporary controller: changing the jump later invalidates the distances.\n- Adding decoration early: the author protects an expensive room even when its route fails.\n\n## Verify it\n\n1. Walk both routes from the same start and record actual travel times.\n2. Check narrow passages with the gameplay collider and camera.\n3. Change one dimension, repeat the walk and explain the behavioral difference.\n4. Record the unresolved question before adding final art.\n\n## Prompt for an AI agent\n\n> Build the warehouse from simple shapes. Expose dimensions, speed and door delay as parameters. Show the timer origin and travel time. Do not claim route clarity without observing a player. Prepare three manual acceptance scenarios.\n\nContinue with [Paper Current](/en/practice/#paper-current): test the rule in a cheap prototype before translating it into space."},{"id":"level-wayfinding","lang":"en","title":"Making a route readable","description":"Give players landmarks and information for choosing a route while preserving room to explore.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["level-design","wayfinding","feedback"],"sources":[{"title":"The Level Design Book: Wayfinding","url":"https://book.leveldesignbook.com/process/blockout/wayfinding"}],"url":"https://gamemechanics.pro/en/lessons/level-wayfinding/","markdownUrl":"https://gamemechanics.pro/content/en/level-wayfinding.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nAn open passage is not enough. Players need information to locate themselves, choose a direction and recognize progress toward their destination.\n\n## The principle\n\nA readable route supports decisions. It does not need to make everyone follow the same road. The [Wayfinding](https://book.leveldesignbook.com/process/blockout/wayfinding) chapter treats navigation as an active player process. Exploring a side room is not by itself evidence of being lost.\n\nSeparate three questions: “Where am I?”, “Where do I want to go?” and “How can I get there?” A landmark may answer only the first. A visible tower does not explain where its staircase is. A maze can deliberately create uncertainty; distinguish that from an accidentally unreadable door.\n\n<span id=\"example-an-observation-station\"></span>\n\n## Practical example\n\n### An observation station\n\nIn this teaching level, the player carries a battery to an antenna. The antenna is visible from the starting platform, but its entrance is one floor above. Place the staircase so its upper landing is also visible from the start. Mark a side workshop with a tool symbol; mark the antenna door with the same antenna outline visible in the world.\n\nAfter climbing, the player sees the destination again from a new position. On the return trip, a recognizable window helps locate the starting platform. Color can reinforce these cues, but shape and placement should preserve meaning without it.\n\nThis is a proposed design to test. It does not establish that the signs are sufficient. Ask someone to deliver the battery independently and record pauses, backtracking and mistaken assumptions.\n\n## Common mistakes\n\n- Every lamp resembles a landmark: the important entrance disappears among equally strong cues.\n- Critical information is visible only from the author's camera: the player looks elsewhere.\n- Every detour is treated as a mistake: intended exploration disappears.\n\n## Verify it\n\n- Capture the actual gameplay camera at route decision points.\n- Check whether the destination and the immediate next step can be named separately.\n- Remove color differences and inspect remaining signs. This is a partial check, not proof of accessibility.\n- Check return navigation after visiting the side room.\n\n## Prompt for an AI agent\n\n> Propose three station navigation cues: destination, route to the staircase and return. Name the observation point and a possible misinterpretation for each. Change one cue after a playtest while retaining the side workshop.\n\nUse the [Goals lens](/en/lenses/#schell-032) and [Three-Minute Museum](/en/practice/#three-minute-museum) to review the first independent action."},{"id":"npc-action-selection","lang":"en","title":"How an NPC selects an action","description":"Separate eligibility, priority and execution so a character makes explainable decisions without rapidly switching between them.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["npc-ai","decision-making","debugging"],"sources":[{"title":"Dawe et al.: Behavior Selection Algorithms, An Overview","url":"https://www.gameaipro.com/GameAIPro/GameAIPro_Chapter04_Behavior_Selection_Algorithms.pdf"},{"title":"David Rez Graham: An Introduction to Utility Theory","url":"https://www.gameaipro.com/GameAIPro/GameAIPro_Chapter09_An_Introduction_to_Utility_Theory.pdf"}],"url":"https://gamemechanics.pro/en/lessons/npc-action-selection/","markdownUrl":"https://gamemechanics.pro/content/en/npc-action-selection.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA character may need charging, repairs and helping the player simultaneously. Write the selection rule explicitly before adding behavioral architecture.\n\n## The principle\n\nFirst filter eligible actions, then select one, then execute it. Do not let each subsystem independently control movement. The Game AI Pro overview compares state machines, behavior trees and other selection methods; there is no universal winner.\n\nA state machine suits a few distinct modes. A behavior tree suits sequences of conditions and actions. Comparing situational value can use a common scoring scale, as described in the utility-theory chapter. Scoring does not replace prohibitions or eligibility checks.\n\n<span id=\"example-a-maintenance-robot\"></span>\n\n## Practical example\n\n### A maintenance robot\n\nIn this teaching model, a robot can charge, repair a pump or help the player open a heavy door. Battery is normalized from 0 to 1. Below 0.1, a mandatory rule sends it to an available charger. If no route exists, it waits safely and reports why.\n\nOtherwise, compare eligible candidates:\n\n| Action | Score in this model | Eligibility                             |\n| ------ | ------------------- | --------------------------------------- |\n| Charge | `1 - battery`       | Charger reachable                       |\n| Repair | `leakSeverity`      | Parts available and pump reachable      |\n| Help   | `requestUrgency`    | Request still active and door reachable |\n\nAll inputs are bounded to 0..1. With battery 0.6, leak severity 0.8 and urgency 0.5, repair wins. These are authored design scores, not measurements of human desires.\n\nTo prevent close scores causing rapid switching, retain the current action until a competitor scores at least 0.15 higher. Release completed or ineligible actions immediately. Break ties with a stable order. Tune the margin after observation; the mandatory low-battery rule still takes priority.\n\n## Common mistakes\n\n- Comparing distance in meters with urgency on a 0..1 scale without conversion.\n- Restarting repair every frame and resetting its progress.\n- Retaining an action for stability after its target has been destroyed.\n\n## Verify it\n\n- Log inputs, excluded actions, scores and selection reasons.\n- Check tied scores, lost targets and no eligible candidates.\n- Vary urgency around the margin and check for excessive switching.\n- Separately check mandatory charging and an unreachable charger.\n\n## Prompt for an AI agent\n\n> Implement selection as a pure function of a world snapshot and current action. Keep execution separate. Prepare a boundary-case table and explain every result without random selection. Do not connect a language model to per-frame control.\n\nReview through the [Action](/en/lenses/#schell-031) and [Transparency](/en/lenses/#schell-062) lenses."},{"id":"npc-pathfinding","lang":"en","title":"Pathfinding and following a route","description":"Choose a space representation and traversal costs while separating a computed path from actual NPC movement.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["npc-ai","pathfinding","algorithms"],"sources":[{"title":"Amit Patel, Red Blob Games: Introduction to the A* Algorithm","url":"https://www.redblobgames.com/pathfinding/a-star/introduction.html"}],"url":"https://gamemechanics.pro/en/lessons/npc-pathfinding/","markdownUrl":"https://gamemechanics.pro/content/en/npc-pathfinding.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nFinding a sequence of cells and moving a character through it without getting stuck are separate tasks. Start with a space model, then check both parts.\n\n## The principle\n\nSearch operates on a graph: nodes and allowed transitions between them. [Red Blob Games](https://www.redblobgames.com/pathfinding/a-star/introduction.html) applies the same idea to different spatial representations. A tile grid is convenient but optional.\n\nWith equal edge costs, breadth-first search (BFS) finds a path with the fewest transitions. With differing nonnegative costs, Dijkstra accounts for their sum. A* adds an estimate of the remaining cost. On a four-connected grid without diagonals, Manhattan distance multiplied by the minimum step cost is a suitable lower bound; unusual transitions such as teleporters can invalidate it.\n\n<span id=\"example-maintenance-corridors\"></span>\n\n## Practical example\n\n### Maintenance corridors\n\nThis illustrative graph has two routes from A to G. Only the listed edges exist, and each is bidirectional:\n\n| Edge | Cost |\n| ---- | ---: |\n| A–B  |    1 |\n| B–G  |    4 |\n| A–C  |    2 |\n| C–D  |    1 |\n| D–G  |    1 |\n\nA–B–G has two transitions and costs 5. A–C–D–G has three and costs 4. BFS solves the transition-count problem, not minimum cost. Dijkstra should select the second route. A* with a zero heuristic reduces to Dijkstra and provides a useful baseline check.\n\nNow place the corridors in a game. Include robot width when computing traversability. A closing door can invalidate an old path. A navigation-change signal or detected blockage should trigger recomputation or an understandable failure, according to the project's rules.\n\n## Common mistakes\n\n- Assuming straight-line distance remains a guaranteed lower bound with cheap teleporters.\n- Treating an empty path as success when the goal is unreachable. Start equal to goal is a separate case.\n- Recomputing every frame without need or cost measurement.\n- Forgetting that a smoothed segment can cut an impassable corner.\n\n## Verify it\n\n1. Calculate both path costs manually and compare the algorithm's result.\n2. Remove D–G: route A–B–G must remain, with cost 5. Then remove B–G and check an explicit “no path” result.\n3. Check start equal to goal and a door closing during travel.\n4. Follow the computed route with the real collider, including narrow turns.\n\n## Prompt for an AI agent\n\n> Separate route search from robot movement. Return the route, total cost and status. Compare BFS and Dijkstra on the supplied graph, then handle blockages. Do not declare navigation complete based on one drawn line.\n\nReview the model through the [Functional Space lens](/en/lenses/#schell-026)."},{"id":"npc-perception","lang":"en","title":"NPC perception and target memory","description":"Separate world state from character knowledge: visibility, last observation, forgetting and readable reactions.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["npc-ai","perception","state-machines"],"sources":[{"title":"Martin Walsh: Modeling Perception and Awareness in Splinter Cell Blacklist","url":"https://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter28_Modeling_Perception_and_Awareness_in_Tom_Clancy%27s_Splinter_Cell_Blacklist.pdf"}],"url":"https://gamemechanics.pro/en/lessons/npc-perception/","markdownUrl":"https://gamemechanics.pro/content/en/npc-perception.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nGame code knows every object's coordinates. An NPC does not have to. Here, AI means a character behavior algorithm rather than a language model.\n\n## The principle\n\nSeparate observation from decision. Perception reports “target visible” or “noise heard,” memory retains the last known location, and behavior selects an action. Martin Walsh's Game AI Pro 2 chapter examines perception and awareness as game models where consistent rules and feedback matter.\n\nStart with [States and transitions](/en/lessons/state-machines/). Explicitly define which information each state can access. If an NPC uses hidden player coordinates after losing sight, that should be a deliberate game rule rather than accidental data leakage.\n\n<span id=\"example-an-observation-drone\"></span>\n\n## Practical example\n\n### An observation drone\n\nIn this original teaching model, a drone detects the player within a 90° sector and 8 m range if a ray to a target sample point is unobstructed. Radius alone is insufficient: a wall blocks observation. A ray to one point is also a simplification and can behave oddly at cover edges.\n\nWhile the target is visible, the drone updates its last known position. After losing sight, it searches that position for two seconds, then resumes its route. It does not update memory through a wall.\n\nIllustrative pseudocode, not code for a particular engine:\n\n```text\nvisible = within_range(target) and within_cone(target) and clear_ray(target)\nif visible:\n    memory.position = target.position\n    memory.expires_at = now + 2.0\n    state = tracking\nelse if now < memory.expires_at:\n    state = searching\n    search_position = memory.position\nelse:\n    state = patrol\n```\n\nBefore the first observation, memory is assumed to be expired. This variant provides short memory without modeling accumulating suspicion. Add suspicion only if the gameplay rule needs it.\n\n## Common mistakes\n\n- Range checks without obstruction checks let the NPC see through walls.\n- Search uses the hidden target's current location, making memory effectively omniscient.\n- States change without a cue, leaving the player unsure whether detection occurred.\n\n## Verify it\n\n- Display the debug sector, ray, state and memory position.\n- Check a target in front, behind, behind a wall and at the range boundary.\n- Move the player after losing visibility and confirm the memory point stays fixed.\n- With discrete updates, check memory expiry on the first tick after its deadline.\n\n## Prompt for an AI agent\n\n> Implement separate observation, memory and drone state. Prepare four test scenes and log transition reasons. State the ray and update-frequency simplifications. Visually identify searching without relying on color alone.\n\nReview through the [State Machine](/en/lenses/#schell-028) and [Feedback](/en/lenses/#schell-063) lenses."},{"id":"progression-pacing","lang":"en","title":"Progression: capabilities and pacing","description":"Check whether upgrades change player actions and whether increasing numbers conceal repetition of the same task.","category":"design","level":"intermediate","minutes":5,"updatedAt":"2026-10-20","tags":["balance","progression","economy"],"sources":[{"title":"Ian Schreiber: Level 7, Advancement, Progression and Pacing","url":"https://gamebalanceconcepts.wordpress.com/2010/08/18/level-7-advancement-progression-and-pacing/"}],"url":"https://gamemechanics.pro/en/lessons/progression-pacing/","markdownUrl":"https://gamemechanics.pro/content/en/progression-pacing.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA character's level can increase while their actions remain unchanged. Design progression by describing the experience between stages: a new capability, a different risk or a shorter route to a familiar goal.\n\n## The principle\n\nSeparate numerical growth, skill development and unlocking actions. The [progression lecture](https://gamebalanceconcepts.wordpress.com/2010/08/18/level-7-advancement-progression-and-pacing/) examines advancement alongside game pacing. An experience curve alone cannot establish interest or an appropriate session length.\n\nStart with an intended change: after the first upgrade, perhaps players can quickly clear a small obstacle and focus on choosing a route. Then choose numbers and check whether that change occurs. This is a design hypothesis, not a universal genre rule.\n\n<span id=\"example-three-station-cleanup-stages\"></span>\n\n## Practical example\n\n### Three station-cleanup stages\n\nIn this illustrative model, every hit connects, damage is constant and obstacles do not regenerate.\n\n| Stage          | Damage | Obstacle durability | Hits to destroy |\n| -------------- | -----: | ------------------: | --------------: |\n| Start          |     10 |                  40 |               4 |\n| Before upgrade |     12 |                  60 |               5 |\n| After upgrade  |     20 |                  60 |               3 |\n\nThe first damage increase did not accelerate work: durability grew faster. The second upgrade crosses a hit-count threshold. If attack intervals, misses or animations differ, hit count still does not equal completion time.\n\nNow add a price. An upgrade costing 60 parts, with 10 awarded per encounter, requires six encounters if no other income or expenses exist. The next costs 120 with rewards of 15, requiring eight. Check whether these eight encounters introduce new decisions. A longer wait does not by itself create development.\n\n## Common mistakes\n\n- Multiplying power and enemy health together without checking actual changes in actions.\n- Counting income while overlooking mandatory repair costs.\n- Measuring only total duration and hiding a long stretch without new decisions.\n\n## Verify it\n\n1. Calculate hits and the expected purchase path at each stage.\n2. Check the threshold immediately before and after an upgrade against the same obstacles.\n3. Record new decisions and places that repeat the previous task.\n4. Compare the plan with an observed session instead of fitting the report to the curve.\n\n## Prompt for an AI agent\n\n> Build a table for three station stages. Show hit thresholds, income, mandatory expenses and encounters before an upgrade. Propose a capability change instead of just increasing a number. Label all values as illustrative.\n\nApply the [Reward](/en/lenses/#schell-046) and [Visible Progress](/en/lenses/#schell-055) lenses, then try [Remove the Market](/en/practice/#remove-the-market)."},{"id":"running-a-playtest","lang":"en","title":"Running a playtest with a concrete question","description":"Prepare a short play session, separate observations from interpretations and choose the next change.","category":"workflow","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["playtesting","observation","iteration"],"sources":[{"title":"The Level Design Book: Playtesting","url":"https://book.leveldesignbook.com/process/blockout/playtesting"}],"url":"https://gamemechanics.pro/en/lessons/running-a-playtest/","markdownUrl":"https://gamemechanics.pro/content/en/running-a-playtest.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\n“How did you like the game?” often produces a polite answer that is hard to act on. It is more useful to choose an uncertainty beforehand and observe what someone does in a specific play situation.\n\n## The principle\n\nForm a question, prepare a suitable game segment and observe. [The Level Design Book](https://book.leveldesignbook.com/process/blockout/playtesting) distinguishes self-playtests, critique with a colleague and observing an outside player. They serve different purposes.\n\nTesting a first encounter requires someone who does not already know the solution. The same person's repeat attempt can check usability, but no longer reproduces first discovery. A few observations can reveal problems; they do not establish the preferences of an entire audience.\n\n<span id=\"example-a-station-delivery\"></span>\n\n## Practical example\n\n### A station delivery\n\nThe teaching question is: “Can a new player deliver a battery to the antenna without spoken explanation?” Prepare one level version, the same starting state and a consistent objective. Invite the person to play and explain that the game is being tested, not their abilities. Obtain consent before recording screen or voice.\n\nDuring play, separate your notes:\n\n| Observation                              | Possible explanation              | Next check                        |\n| ---------------------------------------- | --------------------------------- | --------------------------------- |\n| Approached a locked hatch three times    | Hatch suggests an available route | Change its signage                |\n| Returned to the start after climbing     | Lost direction toward the goal    | Check antenna visibility upstairs |\n| Asked whether the battery can be dropped | Allowed actions are unclear       | Check the carrying hint           |\n\nThese are example notes, not completed research. Do not supply the solution merely to get a successful run sooner. If a blocking bug requires intervention, record when and how you helped.\n\nAfterward, ask which goal the player pursued at an ambiguous moment. Their answer helps refine an interpretation without erasing the observation. Choose one change connected to the question and test again.\n\n## Common mistakes\n\n- Changing the build midway through a series and treating conditions as equivalent.\n- Recording “confused” without location, action or context.\n- Changing camera, route and controls simultaneously and losing the cause of an effect.\n\n## Verify it\n\n- The report includes a question, build version, starting conditions and the participant's prior familiarity.\n- Facts are separate from assumptions and author decisions.\n- Assistance and blocking bugs are recorded separately.\n- The next change connects to at least one observation.\n\n## Prompt for an AI agent\n\n> Prepare a five-minute station playtest: one question, a neutral task, an observation table and follow-up questions. Do not invent participants or results. After receiving real notes, propose one next experiment.\n\nUse the [Playtesting lens](/en/lenses/#schell-103) and [Three-Minute Museum](/en/practice/#three-minute-museum)."},{"id":"teaching-a-mechanic","lang":"en","title":"Teaching one mechanic through a level","description":"Build a short sequence in which players try a rule, receive feedback and apply it in a new situation.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["level-design","learning","feedback"],"sources":[{"title":"Patrick Holleman: Reverse Design, Super Mario World","url":"https://thegamedesignforum.com/features/RD_SMW_1.html"}],"url":"https://gamemechanics.pro/en/lessons/teaching-a-mechanic/","markdownUrl":"https://gamemechanics.pro/content/en/teaching-a-mechanic.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nPlayers can read a hint without understanding the rule. To check understanding, let them perform an action and independently transfer it to a slightly different situation.\n\n## The principle\n\nChoose one skill the level should clarify. A useful aspect of [Reverse Design: Super Mario World](https://thegamedesignforum.com/features/RD_SMW_1.html) is its method: examine individual challenges and their sequences instead of relying on a general instruction to “make it harder.”\n\nFor your prototype, separate introduction, independent attempt and skill transfer. This is a working structure, not a mandatory law for every level. It does not replace understandable controls, accessible hints or testing with your audience.\n\n<span id=\"example-a-pulse-platform\"></span>\n\n## Practical example\n\n### A pulse platform\n\nThis invented level teaches a platform that rises for one second after a button press. In the first room, the button and platform are visible together, and a failed jump returns the player to safe ground. They can observe the relationship between action and movement without losing progress.\n\nIn the second room, the button is slightly farther away. The rule is unchanged, but movement must begin immediately after the press. The third room offers two possible platforms, and the player chooses one that reaches the exit. Adding a new enemy, button type and jump at once would make the reason for failure unclear.\n\nChange one parameter between attempts. If the player waits for the platform but never jumps, check jump controls. If they do not connect the button with the platform, fix feedback before tightening timing.\n\n## Common mistakes\n\n- The first encounter immediately punishes failure with death and a long replay.\n- The second room requires a different rule that has never been introduced.\n- The author explains the solution aloud and mistakes completion for independent understanding.\n\n## Verify it\n\n1. Record which action would demonstrate understanding in each room.\n2. Observe an attempt without spoken hints; record any help separately.\n3. Ask the player to describe the rule afterward without supplying the wording.\n4. After failure, change one element and observe a new participant.\n\n## Prompt for an AI agent\n\n> Describe three pulse-platform rooms. For each, name the known rule, new question, safe retry and observable sign of understanding. Do not add mechanics outside this skill.\n\nDevelop the sequence in [Signal Room](/en/practice/#signal-room) and review it through the [Skill lens](/en/lenses/#schell-034)."},{"id":"world-to-gameplay","lang":"en","title":"From world rules to player actions","description":"Connect a fictional world to actions and consequences, then choose a small situation to test in a prototype.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["worldbuilding","mechanics","prototyping"],"sources":[{"title":"Yaropolk Rash / Yarr Rash: The Iconic IP Guide","url":"https://worldfirstmethod.com/ipguide"}],"url":"https://gamemechanics.pro/en/lessons/world-to-gameplay/","markdownUrl":"https://gamemechanics.pro/content/en/world-to-gameplay.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Prerequisites\n\nA world description helps design a game when it leads to actions and consequences. Start with one rule that players can notice, use and test. A world idea and a simple plan of a playable situation are enough; no engine is needed yet.\n\n## The principle\n\nA world can have an unusual history, culture and appearance. For a playable situation, establish what these change about the available actions. If cities run on magic, specify what players do with it, what they pay and what happens after they use it.\n\nYaropolk Rash, known as Yarr Rash and the creator of World-First Method, examines the connection between a world and the possibilities for its first game in [The Iconic IP Guide](https://worldfirstmethod.com/ipguide). This lesson draws on the idea in PDF pages 32–39 of the Russian v3.2 edition. The example and verification procedure below were developed for this lesson.\n\nThis approach is useful when a world's distinctive features should inform player decisions. You can also start with an existing mechanic: check which world rules explain its possibilities and limits. One situation is enough for an initial prototype.\n\n### From a premise to a choice\n\nWrite a short chain:\n\n```text\nWorld rule → player action → changed situation → next choice\n```\n\nName an observable result for each step. “Magic is dangerous” does not yet define behaviour. “A spell opens a door but draws a guard to the source of its sound” allows a choice of route, timing and location.\n\nSpecify the action's cost separately: a consumable item, time, revealing a position or giving up another route. Add a cost where you want a decision. A decorative detail does not have to become a mechanic.\n\n## Practical example\n\n### Sound-powered gates\n\nThis is an illustrative teaching scenario. In a city, ringing powers machinery. A courtyard contains gates, two bells and a guard. Both bells can be heard at the gates; ringing either opens them for the rest of the attempt. The guard hears the same sound and walks toward its source.\n\nPlayers can approach the bell beside the gates and ring it by hand. They keep their stone, but the guard heads toward the place they have just occupied. Alternatively, they can throw their only stone from cover at the distant bell, draw the guard away and approach the gates. The thrown stone cannot be recovered until the attempt restarts.\n\nOne world property connects opening a route, enemy behaviour and item consumption. The city's history, other energy types and a trading system are unnecessary for testing that connection. Which options prove useful depends on distances, guard speed and cover; the prototype must investigate those details.\n\n### What to keep in the prototype\n\nChoose the details needed to test the intended decision. This example requires a courtyard, two bells, gates, a guard and one stone. Tokens on a plan can represent them initially.\n\nBefore testing, define throwing range, movement order and the detection condition. Keep those rules consistent across attempts. Prepare two starting guard positions to see whether players consider the situation when choosing a sound source.\n\nAfter introducing the rule, ask players to indicate where the guard will go and what will happen to the gates before they act. Then let them cross the courtyard and record their choice, outcome and any hints they needed. If their prediction is correct but they cannot get through, examine execution separately: there may be insufficient time to manoeuvre even when the rule is clear.\n\n## Common mistakes\n\n- A distinctive feature exists only in the description: players cannot use it.\n- A rule changes to serve a scene: the same ringing produces different results without explanation.\n- The entire imagined universe enters the prototype: testing one decision keeps getting postponed.\n- Approval of the idea is treated as validation: what the person understood and did remains unknown.\n\n## Verify it\n\n- Players have an action through which they encounter the world rule.\n- The action has observable consequences that affect the next opportunity.\n- Limits are consistent; exceptions can be noticed and explained.\n- Every prototype detail has a stated role in the situation being tested.\n- The designer's expectations are recorded separately from player observations.\n\n## Prompt for an AI agent\n\n> Take one rule from my game world and propose two situations in which it changes player actions. Choose one for a small prototype. Describe actions, consequences, limits and a way to test understanding of the rule. Identify details that can wait. List assumptions and questions that need my decision separately; do not invent playtest results.\n\nUse [Scope and a testable prototype](/en/lessons/scope-and-prototype/) to bound the work. Review coherence with the [World](/en/lenses/#schell-084) and [Unification](/en/lenses/#schell-011) lenses."},{"id":"choice-cost","lang":"ru","title":"Цена выбора и полезность вариантов","description":"Сравниваем игровые варианты с учётом времени, ресурсов и ситуации, чтобы обнаружить доминирующий выбор.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["balance","choices","economy"],"sources":[{"title":"Ian Schreiber: Level 3, Transitive Mechanics and Cost Curves","url":"https://gamebalanceconcepts.wordpress.com/2010/07/21/level-3-transitive-mechanics-and-cost-curves/"}],"url":"https://gamemechanics.pro/ru/lessons/choice-cost/","markdownUrl":"https://gamemechanics.pro/content/ru/choice-cost.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nДва оружия с разными числами могут предлагать один и тот же выбор: брать то, которое выгоднее при любых обстоятельствах. Начните баланс с вопроса, чем игрок платит и в какой ситуации получает пользу.\n\n## Принцип\n\nЦена может включать ресурс, время, занятый слот и отказ от другой возможности. Сравнение по общей модели стоимости, как в [лекции Иэна Шрайбера](https://gamebalanceconcepts.wordpress.com/2010/07/21/level-3-transitive-mechanics-and-cost-curves/), помогает найти подозрительный вариант. Но единственный коэффициент не описывает всю игровую ценность.\n\nВариант доминирует над другим в выбранной модели, если он не хуже по всем значимым критериям и лучше хотя бы по одному. Слово «значимым» требует явных допущений: дальность или точность нельзя молча исключать из реальной игры.\n\n<span id=\"пример-инструменты-спасателя\"></span>\n\n## Практический пример\n\n### Инструменты спасателя\n\nВ условной игре нужно разрезать завалы. Пила снимает 12 единиц прочности за действие и тратит 3 заряда. Резак снимает 8 и тратит 2. Оба дают 4 единицы прочности на заряд. Это ещё не означает равенства.\n\nУ завала прочность 8: резак завершает работу за действие и 2 заряда, пила за действие и 3. У завала прочность 12: пила тратит действие и 3 заряда, резак два действия и 4. Округление числа действий меняет предпочтение. Здесь нет промахов, восстановления энергии и урона спасателю; при добавлении этих систем пересмотрите таблицу.\n\nСоставьте ситуации до изменения чисел. Если нужно дать пиле отдельную роль, можно проверить завалы разной прочности и ограничения времени. Не добавляйте иммунитет к резаку только ради оправдания его соседа: сначала выясните, нужен ли второй инструмент вообще.\n\n## Частые ошибки\n\n- Сравнивать только урон за секунду, когда решает расход редкого заряда.\n- Уравнивать средние числа, игнорируя округление и пороги.\n- Делать каждый вариант равным в каждой ситуации, убирая причину выбирать.\n\n## Проверка результата\n\n- Пересчитайте число действий как округлённое вверх отношение прочности к силе инструмента.\n- Для трёх ситуаций запишите действия, расход и причину предпочтения.\n- Найдите ситуацию, где каждый нужный вариант оправдан.\n- Проверьте модель в игре: ожидание анимации тоже может быть ценой.\n\n## Задание для ИИ-агента\n\n> Сделай таблицу для завалов прочностью 8, 12 и 20. Отдельно считай действия и заряды, покажи допущения. Предложи одно изменение, если инструмент нигде не нужен. Не объявляй баланс доказанным по таблице.\n\nПродолжите [«Последним паромом»](/ru/practice/#last-ferry) и призмой [«Осмысленный выбор»](/ru/lenses/#schell-039)."},{"id":"controlled-randomness","lang":"ru","title":"Случайность и неудачные серии","description":"Отличаем среднюю вероятность от опыта короткой сессии и выбираем, нужны ли игре ограничения на серии исходов.","category":"design","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["balance","probability","testing"],"sources":[{"title":"Ian Schreiber: Level 4, Probability and Randomness","url":"https://gamebalanceconcepts.wordpress.com/2010/07/28/level-4-probability-and-randomness/"},{"title":"Ian Schreiber: Level 5, Probability and Randomness Gone Horribly Wrong","url":"https://gamebalanceconcepts.wordpress.com/2010/08/04/level-5-probability-and-randomness-gone-horribly-wrong/"}],"url":"https://gamemechanics.pro/ru/lessons/controlled-randomness/","markdownUrl":"https://gamemechanics.pro/content/ru/controlled-randomness.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНаграда с вероятностью 25% не обязана появляться раз в четыре попытки. Короткая сессия может сильно отличаться от среднего по большому числу запусков.\n\n## Принцип\n\nДо реализации назовите событие, вероятность и зависимость между попытками. [Курс Game Balance Concepts](https://gamebalanceconcepts.wordpress.com/2010/07/28/level-4-probability-and-randomness/) помогает различать вероятностную модель и отдельный исход. Если меняете распределение ради игрового опыта, меняйте и описание правила.\n\nНезависимые броски подходят не каждой задаче. Можно ограничить серию неудач, но тогда следующий исход зависит от истории. Такой выбор не становится автоматически справедливым: нужно определить, для кого и какое поведение важно.\n\n<span id=\"пример-батареи-для-экспедиции\"></span>\n\n## Практический пример\n\n### Батареи для экспедиции\n\nВ учебной модели каждый ящик независимо содержит батарею с вероятностью 0,25. За пять ящиков ожидаемое количество батарей равно `5 × 0,25 = 1,25`. Вероятность не найти ни одной равна `0,75^5 ≈ 23,73%`. Среднее больше единицы совместимо с заметным риском остаться без батарей.\n\nАльтернатива: перемешивать мешок из четырёх жетонов, где один означает батарею. Каждый полный мешок даст ровно одну. Порядок случаен, исходы зависимы. Между батареей в начале одного мешка и в конце следующего возможны шесть пустых ящиков подряд. Мешок из четырёх не гарантирует награду в любом скользящем окне из четырёх попыток.\n\nЕсли батарея обязательна для завершения уровня, отдельно предусмотрите восстановление после плохого исхода. Гарантия или запасной путь изменяют дизайн, а не только генератор чисел.\n\n## Частые ошибки\n\n- Проверять 25% на четырёх бросках и объявлять генератор сломанным.\n- Считать зависимые исходы по формуле независимых.\n- Сохранять только seed (начальное значение генератора), забыв сохранить порядок обращений к генератору.\n\n## Проверка результата\n\n1. Пересчитайте вероятность пустой серии аналитически.\n2. В симуляции запишите частоту наград и распределение длины серий, а не только среднее.\n3. Для мешка проверьте все позиции единственной батареи в двух соседних мешках.\n4. Сохраняйте seed, версию алгоритма и последовательность событий для повтора ошибки.\n\n## Задание для ИИ-агента\n\n> Сравни независимые броски и мешок на одинаковом числе ящиков. Покажи исходные допущения, воспроизводимый запуск и худшую возможную серию для мешка. Не подменяй расчёт гарантии результатом случайной симуляции.\n\nПроверьте выбор в [«Окне погоды»](/ru/practice/#weather-window) и через призму [«Случайность»](/ru/lenses/#schell-036)."},{"id":"game-accessibility","lang":"ru","title":"Базовая доступность игровой сессии","description":"Ищем барьеры от запуска до завершения задачи: управление, текст, сигналы, время реакции и движение камеры.","category":"design","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["accessibility","input","feedback"],"sources":[{"title":"Game Accessibility Guidelines: Basic","url":"https://gameaccessibilityguidelines.com/basic/"},{"title":"Microsoft Xbox Accessibility Guideline 117: Visual distractions","url":"https://learn.microsoft.com/en-us/xbox/accessibility/xbox-accessibility-guidelines/117"}],"url":"https://gamemechanics.pro/ru/lessons/game-accessibility/","markdownUrl":"https://gamemechanics.pro/content/ru/game-accessibility.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nБарьер может возникнуть ещё до первой игровой задачи: мелкое меню, обязательное удержание кнопки или сигнал, который можно только услышать. Проверяйте весь путь игрока, включая настройки и возвращение после ошибки.\n\n## Принцип\n\nСформулируйте, какую информацию игроку нужно получить и какое действие выполнить. Затем найдите альтернативу там, где единственный способ создаёт барьер. [Game Accessibility Guidelines](https://gameaccessibilityguidelines.com/basic/) даёт отправные точки для такого разбора; рекомендации следует выбирать под конкретную игру.\n\nНастройки доступны только тогда, когда до них можно добраться до проблемной сцены. Изменение должно сохраняться, а подсказки управления должны соответствовать новой раскладке. Проверка разработчиком находит явные ошибки, но не заменяет обратную связь игроков с разными потребностями.\n\n<span id=\"пример-запуск-насосной-станции\"></span>\n\n## Практический пример\n\n### Запуск насосной станции\n\nВ самостоятельном учебном сценарии нужно сопоставить три символа, удержать рычаг и заметить перегрев насоса. Разберём барьеры отдельно:\n\n| Исходное решение                             | Вариант для проверки                                   |\n| -------------------------------------------- | ------------------------------------------------------ |\n| Красный и зелёный индикаторы без обозначений | Разные формы, символы и подписи состояния              |\n| Сигнал перегрева только звуком               | Текстовое предупреждение и заметный значок             |\n| Рычаг требует долгого удержания              | Настраиваемое переключение нажатием                    |\n| Тряска камеры при запуске                    | Доступная до запуска настройка снижения или отключения |\n\nПроверьте, что переключение рычага не требует случайного повторного нажатия для выхода из меню. Значок перегрева должен оставаться различимым поверх рабочего фона. Снижение тряски не должно убирать единственное подтверждение запуска: оставьте состояние насоса и текст.\n\nЕсли задача требует реакции за короткое время, рассмотрите отдельную настройку окна реакции. Она может изменить сложность, поэтому опишите её действие честно. Цель проверки здесь состоит в сохранении доступа к действию, а не в обещании одинакового опыта для всех.\n\n## Частые ошибки\n\n- Прятать настройку в сцене, до которой человек не может добраться.\n- Добавлять субтитры речи, забывая о важном звуке опасности.\n- Проверять только экран настроек, не проходя саму задачу после изменения.\n- Называть игру полностью доступной после короткого внутреннего списка проверок.\n\n## Проверка результата\n\n1. Пройдите путь от запуска до результата одним выбранным способом ввода.\n2. Выключите звук и проверьте получение важной информации; отдельно проверьте обозначения без различения цветов.\n3. Измените управление, размер текста и движение камеры, перезапустите игру и проверьте сохранение.\n4. Пригласите участников с соответствующими потребностями и зафиксируйте оставшиеся барьеры без общих обещаний.\n\n## Задание для ИИ-агента\n\n> Составь таблицу барьеров насосной станции. Для каждого предложи настройку или альтернативный сигнал и сценарий проверки всей задачи. Отдельно перечисли непроверенные случаи. Сохрани важную обратную связь при отключённых эффектах.\n\nПродолжите упражнением [«Ритм без спешки»](/ru/practice/#rhythm-without-hurry) и призмой [«Физический интерфейс»](/ru/lenses/#schell-060)."},{"id":"gameplay-acceptance","lang":"ru","title":"Проверка игрового поведения","description":"Переводим фразу «механика готова» в воспроизводимые сценарии с условиями, действием и наблюдаемым результатом.","category":"workflow","level":"beginner","minutes":6,"updatedAt":"2026-10-20","tags":["testing","acceptance","debugging"],"sources":[{"title":"Cucumber: Gherkin reference","url":"https://cucumber.io/docs/gherkin/reference/"},{"title":"Godot: Overview of debugging tools","url":"https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html"}],"url":"https://gamemechanics.pro/ru/lessons/gameplay-acceptance/","markdownUrl":"https://gamemechanics.pro/content/ru/gameplay-acceptance.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nИгра запускается, кнопка нажимается, а механика всё ещё может нарушать правило. Проверяйте обещанное поведение в известных условиях, а затем отдельно проверяйте, как оно воспринимается игроком.\n\n## Принцип\n\nЗапишите начальное состояние, событие и ожидаемый наблюдаемый результат. Такая структура соответствует Given/When/Then из [справочника Gherkin](https://cucumber.io/docs/gherkin/reference/), но для ручной проверки не требуется устанавливать Cucumber.\n\nРазделите чистое правило и его интеграцию. Расход заряда можно проверить на модели; столкновение с дверью, звук и восстановление после паузы требуют проверки в игре. Отладочные инструменты движка помогают увидеть причину, но отсутствие ошибок в консоли не означает правильность механики.\n\n<span id=\"пример-рывок-с-одним-зарядом\"></span>\n\n## Практический пример\n\n### Рывок с одним зарядом\n\nВ учебном контракте рывок тратит один заряд и длится 0,2 секунды игрового времени. Пауза останавливает игровой таймер. Смерть отменяет движение рывка, но не возвращает заряд. Это выбранные правила примера, а не универсальные требования.\n\n| Дано                  | Когда                    | Тогда                                      |\n| --------------------- | ------------------------ | ------------------------------------------ |\n| Персонаж жив, заряд 1 | Принят запрос рывка      | Заряд 0, состояние рывка активно           |\n| Заряд 0               | Повторный запрос         | Новый рывок не начинается                  |\n| Идёт рывок            | Игра поставлена на паузу | Длительность не расходуется во время паузы |\n| Идёт рывок            | Получено событие смерти  | Движение отменено, заряд остаётся 0        |\n\nДля одновременного запроса и смерти заранее задайте приоритет: в этой модели сначала обрабатывается смерть, рывок не начинается. На каждом прогоне восстанавливайте начальное состояние, иначе предыдущий тест исчерпает заряд следующего.\n\nВ модели с фиксированным шагом завершение проверяйте на первом тике, где накопленное игровое время достигло 0,2 секунды. Для ручного наблюдения укажите допустимую погрешность и используйте журнал, а не оценку на глаз.\n\n## Частые ошибки\n\n- Проверять только успешный случай с полным запасом ресурсов.\n- Считать скриншот доказательством правильной длительности.\n- Требовать тот же номер кадра при разной частоте отрисовки.\n- Выдавать автоматическую проверку правила за проверку удобства управления.\n\n## Проверка результата\n\n1. Выполните каждый сценарий из указанного состояния и сохраните результат.\n2. Повторите интеграционный проход при разных частотах отрисовки, сохраняя шаг симуляции.\n3. Проверьте паузу, перезапуск и одновременные события.\n4. Для сбоя запишите сборку, входные события, ожидаемое и фактическое поведение.\n\n## Задание для ИИ-агента\n\n> Реализуй контракт рывка и таблицу сценариев. Автоматизируй чистые переходы, остальные проверки опиши для целевого устройства. В отчёте раздели выполненное, не выполненное и найденные расхождения. Не выдумывай успешный запуск.\n\nСверьте переходы с уроком [«Состояния и переходы»](/ru/lessons/state-machines/) и призмой [«Правила»](/ru/lenses/#schell-033)."},{"id":"level-blockout","lang":"ru","title":"Блокаут: проверяем пространство до графики","description":"Собираем черновой уровень под реальные размеры, скорость и камеру персонажа, чтобы проверить игровую задачу.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["level-design","prototyping","playtesting"],"sources":[{"title":"The Level Design Book: Blockout","url":"https://book.leveldesignbook.com/process/blockout"},{"title":"The Level Design Book: Metrics","url":"https://book.leveldesignbook.com/process/blockout/metrics"}],"url":"https://gamemechanics.pro/ru/lessons/level-blockout/","markdownUrl":"https://gamemechanics.pro/content/ru/level-blockout.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nБлокаут, или graybox, нужен, чтобы проверить игру в пространстве, которое ещё легко переделать. Кубы, плоскости и условные обозначения достаточны, если персонаж уже движется по настоящим правилам.\n\n## Принцип\n\nПлан сверху показывает связи между комнатами. Играбельный черновик показывает, как эти связи работают со скоростью, коллизией и камерой. [The Level Design Book](https://book.leveldesignbook.com/process/blockout) рассматривает блокаут как средство ранних итераций. Это не обещание, что после него уровень больше не изменится.\n\nСначала сформулируйте вопрос: например, «Успевает ли игрок заметить закрывающуюся дверь и выбрать обход?» Красивый вид из редактора на него не отвечает. Если ключевая механика ещё не работает, выводы о подходящей геометрии будут предварительными.\n\n<span id=\"пример-склад-с-подвижной-дверью\"></span>\n\n## Практический пример\n\n### Склад с подвижной дверью\n\nЭто самостоятельный учебный сценарий, а не результат проведённого теста. У персонажа ширина 0,8 м и скорость 4 м/с. На складе есть прямой коридор длиной 12 м и обход длиной 20 м. Без остановок они занимают 3 и 5 секунд. Дверь на прямом пути закрывается через 4 секунды после сигнала.\n\nСоберите оба маршрута из примитивов. Поставьте камеру в игровое положение и включите настоящую коллизию. Измерьте путь от точки, где игрок впервые замечает сигнал, а не от удобной отметки в редакторе. Повороты и разгон могут увеличить время.\n\nПервый проход проверяет достижимость двери. Второй проверяет, остаётся ли понятный выход после её закрытия. Третий проверяет возврат с грузом, если груз влияет на движение.\n\n## Частые ошибки\n\n- Проверять уровень полётом камеры: проход выглядит широким, но персонаж застревает.\n- Заменять игровой контроллер временным: после изменения прыжка все расстояния требуют пересмотра.\n- Рано добавлять декор: автор защищает дорогую комнату, хотя маршрут не работает.\n\n## Проверка результата\n\n1. Пройдите оба маршрута из одинакового старта и запишите фактическое время.\n2. Проверьте узкие места с коллайдером и камерой игрового персонажа.\n3. Измените один размер, повторите проход и объясните изменение поведения.\n4. Зафиксируйте нерешённый вопрос перед переходом к оформлению.\n\n## Задание для ИИ-агента\n\n> Собери склад из простых форм. Все размеры, скорость и задержку двери вынеси в параметры. Покажи начало отсчёта и время прохождения. Не делай вывод о понятности маршрута без наблюдения за игроком. Подготовь три ручных сценария проверки.\n\nПродолжите упражнением [«Течение на бумаге»](/ru/practice/#paper-current): сначала проверьте правило дешёвым прототипом, затем перенесите его в пространство."},{"id":"level-wayfinding","lang":"ru","title":"Как сделать маршрут читаемым","description":"Даём игроку ориентиры и информацию для выбора пути, сохраняя возможность исследовать уровень.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["level-design","wayfinding","feedback"],"sources":[{"title":"The Level Design Book: Wayfinding","url":"https://book.leveldesignbook.com/process/blockout/wayfinding"}],"url":"https://gamemechanics.pro/ru/lessons/level-wayfinding/","markdownUrl":"https://gamemechanics.pro/content/ru/level-wayfinding.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nИгроку недостаточно доступного прохода. Ему нужна информация, чтобы понять своё положение, выбрать направление и заметить, что он приблизился к цели.\n\n## Принцип\n\nЧитаемый маршрут помогает принять решение. Он не обязан заставлять всех идти одной дорогой. Раздел [Wayfinding](https://book.leveldesignbook.com/process/blockout/wayfinding) предлагает смотреть на навигацию как на активное действие игрока. Исследование боковой комнаты само по себе не означает, что человек потерялся.\n\nРазделите три вопроса: «Где я?», «Куда хочу попасть?» и «Как отсюда пройти?». Ориентир может отвечать только на первый. Видимая башня не объясняет, где лестница к ней. Для лабиринта допустима намеренная неопределённость, но её следует отличать от случайно нечитаемой двери.\n\n<span id=\"пример-станция-наблюдения\"></span>\n\n## Практический пример\n\n### Станция наблюдения\n\nВ учебном уровне игрок несёт батарею к антенне. С площадки старта видна антенна, но вход к ней находится этажом выше. Разместим лестницу так, чтобы её верхняя площадка тоже была видна со старта. Дверь мастерской сбоку получит знак инструмента, а дверь к антенне получит тот же контур антенны, который виден в мире.\n\nПосле подъёма игрок снова видит цель из нового положения. На обратном пути узнаваемое окно помогает найти площадку старта. Цвет можно использовать дополнительно, но форма и расположение должны сохранять смысл без него.\n\nЭто проектный вариант для проверки. Он не доказывает, что указателей уже достаточно. Попросите человека самостоятельно доставить батарею и отметьте места остановок, возвратов и неверных предположений.\n\n## Частые ошибки\n\n- Каждая лампа выглядит как ориентир: важный вход теряется среди равнозначных сигналов.\n- Критическая информация видна только с камеры автора: игрок смотрит в другую сторону.\n- Автор считает любой обход ошибкой: исчезает запланированное исследование.\n\n## Проверка результата\n\n- Снимите вид из точек, где нужно выбрать путь, в реальной игровой камере.\n- Проверьте, можно ли назвать цель и ближайший шаг отдельно.\n- Уберите цветовые различия и проверьте оставшиеся обозначения. Это частичная проверка, а не доказательство доступности.\n- После боковой комнаты проверьте возвращение к основному маршруту.\n\n## Задание для ИИ-агента\n\n> Предложи для станции три навигационных сигнала: цель, путь к лестнице, возврат. Для каждого укажи точку наблюдения и возможное ошибочное прочтение. Измени один сигнал после плейтеста, сохрани боковую мастерскую.\n\nИспользуйте призму [«Цели»](/ru/lenses/#schell-032) и упражнение [«Три минуты в музее»](/ru/practice/#three-minute-museum) для проверки первого самостоятельного действия."},{"id":"npc-action-selection","lang":"ru","title":"Как NPC выбирает действие","description":"Разделяем допустимость, приоритет и выполнение действия, чтобы персонаж принимал объяснимые решения и не метался между ними.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["npc-ai","decision-making","debugging"],"sources":[{"title":"Dawe et al.: Behavior Selection Algorithms, An Overview","url":"https://www.gameaipro.com/GameAIPro/GameAIPro_Chapter04_Behavior_Selection_Algorithms.pdf"},{"title":"David Rez Graham: An Introduction to Utility Theory","url":"https://www.gameaipro.com/GameAIPro/GameAIPro_Chapter09_An_Introduction_to_Utility_Theory.pdf"}],"url":"https://gamemechanics.pro/ru/lessons/npc-action-selection/","markdownUrl":"https://gamemechanics.pro/content/ru/npc-action-selection.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nПерсонажу могут одновременно требоваться зарядка, ремонт и помощь игроку. Напишите правило выбора явно, прежде чем усложнять архитектуру поведения.\n\n## Принцип\n\nСначала отберите допустимые действия, затем выберите одно, затем выполните его. Не позволяйте каждой подсистеме независимо управлять движением. Обзор алгоритмов в Game AI Pro сравнивает машины состояний, деревья поведения и другие способы выбора; универсального победителя здесь нет.\n\nДля нескольких жёстких режимов удобна машина состояний. Для последовательностей проверок и действий подходит дерево поведения. Для сравнения ситуативной полезности можно оценивать кандидатов общей шкалой, как описано в главе о utility theory. Система оценок не заменяет запреты и проверку доступности действия.\n\n<span id=\"пример-ремонтный-робот\"></span>\n\n## Практический пример\n\n### Ремонтный робот\n\nВ нашей учебной модели робот может заряжаться, чинить насос или помогать игроку открыть тяжёлую дверь. Заряд нормирован от 0 до 1. Ниже 0,1 действует обязательное правило: отправиться на доступную зарядку. Если путь к ней отсутствует, робот переходит в безопасное ожидание и сообщает причину.\n\nВ остальных случаях сравним допустимые кандидаты:\n\n| Действие | Оценка в этой модели | Условие допуска                       |\n| -------- | -------------------- | ------------------------------------- |\n| Зарядка  | `1 - battery`        | Станция достижима                     |\n| Ремонт   | `leakSeverity`       | Есть детали и путь к насосу           |\n| Помощь   | `requestUrgency`     | Запрос ещё актуален и дверь достижима |\n\nВсе входы ограничены диапазоном 0..1. При заряде 0,6, утечке 0,8 и срочности 0,5 выигрывает ремонт. Это выбранные проектные оценки, а не измерение человеческих желаний.\n\nЧтобы близкие оценки не вызывали метания, сохраняйте текущее действие, пока конкурент не лучше минимум на 0,15. Недопустимое или завершённое действие освобождайте сразу. При равенстве используйте стабильный порядок. Порог можно менять после наблюдения; жёсткое правило низкого заряда всё равно имеет приоритет.\n\n## Частые ошибки\n\n- Сравнивать расстояние в метрах с срочностью 0..1 без преобразования шкалы.\n- Каждый кадр начинать ремонт заново, сбрасывая прогресс.\n- Удерживать действие ради стабильности, когда цель уже уничтожена.\n\n## Проверка результата\n\n- Запишите входы, исключённые действия, оценки и причину выбора.\n- Проверьте равенство оценок, потерю цели и отсутствие любого допустимого кандидата.\n- Колеблите срочность рядом с порогом и проверьте отсутствие частых переключений.\n- Отдельно проверьте обязательную зарядку и её недостижимость.\n\n## Задание для ИИ-агента\n\n> Реализуй выбор как чистую функцию снимка мира и текущего действия. Отдельно сделай выполнение. Подготовь таблицу граничных ситуаций и объясни каждый результат без случайного выбора. Не подключай языковую модель к покадровому управлению.\n\nПроверьте решение через призмы [«Действия»](/ru/lenses/#schell-031) и [«Прозрачность»](/ru/lenses/#schell-062)."},{"id":"npc-pathfinding","lang":"ru","title":"Поиск пути и выполнение маршрута","description":"Выбираем представление пространства и стоимость переходов, отделяя найденный путь от реального движения NPC.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["npc-ai","pathfinding","algorithms"],"sources":[{"title":"Amit Patel, Red Blob Games: Introduction to the A* Algorithm","url":"https://www.redblobgames.com/pathfinding/a-star/introduction.html"}],"url":"https://gamemechanics.pro/ru/lessons/npc-pathfinding/","markdownUrl":"https://gamemechanics.pro/content/ru/npc-pathfinding.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nНайти последовательность клеток и провести по ней персонажа без застреваний являются двумя разными задачами. Начните с модели пространства, затем проверьте обе части.\n\n## Принцип\n\nПоиск работает с графом: узлами и допустимыми переходами между ними. В [объяснении Red Blob Games](https://www.redblobgames.com/pathfinding/a-star/introduction.html) одна и та же идея применяется к разным представлениям пространства. Клеточная сетка удобна, но не обязательна.\n\nПри одинаковой стоимости переходов поиск в ширину (BFS) находит путь с наименьшим числом переходов. При неотрицательных разных стоимостях Dijkstra учитывает их сумму. A* добавляет оценку остатка пути. На четырёхсвязной сетке без диагоналей расстояние Манхэттена, умноженное на минимальную стоимость шага, подходит как нижняя оценка; нестандартные переходы вроде телепорта могут её нарушить.\n\n<span id=\"пример-коридоры-ремонтного-робота\"></span>\n\n## Практический пример\n\n### Коридоры ремонтного робота\n\nВ условном графе есть два маршрута от A к G. В обе стороны доступны только перечисленные рёбра:\n\n| Ребро | Стоимость |\n| ----- | --------: |\n| A–B   |         1 |\n| B–G   |         4 |\n| A–C   |         2 |\n| C–D   |         1 |\n| D–G   |         1 |\n\nМаршрут A–B–G содержит два перехода и стоит 5. Маршрут A–C–D–G содержит три и стоит 4. BFS решит задачу числа переходов, но не минимальной стоимости. Dijkstra должен выбрать второй маршрут. A* с нулевой эвристикой сводится к Dijkstra и удобен как исходная проверка.\n\nТеперь разместите коридоры в игре. Учитывайте ширину робота при построении проходимости. Если дверь закрылась, старый путь может потерять смысл. Сигнал изменения навигации или обнаружение блокировки должны приводить к пересчёту либо понятному отказу по правилам проекта.\n\n## Частые ошибки\n\n- Использовать прямое расстояние как гарантированную оценку при дешёвых телепортах.\n- Считать пустой путь успехом, когда цель недостижима. Старт, совпавший с целью, является отдельным случаем.\n- Пересчитывать путь каждый кадр без необходимости и без измерения стоимости.\n- Забывать, что сглаженный отрезок может срезать непроходимый угол.\n\n## Проверка результата\n\n1. Проверьте обе суммы вручную и сравните результат алгоритма.\n2. Удалите D–G: должен остаться маршрут A–B–G стоимостью 5. Затем удалите B–G и проверьте явный результат «пути нет».\n3. Проверьте совпадение старта и цели и закрытие двери во время движения.\n4. Пройдите найденный маршрут реальным коллайдером, включая узкие повороты.\n\n## Задание для ИИ-агента\n\n> Отдели поиск пути от движения робота. Верни маршрут, суммарную стоимость и статус. На указанном графе сравни BFS и Dijkstra, затем добавь обработку блокировки. Не объявляй готовую навигацию по одной нарисованной линии.\n\nОцените функциональное пространство через призму [«Функциональное пространство»](/ru/lenses/#schell-026)."},{"id":"npc-perception","lang":"ru","title":"Восприятие NPC и память о цели","description":"Разделяем состояние мира и знания персонажа: видимость, последнее наблюдение, забывание и понятная реакция.","category":"engineering","level":"intermediate","minutes":6,"updatedAt":"2026-10-20","tags":["npc-ai","perception","state-machines"],"sources":[{"title":"Martin Walsh: Modeling Perception and Awareness in Splinter Cell Blacklist","url":"https://www.gameaipro.com/GameAIPro2/GameAIPro2_Chapter28_Modeling_Perception_and_Awareness_in_Tom_Clancy%27s_Splinter_Cell_Blacklist.pdf"}],"url":"https://gamemechanics.pro/ru/lessons/npc-perception/","markdownUrl":"https://gamemechanics.pro/content/ru/npc-perception.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nИгровой код знает координаты всех объектов. NPC не обязан знать их. В этом уроке ИИ означает алгоритм поведения персонажа, а не языковую модель.\n\n## Принцип\n\nОтделите наблюдение от решения. Восприятие сообщает «цель видна» или «шум услышан», память хранит последнее известное место, поведение выбирает действие. Глава Мартина Уолша в Game AI Pro 2 разбирает восприятие и осведомлённость как игровые модели, для которых важны последовательность правил и обратная связь.\n\nНачните с [состояний и переходов](/ru/lessons/state-machines/). Затем явно определите, какие сведения доступны в каждом состоянии. Если NPC использует скрытые координаты игрока после потери видимости, это должно быть осознанным правилом игры, а не случайной утечкой данных.\n\n<span id=\"пример-наблюдательный-дрон\"></span>\n\n## Практический пример\n\n### Наблюдательный дрон\n\nВ самостоятельной учебной модели дрон замечает игрока в секторе 90° на расстоянии до 8 м при свободном луче до контрольной точки цели. Одного радиуса недостаточно: стена блокирует наблюдение. Луч до одной точки тоже упрощает реальность и может давать странные результаты у края укрытия.\n\nПри видимости дрон обновляет последнее известное место. Потеряв игрока, он ищет в этом месте две секунды, затем возвращается к маршруту. Он не обновляет память сквозь стену.\n\nИллюстративный псевдокод, не код конкретного движка:\n\n```text\nvisible = within_range(target) and within_cone(target) and clear_ray(target)\nif visible:\n    memory.position = target.position\n    memory.expires_at = now + 2.0\n    state = tracking\nelse if now < memory.expires_at:\n    state = searching\n    search_position = memory.position\nelse:\n    state = patrol\n```\n\nПредполагается, что до первого наблюдения срок памяти уже истёк. Вариант хранит короткую память, но не моделирует накопление подозрения. Добавляйте его, только если это нужно игровому правилу.\n\n## Частые ошибки\n\n- Дальность есть, проверки преграды нет: NPC видит через стены.\n- Поиск идёт к текущей скрытой цели: память на деле всеведущая.\n- Состояние меняется без сигнала: игрок не понимает, обнаружен ли он.\n\n## Проверка результата\n\n- Покажите отладочный сектор, луч, состояние и точку памяти.\n- Проверьте цель впереди, позади, за стеной и на границе дальности.\n- После потери видимости переместите игрока и убедитесь, что точка памяти неподвижна.\n- При дискретном обновлении проверьте истечение памяти на первом тике после срока.\n\n## Задание для ИИ-агента\n\n> Реализуй раздельные наблюдение, память и состояние дрона. Подготовь четыре сцены проверки и журнал причин перехода. Назови упрощения луча и частоты обновления. Визуально обозначь поиск, не используя только цвет.\n\nДля разбора используйте призмы [«Машина состояний»](/ru/lenses/#schell-028) и [«Обратная связь»](/ru/lenses/#schell-063)."},{"id":"progression-pacing","lang":"ru","title":"Прогрессия: рост возможностей и темп","description":"Проверяем, что улучшения меняют действия игрока, а рост чисел не скрывает повторение одной задачи.","category":"design","level":"intermediate","minutes":5,"updatedAt":"2026-10-20","tags":["balance","progression","economy"],"sources":[{"title":"Ian Schreiber: Level 7, Advancement, Progression and Pacing","url":"https://gamebalanceconcepts.wordpress.com/2010/08/18/level-7-advancement-progression-and-pacing/"}],"url":"https://gamemechanics.pro/ru/lessons/progression-pacing/","markdownUrl":"https://gamemechanics.pro/content/ru/progression-pacing.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nУровень персонажа может расти, а его действия оставаться прежними. Чтобы проектировать прогрессию, опишите изменение опыта между этапами: новую возможность, другой риск или более короткий путь к знакомой цели.\n\n## Принцип\n\nРазделяйте рост чисел, освоение навыка и открытие действий. [Лекция о прогрессии](https://gamebalanceconcepts.wordpress.com/2010/08/18/level-7-advancement-progression-and-pacing/) рассматривает развитие вместе с темпом игры. Одной кривой опыта недостаточно, чтобы проверить интерес или подходящую длительность сессии.\n\nНачните с желаемого изменения: например, после первого улучшения игрок способен быстро убрать мелкое препятствие и заняться выбором маршрута. Затем подберите числа и проверьте, происходит ли это изменение. Это проектная гипотеза, не установленная норма для всех жанров.\n\n<span id=\"пример-три-этапа-очистки-станции\"></span>\n\n## Практический пример\n\n### Три этапа очистки станции\n\nВ условной модели каждый удар попадает, урон постоянен, восстановления прочности нет.\n\n| Этап             | Урон | Прочность препятствия | Ударов до разрушения |\n| ---------------- | ---: | --------------------: | -------------------: |\n| Начало           |   10 |                    40 |                    4 |\n| Перед улучшением |   12 |                    60 |                    5 |\n| После улучшения  |   20 |                    60 |                    3 |\n\nПервый рост урона не ускорил работу: прочность выросла сильнее. Второе улучшение пересекает порог числа ударов. Если интервалы, промахи и анимации отличаются, число ударов ещё не равно времени решения.\n\nТеперь добавим цену. Улучшение за 60 деталей при награде 10 за встречу требует шести встреч, если других расходов и доходов нет. Следующее за 120 при награде 15 требует восьми. Проверьте, добавились ли за эти восемь встреч новые решения. Более длинное ожидание само по себе не создаёт развитие.\n\n## Частые ошибки\n\n- Одновременно умножать силу и здоровье врагов, не проверяя реальное изменение действий.\n- Учитывать доход, забыв обязательные расходы на ремонт.\n- Мерить прогресс только общей длительностью, скрывая длинный участок без новых решений.\n\n## Проверка результата\n\n1. Посчитайте удары и ожидаемый путь к покупке для каждого этапа.\n2. Отдельно проверьте порог до и после улучшения на тех же препятствиях.\n3. Запишите новые решения игрока и места, где повторяется прежняя задача.\n4. Сравните план с наблюдаемой сессией; не подгоняйте отчёт под кривую.\n\n## Задание для ИИ-агента\n\n> Подготовь таблицу трёх этапов станции. Покажи пороги ударов, доход, обязательные расходы и число встреч до улучшения. Предложи изменение возможностей вместо одного повышения числа. Все значения назови учебными.\n\nПримените призмы [«Награды»](/ru/lenses/#schell-046) и [«Видимый прогресс»](/ru/lenses/#schell-055), затем попробуйте [«Убрать рынок»](/ru/practice/#remove-the-market)."},{"id":"running-a-playtest","lang":"ru","title":"Плейтест с конкретным вопросом","description":"Готовим короткую игровую сессию, отделяем наблюдения от интерпретаций и выбираем следующее изменение.","category":"workflow","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["playtesting","observation","iteration"],"sources":[{"title":"The Level Design Book: Playtesting","url":"https://book.leveldesignbook.com/process/blockout/playtesting"}],"url":"https://gamemechanics.pro/ru/lessons/running-a-playtest/","markdownUrl":"https://gamemechanics.pro/content/ru/running-a-playtest.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nВопрос «Ну как тебе игра?» часто даёт вежливый ответ, с которым трудно работать. Полезнее заранее выбрать неопределённость и посмотреть, что человек делает в конкретной игровой ситуации.\n\n## Принцип\n\nСформулируйте вопрос, подготовьте подходящий фрагмент игры и наблюдайте. [The Level Design Book](https://book.leveldesignbook.com/process/blockout/playtesting) различает самостоятельный проход, разбор с коллегой и наблюдение за внешним игроком. Они решают разные задачи.\n\nДля проверки первого знакомства нужен участник, который ещё не знает решение. Повторный проход того же человека помогает проверить удобство, но уже не воспроизводит первое открытие. Несколько наблюдений обнаруживают проблемы; они не доказывают предпочтения всей аудитории.\n\n<span id=\"пример-доставка-на-станцию\"></span>\n\n## Практический пример\n\n### Доставка на станцию\n\nУчебный вопрос: «Находит ли новый игрок способ доставить батарею к антенне без устного объяснения?» Подготовьте одну версию уровня, одинаковый старт и формулировку цели. Попросите человека поиграть; объясните, что проверяется игра, а не его способности. Перед записью экрана или голоса получите согласие.\n\nВо время прохода разделяйте записи:\n\n| Наблюдение                        | Возможное объяснение       | Следующая проверка                 |\n| --------------------------------- | -------------------------- | ---------------------------------- |\n| Трижды подошёл к закрытому люку   | Люк обещает доступный путь | Изменить обозначение люка          |\n| Вернулся на старт после лестницы  | Потерял направление к цели | Проверить видимость антенны сверху |\n| Спросил, можно ли бросить батарею | Неясны допустимые действия | Проверить подсказку переноса       |\n\nЭто примеры возможных записей, а не проведённое исследование. Не подсказывайте решение, чтобы быстрее получить успешный проход. Если пришлось помочь из-за блокирующей ошибки, зафиксируйте момент и содержание помощи.\n\nПосле сессии спросите, какую цель игрок преследовал в спорном месте. Ответ помогает уточнить интерпретацию, но не отменяет наблюдение. Выберите одно изменение, связанное с вопросом, и повторите проверку.\n\n## Частые ошибки\n\n- Изменять сборку посреди серии и сравнивать результаты как одинаковые условия.\n- Записывать «запутался» без места, действия и контекста.\n- Одновременно менять камеру, маршрут и управление, теряя причину эффекта.\n\n## Проверка результата\n\n- У отчёта есть вопрос, версия сборки, условия старта и сведения о знакомстве участника с игрой.\n- Факты отделены от предположений и решений автора.\n- Помощь и блокирующие ошибки отмечены отдельно.\n- Следующее изменение связано хотя бы с одним наблюдением.\n\n## Задание для ИИ-агента\n\n> Подготовь план пятиминутного плейтеста станции: один вопрос, нейтральное задание, таблицу наблюдений и вопросы после игры. Не выдумывай участников и результаты. После реальных заметок предложи один следующий эксперимент.\n\nИспользуйте призму [«Плейтест»](/ru/lenses/#schell-103) и упражнение [«Три минуты в музее»](/ru/practice/#three-minute-museum)."},{"id":"teaching-a-mechanic","lang":"ru","title":"Обучение одной механике через уровень","description":"Строим короткую последовательность, в которой игрок пробует правило, получает обратную связь и применяет его в новой ситуации.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["level-design","learning","feedback"],"sources":[{"title":"Patrick Holleman: Reverse Design, Super Mario World","url":"https://thegamedesignforum.com/features/RD_SMW_1.html"}],"url":"https://gamemechanics.pro/ru/lessons/teaching-a-mechanic/","markdownUrl":"https://gamemechanics.pro/content/ru/teaching-a-mechanic.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nИгрок может прочитать подсказку и всё ещё не понимать правило. Чтобы проверить понимание, дайте ему возможность выполнить действие и самостоятельно перенести его в немного другую ситуацию.\n\n## Принцип\n\nВыберите один навык, который уровень должен сделать понятным. У анализа [Reverse Design: Super Mario World](https://thegamedesignforum.com/features/RD_SMW_1.html) полезен сам подход: рассматривать отдельные препятствия и их последовательности, а не ограничиваться общим советом «сделать сложнее».\n\nДля своего прототипа разделите знакомство, самостоятельную попытку и перенос навыка. Это рабочая схема, а не обязательный закон построения любого уровня. Она не заменяет понятного управления, доступных подсказок и проверки с вашей аудиторией.\n\n<span id=\"пример-импульсная-платформа\"></span>\n\n## Практический пример\n\n### Импульсная платформа\n\nПридуманный уровень обучает платформе, которая поднимается на одну секунду после нажатия кнопки. В первой комнате кнопка и платформа видны одновременно, а неудачный прыжок возвращает на безопасный пол. Игрок может без потери прогресса увидеть связь между действием и движением.\n\nВо второй комнате кнопка стоит чуть дальше. Правило прежнее, но теперь нужно начать движение сразу после нажатия. В третьей комнате две возможные площадки, и игрок выбирает подходящую для подъёма к выходу. Новый враг, новый вид кнопки и новый прыжок одновременно здесь не нужны: иначе причина ошибки станет неясной.\n\nИзменяйте один параметр между попытками. Если игрок ждёт подъёма платформы, но не прыгает, проверьте управление прыжком. Если он не связывает кнопку с платформой, исправьте обратную связь до усложнения времени.\n\n## Частые ошибки\n\n- Первое знакомство сразу наказывает смертью и долгим повтором.\n- Вторая комната требует другого, ещё не показанного правила.\n- Автор объясняет решение голосом и принимает выполнение за самостоятельное понимание.\n\n## Проверка результата\n\n1. Запишите, какое действие свидетельствует о понимании в каждой комнате.\n2. Проведите попытку без устных подсказок; отдельно отметьте оказанную помощь.\n3. Попросите игрока описать правило после прохождения, не подсказывая формулировку.\n4. При неудаче измените один элемент и повторите наблюдение с новым участником.\n\n## Задание для ИИ-агента\n\n> Опиши три комнаты для импульсной платформы. Для каждой укажи уже известное правило, новый вопрос, безопасный способ повторить попытку и наблюдаемый признак понимания. Не добавляй механики за пределами этого навыка.\n\nРазверните последовательность в упражнении [«Комната сигналов»](/ru/practice/#signal-room) и проверьте её через призму [«Навыки»](/ru/lenses/#schell-034)."},{"id":"world-to-gameplay","lang":"ru","title":"От правил мира к действиям игрока","description":"Связываем устройство игрового мира с действиями и последствиями, затем выбираем небольшую ситуацию для проверки прототипом.","category":"design","level":"beginner","minutes":5,"updatedAt":"2026-10-20","tags":["worldbuilding","mechanics","prototyping"],"sources":[{"title":"Ярополк Раш: Руководство по созданию культовых IP / The Iconic IP Guide","url":"https://worldfirstmethod.com/ipguide"}],"url":"https://gamemechanics.pro/ru/lessons/world-to-gameplay/","markdownUrl":"https://gamemechanics.pro/content/ru/world-to-gameplay.md","license":"CC-BY-4.0","codeLicense":"MIT","attribution":"gamemechanics.pro contributors","body":"## Что нужно знать\n\nОписание мира помогает проектировать игру, когда из него можно вывести действия и последствия. Начните с одного правила, которое игрок сможет заметить, использовать и проверить. Достаточно идеи мира и простого плана игровой ситуации; движок пока не нужен.\n\n## Принцип\n\nУ мира могут быть необычная история, культура и внешний вид. Для игровой ситуации важно понять, что они меняют в доступных действиях. Если города живут за счёт магии, уточните, что игрок с ней делает, чем платит и что происходит после её применения.\n\nСвязь устройства мира с возможностями первой игры рассматривает Ярополк Раш, автор World-First Method, в [«Руководстве по созданию культовых IP»](https://worldfirstmethod.com/ipguide). Здесь использована идея из русской версии 3.2, страниц 32–39 PDF. Пример и порядок проверки ниже разработаны для этого урока.\n\nТакой подход полезен, когда особенности мира должны участвовать в решениях игрока. Начать можно и с готовой механики: тогда проверьте, какие правила мира объясняют её возможности и ограничения. Для первого прототипа достаточно одной ситуации.\n\n### От допущения к выбору\n\nЗапишите короткую цепочку:\n\n```text\nПравило мира → действие игрока → изменение ситуации → следующий выбор\n```\n\nДля каждого перехода назовите наблюдаемый результат. «Магия опасна» пока не задаёт поведения. «Заклинание открывает дверь, но привлекает стража к источнику звука» уже позволяет выбрать маршрут, момент и место применения.\n\nОтдельно укажите цену действия: расходуемый предмет, время, раскрытие позиции или отказ от другого пути. Цена нужна там, где вы хотите создать выбор. Декоративной детали не обязательно становиться механикой.\n\n## Практический пример\n\n### Звуковые ворота\n\nЭто условный учебный сценарий. В городе механизмы получают энергию от звона. Во дворе находятся ворота, два колокола и страж. Любой из колоколов слышен у ворот; звон открывает их до конца попытки. Страж слышит тот же звон и идёт к его источнику.\n\nИгрок может подойти к колоколу у ворот и позвонить вручную. Камень сохранится, но страж направится к месту, где только что стоял игрок. Другой вариант: из укрытия бросить единственный камень в дальний колокол, увести стража в сторону и пройти к воротам. Камень после броска недоступен до перезапуска.\n\nОдно свойство мира связывает открытие прохода, поведение противника и расход предмета. Чтобы проверить эту связь, пока не нужны история города, другие виды энергии и система торговли. Какие варианты окажутся полезными, зависит от расстояний, скорости стража и укрытий; это предстоит выяснить в прототипе.\n\n### Что оставить в прототипе\n\nВыберите детали, без которых нельзя проверить нужное решение. Для примера достаточно двора, двух колоколов, ворот, стража и одного камня. Сначала их можно представить фишками на плане.\n\nДо проверки задайте дальность броска, порядок перемещений и условие обнаружения. Используйте одни правила во всех попытках. Подготовьте два стартовых положения стража, чтобы увидеть, учитывает ли игрок ситуацию при выборе источника звука.\n\nПосле знакомства с правилом попросите игрока до действия показать, куда пойдёт страж и что случится с воротами. Затем дайте пройти двор и запишите выбор, результат и потребовавшиеся подсказки. Если прогноз верен, а пройти не удаётся, отдельно проверьте исполнение: времени на манёвр может не хватать даже при понятном правиле.\n\n## Частые ошибки\n\n- Особенность существует только в описании: игрок не может ею воспользоваться.\n- Правило меняется ради сцены: одинаковый звон без объяснения даёт разные результаты.\n- В прототип попадает вся придуманная вселенная: проверка одного решения откладывается.\n- Одобрение идеи принимают за результат проверки: остаётся неизвестно, что человек понял и сделал.\n\n## Проверка результата\n\n- Есть действие, через которое игрок знакомится с правилом мира.\n- У действия видны последствия, влияющие на следующую возможность.\n- Ограничения последовательны; исключения можно заметить и объяснить.\n- Для каждой детали прототипа названа её роль в проверяемой ситуации.\n- Ожидания автора записаны отдельно от наблюдений за игроком.\n\n## Задание для ИИ-агента\n\n> Возьми одно правило моего игрового мира и предложи две ситуации, где оно меняет действия игрока. Выбери одну для маленького прототипа. Опиши действия, последствия, ограничения и способ проверить понимание правила. Укажи детали, которые можно отложить. Отдельно перечисли допущения и вопросы, требующие моего решения; не придумывай результаты плейтеста.\n\nОграничить работу поможет урок [«Скоуп и проверяемый прототип»](/ru/lessons/scope-and-prototype/). Для проверки связности используйте призмы [«Мир»](/ru/lenses/#schell-084) и [«Единство»](/ru/lenses/#schell-011)."}]}