Как игра на Delphi, собранная на соплях, превратилась в четыре принципа, которые работают до сих пор
Олег Крючков
Много лет назад у нас возникла довольно дурацкая ситуация: клиент хотел новогодний корпоратив, а вариантов «в помещении» тогда у нас не было.
И тут я за ночь придумываю игру, которую назвал «Левитан». Каждая команда получала компьютер. Не телефон — тогда это были нормальные десктопы или ноутбуки. На компьютере запускалось приложение, которое я сам написал на Delphi. Простенький редактор: кисти, краски, возможность что-то рисовать.
Но просто рисовать было бы скучно, поэтому я скрестил редактор с квизом. Команда отвечала на вопросы и выполняла задания. За правильные ответы получала не баллы, а возможность получить новые краски, кисти и другие ресурсы. То есть правильный ответ не просто увеличивал цифру в таблице. Он реально менял то, что команда могла делать дальше.
Но и этого мне показалось мало. Команды должны были нарисовать не что угодно, а вполне конкретный сюжет — только сюжет был собран из разных известных картин. Что-нибудь вроде «Запорожцы пишут письмо царевне Лебедь», «Девочка с персиками на перевале Сен-Бернар» или «Переход Суворова через Девятый вал».
Всё это было довольно криво, местами на соплях и, конечно, совершенно не похоже на продукт, который прошёл нормальный цикл разработки.
Но оно взлетело.
Люди играли, спорили, зарабатывали себе кисточки и краски, рисовали какую-то абсолютную дичь — и им было весело.
И вот сейчас, когда я вспоминаю эту историю, я вижу в ней четыре довольно универсальных принципа проектирования.
Ограничение — не помеха, а исходный материал
Продукт часто появляется не потому, что кто-то решил «давайте создадим новый продукт», а потому что обычное решение не подходит, денег нет, времени нет или предложить клиенту просто нечего.
Новое часто получается не из нового, а из неожиданного соединения известного
Графический редактор сам по себе не был новым. Квиз — тоже. Но если результат квиза начинает менять возможности в редакторе, возникает уже другая механика.
Хорошая система строится не вокруг функций, а вокруг последствий действий
Ответил правильно — изменилось состояние системы. Появились новые инструменты. Значит, появилось новое возможное действие. Именно эта цепочка «действие → изменение состояния → новая возможность» и делает механику живой.
Механике нужен сюжет, который люди смогут пересказать
Можно было просто предложить нарисовать что-нибудь. Но «Запорожцы пишут письмо царевне Лебедь» или «Переход Суворова через Девятый вал» запоминается гораздо лучше. Технология становится событием только тогда, когда у неё появляется человеческая оболочка.
Я почему сейчас это вспомнил: потому что иногда новый продукт появляется не тогда, когда у тебя есть стратегия, бюджет, исследование рынка и roadmap.
Иногда он появляется, когда тебе просто нечего предложить клиенту. И ты садишься и делаешь штуку, которой вчера ещё не существовало.
Если у вас тоже есть задача, для которой «нормального продукта пока нет», — возможно, это как раз хороший повод его придумать.