Даниил Басманов

Были такие вопросы совсем недавно:
Как создавать игру квест(текстовый)?
Какой игровой движок лучше использовать для текстового квеста на андроид?

Вкратце: делаете редактор графа, делаете механику перемещения по графу, цепляете в узлы графа данные для отображения. Конкретно в LifeLine продвижение по графу связано со временем, но это просто ещё одна механика.

Для сферической игры в вакууме, я бы начал делать сохранения после того, как сделал меню, чтобы как можно раньше реализовать полный цикл приложения. Никто мешает вам в отдельных тестовых сценах/проектах продолжать работу над геймплеем, и никто не заставляет вас сразу сохранять все механики. Но, по крайней мере, вы сразу задумаетесь о том, какие переменные может понадобиться сохранять, а это заставит вас соответствующим образом поменять архитектуру, что сделает ваше приложение более гибким. А "кучу идей" в любом случае не стоит пихать в основное приложение, эксперименты с механиками не должны ломать стабильное состояние игры. Интегрировать механики с сохранками имеет смысл только после их утверждения.

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

Порталы на рендер текстурах делаются проще, но они дороже по производительности, даже на простой геометрии несколько порталов могут оказаться непосильной задачей для компьютера. Основной принцип следующий: когда вы смотрите на портал, на другой стороне портала камера рисует картинку в текстуру, эта текстура натягивается на плоскую геометрию, и со стороны кажется, будто бы через дырку видно другую часть сцены. Примитивную реализацию такой схемы можно собрать руками в редакторе, но дальше начинаются сложности. Если у конечного портала "за спиной" будет геометрия, она попадёт во вьюпорт камеры и будет странно смотреться. Чтобы это предотвратить нужно ближнюю плоскость отсечения у камеры сдвигать в плоскость портала с помощью CalculateObliqueMatrix. Для вычисления положения камеры и пересчёта матрицы есть удобный колбэк OnRenderObject. После корректировки матрицы порталы будут смотреться более-менее корректно, но будут всплывать всевозможные косяки при перемещении через плоскость портала из-за буфера глубины и nearClipPlane основной камеры.

Стенсильные порталы будут работать сильно быстрее, но для их реализации нужно хорошо шарить в шейдерах. Расписывать их работу подробно не буду, в целом они делаются точно так же, только трюки с рендер текстурами заменяются на трюки с буферами, предлагаю лучше почитать пару полезных статей на тему: раз и два. В контексте юнити всё немного сложнее, чем на чистом OpenGL, потому что нет прямого доступа ко всем буферам и для получения похожего результата придётся немного поизвращаться. Потенциально облегчить задачу может низкоуровневое API, но у меня не получилось добиться хороших результатов без потери качества картинки. Я возлагаю большие надежды на ScriptableRenderLoop, если судить по документации, это как раз то, что нужно.

Прошу заметить, что всё вышесказанное касается чисто графической части, для простейшего случая, когда мы имеем FPS камеру без анимаций, без дополнительных механик, которая просто ездит по уровню и может заглядывать в порталы. Что уж говорить про миллион потенциальных багов, если вы захотите включить рядом с порталом систему частиц или взять в руки кубик. Посему советую либо купить плагин и довольствоваться тем, что он умеет, либо приготовиться потратить несколько месяцев на разработку своей портальной системы. И в том и другом случае ограничения движка не позволят вам в разумные сроки получить Portal, в лучшем случае это будет Narbacular Drop.

Были такие вопросы и не раз:
GameDev — куда «шагнуть», и как туда попасть для обучения?
С чего начать путь в Game Dev?
Что нужно, чтобы стать разработчиком игр?

Берёте движок (Unreal или Unity по вкусу), читаете мануал, разбираете официальные туториалы, а потом берёте документацию к языку и движку и делаете тетрис или змейку, любую примитивную классическую игру. Когда сделаете парочку простых игрушек, то уже будете лучше понимать свои возможности. С таким мини-портфолио можно пойти в студию разработчиком, либо, если есть куча денег и хочется приключений, можно попробовать делать игры в одиночку и пытаться на них зарабатывать.

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

Ответы на вопросы могут выставлять специальные флаги, которые проверяются позже по графу. "Убить злодея?" - "Да", выставили флаг, через несколько вершин графа проверили условие и попали в другую сюжетную ветку. Флаги можно комбинировать и получать дополнительные варианты концовок.

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

Короче говоря, я бы предложил вам начать с абстракции над switch-case, которую можно связывать друг с дружкой, а потом почитал бы блог Emily Short, она специалист в текстовых квестах и делала кучу всевозможных механик учёта решений игрока.

UPD: Ещё советую попробовать Twine, сейчас это самый популярный движок для текстовых игр.

Популярный способ - это построить карту высот, выбрать одну из точек в горах в качестве источника, а потом с помощью поиска пути спуститься по карте высот вниз одновременно рисуя путь реки.
www-cs-students.stanford.edu/~amitp/game-programmi...

А вот зря отказываетесь от изучения движков, на живом примере проще понять внутреннее устройство.

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

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

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

Напрямую из нормалей геометрию не получить, но это можно сделать из displacement map. Получить displacement map из карты нормалей можно например с помощью этой утилиты. Далее используете Displacement to Polygons в Maya, Displace Mesh в 3ds Max или аналогичную кнопку в своём любимом редакторе.

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