Как я в одиночку сделал игру и выводы

в 10:26, , рубрики: c++, gamedesign, Gamedev, gamedevelopment, Lua, выводы, опыт разработки игры, разработка игр, метки:

История разработки одной фанатской компьютерной игры Fallout: The X-Project и попытки сделать из неё «конфетку»

Предупрежу сразу, вы не увидите в этой статье каких-то актуальных и современных знаний, да и в целом, я не стану в ней уделять много внимания техническим аспектам.

Объясню почему: сама по себе игра разрабатывалась в период с 1998 по 2008 год, а наиболее активно — где-то с 2004 по 2007. Если честно, то я и в 2005-м понимал, что будущего у игры нет. Но хотел просто её закончить. Иначе зачем столько времени и усилий потратил на проект? К тому же, я был не один, и нельзя допускать, чтобы чужие усилия были потрачены впустую. Ответственность.

Но не будем отходить в сторону. Кому будет полезна статья? В первую очередь таким же ребятам, каким я был сам, учась в институте. Мечтателям, желающим создать свою игру мечты.

Начнём благословясь

Хотя нет, эта игра не была той самой «мечтой», конечно же. Но на момент решения о её разработке, я думал, что смогу быстро закончить проект (ага-ага!) и привлечь внимание таких же, как и я. «Надежды юноши питают...»

Конечно, я играл в Fallout. Тот самый, от Black Isle и Interplay, оставшихся теперь лишь в анналах истории. Двумерный, изометрический. С отвратным русским переводом. Но это был взрыв. Крышеснос.

Потому при выборе проекта, я решил использовать именно данную тему. Второй Fallout уже вышел, а про 3-й пока никто даже не заикался (на момент задумки). Игрушка предполагалась фанатской, рассчитанной только на русскоязычных игроков, и не предполагала извлечение прибыли. Только опыта. Коим я здесь и делюсь.

Кстати, позже вышла еще Fallout Tactics, из которой было позаимствовано не мало графики для игры. И звуков. Впрочем, тягалось всё и из обоих оригинальных фоллаутов.

Почему текстовый квест? Опять же, потому что графики требуется по минимуму. Художников не было, никаких бирж фриланса еще не существовало (а то, подозреваю, я бы еще и вложился), и только один 3D-моделлер был найден на gamedev.ru каким-то чудом. Он сделал коротенький intro при начале новой игры. За что ему отдельное спасибо!

И так, некоторый бэкграунд создания игры я обозначил. Поехали дальше!

Выбор языка и платформы

На момент начала изучения мной GameDev'а, стандартом в нём был C++. А для C++ IDE — MS Visual Studio. Его я и стал изучать и использовать. Для работы с графикой и медиа — MS DirectX, и его части DirectDraw и DirectSound. С 3D у меня с самого начала не задалось, да и в данном проекте он был совсем не к месту.

Но и сам по себе DirectX не столь удобная штука, потому я нашел библиотечку NukeDX, которая позволяла работать с DX гораздо удобнее (читайте, это как libGDX сейчас для Java). Правда, NukeDX уже на момент начала работы с ним приказал долго жить. Но всё, что я хотел — в нём уже было и работало.

То, что игра будет для настольного ПК на Windows – на тот момент не вызывало никаких сомнений. Ноутбуки стоили гораздо дороже ПК, а о планшетах можно было только почитать в заумных обзорах. Android и смартфоны были только в зародыше, в секретных подвалах лабораторий. А Linux воспринимался исключительно как консольное серверное решение.

Хотя не скрою, году так в 2010-м появилась мыслишка «а не запихнуть ли под Windows Pocket всё это дело»? С названием операционки могу наврать, но суть понятна, думаю.

Идея как появилась, так и пропала — пришлось бы переписывать весь код и переделывать графику.

И о скриптах замолвим слово

Поскольку я делал текстовую Role-Playing Game, которая изначально подразумевает нелинейность прохождения (о, это была модная штука тогда!), то надо было как-то заложить возможность манипуляции игровыми данными без перекомпиляции проекта каждый раз. Да и в целом, было крайне интересно попробовать самому прикрутить скриптовый движок к игре.

Скриптовый движок должен был решать следующие задачи:

  • взаимодействие с переменными игры (получение / модификация) и функциями;
  • не требовать предварительной компиляции кода;
  • не нагружать игру.

Из всех удовлетворяющих данным требованиям выбор пал на Lua. Почему конкретно он — сейчас уже не вспомню. Язык точно использовался уже в крупных проектах. Да и сейчас используется (насколько я в курсе, в том же WoW, например).

Библиотека свободно распространяемая, примеры были. И я Lua прикрутил.

Набираем воздуха в лёгкие и задерживаем дыхание перед прыжком

Всё замечательно, с платформой и инструментарием я определился. Теперь надо подумать, как идею превратить в нечто осязаемое.

Поскольку на тот момент я уже делал какие-то простенькие программки с помощью Microsoft Foundation Classes, то с их же помощью решил написать и сценарный редактор для игры.

Рассудив, что игра состоит из последовательности сцен (в нашем случае описываемых текстом), а переход на следующую сцену зависит от выбора варианта ответа, то я создал следующую структуру сценария:

редактор сценария игры

Как видно на скриншоте, в сцене присутствует, помимо текста описания и вариантов выбора, еще и много других данных. Например, текущая дата (по игровому времени). И смотря на это сейчас, я уже вижу, что следует исправить.

Помимо времени, мы еще отображаем картинку сцены. В редакторе она задаётся номером. А в игре отображается в левом верхнем углу. И спрайт, как вы уже догадались, соответствует данному номеру.

Так же есть название сцены (Location). Воспроизводимый для сцены музыкальный файл. И варианты действий со ссылками на соответствующую сцену.

И вот здесь немного поговорим об интерактивности. Думаю, внимательные читатели заметили поле Event, в котором что-то вписано. Всё верно, это скрипт, выполняемый при переходе на данный экран. На первом экране это всего лишь добавление в журнал игрока новых задач:

AddQuest(1, "Вспомнить собственное имя, или, хотя бы кличку");
AddQuest(1, "Найти доктора");

С точки зрения программы мы вызываем в Lua доступные ей функции приложения с теми параметрами, которые нам нужны.

А теперь еще два момента:

1) У каждого варианта ответа есть поле Condition. Через тот же Lua мы можем проверить какие-то игровые переменные, и на основе этой проверки либо выводить вариант ответа, либо его скрыть.
2) Каждый вариант ответа может иметь свой выполняемый скрипт. То есть, если мы выбираем какой-то вариант, то он может повлечь за собой определённое действие. Например, вызов экрана боя. Или проигрывание звука. Или переход на какой-то конкретный экран, если выполняется условие. И т.п.

Вот такими нехитрыми способами я решал вопрос интерактивности и взаимодействия пользователя с миром игры.

А хранится всё в файле scenario.dat, в структуре данных. Сохраняется на диск с помощью механизма сериализации того же MFC. Ну и прикола ради, во время сохранения кодируется.

Ныряем

Хорошо, не очень удобный, но хоть как-то работающий редактор сценариев я сделал. Теперь пора запустить игру.

И вот тут… Да как бы не так! Тут было много муторной работы в Photoshop с выцепленной графикой. Но с точки зрения программирования ничего особо сложного не было. На первый взгляд.

Не буду погружаться в излишние детали, но первая серьёзная задача, которая передо мной возникла — это искусственный интеллект. Если для логических задачек всё можно было вынести в скрипты, то вот с боёвкой я решил закопать всё жестко в коде. И это был интересный, но времязатратный момент разработки игры.

экран боя

Конечно, великий рандом здесь рулит. Но надо было сделать хоть какое-то подобие осмысленности борьбы со стороны компьютера. А вот сама по себе модель боя была позаимствована от некогда крайне популярного «Бойцовского клуба», или просто БК. И адаптирована под Fallout. Выбираешь, куда бить, наносишь удар и получаешь аналогичный ответ.

Но это ладно. А для прохождения некоторых заданий (квестов) требуется инвентарь. И вот здесь я реально встрял на месяцок — другой.

Как я в одиночку сделал игру и выводы - 3

Нет, сам по себе инвентарь — штука не сложная. Даже наоборот. Встрял я на написании drug&drop для него. Правда, сейчас я помню только, что он вызвал много неприличных слов!

Как я в одиночку сделал игру и выводы - 4

Когда поборол проблему с перетаскиванием предметов, то оставались лишь мелкие детали, вроде просмотра голодисков (holodisk), отображения журнала заданий и т.п. мелочи.

Как я в одиночку сделал игру и выводы - 5

Надо проверять дно, чтобы не встретиться с камнем

Но… был уже 2008 год. Вышел и прошел с аншлагом Fallout 3 – эдакий The Elder Scrolls в мире Пустоши. Поколение геймеров давно сменилось, и те, на кого был рассчитан текстовый квест Fallout: The X-Project уже либо перестали играть совсем, либо потеряли всякий интерес к подобного рода играм.

Но я ничуть не жалею о полученном опыте, ведь я доказал себе, да и всем остальным, следующие вещи:

  1. Можно написать программу не обладая изначально никакими знаниями в области программирования, и не обучаясь по данной специальности где-либо.
  2. Даже в одиночку можно создать компьютерную игру, за которую не будет стыдно (привет GameMaker'у и иже с ним).
  3. Разрабатывая игры, получаешь массу удовольствия!

А еще на собственном опыте выяснил, что:

  1. У проекта обязан быть deadline!
  2. Перед тем, как что-то начинать делать, надо очень внимательно изучить, понадобится ли это кому-то, кроме тебя самого. Банальность, но это грабли, на которые все продолжают и продолжают наступать.
  3. Система контроля версий — это просто супер-вещь!
  4. ООП — это еще круче, чем система контроля версий.
  5. Читать большие тексты мало кто любит.
  6. Но уж если предстоит читать тексты, то надо делать чтение УДОБНЫМ! В моём случае стиль победил удобство, что оказалось большой ошибкой.
  7. Необходимо продумывать каналы распространения еще ДО начала работы над проектом.
  8. Найти соратников, которые будут не только трепаться языком, но и что-то делать вполне реально. Но не просто.
  9. Совмещать несколько позиций команды в одном человеке — не продуктивно. Постоянное переключение между задачами негативно сказывается на скорости работы.
  10. Создавать игру в рамках готового сеттинга (вселенной) проще, чем делать с 0.
  11. На этапе проектирования уже стоит убирать лишнее. Всё равно не войдёт в финальный релиз, но время съест. Так, например, в игре отсутствует перемещение между городами (карта мира), хотя изначально она предполагалась.
  12. Компьютерная игра — это сплав различных ингредиентов. Поэтому тут либо нужны все специалисты, либо ты должен уметь всё это делать сам.
  13. Рано или поздно упорство вознаграждается. Но чтобы это не было поздно, см. п.1

А еще этот волшебный момент, когда твоя игра компилируется без ошибок, запускается, и в ней всё именно так, как ты и задумывал. Это волшебство, ради которого стоит тратить свои усилия!

Хозяйке на заметку

Приводить список литературы не стану, т. к. он уже давно не актуален.

→ А вот поковырять исходные коды, при желании, можно на Гитхабе
Сама игра, если любопытно

Автор: Jaguarhl

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js