05 июля 2015

       Разработка игр
Hippiman/Conscience 

  Эта статья состоит из двух больших час─
тей. В  первой  я постараюсь охватить весь
процесс разработки игры,не вдаваясь в тех─
нические  подробности  и не привязываясь к
определённой  платформе и языку программи─
рования, т.к.по каждой платформе в отдель─
ности уже написано множество книг. Во вто─
рой  перейдём  к более приземлённым вопро─
сам: я дам  описание  среды разработки игр
под  ZX Evolution(которые  также пойдут и 
на ATM Turbo 2/2+и на Pentagon 2.6ббLE) - 
Evo SDK. 

   До смешного  обидно бывает, когда ждёшь
какую-нибудь  интересную игру от независи─
мых  разработчиков. Ждешь месяц, год, а её
всё нет,разработчики делятся информацией о
ходе  разработки всё реже, а потом и вовсе
перестают. Игра так и не появляется. А по─
чему? Причины бывают разные: например,раз─
работчик женился, сменил работу, и ему те─
перь некогда делать игру. Такое бывает, но
чаще всего разработку игры забрасывают из-
за неправильно поставленного процесса раз─
работки,просто потому что делать её стано─
вится  не интересно. Энтузиазм  постепенно
угасает, и  разработчик  берётся  за  дело
поинтересней, а  игру  отправляет в долгий
ящик. Вот о том, как этого избежать, и бу─
дет первая часть статьи. Она должна помочь
кому-то  завершить свои заброшенные проек─
ты, кому-то  решиться  начать  делать свою
первую  игру, а кому-то  сделать из своего
проекта "конфетку" с отличным геймплеем.

   Итак, как вообще делается игра?
   Процесс разработки любой игры можно ус─
ловно разделить на 4 этапа:

 1.Идея.
 2.Подготовка.
 3.Разработка и тестирование.
 4.Релиз и пострелизное сопровождение.

   Разберём эти этапы подробнее.

                   Идея

   Перед  началом  разработки  игры  нужно
придумать, о чём она  будет."Хочу сделать
игру про самолёт, летающий по лабиринту из
пещер. А там ещё пыщь-пыщь,и снизу ещё че─
ловечки  бегают туда-сюда". Как бы бредово
идея  ни звучала, её уже хватит для начала
разработки. Начинающему разработчику лучше
немного  обуздать  свою  фантазию и первую
пару игр сделать попроще.Несложной логиче─
ской игры, Тетриса или простенькой одноэк─
ранной аркады  будет более чем достаточно.
Поверьте  мне, при создании даже, казалось
бы, примитивной логической игрушки начина─
ющий разработчик столкнётся с огромным ко─
личеством проблем и, соответственно,приоб─
ретёт неплохой опыт,который уже можно при─
менить для создания игры посложнее.
   Следующим  шагом  нужно  определиться с
платформой и средой разработки.Лучше всего
выбирать  платформу  и среду разработки, с
которыми вы наиболее знакомы, особенно для
первой игры. А для тех,кто не владеет про─
граммированием  ни на каком языке, создано
множество "конструкторов", с помощью кото─
рых можно сделать свою игру почти без еди─
ной  строчки кода. Это не относится только
к PC. Для ZX Spectrum (в дальнейшем просто
"Спектрум") есть Arcade Game Designer. Для 
невладеющих ассемблером есть замечательный
движок   Churrera,  позволяющий  создавать
очень приличные игры для Спектрума на язы─
кеC. А для разработки игр под расширенные
клоны Спектрума типа ATM Turbo 2  есть Evo
SDK - среда разработки на языкеC, которая 
позволяет  писать игры на домашнем компью─
тере более быстро и просто, чем это делае─
тся на ассемблере.
   Итак, с  платформой  и средой определи─
лись. Теперь, возможно, придётся подкорре─
ктировать  идею. Ведь, согласитесь, на  ZX
Spectrum 48K  вряд  ли  получится  создать 
трёхмерную  стратегию  в  реальном времени
или что-то в этом роде.
   Если вы не хотите делать игру "в стол",
но желаете, чтобы она кому-нибудь понрави─
лась,то немаловажным будет определить клю─
чевые  отличия вашей игры от схожих по жа─
нру  на  целевой платформе. Очередной клон
популярной игры мало кому будет интересен,
но если у игры есть своя "фишка", уже есть
шанс привлечь потенциального пользователя.
Возможно, придётся  подкорректировать идею
ещё раз.
   И последнее: для  какой аудитории пред─
назначена  игра. Неоднократно проверено на
практике  и  доказано  провалами  игр  ААА
класса, что попытка угодить "и нашим,и ва─
шим" приводит  только к тому, что игра ни─
кому не нравится. До начала разработки ну─
жно чётко понимать,кто будет играть в вашу
игру, что  нравится этой группе игроков, а
что не нравится, и подстраиваться под них.

                Подготовка

   На этапе подготовки предстоит как можно
тщательнее продумать и описать все аспекты
будущей игры.Лучше всего создать документ,
так называемый "Дизайн документ" или "Диз─
док", в который будут заноситься все идеи, 
касающиеся будущей игры.Можно всё это дер─
жать  и в голове, но  в таком случае будет
очень легко увлечься каким-то одним аспек─
том  и напрочь  забыть о чём-то другом, не
менее  важном. В  конечном итоге потеряете
время и силы, а может быть,и вообще забро─
сите разработку.
   В итоге  у вас  должен получиться доку─
мент (давайте всё-таки считать, что вы по─
следовали совету и создали хотя бы простой
текстовый файл), описывающий:

 1.Мир, в котором происходит игра.
 2.Внешность и характер главного героя.
 3.Других персонажей,возможно,врагов или
главного злодея. 
 4.Мотивацию главного героя.
 5.Мотивацию игрока (не путать с 4-м пу─
нктом, это  разные вещи. Игроку может быть 
абсолютно безразлично, что в мире игры ру─ 
шатся галактики. Ему может быть просто ин─ 
тересно "собрать воооон тот бонус" и полу─ 
чить новый уровень с новой фоновой картин─ 
кой). 
 6.Средства, с помощью которых герой до─
бивается  своей цели (подразумевается, что 
вообще может делать управляемый персонаж). 
 7.Особенности игрового процесса.
 8.Интерфейс.
 9.Стилистику уровней.
 10.Прочее.

   Чтобы этот этап не был слишком утомите─
льным, просто в течение некоторого времени
записывайте  все идеи новой игры в голову,
а потом  структурируйте их  и разложите по
полочкам.

                Разработка

   Далее  начинается  самый  интересный  и
сложный  этап - собственно сама разработка
игры.С чего здесь следует начинать,сказать
сложно. В серьёзных  студиях, где работает
много человек, весь план разработки соста─
вляется  ещё  на этапе создания диздока, а
далее  каждый  разработчик  просто следует
составленному для него плану: программисты
пишут движок, дизайнеры  выдумывают персо─
нажей, художники рисуют текстуры.
   Для независимых разработчиков, которые,
как  правило, делают  игры  в одиночку или
вдвоём / втроём, такой  подход неприемлем.
(Под независимыми разработчиками я понимаю 
нас  с вами, у кого  разработка  игр - это 
хобби,а не indie-разработчиков,для которых 
это способ заработка.У них подходы практи─ 
чески такие же, как и в полноценных конто─ 
рах.)  В больших фирмах каждый разработчик 
материально  заинтересован в издании игры.
У него есть оклад, в будущем "светит" пре─
мия  или  ещё что-то. Они просто выполняют
свою работу. Независимые разработчики обы─
чно делают игру бесплатно, в своё удоволь─
ствие. Если они начнут делать игру по пла─
ну, то  вся  разработка  быстро сведётся к
рутинной работе, и игра так и не будет за─
кончена.
   Вот примерный порядок разработки, кото─
рого обычно придерживаюсь я. Это примерный
план для игры с персонажем. Для логической
игры  многие  пункты будут неприменимы, но
общий ход мысли всё равно будет понятен:

 1. Первым  делом нужно сделать заготовку
главного  героя. Его не обязательно прори─
совывать полностью. Для первого этапа даже
не нужно  делать  анимацию. Одного спрайта
достаточно.
 2. Следующей делается заготовка графиче─
ского  движка. Сначала можно просто заста─
вить двигаться спрайт персонажа по пустому
экрану. Для этого я делаю заготовку класса
или структуры игрового персонажа.На первое
время  хватит всего пары полей для коорди─
нат.
 3. Постепенно усложняю,добавляю повороты
в разные  стороны и, по возможности, делаю
наброски анимации.Каркас движка готов.Всё,
что будет делаться дальше, будет уже доба─
вляться к основному каркасу.
 4. После того,как герой весело и задорно
бегает  по экрану, я начинаю делать основу
карты уровня.
 5. Создаю  структуру  или класс, который
будет содержать, для начала,базовую инфор─
мацию об уровне или экране (стены,лестницы
и т.д.).
 6. В памяти выделяю буфер, в котором бу─
дет храниться карта и (пока вручную) наби─
ваю его данными.
 7. Заставляю персонажа как-то взаимодей─
ствовать с картой. Для этого этапа понадо─
бится  какая-нибудь  графика тайлов. Можно
обойтись самыми примитивными муляжами (си─
ний квадратик, зелёный кружок и т.д.).
 8. После того, как у нас есть уже "почти
игра", можно побегать, попрыгать и сделать
что-нибудь  ещё, самое  время задуматься о
музыке  и озвучке. Я обычно прошу кого-ни─
будь  написать мне пару треков, а пока они
не готовы, вставляю что угодно. Звуки нес─
ложно сделать и самому. Но даже если у вас
пока  нет звуков, обозначьте хотя бы места
в коде, где  эти звуки будут играть, чтобы
потом не рыться во всё разрастающемся лис─
тинге программы в поисках нужного события.
 9. Следующим  этапом добавляются различ─
ные препятствия (шипы,монстры и т.д.), со─
бираемые предметы,рисуется графика для них
и делается  обработка  взаимодействия их с
игроком. Соответственно расширяются классы
игрока  и карты, добавляются классы монст─
ров, объекты которых могут храниться как в
карте, так и отдельным буфером.
 10. Сейчас  у нас есть практически гото─
вая  игра. Можно что-то собирать, можно от
кого-то  убегать  или нападать. Можно уме─
реть, нельзя  только  выиграть, т.к. карта
всего одна.На этом этапе нужно делать под─
грузку карт: или с диска, или из отдельной
области памяти. Возможно, для экономии па─
мяти  карты придётся хранить в сжатом виде
- значит,нужно будет написать процедуру их
распаковки. И желательно  сделать редактор
уровней  в наиболее  удобной среде. Делать
уровни в "Блокноте" не очень удобно.
 11. Игра практически готова. Заканчиваем
написание  логики, делаем  "жизни"  игрока
(если не сделали их ранее),делаем переходы
с карты  на карту, как-то обозначаем конец
игры (по номеру карты  или какому-то собы─
тию).
 12. В самом конце рисуется главное меню,
заставка, пишутся  тексты  поздравления  и
Game Over'a. Графика окончательно заменяе─
тся на финальную. Проводится окончательная
подгонка перед этапом тестирования.
 13. Тестирование - очень важный этап ра─
зработки. Постарайтесь  вовлечь в него как
можно  большее  количество  людей, да так,
чтобы люди  были "разные", с разным стилем
игры. Эти  люди  как  можно более подробно
должны описать, что им понравилось, что не
понравилось. Где  было слишком сложно, где
слишком легко. Где они нашли ошибки и т.д.
 14. После  этого, возможно, вам придётся
вернуться  к какому-то из этапов разработ─
ки. А возможно, и не раз.
 15. И только после того, как все тестеры
"замучены", не  могут  больше тестировать,
все  до  единого  твердят, что ваша игра -
идеал, и вам самим нечего больше к ней до─
бавить, только  тогда  можно  переходить к
следующему этапу - публикации игры.

   Обобщу написанное выше. Самым оптималь─
ным  и простым  способом  разработки  игры
малыми силами является итеративный подход.
Сначала  мы разрабатываем простейшее ядро,
которое выполняет минимум функций,тестиру─
ем  и добиваемся  нормальной работы. После
добавляем к нему какую-либо функцию и сно─
ва тестируем и отлаживаем.И так повторяет─
ся много раз,пока игра не будет закончена.
Плюсы этого подхода: простота отладки (за─
частую  в отладке нуждается только послед─
няя итерация) и наглядность (легко увидеть
и исправить  все недочёты  дизайна будущей
игры).
   Ещё  более оптимальным было бы отделить
игровой  движок  от собственно самой игры.
Что я имею в виду? Часто в играх под мало─
мощные  системы  игровая  логика и игровой
движок переплетаются настолько, что их не─
возможно разъединить.Это может делаться по
нескольким  причинам: оптимизация  (меньше
промежуточных  действий) и скорость разра─
ботки. Но  такой  подход влечет за собой и
недостатки: его  очень  тяжело  отлаживать
и  модифицировать, а в дальнейшем  игровой
движок будет невозможно (или очень сложно)
использовать повторно для другого проекта.
Лучше всего (при наличии ресурсов) сначала
разработать  более-менее универсальный иг─
ровой движок, написать под него инструмен─
тарий, а после через небольшие модификации
использовать его для своей игры. Таким об─
разом  можно  убить сразу двух зайцев: код
будет легко отлаживать, и движок можно бу─
дет  использовать  повторно  с наименьшими
трудозатратами.

    Релиз и пострелизное сопровождение

   Перед публикацией игры нужно будет сде─
лать  её описание: краткое, без "воды", но
такое, чтобы освещало все её положительные
и уникальные  стороны. Сделайте  несколько
скриншотов  самых красивых мест. Очень ре─
комендую сделать руководство пользователя.
Даже  если весь игровой процесс сводится к
ритмичному  нажатию  одной  кнопки (как во
многих мобильных играх),обязательно найдё─
тся  пользователь, который не разберётся в
управлении,который решит,что нужно прыгать
на шипы, а не уворачиваться от них, и обя─
зательно  начнёт трубить об этом на каждом
углу. Опишите  в руководстве всё как можно
подробнее. Напишите  несколько  выигрышных
тактик и стратегий.Можно даже описать про─
хождение первого уровня по шагам. Потруди─
тесь, ведь если вдруг найдётся такой вред─
ный пользователь,то его можно будет ткнуть
носом в руководство.
   Ну  а дальше  выкладывайте  свою игру в
сеть,пишите на тематические форумы и ново─
стные порталы, создайте страничку в социа─
льной сети, всё что угодно,что поможет лю─
дям узнать о вашей игре. И готовьтесь пер─
вую  неделю или пару недель оперативно от─
вечать на все пожелания,предложения и кри─
тику. Возможно, даже  придётся вернуться к
разработке  игры и сделать пару патчей или
выпустить обновлённую версию.
   Далее  я хочу  дать несколько советов о
том, как довести разработку  своей игры до
финала  и показать-таки её людям, и о том,
как сделать её наиболее интересной.

              О разработке:

 * Главным "топливом" свободного разрабо─
тчика  является  энтузиазм  (вдохновение),
который очень быстро улетучивается,как то─
лько  процесс создания становится скучным.
Самое  главное  при разработке игры - под─
держивать свой интерес.
 * Если  чувствуете, что  устали рисовать
графику или писать сложную процедуру, бро─
сьте. Доделаете потом.Не нужно себя заста─
влять, ничего хорошего из этого не выйдет.
Займитесь  чем-то  другим, всегда найдётся
что-то ещё,что нужно сделать или улучшить.
 * Если чувствуете, что не справляетесь с
чем-то, попросите помощи.
 * Карты  намного легче рисовать паралле─
льно  ещё с кем-то, при этом делиться опы─
том.
 * Лучше всего  на протяжении всей разра─
ботки игры советоваться с кем-нибудь.Пусть
это  будет  кто-то из домашних, и пусть он
ничего не смыслит в играх,это не проблема.
Стороннему человеку лучше заметны огрехи в
вашей игре.А пока вы будете объяснять ему,
что у вас не получается, скорее всего,сами
придёте к правильному решению.
 * Сложные  задачи  лучше всего разбивать
на много более лёгких,последовательное ре─
шение  которых  приведёт к решению большой
задачи. Так, например, задачу написания ИИ
врагов можно разбить на:
   -простое перемещение;
   -перемещение от точки до точки;
   -поиск пути;
   -движение по найденному пути;
   -реакция на действия игрока;
   -...
 * Каждую из подзадач,если она также ока─
залась  сложной, можно в свою очередь раз─
бить ещё на ряд более мелких.
 * Если чувствуете, что устаёте от разра─
ботки,не стоит её забрасывать. Потом очень
сложно  заставить  себя продолжить. Просто
замедлите темп.Делайте в день по чуть-чуть
(по  одному спрайту, по кусочку карты  или
куску кода), но делайте.
 * Не стесняйтесь  подсматривать какие-то
дизайнерские решения или хитрые куски кода
у более опытных разработчиков. Я не имею в
виду  наглое  воровство целых кусков уров─
ней, процедур  кода  или текстур. Но зачем
каждому разработчику изобретать велосипед,
когда можно учиться у старших. Можете даже
специально поиграть в несколько знаменитых
игр подобного жанра, чтобы посмотреть, как
интересующая вас вещь сделана в них.
 * Не старайтесь прыгнуть выше головы.Ог─
ромное количество многообещающих игр так и
не было  доделано из-за чрезмерных амбиций
их  разработчиков,  которые  запланировали
сделать  слишком  много, но не "потянули".
Лучше сделать меньше,чем хочется,но закон─
чить  разработку, чем запланировать много,
но остановиться на полпути из-за сложности
или большого объёма работ.
 *  Как бы  банально  ни звучало, делайте
бэкапы. Лучше всего  делать  бэкапы  раз в
день, после какого-то крупного этапа и пе─
ред  внесением  каких-то серьёзных измене─
ний. Ещё  лучше, если вы будете хранить не
только  последний бэкап, а несколько копий
за  несколько  последних дней. Это неодно─
кратно  меня спасало в ситуациях, когда я,
приняв неправильное решение,сильно изменил
код, но  не  добился желаемого результата.
После чего просто "откатывался" на послед─
ний этап и продолжал работу.

                О дизайне:

 * Не перегружайте игру ненужными элемен─
тами геймплея. Когда хотите что-либо доба─
вить к игре спросите себя: "А действитель─
но ли  это там  нужно? Будет ли игра лучше
от этого?". Не нужно добавлять в игру что-
нибудь просто для галочки.
 * Развлекайте  игрока. Скука - его злей─
ший враг.Вспомните,что было с Crysis. Кра─
сивейшая на тот момент игра была абсолютно
неиграбельна  из-за жуткой  скукотищи. Все
её  использовали  просто  для тестирования
производительности компьютера.
 * Думайте в первую очередь об интересно─
сти своей игры. Если какая-то ваша задумка
делает игру менее интересной,от этой заду─
мки стоит избавиться.
 * Делайте геймлпей максимально сбаланси─
рованным, без перекосов к какому-то одному
его  аспекту. Допустим, вы делаете аркаду-
прыгалку  типа "марио" и решили  разбавить
игрвой процесс загадками.Сама по себе идея
хороша, но "включить 3 рычага в правильной
последовательности" - это  одно, а "заста─ 
вить игрока решить логарифмическое уравне─ 
ние, а потом  бинарным  кодом шестнадцатью 
рычагами  ввести  правильный  результат" - 
это совсем другое. Я, конечно, утрирую, но
смысл ясен. Бодрый геймплей аркады  неожи─
данно  и надолго прерывается сложной голо─
воломкой. Это сбивает игрока с толку и ру─
шит всю динамику. Скорее всего, игрок даже
не  будет  решать загадку, а полезет в ин─
тернет за подсказкой или попросту взломает
игру.
 * Не заталкивайте  все возможные ресурсы
в один  уровень. Если у вас есть 10 разных
монстров,растяните их появление на всю иг─
ру. Так игрока будет каждый раз ждать что-
нибудь новенькое.
 * Удивляйте  игрока. Старайтесь  сделать
так, чтобы  каждый новый уровень привносил
в игру что-то новое.
 * Старайтесь  для  каждой игровой задачи
делать несколько возможных решений различ─
ной  сложности  и очевидности, с различным
вознаграждением  в  конце. Приведу  пример
вариативности  решений  на  идеальной (как
мне  кажется) в  этом  плане игре Deus Ex.
Задача:нужно добраться из пункта А в пункт
Б. Путь  игрока  пролегает через комнату с
большим количеством противников. Что может
сделать игрок?
   -Может аки Рэмбо всех перестрелять;
   -Может пролезть через вентиляцию;
   -Может прокрасться в тени;
   -Может  взломать  охранного робота, и
тот решит проблему с врагами; 
   -И наконец,может взломать систему ох─
раны и перепрограммировать турели, которые 
разделаются и с роботом и с врагами. 
   Вариативность повышает интересность иг─
рового процесса  и позволяет игроку глубже
погрузиться в мир игры.
 * Делайте секреты и ловушки (ловушки,ко─
нечно, нужно  обозначить. Не  ставить знак
"тут ловушка", конечно, но пятна крови или
кости  рядом подскажут внимательному игро─
ку,что здесь опасно,а невнимательный,попа─
вшись, сразу поймет,как он опростоволосил─
ся).Всегда награждайте внимательного и лю─
бопытного игрока. Здесь ситуация та же,что
и с вариативностью. Наличие всяческих сек─
ретов повышает интерес от игры.
 * Даже  если  у  вас  линейный уровень с
единственным верным вариантом прохождения,
делайте его так, чтобы игроку казалось,что
он сам принял это решение. Делайте ответв─
ления,тупики,дополнительные проходы и т.д.
Длинный "кишкообразный" уровень без возмо─
жности  даже  сделать  шаг в сторону - это
худший выбор,который только можно сделать.
 * Не забывайте о звуке и музыке.Даже ес─
ли у вас  невероятно красивая графика, без
звукового  оформления  она  не даст нужной
атмосферы. Вспомните: даже  во время немых
фильмов в зале  сидел специальный человек,
который  на пианино играл подходящую музы─
ку.
 * Делайте  игру  в том  жанре, в котором
разбираетесь лучше всего.
 * Придумайте  для  своей  игры  какую-то
"изюминку".Что-то,что будет отличать её от
подобных, даже  если это банальный тетрис.
На этой основе выходило  немало уникальных
игр.Как вам например тетрис,где все фигуры
- "мягкие", после  приземления они гнутся,
пружинят, ведут  себя как подушки и не за─
мирают на месте? Был такой. Сотни однотип─
ных  клонов - что  может быть скучнее? На─
пример, сейчас на испанском движке Churera
выходят  десятки  одинаковых игр. Меняется
только графика,но не игровой процесс. Ста─
новится  просто  обидно  за разработчиков:
потрачено  столько времени и сил, а играть
в это абсолютно не хочется, потому что но─
вого  в игре нет ничего и всё уже изучено.
Я не хочу сказать, что движок Churera плох
или что-то в этом роде. Сам движок - заме─
чательный, простой в освоении и достаточно
быстрый  для написанного наС. Я хочу ска─
зать,что многие люди абсолютно не умеют им
распорядиться. И вместо  создания уникаль─
ной  игры  на  готовом  движке (хотя такие
есть) просто копируют одно и то же.
 * Стилистику графического оформления иг─
ры обязательно нужно проверять в сборке. У
вас могут быть прекрасно нарисованные тай─
лы  карты  и шедевральные спрайты персона─
жей,которые могут занимать первые места на
конкурсах пиксель-арта,но вместе они будут
выглядеть  мазнёй и вызывать приступы эпи─
лепсии.Чтобы после тяжелой месячной работы
по рисовке графики такого не произошло,ну─
жно  заранее определиться со стилем, нари─
совать пару тайлов и пару спрайтов, да по─
смотреть, как  они будут вместе выглядеть.
После чего сделать поправки и со спокойной
душой продолжить работу, периодически про─
веряя общую картину, конечно.
 * Совершенно  не помешает подумать о ре─
играбельности вашего проекта.Вот несколько
факторов, которые могут повысить реиграбе─
льность:
   - Различные  уровни сложности.Естест─
венно, просто  возросшая  сила врагов мало 
что изменит,нужно подходить более кардина─ 
льно, к примеру,закрывать часть уровней на 
низких уровнях сложности или делать проти─ 
вников умнее на высоких,или бросать игроку 
вызов, вознося  планку  сложности до очень 
высокого уровня. К примеру,уровень сложно─ 
стиNightmareв Doom/Doom2, на котором все 
противники воскресают. Чем не лишний повод 
пройти  знакомую игру, чтобы испытать свои 
навыки. 
   - Таблица рекордов.Несколько устарев─
ший способ поднять реиграбильность, но всё 
ещё  рабочий. Сейчас его можно применять в 
немного  изменённом  виде. Например, можно 
таблицу  рекордов  хранить не на платформе 
игрока,а в интернете. Так сразу появляется 
некая соревновательная нотка. 
   - Секреты.Про них я уже писал,но пов─
торюсь.Хорошо сделанные,интересные секреты 
(потайные места, скрытое оружие, мини игры 
и т.д.) заставят игрока надолго засесть за 
игрой. 
   - Вариативность  геймплея.Про  это  я
тоже писал.Просто добавлю ещё один пример: 
аркадная  гонка Outrun. Сама игра не очень 
сложная и при прямых руках проходится за 5 
минут, но переигрывать её можно очень мно─ 
го раз из-за возможности менять свой марш─ 
рут прямо по ходу игры. Как это  выглядит: 
весь игровой мир состоит из отрезков трас─ 
сы, в конце каждого из которых есть разви─ 
лка.Игрок стартует всегда в одном и том же 
месте, а финишировать  может  на одном  из 
пяти этапов,и посетить все возможные места 
за  одну  игру  просто физически не может. 
Любознательность будет подталкивать игрока 
проходить  игру раз за разом, строя каждый 
раз новый маршрут. 
   - Случайная  генерация  контента. Эта
тема стоит отдельной  статьи. Приведу лишь 
несколько  популярных игр со случайной ге─ 
нерацией мира,в которые можно играть очень 
долго: Diablo, Rogue (и подобные), Binding 
of Isaac, Minecraft. В общем, вы поняли. 
   - Различные "плюшки", которые открыва─
ются после прохождения игры. Японцы,напри─ 
мер, очень  любят открывать дополнительные 
костюмы персонажам игры,давать новые игро─ 
вые режимы и т.д.В том же Binding of Isaac 
при каждом новом прохождении игра станови─ 
тся  больше, в  ней появляются новые пред─ 
меты, монстры, стили окружения  и т.д. А в 
популярной  серии  игр LEGO от Traveller's 
Tales вообще главная цель игрока не пройти 
игру, а открыть  все  секреты, персонажей, 
предметы и т.д. В результате игровое время 
увеличивается раз в десять. 

   (про Evo SDK см. в следующей статье)