Игра за 14 дней [Для тех, кто годами собирает команду, но так и не сделал прототип]

    На просторах интернета часто встречаются «команды», которые существуют уже годами, список разработчиков состоит из десятка персон, да ещё и «нужны все!». При этом никакой адекватной демки нет даже в ближайших планах. Глядя на это всё так и хочется сказать: «Да что же вы, блин, делаете?!». Но это деструктив. Мало раскритиковать. Нужно и позитивные примеры предоставить.

    Эти размышления натолкнули меня на занятный эксперимент: в ноябре на gamedev.ru стартовал «конкурс леталок». Конкурс предполагал разработку в течении двух месяцев. Однако мне показалось, что это многовато. Поэтому я записался в участники… И забыл о конкурсе на полтора месяца.

    Основная идея эксперимента — сделать полноценный проект за две недели. Срок завершения конкурса — неплохой дедлайн. К тому же последняя неделя конкурса совпала с концом новогодних праздников, что дало возможность не отвлекаться на другие задачи. Итак: конкурс, проект с нуля, две недели.

    image

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

    У нас есть две недели. Основной вопрос в том, что делать. Честно говоря, я изначально думал, что конкурс идёт до 7 января и планировал потратить на него только одну неделю.

    Одна неделя — это не очень много, в связи с чем и был выбран жанр лаунчеров.

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

    Прекрасным представителем этого жанра является игра Butibo Bison.

    Повторить геймплей именно этой игры я и планировал. Однако когда решил уточнить детали конкурса, выяснилось, что финал не 7, а 12. 12 дней! С этим уже можно работать! Будем делать 3D Action!

    За основу возьмём несколько моих любимых игр: Вангеры, Механоиды, Ex Machine, Renegade Ops. Хочется сделать РПГ, но в такой короткий срок проработать прокачку не выйдет. Поэтому цель: за основу берём геймплей RenegadeOps/Вангеры, набор квестов — по аналогии с Ex Machine/Механоиды. Ну и чтобы не тратить время на продумывание вселенной, пусть игра будет во вселенной Механоидов. Тем более, что моё фактическое место жительство в 7 км от бывшего офиса SKYRIVER studios располагает к таким заимствованиям.

    День первый
    Что мы имеем? Фреймворк, на котором выпущено несколько 2Д игр. Из 3Д возможностей — только загрузка меша из файла. Ещё есть редактор ландшафтов. Используем его для создания игрового ландшафта. Задача на первый день:
    • Создать тестовый ландшафт и отобразить его в игре.

    Для этого нам понадобится 3Д камера. Она должна уметь устанавливать видовую матрицу и матрицу проекции. Класс камеры даже не пришлось писать, за годы разработки он у меня уже был сделан. Просто перетаскиваем камеру во фреймворк.

    Следующая подзадача — перенести шейдеры из редактора в игру. Шейдеры лежат в открытом виде, всё что нужно сделать — убрать из них обработку инструментов редактора: подсветку края тайлов, динамический расчёт нормалей и прочие мелочи.
    Основная подзадача, которая заняла большую часть дня — реализация класса, отвечающего за загрузку файла, содержащего ландшафт и передачу геометрии на рендер. Задача не слишком сложная, но пол дня заняла.

    Итог работы:



    И что же мы видим в результате? Ландшафт страшно шумит. Причина очень простая — при конвертации текстур я забыл прописать генерацию MipMap'ов. Но уже 11 часов вечера… Мелкая задача, но очень хочется спать.

    День второй
    На сегодня запланировано две задачи:
    • Карты теней.
    • Отрисовка моделей (без моделей толком не протестировать работу теней).

    Первым делом включаю MipMap'ы, которые не включил вчера и выясняется, что в коде что-то генерирует OpenGL ошибку. Проверок в коде не очень много и ошибка вылезает при загрузке шейдеров. Грешу на криво перенесённые шейдеры из редактора… Потратил час, чтобы понять, что ошибка не в шейдерах… Оказывается, неправильно указал настройку текстур и в MAG_FILTER уходило значение GL_LINEAR_MIPMAP_LINEAR, которого там быть не должно. Исправляю на GL_LINEAR и всё заводится без проблем. А между тем потрачено два часа… Это очень много, учитывая что есть всего 12 дней.

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

    Ландшафт уже разбит на примерно такие квадраты, поэтому создаём менеджер объектов, который разбивает игровое пространство на квадраты в соответствии с настройками ландшафта и при отрисовке обрабатывает только те объекты, которые находятся не далее одного квадрата от камеры. То есть рисуется зона 3х3 квадрата, где центральный квадрат — это квадрат, в котором находится камера. Плюс менеджер объектов должен отслеживать перемещение объектов и в случае, если объект выехал за пределы своего квадрата, перемещать его в актуальный квадрат. Задача по написанию такого менеджера заняла около 5 часов.

    Следующая задача — реализация карты теней. Но для карт теней нужна поддержка Render To Texture во фреймворке, которой у меня не было, поскольку ранее реализованные проекты не требовали пост эффектов, а RTT в 2Д, кроме как для пост-эффектов, нигде не используется.

    Ещё час тратим на реализацию обёртки над FBO. Ничего особо сложного.

    Приступаем к последней задаче второго дня — Shadow Maps. Всё бы ничего, но я приверженец Stencil Shadows… Всеми силами я всегда избегал прикасаться к Shadow Maps. Ну не нравились они мне. Но время идёт… в современных реалиях вообще нет ни одной причины использовать стенсильные тени. Слишком сильно падает их производительность с ростом сложности геометрии и разрешений экранов. Так что альтернативы нет — приходится взяться за реализацию карт теней. Конечно, я прекрасно знаком с теорией работы карт теней, хотя никогда их не реализовывал. Поэтому особых сложностей не жду. Взял давно отложенный на чёрный день мануал и по нему реализовал отрисовку теней.

    Кстати, использовал этот мануал. Всем рекомендую. Грамотно и по делу всё расписано, в том числе и основные проблемы, вылезающие при реализации карт теней.



    С мипмапами ландшафт стал выглядеть лучше, да и тени неплохо смотрятся.

    День третий
    Продолжаем прикручивать нужный нам функционал. На сегодня запланировано две задачи.
    • Интеграция скриптового языка Lua с помощью проекта LuaJIT. Как раз не так давно вышла обновленная версия JIT компилятора для этого языка и наш эксперимент — отличная возможность новый компилятор опробовать.
    • Интеграция системы частиц. Я планировал использовать Magic Particles от Astralax.


    Начнем с LuaJIT. Качаем исходники и легко собираем dll под Windows. Пишем небольшой класс-обертку (не люблю luabind и аналоги, предпочитаю работать с lua через минимум прослоек). И, собственно, всё.

    Попробовал собрать под Android… и в течение часа не смог этого сделать. Решил не тратить дальше на это время, потому что для конкурса это не критично, а в дальнейшем можно будет и отдельно заморочиться.

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

    Однако меня остановил один не важный для конкурса, но важный для фреймворка момент. Дело в том, что фреймворк создаётся, в частности, для проектов под Windows CE. И, к сожалению, это чуть ли не единственная из распространенных ОС, которая не поддерживается MP. Это и понятно, игровой рынок на WinCE отсутствует как класс. Но для меня это важно, поэтому MP я решил пока не использовать…

    От расстройства и прокрастинации пошёл играть в Burito Bison и потратил на это полтора часа времени.

    Однако день ещё далеко не закончен. Едва перевалило за обед. Решил сделать стартовое меню. Сделал несложный ландшафт, поместил на него пару зданий и два вертолётика. И вылез баг с картами теней. Его хорошо видно на КДПВ на угловой стене слева под кнопкой «Выход». Однако решил этот баг не править — вид в игре не такой и на нём эти баги практически не видны. А правка альясинга теней обещает убить несколько драгоценных часов.

    Сделал меню, интересно ездящее вверх/вниз. Получилось занятно. Добавил кнопки «Настройка» и «Продолжить», хотя прекрасно понимаю, что с большой вероятностью их функционал в рамках конкурса реализовать не смогу — не хватит времени.

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



    День четвертый
    План на сегодня:
    • Управление вертолётом игрока
    • Оружие: лазер, пулемёт, ракеты


    Только в 16 часов дня я занялся задачами непосредственно из плана. До этого решал всякие задачи, которые к плану отношения напрямую не имеют, но выполнение плана нельзя было начинать пока их не закончишь. Одна из таких задач — спаун юнита. Например, вертолёта игрока… Спаун требует работающих скриптов, работающие скрипты требуют загрузки уровня и прописывания соответствующих функций, через которые можно управлять юнитами…

    Дальше — больше. Сделал управление вертолётом и оказалось, что при нажатии на кнопку и движении мышью Qt начинает адски тормозить.

    Я, как любой разумный программист, грешил на себя… Переписал внутреннюю систему обработки сообщений. Сделал проверку на дублирование сообщений… И это не помогло.

    Ладно, я отказался от обычной системы сообщений и сделал считывание состояния клавиатуры и мышки… И это не помогло.

    Я полностью отключил систему ввода в своём движке… И всё равно получил фризы. Сделал хук WH_GETMESSAGE на все сообщения, касающиеся ввода, с перехватом и отменой всех сообщений… Это не помогло. Ничего не осталось, кроме как исследовать систему вне моей среды разработки.

    Разгадка оказалась простой… Я потратил три часа, исправляя баг, которого нет… Это Synergy тормозила, если зажимать несколько кнопок одновременно. Убрал Synergy и всё стало плавненько и аккуратненько.

    В итоге не успел сделать наклон вертолёта в сторону полета. Вроде бы мелочь, но ведь важная… Но всё же не настолько важная, чтобы тратить на неё время сейчас. Тем более, что уже 11 вечера 4 января… Прошло 4 дня, а я только вертолёт запустил полетать. Так что стрельба, стрельба и ещё раз стрельба.

    В два часа ночи я записал видео. Ракеты не успел. Но решил, что сейчас они не так важны, как сон.



    День пятый
    Задача на сегодня — сделать игровую локацию.
    У меня есть десять зданий, который были куплены на 3drt.com для другого проекта. Сначала я примерно расписал сюжет игры, далее составил список зданий и прикинул, какое здание какую роль может выполнять в игре. Что похоже на шахту, что похоже на главную базу и т.д.
    В редакторе ландшафтов примерно набросал игровую зону:



    На каждой точке сделал подпись, состоящую из названия и порядкового номера используемой модели.

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

    Следующий этап — придание неоднородности ландшафту и прокладывание дорог. Т.к. времени очень мало — выделил на всё три часа. Этого времени хватило только на то, чтобы создать минимально играбельный ландшафт. На какие-то художественные изыски времени не осталось.

    Следующая задача — расстановка объектов и задание зон проходимости. У меня нет подходящего 3Д редактора для фреймворка, т.к. фреймворк всегда был 2Д и все проекты на нем были 2Д. К счастью, у меня есть редактор, созданный гораздо раньше для 3Д проектов. Он достаточно сложный и имеет сложный формат сохранений. Да и писался он для совершенно другого движка, поэтому напрямую использовать его не получится. Однако, на сегодня это не важно. Создаем в этом редакторе локацию.
    В редакторе я расставил объекты и нарисовал зоны:
    • Дороги
    • Проходимые зоны бездорожья
    • Зоны для полетов
    • Безопасные зоны (расположены рядом со зданиями, в пределах таких зон нельзя стрелять).



    Моменты на видео, когда весь ландшафт раскрашен в красно-зелёное — это, собственно, редактирование зон.

    День шестой
    План:
    • Загрузка локации, созданной в редакторе
    • Функционирование всех зданий (функционирование турелей и определение «входа» в здания)


    У нас есть локация в редакторе, который не предназначен для работы с нашим игровым движком.
    Я решил не заморачиваться с загрузкой его сложного формата в игре и сделал простую вещь: добавил в редактор возможность сохранения сцены в виде текстового файла.
    Дальше локацию сохранил в текстовый файл. Получилось что-то вроде:

    Пример содержимого текстового файла с уровнем
    FILENAME
    TLevelStaticObject.Model.FileName
    \\buildings\bld10.sxm
    STRING
    TLevelBaseObject.Name
    CLIMAT_1
    FLOAT
    TLevelBaseObject.Position.x
    2248.16
    FLOAT
    TLevelBaseObject.Position.y
    2874.08
    FLOAT
    TLevelBaseObject.Position.z
    -0.355
    FLOAT
    TLevelBaseObject.Rotation.angle
    0
    FLOAT
    TLevelBaseObject.Quaternion.x
    0
    FLOAT
    TLevelBaseObject.Quaternion.y
    0
    FLOAT
    TLevelBaseObject.Quaternion.z
    -0.732
    FLOAT
    TLevelBaseObject.Quaternion.w
    -0.68
    BOOL
    TLevelBaseObject.ShadowCaster
    false

    Дальше пишем простенькую утилиту, которая из сложного текстового файла с кучей объектов и свойств выдирает только нужные непосредственно в игре и сохраняет в удобоваримом формате.

    Дальше нам нужно загрузить зоны и объекты. Объекты-декорации просто добавляются в менеджер объектов, написанный ранее, и игра о них забывает, а остальные объекты создаются в обычном порядке.

    В общем-то конверт и загрузка локации заняли достаточно маленькую часть дня. Больше всего времени ушло на реализацию функционала турелей. Работают они просто: если игрок выстрелил в безопасной зоне, то активируется таймер на 15 секунд, в течении которого все турели, в радиусе поражения которых находится игрок, открывают по нему огонь.



    День седьмой
    • Пришло время реализовать искусственный интеллект.

    У меня уже есть искусственный интеллект, который умеет выполнять разные функции.
    Делался он несколько лет назад, когда была идея реализовать конкурс ИИ. Собственно была реализована 2Д модель мира механоидов с их правилами. Торговцы получали очки за доставку товаров, охранники — за сопровождение торговцев, охотники — за привезённые головы, мародеры — за украденные (не купленные) и проданные товары.
    Как работал этот ИИ можно посмотреть тут:



    Круги — это живые юниты.
    Красные буквы — это мёртвые юниты.
    Чёрные кресты — это груз.
    Две команды — зелёные и красные. Активно пытаются изображать живой мир.

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

    Весь день был потрачен на то, чтобы сделать ИИ.

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

    Конфиг обычного юнита выглядит примерно так:

    Конфиг, описывающий юнит
    FILENAME
    VERSION
    1
    TYPE
    CAR
    NAME
    GUN_JEEP
    SCALE
    1.0
    BODY
    vehicles/jeep_1/body.sxm
    WHEELS_COUNT
    4
    MODEL
    vehicles/wheels/wheel3_left.sxm
    POSITION
    3.581
    -4.362
    2.024
    MODEL
    vehicles/wheels/wheel3_right.sxm
    POSITION
    -3.537
    -4.362
    2.024
    MODEL
    vehicles/wheels/wheel3_left.sxm
    POSITION
    3.581
    3.387
    2.024
    MODEL
    vehicles/wheels/wheel3_right.sxm
    POSITION
    -3.537
    3.387
    2.024
    SPEED
    50
    ROTATION_PER_METER
    1
    STORAGE_SIZE
    2
    HEALTH
    4000
    SHIELD
    4000
    SHIELD_REGENERATION
    50
    WEAPONS_COUNT
    1
    TYPE
    GUN_TURRET_1
    POSITION
    0.013
    3.251
    6.755

    За день игра научилась парсить это всё и загружать данные. Конфигов подобного рода, на самом деле, не один, а два. Второй — для описания турелей, которые ставятся на юнита. В данном случае ставится турель GUN_TURRET_1.
    Как можно понять — это 7 января, Рождество. И семейная традиция — собираться вместе со всеми родственниками в родительском доме… Поэтому так мало сделано — большую часть дня я провел в кругу семьи.

    День восьмой
    • Продолжаем пилить ИИ.

    Юниты научились ездить и атаковать. Также преследуют противника в зоне видимости. Основная часть работы была посвящена передвижению.

    Амортизаторы прикручивать не стал. Час ночи… Из-за отставания по срокам седьмого января — категорически выбился из плана. Так что объезд препятствий — в топку… В ту же топку и физическое взаимодействие между юнитами… И подвеску техники тоже туда же… Особенно печалит последнее. Без расчета подвески юниты жёстко повторяют ландшафт и выглядит это не айс. Но функционал свой выполняют, так что оставляем так.



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

    Сделан HUD. Сделан инвентарь, в который можно подбирать убитых юнитов и из которого их можно выкидывать при необходимости.



    День десятый
    Приближается финал.

    Есть понимание того, что нужно финализировать картинку. Как видно по результату предыдущего дня, бои смотрятся нормально… до тех пор, пока кто нибудь не умирает. Юниты просто исчезают, что смотрится нехорошо. Вариантов два. Либо сделать разваливание юнитов на отдельные части. Это задача достаточно сложная, причём не столько с точки зрения программирования, сколько с точки зрения рутинной работы по разрезанию юнитов на части и экспорту их в удобоваримый формат. Отдельный момент — очень не хочется тратить время на добавление анимаций в движок. Второй вариант — система частиц. Но Magic Particles не умеет WinCE. Интегрировать его для использования на остальных платформах? Но очень хочется избежать решений в кроссплатформенном фреймворке, которые не смогут работать везде…

    В итоге я остановился на следующем решении: использовать Magic Particles, но при этом полностью отказаться от его родного API.

    На практике это было реализовано следующим образом: был реализован конвертер, который проигрывал эффекты созданные в MP и каждый кадр сохранял состояние всех видимых частиц в файл. На выходе получался файл, описывающий состояние эффекта в каждый момент времени, но при этом не привязанный к Magic Particles API. Файл, который я могу проигрывать своими силами на любой платформе.

    Такой вариант даже близко не покрывает весь спектр возможностей MP, но со взрывами и другими простыми и не зацикленными эффектами вполне справляется. А это-то мне и нужно.



    Взрыв почему-то получился белёсым, но я решил не тратить время на разбирательства. Выглядит на троечку, но времени осталось совсем мало. По факту — полтора дня: одиннадцатое число и ночь на двенадцатое (конкурс заканчивается 12 числа в 9 утра).

    День одиннадцатый
    Всё оставшееся время решено потратить на квесты. Конечно, в игре и так уже есть какой-никакой геймплей. Но квесты придадут смысл и, может быть, задержат игрока чуть подольше.
    Расписывать тут особо нечего.
    Квесты полностью захардкожены в скриптах. Никаких инструментов для редактирования связей. Никаких инструментов для настройки скрипта без кодинга… Простой и незамысловатый код.
    Сделал окно диалогов для общения с NPC (у нас их роль исполняют здания). Принцип работы такого окна почти идентичен квестовому диалоговому окну в Космических рейнджерах. Думаю, вполне реально написать несложный конвертер, который сделает текстовые квесты из Космических рейнджеров пригодными для запуска в данной игре.
    Решил не делать мини-карту, т.к. тогда сразу становится очевидной ограниченность мира. А ведь хочется создать впечатление, что мир живой и большой. Но и просто так оставлять игрока блуждать нельзя. Конечно, найдутся игроки, которым это будет интересно. Но большая часть заблудится на первом перекрестке и пошлёт проект подальше.
    Поэтому было принято половинчатое решение — реализовать компас без карты. Компас указывает направление на выбранную цель, а на стартовой базе можно отдельно добавить себе метку на любое здание.

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



    Surprise!
    Доделал квесты. Игру возможно полностью пройти. Поздняя ночь одиннадцатого дня. Полез в тему конкурса, чтобы ещё раз уточнить сроки и определить план на ночь… И оказалось, что пару дней назад большинство участников проголосовало за продление конкурса ещё на две недели!

    image

    Это идёт вразрез с моими планами. Да и нарушает идею сделать проект за короткий срок.

    В итоге прихожу к следующему решению: ночь нормально отсыпаюсь, а в двенадцатый день делаю то, что планировал сделать в ночь. И добавляю ещё два дня (до полных двух недель), чтобы «причесать» проект.

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

    Добавил ещё несколько видов юнитов. Вернее не видов — юниты фактически остались те же. Но раньше все роли (охотник, мародер) у всех кланов выполняли юниты, выглядящие одинаково. А я сделал так, чтобы каждый юнит у каждого клана выглядел уникально.

    Чуть-чуть подправил работу ИИ: раньше охотники почти никогда не привозили юнитов на респаун. Просто не доезжали.



    Последние два дня
    Плана работы нет. Делаю всё, что взбредет в голову. Всё, что бросается в глаза. Всё, что хочется исправить. Видео результата работы в эти дни нет, т.к. изменений много и они в основном мелкие. Потребовалось бы минут 10-15 снимать, чтобы показать их все на видео. А всё, что получилось в итоге и так видно в конкурсном проекте.

    Вот примерный список того, что было сделано (совсем мелкие исправления не включены):
    Включена поддержка геймпада — вообще, фреймворк для интерфейса умеет геймпад из коробки, ничего придумывать не нужно. Только добавил управление непосредственно вертолётом.
    Исправлен баг с неверным расчётом наклона юнитов по отношению к поверхности — на видео иногда проскакивает момент, когда транспорты странно носом в землю закапываются. Это связано с неверным применением кватерниона, описывающего наклон поверхности под колесами юнита.
    Сделан простой расчёт движения юнитов, чтобы они друг в друга не въезжали — добавил несложные коллизии между юнитами.
    Исправлен баг с вылетом при работе с окном диалогов: пересоздавать элементы окна в обработчике этих самых элементов — плохая идея.
    Добавлены метки кланов над клановыми юнитами.
    Тени от облаков — вроде бы мелочь, а плоский мир перестаёт таким быть.
    Разлёт груза — груз теперь не просто появляется на земле рядом с местом, где его выбросили, а красиво разлетается от точки выбрасывания.
    Эффект телепортации грузов — при подборе груза он исчезает не мгновенно, а плавно, с соответствующим эффектом.
    Тестирование и исправление багов.

    Результат работы можно посмотреть по ссылке в теме проекта: SkyRanger.

    Обзоры на все конкурсные проекты:



    Ссылка непосредственно на проект, о разработке которого вы читаете (если не хотите смотреть весь обзор):
    www.youtube.com/watch?v=0nu2QxXAYjo&t=708

    Итог:
    Данная игра была сделана за 14 дней с нуля на фреймворке, который вообще не умел 3Д на момент старта.
    Если уж говорить откровенно, половина времени потрачена не на игру, а на то, чтобы допилить недостающий функционал в самом фреймворке.

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

    Выводы:
    Если вдруг вы видите людей, которые предлагают вам вступить в проект на энтузиазме и сделать Супер-МЕГА-Убийцу-Крайзиса-и-ВОВки, но при этом у них нет хотя бы минимальной демки — бегите от них, ведь это лентяи, которые не удосужились потратить неделю работы и 200$ на ассеты, чтобы сделать прототип, реализующий их идею.

    P.S. Проект после конкурса решено в неспешном режиме дорабатывать. Проект полностью открыт для участия — любой может придти и сделать что-то своё. Также с выходом UE4 решено перенести всё уже сделанное на UE4 и сосредоточиться именно на разработке игры, а не движка для неё.Если сообществу будет интересно, я напишу статью о том, как делался переход на UE4 и с какими сложностями при этом пришлось столкнуться.

    UPD:
    Хаброэффект убил мне дропбокс и мне заблокировали внешние ссылки. Все файлы будут перенесены на свой хостинг в ближайшие часы, пока все это недоступно. Это будет исправлено в ближайшее время. Прошу прощения за доставленные неудобства.

    Ссылки снова живые.

    UPD2:
    Выяснилось, что часть читателей восприняла данную статью как «Ой, да игры можно за пару недель делать! Чё вы там уже три года ковыряетесь, лентяи???».
    Это не то, о чём я говорил.
    К сожалению, правило «20% работы отнимают 80% времени» никуда не делось.
    За очень короткий срок можно сделать прототип, который будет играбельным и будет отражать ваши идеи.
    Но это ещё очень и очень далеко от игры. Скорость разработки падает с каждой новой фишкой.
    Первые дни разработки носят взрывной характер:
    Вот у нас нет ничего. Через день у нас ландшафт. Разница между «ничего» и «ландшафтом на экране» — огромна. Но ведь всего полдня работы!
    А теперь добавьте сюда деревьев. Нет, серьёзно. Самых обычных деревьев. Ну лесок небольшой.
    «То есть как? Сделать ландшафт — 5 часов работы, а лес на ландшафте — месяц????». А вот так. При реализации леса у нас встаёт ряд вопросов, начиная с оптимизации (нарисовать в лоб лес не выйдет. Просто упрётесь в недостаток производительности. А значит, нужны оптимизации — много и зачастую нетривиальные) и заканчивая визуальными артефактами (внезапно deffered shading не хочет нормально работать с блендингом, а оптимизированная листва только блендингом и делается). Не говоря уж о поиске пути, который вообще не учитывал существования отдельно стоящих мелких объектов, которые ИИ должны объезжать.

    Разработка нормальной и качественной игры — это сложная, долгая и кропотливая работа. Большая часть которой вообще не видна снаружи.
    Я рассказал о том, что можно за короткий срок создать демонстрацию вашей идеи, но никак не законченный продукт.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 25

      +7
      [Комментарий про сову]
        +7
        Так пост и не декларировался как туториал.
          +9
          Это просто выброс порции зависти из толпы тех, кто «годами собирает команду, но так и не сделал прототип»…
            +1
            Верно. Это скорее мотивационный пост, нежели какой-то туториал.
            В процессе работы не решалось никаких сложных задач, которые нужно было бы выносить в туториал.
              +1
              Очень мотивирует. Я даже жалею, что к геймдеву не имею никакого отношения. :)
          0
          А паиграть где? =)
            +1
            Результат работы можно посмотреть по ссылке в теме проекта: SkyRanger.
              +1
              Пока нигде. Хабраэффект убил мне дропбокс. В ближайшее время перенесу на свой хостинг все ссылки, и восстановлю доступ.
              +6
              Jungle|Desert|Urban Strike жив!
                +3
                Современное продолжение Jungle|Desert|Urban Strike? Я двадцать джва года жду эту игру.
                  0
                  На данный момент скорее нет чем да. Хотя что-то общее безусловно есть.
                    0
                    Кстати, а вы не смотрели в сторону Renegade Ops? Мне кажется это по духу Desert Strike в чистом виде. Ну, понятно, немного более аркадный в соответствии с модой, но вполне доставляющий. Особенно в кооперативе.
                      0
                      Спасибо за наводку, по скринам выглядит интересно.
                  +5
                  Спасибо, прочитал с удовольствием. Вдохновляет :)

                  Если сообществу будет интересно, я напишу статью о том, как делался переход на UE4 и с какими сложностями при этом пришлось столкнуться.

                  Очень интересно.
                    0
                    Спасибо. Рад что вам понравилось. Статья про переход на UE скорее всего будет. Но много позже.
                    0
                    Было бы интересно еще почитать мануал, про первую неделю разработки, хотя на самом деле интересно почитать вообще про всю разработку более подробнее ))
                      +3
                      +1 с примерами кода. И я так и не понял какой фреймворк использовался в начале? Самописный?
                        0
                        Фреймворк свой, планировалось развить его до уровня современных проектов. Однако выход UE4 в свободный доступ перечеркнул это будущее и фреймворк останется только для разработки мобильных игр, которые мы сейчас иногда делаем. Все что 3Д и для дектопа — сейчас пробуем делать только на UE и связываем с этим большие планы.

                        По поводу примеров кода… А что вы хотите увидеть? Никаких особо интересных решений там нет. Просто код и все. Самый обычный. Сложных задач в процессе разработки не возникало. Каких-то гениальных архитектурный решений тоже не было. :(
                          0
                          Хорошо, напишу лично свое пожелание. Хотя на самом деле страшно за карму )))

                          У меня как у веб разработчика, был небольшой опыт написание 2Д платформера с мультиплеером на Box2D. Поэтому свои познания в создания полноценных игр я свожу к минимуму. Соответственно нету представления о том каким образом используя 2Д движок вы смогли интегрировать 3д модели. Каким образом переносятся шейдеры, настраивается камера и еще миллион задач, которых лично мне (поскольку я не ознакомлен с разработкой 3D чего-либо) кажутся чем-то невероятно сложным. Тем более с математической точки зрения. Для познания садится, читать мануалы, пытаться велосипедить мне не хочется. Но вот почитать об опыте и как решаются какие-то общие задачи — было бы полезно. Вот как-то так.
                            +3
                            На конкретные вопросы я могу ответить прямо здесь в комментариях. Писать статью — ИМХО достаточно бесполезно. Я просто повторю материалы всех тех туториалов, что уже написаны.
                            Отвечу на то, что уже обозначено — перенос шейдеров и настройка камеры.
                            Перенос шейдеров
                            Шейдеры отрисовки ландшафтов идут вместе с редактором ландшафтов, который я использовал. Это Land — для отрисовки ландшафта и objects — для отрисовки объектов и дорог.
                            Я скопировал эти шейдеры в каталог с контентом проекта и выпилил оттуда всякую ненужную фигню.
                            Например, шейдеры умеют динамический рассчет нормалей. Он нужен для того, чтобы при скульптинге освещение геометрии менялось в реальном времени. Этот код в игре не нужен, т.к. в игре ландшафт статичен и нормали предрассчитаны. Также шейдеры умеют рисовать кисть. Этот код тоже не нужен в игре. Его выпилил.
                            Убирать код легко. Например с нормалями убираем функцию calcNormal и код:
                            vec3 N;
                            if (DynamicNormals==1)
                            N = calcNormal(gl_Vertex.xyz, MapCoords);
                            else{
                            N = normalize(gl_Normal);
                            }
                            normal = N;

                            заменяем на:
                            normal = normalize(gl_Normal);


                            Плюс я перевел шейдеры на новую версию GLSL — то есть отказался от depricated элементов(вместо встроенных gl_Normal,gl_Vertex и т.п. — ручками установленные атрибуты).

                            Камера
                            3D камера должна уметь две основных вещи:
                            1) Проецирование 3D пространства в 2D для отображения на плоском экране — это делается через задание матрицы проекции. Для обычной камеры используется перспективная матрица проекции(чем дальше объект, тем он меньше). Это очень простая операция. Даже математику знать не надо. Исходники методов строящих матрицу проекции есть в интернете, тысячи их.
                            2) Работа с видом. Вид — это перемещение камеры в 3D пространстве(вообще, формально мы не камеры двигаем, а само пространство, в то время как камера всегда находится в центре системы координат. Но это математические мелочи имеющие мало значения для практики). Видовая матрица считается очень просто(если вы знаете что такое базис, то проблемы понять что это за матрица — не будет):
                            image
                            Подматрица 3х3 задает вращение с помощью направляющих векторов. По сути задается три оси координат базиса и смещение.
                            m3 m7 и m11 на самом деле могут быть не 0. Это масштабирование. Но при задании видовой матрицы стараются избегать масштабирования, т.к. вылезает много сторонних проблем. Гораздо проще достигать масштабирования сцены другими способами.
                            В случае OpenGL матрица будет транспонированной.

                            Перемножив матрицы из пунктов 1 и 2 мы получим финальную матрицу. С помощью которой точка где-то в 3Д мире превращается в точку на экране нашего монитора.

                            Отдельным пунктом идет задание не перспективной проекции, а ортогональной. Ортогональная проекция — это, грубо говоря, чертежная проекция. Размер объекта не меняется при изменении расстояния до него. Такая проекция нужна для построения теней от бесконечно удаленных источников света(например, солнца). Ортогональная проекция тоже достаточно просто строится. Мануалы есть в сети.

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

                            Ответил?

                            Конечно, всё что я сейчас написал не является каким-то откровением, т.к. лежит в основе базовых понятий 3Д графики.
                              +1
                              Более чем ))) Вам определенно нужно писать учебники «для чайников» =)))) Помоему эту призвание
                        0
                        Я не знаю о чем тут можно написать. Даже краткое изложение разработки превратилось в огромную портянку…
                        Если я просто распишу один день — получится статья больше этой… Да и будет ли это интересно?
                        Я не решал никаких серьезных задач… Ну я могу, например, рассказать как интегрировал карту теней в игру.
                        Но получится просто пересказ туториала по которому я сам все делал и на который ссылался в тексте статьи,
                        Не было вообще задач, которые бы заслуживали подробного описания. ИМХО
                        +11
                        >Класс камеры даже не пришлось писать, за годы разработки он у меня уже был сделан.

                        Комментарий:

                        Вот это «игра за 14 дней»? или всё-таки «игра за 14 дней от гуру, который потратил годы разработки на написание движков к играм»?
                          +8
                          Очевидно, что если вы(утрированно) никогда не писали ничего и видите компьютер второй раз в жизни — то за две недели проект не сделаете. И за два года — тоже. Просто потому что в основе любой работы лежит огромная база знаний.
                          Кто сделает игру за 14 дней? Тот, кого вы наймете(или привлечете бесплатно) чтобы сделать вам прототип.
                          То есть это попытка рассказать, чего можно ждать от специалиста в разработке игре.
                          А также напомнить программистам, что разработка это достаточно быстро, если сосредоточиться на задаче.
                          • НЛО прилетело и опубликовало эту надпись здесь

                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                        Самое читаемое