Показываем наш игровой город
Продолжаем работать над мобильным раннером)
Потихоньку наша коробочка выходит на улицы города
Продолжаем работать над мобильным раннером)
Потихоньку наша коробочка выходит на улицы города
Такс, авторский контент, пускай специфический, но тем не менее)
Я тут разрабатываю игру-выживач, в немного нестандартных условиях. Если вкратце, это выживание в плоском мире (кстати его плоскость лорно-обоснована), ни гор, ни холмов, ни рек ни лесов. Просто бесконечные поля, пустыни, ледянные шапки на полюсах. Ресурсов мало, их способы получения не всегда стандартны
Вчера вечером доделал первые механики строительства, и хотелось бы поделится видео, я тут закладываю каменную основу для дома (в плоском мире под ногами валяются только камни).
Буду рад любой критике и замечаниям. Оно местами ещё сыровато и косо (интерфейс вообще не работает 😀).
Как это работает:
На кнопку B включается режим строительства
Есть блоки, например каменная стена, или каменный пол, переключаемся между ними на Q и R
И есть вариации блоков (для каменных стен например, угол, окно, проем и.т.д)
Блоки ставятся строго по сетке. Некоторые строятся "штабелями", а некоторым (арка, которая забаговалась) просто требует "соединения" с блоками по сторонам.
Прочие структуры типа мебели и станков (которых в видео нет) будут размещаться без привязки к сетки.
Решил поделиться работой навигации в Deep Alchemy Dungeon. Сделано на Unity с использованием A* Pathfinding Project.
Всем любить и скачивать бесплатное демо
Многие программисты так или иначе имеют тягу и интерес к разработке игр. Немалое количество спецов было замечено за написанием маленьких и миленьких игрушек, которые были разработаны за короткое время «just for fun». Большинству разработчиков за счастье взять готовый игровой движок по типу Unity/UE и попытаться создать что-то своё с их помощью, особенно упорные изучают и пытаются что-то сделать в экзотических движках типа Godot/Urho, а совсем прожжённые ребята любят писать игрушки… с нуля. Таковым любителем писать все сам оказался и я. И в один день мне просто захотелось написать что-нибудь прикольное, мобильное и обязательно — двадэшное! В этой статье вы узнаете про: написание производительного 2D-рендерера с нуля на базе OpenGL ES, обработку «сырого» ввода в мобильных играх, организацию архитектуры и игровой логики и адаптация игры под любые устройства. Интересно? Тогда жду вас в статье!
Конечно же разработка собственных игр с нуля — это довольно веселое и увлекательное занятие само по себе. Ведь удовольствие получает не только пользователь, который играет в уже готовую игру, но и её разработчик в процессе реализации своего проекта. В геймдеве есть множество различных и интересных задач, в том числе — и для программиста.
Один из прошлых проектов — 3D шутэмап под… коммуникаторы с Windows Mobile без видеоускорителей! Игра отлично работала и на HTC Gene, и на QTek S110!
В больших студиях принято всю нагрузку распределять на целые команды разработчиков. Артовики занимаются графикой, звуковики — музыкой и звуковыми эффектами, геймдизайнеры — продумывают мир и геймплей будущей игры, а программисты — воплощают всё это в жизнь. Однако, за последние 20 лет появилось довольно большое количествобесплатныхинструментов, благодаря которым маленькие команды или даже разработчики-одиночки могут разрабатывать собственные игры сами!
Подобные инструменты включают в себя как довольно функциональныеконструкторы игр, которые обычно не требуют серьёзных навыков программирования и позволяют собирать игру из логических блоков, так и полноценных игровых движков на манер Unity или Unreal Engine, которые позволяют разработчикам писать игры и продумывать их архитектуру самим. Можно сказать что именно «благодаря» доступности подобных инструментов мы можем видеть текущую ситуацию на рынке мобильных игр, где балом правят очень простые и маленькие донатные игрушки, называемыегиперкежуалом.
Но у подобных инструментов есть несколько минусов, которые банально не позволяют их использовать в реализации некоторых проектов:
Большой вес приложения: При сборке, Unity и UE создают достаточно объёмные пакеты из-за большого количества зависимостей. Таким образом, даже пустой проект может спокойно весить 50-100 мегабайт.
Неоптимальная производительность: И у Unity, и у UE очень комплексные и сложные рендереры «под капотом». Если сейчас купить дешевый смартфон за 3-4 тысячи рублей и попытаться на него накатить какой-нибудь 3 в ряд, то нас ждут либо вылеты, либо дикие тормоза.
Лично я для себя приметил ещё один минус — невозможность деплоить игры на устройства с старыми версиями Android, но это, опять же, моя личная хотелка.
Поэтому когда мне в голову пришла мысль сделать игрушку, я решил написать её с нуля — не используя никаких готовых движков, а реализовав всё сам — и игровую логику, и сам «движок» (правильнее сказать фреймворк). Не сказать, что в этом есть что-то очень сложное — в геймдеве есть отдельная каста «отшельников», которые называют себя «движкописателями» и пишут либо движки, либо игры — правда, не всегда хотя-бы одна игра доходит до релиза.
Перед тем, как садится и пилить игрушку, нужно сразу же определится с целями и поставить перед собой задачи — какой стек технологий мы будет использовать, как будем организовать игровую логику, на каких устройствах игра должна работать и.т.п. Я прикинул и решил реализовать что-то совсем несложное, но при этом достаточно динамичное и забавное… 2D-шутер с видом сверху!
Игра будет написана полностью на Java — родном языке для Android-приложений. Пустые пакеты без зависимостей весят всего около 20 килобайт — что только нам на руку! Ни AppCompat, ни какие либо ещё библиотеки мы использовать не будем — нам нужен минимальный размер из возможных!
Итак, что должно быть в нашей игре:
Основная суть: Вид сверху, человечком по центру экрана можно управлять и стрелять во вражин. Цель заключается в том, чтобы набрать как можно больше очков перед тем, как игрока загрызут. За каждого поверженного врага начисляются баксы, за которые можно купить новые пушки!
Оружие: Несколько видов вооружения, в том числе пистолеты, дробовики, автоматы и даже пулеметы! Всё оружие можно купить в внутриигровом магазине за валюту, которую игрок заработал во время игры
Враги: Два типа врагов — обычный зомби и «шустрик». Враги спавнятся в заранее предусмотренных точках и начинают идти (или бежать) в сторону игрока с целью побить его.
Уровни: Можно сказать, простые декорации — на момент написания статьи без какого либо интерактива.
Поскольку игра пишется с нуля, необходимо сразу продумать необходимые для реализации модули:
Графика: Аппаратно-ускоренный рендерер полупрозрачных 2D-спрайтов с возможность аффинных трансформаций (поворот/масштаб/искривление и.т.п). На мобильных устройствах нужно поддерживать число DIP'ов (вызовов отрисовки) как можно ниже — для этого используется техника батчинга. Сам рендерер работает на базе OpenGLES 1.1 — т.е чистый FFP.
Ввод: Обработка тачскрина и геймпадов. Оба способа ввода очень легко реализовать на Android — для тачскрина нам достаточно повесить onTouchListener на окно нашей игры, а для обработки кнопок — ловить события onKeyListener и сопоставлять коды кнопок с кнопками нашего виртуального геймпада.
Звук: Воспроизведение как «маленьких» звуков, которые можно загрузить целиком в память (выстрелы, звуки шагов и… т.п), так и музыки/эмбиента, которые нужно стримить из физического носителя. Тут практически всю работу делает за нас сам Android, для звуков есть класс — SoundPool (который, тем не менее, не умеет сообщать о статусе проигрывания звука), для музыки — MediaPlayer. Есть возможность проигрывать PCM-сэмплы напрямую, чем я и воспользовался изначально, но с ним есть проблемы.
«Физика»: Я не зря взял этот пункт в кавычки :) По сути, вся физика у нас — это один метод для определения AABB (пересечения прямоугольник с прямоугольником). Всё, ни о какой настоящей физике и речи не идет :)
Поэтому, с учетом требований описанных выше, наша игра будет работать практически на любых смартфонах/планшетах/тв-приставках кроме китайских смартфонов на базе чипсета MT6516 без GPU из 2010-2011 годов. На всех остальных устройствах, включая самый первый Android-смартфон, игра должна работать без проблем. А вот и парк устройств, на которых мы будем тестировать нашу игру:
С целями определились, самое время переходить к практической реализации игры! По сути, её разработка заняла у меня около дву-трех дней — это с учетом написания фреймворка. Но и сама игра совсем несложная :)
Начинаем, мы конечно же, с инициализации контекста GLES и продумывания архитектуры нашего будущего фреймворка. Я всегда ставил рендерер на первое место, поскольку реализация остальных модулей не особо сложная и их можно дописать прямо в процессе разработки игры.
По сути, в современном мире, 2D — это частный случай 3D, когда рисуются всё те же примитивы в виде треугольников, но вместо перспективной матрицы, используется ортографическая матрица определенных размеров. Во времена актуальности DirectDraw (середина-конец 90х) и Java-телефонов, графику обычно не делали адаптивной, из-за чего при смене разрешения, игровое поле могло растягиваться на всю площадь дисплея. Сейчас же, когда разброс разрешений стал колоссальным, чаще всего можно встретить два подхода к организацию проекции:
Установка ортографической матрицы в фиксированные размеры: Если координатная система уже была завязана на пиксели, или по какой-то причине хочется использовать именно её, то можно просто завязать игру на определенном разрешении (например, 480x320, или 480x800). Растеризатор формально не оперирует с пикселями — у него есть нормализованные координаты -1..1 (где -1 — начало экрана, 0 — середина, 1 — конец, это называется clip-space), а матрица проекции как раз и переводит координаты геометрии в camera-space координатах в clip-space — т.е в нашем случае, автоматически подгоняет размеры спрайтов из желаемого нами размера в физический. Обратите внимание, физические движки обычно рассчитаны на работу в метрических координатных системах. Попытки задавать ускорения в пикселях вызывают рывки и баги.
Перевод координатной системы с пиксельной на метрическую/абстрактную:
Сейчас этот способ используется чаще всего, поскольку именно его используют самые популярные движки и фреймворки. Если говорить совсем просто — то мы задаем координаты объектов и их размеры не относительно пикселей, а относительно размеров этих объектов в метрах, или ещё какой-либо абстрактной системы координат. Этот подход близок к обычной 3D-графике и имеет свои плюшки: например, можно выпустить HD-пак для вашей игры и заменить все спрайты на варианты с более высоким разрешением, не переделывая половину игры.
Для совсем простых игр я выбираю обычно первый подход. Самое время реализовать главный метод всего рендерера — рисование спрайтов. В моём случае, спрайты не были упакованы в атласы (одна текстура, содержащая в себе целую анимацию или ещё что-то в этом духе), поэтому и возможность выборки тайла из текстуры я реализовывать не стал. В остальном, всё стандартно:
Всё более чем понятно — преобразуем координаты спрайта из world-space в camera-space, отсекаем спрайт, если он находится за пределами экрана, задаем стейты для GAPI (на данный момент, их всего два), заполняем вершинный буфер геометрией и рисуем на экран. Никакого смысла использовать VBO здесь нет, а на nio-буфферы можно получить прямой указатель без лишних копирований, так что никаких проблем с производительностью не будет. Обратите внимание — вершинный буфер выделяется заранее — аллокации каждый дравколл нам не нужны и вредны.
Обратите внимание на вызовы ByteBuffer.order — это важно, по умолчанию, Java создаёт все буферы в BIG_ENDIAN, в то время как большинство Android-устройств — LITTLE_ENDIAN, из-за этого можно запросто накосячить и долго думать «а почему у меня буферы заполнены правильно, но геометрии на экране нет!?».
В процессе разработки игры, при отрисовке относительно небольшой карты с большим количеством тайлов, количество вызовов отрисовки возросло аж до 600, из-за чего FPS в игре очень сильно просел. Связано это с тем, что на старых мобильных GPU каждый вызов отрисовки означал пересылку состояния сцены видеочипу, из-за чего мы получали лаги. Фиксится это довольно просто: реализацией батчинга — специальной техники, которая «сшивает» большое количество спрайтов с одной текстурой в один и позволяет отрисовать хоть 1000, хоть 100000 спрайтов в один проход! Есть два вида батчинга, статический — когда объекты «сшиваются» при загрузке карты/в процессе компиляции игры (привет Unity) и динамический — когда объекты сшиваются прямо на лету (тоже привет Unity). На более современных мобильных GPU с поддержкой GLES 3.0 есть также инстансинг — схожая технология, но реализуемая прямо на GPU. Суть её в том, что мы передаём в шейдер параметры объектов, которые мы хотим отрисовать (матрицу, настройки материала и.т.п) и просим видеочип отрисовать одну и ту же геометрию, допустим, 15 раз. Каждая итерация отрисовки геометрии будет увеличивать счетчик gl_InstanceID на один, благодаря чему мы сможем расставить все модельки на свои места! Но тут уж справедливости ради стоит сказать, что в D3D10+ можно вообще стейты передавать на видеокарту «пачками», что здорово снижает оверхед одного вызова отрисовки.
Для загрузки спрайтов используется встроенный в Android декодер изображений. Он умеет работать в нескольких режимах (ARGB/RGB565 и.т.п), декодировать кучу форматов — в том числе и jpeg, что положительно скажется на финальном размере игры.
На этом реализация рендерера закончена. Да, все вот так просто :)
Переходим к двум остальным модулям — звук и ввод.
Как я уже говорил, звук я решитл реализовать на базе уже существующей звуковой подсистемы Android. Ничего сложного в её реализацир нет, можно сказать, нам остаётся лишь написать обёртку, необходимую для работы. Изначально я написал собственный загрузчик wav-файлов и хотел использовать AudioTrack — класс для воспрозизведения PCM-звука напрямую, но мне не понравилось, что в нём нет разделения на источники звука и буферы, из-за чего каждый источник вынужден заниматься копированием PCM-потока в новый и новый буфер…
Полная реализация звукового потока выглядит так. И да, с SoundPool нет возможности получить позицию проигрывания звука или узнать, когда проигрывание закончилось. Увы.
Да будет звук! Ну и про ввод не забываем (листинг получился слишком длинный, а на Пикабу нет тега для кода - так что как-то так):
Сама реализация джойстика крайне простая — запоминаем координаты, куда пользователь поставил палец и затем считаем дистанцию положения пальца относительно центральной точки, параллельно нормализововая их относительно максимальной дистанции:
Кроме того, я добавил вспомогательный метод для вызова диалога ввода текста — это для таблицы рекордов и прочих фишек, которые требуют ввода текста пользователем. Ну не будем же мы сами клавиатуру костылить!
Основа для игры есть, теперь переходим к её реализации!
Писать игру я начал с создания первого уровня и реализации загрузчика уровней. В качестве редактора, я выбрал популярный и широко-известный TileEd — удобный редактор с возможностью экспорта карт в несколько разных форматов. Я лично выбрал Json, поскольку в Android уже есть удобный пакет для работы с этим форматом данных.
Карта делится на 3 базовые понятия: тайлы — фон, с изображением травы/асфальта/земли и.т.п, пропы — статичные объекты по типу деревьев и кустов и сущности — объекты, участвующие в игровом процессе, т.е игрок, зомби и летящие пули. Система сущностей реализована в виде абстрактного базового класса, который реализовывает логику апдейтов, просчитывает Forward-вектор и выполняет другие необходимые задачи:
После этого, я приступил к реализации игрока, оружия и механики стрельбы. В целом, практически всю логику игрока можно описать в виде одного метода update: обрабатываем ввод и ходьбу с джойстика, поворачиваем игрока в сторону пальца на экране и пока зажата какая-либо область на экране мы ходим и стреляем:
Ну и не забываем про реализацию зомби. Она тоже очень простая: есть базовый класс Zombie, от которого наследуются все монстры и который реализует несколько необходимых методов — повернуться в сторону игрока, идти вперед и конечно же атака!
Честно сказать, статья итак уже получилась слишком длинной. Я очень хотел написать игру, о разработке которой можно было бы рассказать в рамках одной не особо большой статьи, но с моим стилем написания текстов так сделать не выйдет. Придется разбивать на части!
Однако, некоторый прогресс уже есть и мы можем даже поиграть в игру на текущем ее этапе!
Как мы видим, игра (а пока что — proof of concept) работает довольно неплохо на всех устройствах, которые были выбраны для тестирования. Однако это ещё не всё — предстоит добавить конечную цель игры (набор очков), магазин стволов и разные типы мобов. Благо, это всё реализовать уже совсем несложно :)
Написать небольшую игрушку с нуля в одиночку вполне реально. Разработка достаточно больших проектов конечно же требует довольно больших человекочасов, однако реализовать что-то своё, маленькое может и самому!
Пишите своё мнение в комментариях. Если вам вдруг интересна тематика самопальной разработки игр, то постараюсь выпускать подобные статьи почаще!
Статья подготовлена при поддержке компании TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Но тут я даже чутка навру - на этой неделе вас ждёт сразу две статьи :) Следующая - в четверг, прошлую неделю я отдыхал и работал.
Всем привет! Это девлог игры The Last World. Игра разрабатывается одним человеком. В первой части рассказываю о том, что это за игра и с чем её едят. Критика, предложения, советы и вопросы по теме приветствуются.
Возможно некоторые из вас могли видеть его на другом ресурсе, однако мне хочется донести его как можно до большего числа людей. Прошу встречать и жаловать.
Немного дополню: я хочу бросить вызов лидерам этого игрового жанра и показать всем, что один в поле воин, хоть и многие говорят обратное.
Заранее прошу прощения за длинный пост, я старался максимально минимизировать его, давая больше визуального сопровождения.
НАЧАЛО
Проект зародился в середине 2017 года. На тот момент у меня имелся готовый (как я тогда думал, вскоре пришлось его переписать полностью) ассет инвентаря и моддинга, называется ICWM – Inventory And Weapon Modding System, его можно найти в Unity Asset Store.
С утра до вечера работал в Конструкторском Бюро, а вечером часа 3 или 4 сидел и трудился над игрой, плюс выходные не тратил зря. На тот момент игра казалось пустяковой, внушал себе - «Да что там, годик, а то и два и готова». Но не тут та было, это приключение растянулось на более чем 4 года.
С начала и по сей день над игрой трудится один человек, вот и вся команда. Увлекался 3D моделированием, делал модельки (ArtStation). В студенческие годы освоил программирование. Поэтому сделать модельку или написать какую-нибудь логику не составляло большого труда.
Эта статья (вернее девлог) состоит из сборки всех моих наработок, плюс спец часть, в которой я коротко расскажу про механики игры. Всего планирую написать 2 части, а дальше как пойдет. Слишком много драгоценного времени уходит на это.
НЕМНОГО ПРО ИГРУ
The Last World – это научно-фантастическая игра-симулятор с элементами космоса, приключений, выживания, моддинга и автоматизации производства, в которой игроку предстоит создать собственную империю из руин старой.
По крайней мере я вижу ее такой на выходе.
TheLastWorld – из названия все понятно, последний мир и второй шанс человечеству, другого не будет. Название игры пришло только через 3 года, по началу проект был безликим.
ВКРАТЦЕ
Мир, который мы так все прекрасно знали и любили - умер. Его погубила бактерия, родившиеся в пробирке ученого, пытавшего создать панацею - лекарство от всех болезней. Итог один - исчезновение всего живого на планете. На грани вымирания люди создали проект «Ironborns» - это искусственный интеллект, цель которого найти пригодную для существования биологических организмов планету в бескрайнем океане звезд и дать человеку второй шанс, шанс на существование.
Сплотившись, земное правительство построило космические суда разместив в грузовых отсеках капсулы с людьми. Эти суда напоминали большие города, не имеющих начала и конца. Управление было возложено на ИИ, центральное ядро, сверхразум, созданный в помощь человеку. Однако он оказался непредсказуем. В процессе блуждания по бескрайнему океану звезд ИИ по каким-то причинам раскололся на несколько потоков, тем самым создав множество ответвлений, эту дату назвали «День распада»….
Игроку предстоит строить и развивать свою базу, много путешествовать, исследовать, торговать, сражаться и договариваться, а также многое другое. В игре присутствует механика завода, где игрок сможет производить более дорогие ресурсы для продажи или улучшений, где сможет добывать ресурсы из недр планет и не только. The Last World - это песочница, где игрок сам волен выбирать свой путь.
Изначально у игрока есть база только на космическом судне, это его отправная точка, оттуда он управляет наземной базой. На своей космической базе он может хранить ресурсы, переправлять их между земной и космической базами и продавать их. Также он может перелетать между планетами или вообще улететь с текущей солнечной системы в другую. Космическая база не ограничивается только перечисленными выше механиками, в будущем они будут расширяться.
НА СТАРТ
На старте игрока встречает генератор планет. Ему предстоит выбрать на какой тип планеты ему отправиться и попытаться там выполнить миссию. В будущем планирую добавить солнечные системы.
Далее предстоит выбрать персонажа. В роли главных героев в игре выступают роботизированные механизмы под управлением одного из ИИ. Собственно, игрок и представляет этого ИИ. В игре будут только роботы, также планирую добавить «клановую» систему, как написал выше – «…был разделен на несколько потоков», в которой будет один из кланов, специализирующийся на гибридных технологиях – плоть и железо.
Игрок может создавать и настраивать своего персонажа в Конструкторе (редактор юнитов). Важно помнить, что каждый персонаж является модульным, его можно собрать по частям, но об этом я расскажу в спец части.
После игрок выбирает место дислокации и начинается игра.
ВЫСАДКА
Высадившись на планету первым делом нужно её изучить, а может там не безопасно вовсе? кто знает… Игроку доступны базовые ресурсы, которые разбросаны по локации, их та и предстоит ему добыть на первых этапах игры.
Далее построить небольшой блокпост, разместить там пару построек и начать исследовать новые технологии. Для открытия технологий игроку нужно накопить определенное количество очков, здесь они выступают в роли предметов, которые потом перерабатываются в виртуальные очки в специальной исследовательской постройке. Можно привести аналогию с игрой Factorio и их колбами. Дальше игроку открываются все больше и больше возможностей, например, доступ к глобальной карте, на которой игрок может перемещаться с одной локации на другую (путешествовать, открывать новые территории и т.д.).
ЛОКАЦИЯ
Все локации являются процедурно генерируемыми. Из динамики в игре присутствует, пока что, смена дня и ночи и жизненный цикл растительного мира. Ночное время суток было умышленно сделано темнее, т.к. планирую добавить NPC и «заразу», местный аналог антивируса.
Из фич, можно выделить – генерацию травы на локациях. По моим тестам на самой большой локации получилось разместить до 14млн (на самом деле дело доходило до 100млн но об этом в спец части) травинок, однако такая функция присуща для настройки «Не оптимизировано».
На данный момент в игре «почти полностью» реализована механика завода и первый прототип торговой площадки, а также есть и дополнительные механики, о них поведаю в следующей статье, вкратце - это система сетей, глобальная карта, моддинг юнитов и тп. Еще из ключевых механик является – инвентарь. Инвентарем владеет почти каждая постройка и все юниты. Инвентарь выполнен по типу ячеек. Инвентаря в игре много, поэтому будет и много лута.
ДРОНАТИЗАЦИЯ
Помимо основных (управляемых) юнитов в игре есть и неуправляемые – автоматизированные дроны, которые помогают игроку выполнять некоторые задачи (добывать, приносить, строить). Они привязаны к постройкам, поэтому ими игрок не будет управлять на прямую, а лишь давать команды, например, очистить область в указанном радиусе от растительности.
ИНТЕРЕСНЕНЬКОЕ
Всего в игре доступно 5 слотов для основных юнитов (т.е. игрок сможет управлять одновременно 5ю юнитами), новых юнитов нужно будет покупать, открывать или находить. На самом деле хочется много рассказать про юниты, но оставлю это для спец части, там я расскажу и про инструменты для юнитов (аналог оружия в игре) и про его моддинг.
ПОСТРОЙКИ
В игре The Last World, на текущей момент, присутствует более 40 уникальных функциональных построек, которые игрок может строить. В будущем планирую добавить больше построек. Все постройки разбиты по классам – контроль, сервис, добыча, очистка, производство, хранение, поддержка, исследование, энергетика, оборона. Размещение построек на локации осуществляется по сетке.
Для каждой постройки можно открыть окно «Inspect Window – Окно Осмотра», в которой будет выведена самая необходимая информация. Также там отображен инвентарь постройки и панель управления, где можно точно настроить сколько ресурсов будет забирать постройка из сети или наоборот запретить отдавать ресурсы сетям и тп.
ЕЩЁ НЕМНОГО, НЕ РАСХОДИМСЯ
Как упомянул выше, юниту нужно выбрать планету и высадиться на ней. Пока что в игре присутствует два типа планет, пустынная и земле подобная. Планируется и много других планет, но на текущий момент для тестирования этого достаточно.
В будущем добавлю генерацию солнечной системы. Планеты будут также процедурными и мне хочется, чтобы хотя-бы 70 процентов из них были необитаемыми (не как в игре «Не мужское небо»). Между планетами игрок сможет путешествовать и искать точки интереса.
Помимо основной локации, где игрок будет проводить большую часть времени я планирую добавить и точки интереса по всей глобальной карте, к примеру, заброшенные катакомбы или брошенный карьер и тд. Места, где игрок сможет побродить и может найти что-нибудь полезное и интересное.
Игра делается на движке Unity. В следующей статье расскажу немного подробней про механики игры и затрону некоторые другие аспекты:
* визуальная составляющая – цвет, стилистика, UI
* конструкторы – моддинг юнитов и инструментов, модулей юнитов
* генераторы – world, terrain, props, resources, grass
* торговая площадка
* игровые инструменты - система сетей
* древо технологий
* строительство
* свет
* инвентарь – юнита, постройки
ЗАКЛЮЧЕНИЕ
В заключение хочу добавить, что работа была проделана колоссальная, особенно с инвентарем и взаимодействием игрока с ним. Парой исправление одного лишь пустякового бага может занять несколько дней (хотя такие баги должны исправляться за пару минут), которые я мог бы потратить на что-то более полезное, например, контент.
В игру уже можно играть, можно построить огромный завод и поторговаться на торговой площадке. Поэтому следующий (вернее уже текущий) год буду добавлять только контент и стараться выйти в альфу как можно раньше для старта сбора обратной связи, конечно, если выполню все планы.
Впереди еще много работы – в игре нет ни одного звука, очень мало контента, нет точек интереса, слабая экономика и многое другое, что необходимо выполнить перед показом полноценного игрового процесса.
Критика, предложения, советы и вопросы по теме приветствуются.
Спасибо за инвестированное время! Присоединяйтесь к сообществу и следите за ходом разработки! Следующая статья будет через неделю.
ССЫЛКИ
Всем привет! В течении нескольких лет и десятка постов мы рассказывали о том, как поживает наш проект Bus Driver Simulator, какой новый контент для него мы добавляем. С начала разработки игры прошло 5 лет. Для нас это повод оглянуться назад и вспомнить, с какими сложностями мы столкнулись и как их преодолевали.
Это история о том, как начали разрабатываться отечественные автобусные симуляторы и к чему это привело.
Идея игры
В ноябре 2016 года стартовала разработка игры Bus Driver Simulator 2017 (да, на тот момент в названии игры ещё стояла цифра 2017). Затеяли эту разработку всего двое молодых разработчиков, которые до этого занимались разными мелкими инди-играми. Идея была довольно незамысловатая — сделать игру, в которой можно будет играть за водителя автобуса и развозить людей по остановкам, следуя расписанию. А в качестве места действия игры решено было выбрать родной для обоих разработчиков город Серпухов. На тот момент идея казалась нам (тем самым разработчикам) довольно простой и вполне оправданной.
С одной стороны, казалось, что реализовать такую идею не будет слишком сложно и долго, ведь нужно только реализовать функционал езды на паре автобусов и сделать пассажиров, которые будут садится в автобус и выходить из него. Также предполагалось сделать какой-то совершенно незамысловатый трафик, а игру оформить в виде прохождения сценариев или, другими словами, миссий по нескольким маршрутам города. За столкновения с машинами трафика или другими нарушениями игрок должен был мгновенно получать окно о своём проигрыше и проходить всё заново.
С другой стороны, нам хотелось проявить себя и реализовать свою детскую мечту, сделав игру со своим собственным городом, тем более, что было очевидно, что никто другой за нас это в жизнь не воплотит. Причина элементарна: Серпухов — город небольшой и в принципе не особо примечательный. В нём нет ни игровых студий, ни чего-либо действительно известного в масштабах страны или мира, чтобы им кто-то серьёзно заинтересовался для переноса в виртуальную реальность.
Конечно, мы понимали, что перенести целый город в игру — задача непосильная, но воссоздать небольшой кусок города казалось более, чем реальным. Плюс к этому, хотелось воссоздать отечественные автобусы и автомобили для полного погружения.
Итак, по прикидкам работы выходило на полгода. Но всё пошло не совсем так, как ожидалось.
Анонс игры и реакция на него
Через несколько месяцев были готовы первые материалы по игре в виде 3D-моделей и небольшого куска города. Также мы сделали фейковый геймлейный ролик, в котором всё было реализовано на базе простейших анимаций движения. На самом деле, на тот момент не было готово практически ничего. Работа над пассажирской системой и трафиком только начиналась. Но всего этого хватило для анонса игры широкой публике.
Самый первый логотип игры. Смотрится мрачно
На тот момент нам нужно было понять, будет ли вообще игрокам интересна данная игра и имеет ли смысл её разработка. Представленного ролика, первых скриншотов и подробного описания того, что мы делаем, оказалось более, чем достаточно, чтобы понять, что заинтересованные люди есть. И мы получили большое количество комментариев (по нашим тогдашним меркам).
Часть людей, конечно, была настроена очень негативно. Одни из них смеялись по поводу того, кому вообще нужны подобные игры. Их можно было понять: жанр довольно узкий и действительно не для всех, так что эти люди просто не были нашей целевой аудиторией.
Уровень нашего левел-дизайна в 2017 году был весьма примитивным
Другие негативно настроенные люди оказались фанатами уже существующего автобусного симулятора и писали о том, что наша затея никому не нужна, так как уже есть идеальная, по их мнению, игра в этом жанре. На самом деле игр в жанре автобусных симуляторов на тот момент было уже несколько, но почему-то именно фанаты одной конкретной игры считали своим долгом оставлять свои комментарии под любыми нашими постами того времени.
К слову, у нас не было цели делать игру-«убийцу» другой игры, делая всё то же самое, как где бы то ни было, только лучше. Мы просто хотели сделать свою игру в данном жанре так, как мы это видели.
Первые 3D-модели пассажиров и автомобилей
Но была и третья довольно большая группа людей, которая поддержала нашу затею, давали десятки советов, что нам надо сделать, что они хотят видеть и т.п. Эта бурная реакция показала нам, что интерес к игре есть, и что нам стоит заняться ей намного серьёзней, чем мы предполагали изначально.
Первый год разработки
Мы стали вести соцсети, документируя процесс разработки и взаимодействуя с нашей небольшой, но активной аудиторией. Становилось всё очевиднее, что игру нужно делать более продуманной и качественной, так как какой-то спрос на неё есть, и мы хотели сделать лучшее, что мы можем.
Наши изначальные планы были серьёзно расширены. Мы по-прежнему собирались сделать кусок города, только теперь намного больше и детализированнеe. Столкновение с автомобилем трафика теперь не должно было приводить к мгновенному проигрышу, а должен был выдаваться штраф за столкновение, игра — продолжаться, а машина трафика должна была восстановить свой путь движения после столкновения.
Пассажирам теперь точно не было позволено сразу телепортироваться на сидения автобуса, а полноценно находить открытые двери автобуса, входить в него и садится на свободные места. Словом, уровень искусственного интеллекта и всего остального теперь предполагался намного сложнее.
Так выглядела игра в конце 2017
У нас уже был какой-то опыт разработки игр, но Bus Driver Simulator становилась игрой совершенно другого масштаба, намного более крупной и требовала другого уровня качества. А опыта разработки такого рода проектов у нас не было никакого. Поэтому мы столкнулись, наверное, со всеми проблемами, которые мы только могли словить.
Мы изначально сделали неправильную архитектуру проекта, что в дальнейшем привело к большим сложностям во внедрении изменений. Наши скрипты были абсолютно не гибкими и запутанными. Объекты на сцене располагались без понятной иерархии.
Мы делали 3d-модели и карту, не оглядываясь на многие вещи, с которыми мы бы даже не столкнулись, если бы делали игры, где бы не было такого огромного количества объектов на карте. При этом большинство подобных моделей были визуально весьма простые и невзрачные. Это привело к лютейшим тормозам при очень посредственной графике.
Такая версия планшета с расписанием тогда не понравилась никому
Мы наводнили проект кучей различных плагинов, которые были призваны помочь в более быстрой разработке систем, но это привело к тому, что между плагинами стали возникать конфликты. При обновлениях движка Unity некоторые плагины банально отваливались и переставали работать. Самое обидное, что некоторые плагины имели ограничения и не позволяли реализовать определённый функционал именно так, как хотели бы мы или игроки.
В итоге, получалось всё совершенно не того качества, которое должно было быть. Мы делали всё возможное, чтобы из всего этого хаоса слепить работающую игру. Но время поджимало. Мы уже год работали над Bus Driver Simulator. К тому моменту мы уже поняли, что вдвоём такой большой проект не вытянуть, так что к концу первого года разработки нас было уже четверо, чего, впрочем, все равно было недостаточно. Но у нас не было ни издателей, ни инвесторов. Успех подобной игры, которая по сути делалась чисто под российскую аудиторию, никем не гарантировался. Нужна была финансовая помощь и моральная поддержка. Игру нужно было выпускать, и как можно скорее.
Выход в ранний доступ Steam и проблемы игры
Каким-то образом, мы всё-таки смогли собрать всё сделанное вместе и выпустили игру в ранний доступ Steam 31 января 2018 года. К сожалению, многие вещи тогда пришлось упростить или оставить в недоделанном виде. Итого в игре про автобусы у нас было всего лишь два автобуса, кусок города и 8 маршрутов, доступных к прохождению. А вместе с тем, большое количество багов и глючно работающие практически все системы игры. Но тут вопрос стоял уже так, что либо мы выпускаем, как есть, либо, вероятно, игра уже свет не увидит.
С анимациями пассажиров было особенно много проблем
Реакция аудитории была смешанной. Нас много критиковали за сырую игру, за многочисленные баги и недоработки, которые мешали играть. Но, вместе с тем, нас и хвалили за то, что мы сделать успели. Отечественные автобусы и русский город многим пришлись по душе. Люди отмечали потенциал игры и закидывали нас просьбами исправить те или иные проблемы, а также добавить какой-либо автобус или город в игру.
Какая-никакая поддержка у игры образовалась, а мы хотели быть теми, кто доделывает любое дело до конца. Это нужно было доказать не только обычным игрокам, но и самим себе. Так началась бесконечная доработка и переработка всего и вся.
Текстуры и освещение оставляли желать лучшего
Мы выписывали баги и задачи, которые нам нужно сделать по игре, чтобы привести её в достойный вид. На тот момент получилось больше сотни проблем, которые нужно было решить. Некоторые из них решались довольно просто, а решение некоторых просто ломало всё. Исправление одного бага вело к появлению нового, и всё как домино рассыпалось. Происходила цепная реакция, костыль висел на костыле.
Дальнейшие правки плохо сделанных систем требовали невероятного внимания к себе. Нам стало очевидно, что нужно переделывать игру. Этого очень не хотелось, учитывая сколько мы уже на это потратили. Но чем дальше мы шли, тем больше приходили к тому, что переделывать надо было всё именно с нуля. Это касалось и кода игры, и всей графики.
Конечно, в одночасье это было невозможно. Потому началась долгая и непростая работа, что растянулась на несколько лет. Мы брались за наиболее проблемные аспекты и постепенно переделывали их.
После выхода в раннем доступе Steam в игре всё было дико засвечено
Помимо исправлений багов люди хотели и контентных обновлений, и мы ими не менее активно занимались. Мы составили дорожную карту на один год, что мы хотим реализовать и выложили её в открытый доступ. Стоит ли говорить, что реализовать всё это целиком удалось лишь к 2021 году.
Фиаско с обновлением графики
Глобально на протяжении всей разработки мы шли в правильном направлении, делая то, что нужно было нашим игрокам. Мы сделали очень многое из того, что просили люди в многочисленных комментариях, имейлах и сообщениях, хотя и не так быстро, как хотелось бы. Но на определённых этапах у нас случались и настоящие фиаско.
Так осенью 2018 года мы выпустили большое обновление, которое серьёзно улучшало графику в игре и добавляло в неё второй город Кёльн. Во время подготовки обновления оно казалось нам совершенно отличным. Дело в том, что на момент выхода игры в ранний доступ графика была очень слабой. Было очень плохо настроено освещение, шейдеры, материалы. Многие части Серпухова были плохо детализированы.
С точки зрения левел-дизайна оригинальная карта имела огромное количество огрехов, и некоторые места её были сделаны неправильно. Мы всё это дело переработали и подтянули к более достойному на тот момент виду. Игра будто заиграла новыми красками. Но наш рестайлинг обернулся нам тонной гневных комментариев.
Качество графики заметно поднялось к концу 2018-го
Оказалось, что у игры резко повысились системные требования, причём проблемы возникли именно на старых компьютерах. Но так как подавляющее большинство наших игроков сидело именно на старых машинах, игра у них стала тормозить и портить всё впечатление. Так началась многомесячная работа над оптимизацией, что привело к полной переработке трафика, пассажиров и уже второй, правда частичной, переработке карты.
Утопшие автобусы в асфальте
Этот критический баг не давал никому спокойно играть
Другим знаменитым фиаско стал глюк с проваливанием колёс автобуса под асфальт. Эта проблема пришла с той стороны, с которой мы её точно не ждали. Мы решили обновить версию движка Unity, на которой мы работали, на самую последнюю для доступа к новым возможностям.
На первый взгляд всё прошло хорошо. Все системы работали, особых проблем не возникло. Мы с чистой душой выпустили своё очередное обновление под Новый год, как вскоре на нас посыпались обвинения со стороны игроков. Оказалось, что время от времени колеса автобуса утопали под асфальт, и ничего больше сделать было невозможно. Единственным вариантом было начинать игру заново.
Мы усиленно тестировали игру и пытались найти причину внезапно возникшего бага, но ничего не могли найти. Все наши попытки исправить эту ситуацию ни к чему не приводили. И вот с таким чудовищным багом мы вступали в Новый 2019 Год. Работая на новогодних праздниках, наконец, стало понятно, что в возникшей проблеме оказалась виновата новая версию Unity, в которой сломали обработку определённых событий. Если кратко, то проблема была связана с навигацией пассажиров. Казалось бы, где связь системы пассажиров и утопания колёс в асфальте?
Ох уж эти рули
Ещё одной большой проблемой была реализация поддержки рулей. Крайне сложно было сделать адекватную поддержку рулей просто из-за того, что рулей огромное количество, а работают они все по-разному. На нас постоянно сыпались оскорбления из-за того, что у людей не работали их модели рулей, особенно какие-нибудь дешёвые китайские рули.
Даже когда мы сделали возможность настройки своего руля, ничего не поменялось. Игрокам было сложно потратить 10 минут на настройку своего руля. Конечно, было бы здорово сделать так, чтобы человек просто воткнул руль, и всё сразу заработало, но увы, у нас не было возможности реализовать это, хотя бы потому, что мы не могли взять и купить все возможные модели рулей для того, чтобы идеально настроить их и всё отлично оттестировать.
Так что поддержка рулей прошла множество итераций, прежде чем прийти к тому виду, что есть сейчас. И тут надо отдать должное некоторым игрокам, которые активно помогали нам с тестированием.
Злополучный трафик
Покажется безумием, но какие-то вещи нам пришлось переделывать больше, чем один раз. Намного больше. О злополучном трафике можно было бы рассказывать часами. Это тот самый случай, когда изначально хотелось не придумывать велосипед, а взять готовое решение и сделать всё максимально быстро. Но получилось всё с точностью наоборот.
Для движка Unity можно найти гигантское количество плагинов и компонентов в их магазине Asset Store. Чтобы не изобретать всё с нуля, ещё в самом начале разработки Bus Driver Simulator было решено найти что-то подходящее для реализации трафика в этом магазине. Был найден и проверен один из таких плагинов, который казался просто отличным. После подробного изучения началась работа на нём. Естественно, плагин – это лишь инструмент, который всего лишь помогает в работе, а не делает её за специалиста, и всё не заработает по нажатию одной кнопки.
Машины иногда любили прыгать и переворачиваться
Так что работа над трафиком началась и шла, а транспортная сеть всё разрасталась и разрасталась. Вместе с тем, росла и сама игровая карта, которую решено было сделать больше к выходу игру. Чем дальше продвигалась работа, тем больше становилось объектов, регулирующих трафик и тем медленнее и медленнее работал плагин в движке Unity.
Прошла пара месяцев, и наступил критический момент. Компьютер не мог справится с обработкой данных. Задержка после каждого клика стала занимать несколько секунд. Трафик не покрывал даже четверти карты. А работать над ним дальше не представлялось возможным. А ведь ещё какое-то время назад, не было никаких предпосылок на то, что всё будет так дико тормозить из этой системы трафика. Стало ясно, что этот инструмент для трафика не подходит. Он просто не подходил для таких больших карт. И изменить в нём что-либо нельзя, он был закрытым.
Обыденное дело при езде по городу в 2018 году
В короткие сроки был найден другой плагин для создания трафика. Он был попроще, но зато был лучше оптимизирован. Первым делом было проверено, насколько транспортная сеть, построенная на новом плагине, готова к масштабированию.
Результаты теста были хорошими. Было ясно, что на этом плагине можно будет построить всю транспортную сеть игры, даже на такой большой карте как Серпухов, и это не приведёт к тормозам, по крайней мере к таким тормозам от трафика, которые были. Началась работа с нуля над новой версией трафика.
Плагин был не очень удобным, приходилось абсолютно все объекты настраивать вручную. Для понимания уточню, что только на карте Серпухов было несколько тысяч объектов по управлению трафиком. Это так называемые вейпоинты, триггеры, специальные объекты для светофоров и т. д. Так что порой возникала мысль о том, а стоит ли вообще использование такого плагина, так как на нём безумно долго строить транспортную сеть для такой большой карты.
Сейчас уже очевидно, что тот плагин тоже не годился для трафика. Но время поджимало, искать ещё один плагин и начинать всё заново не хотелось. Писать собственную систему трафика с нуля всё же потребовало бы больше времени, чем доделать текущую работу. Так что долгая работа по созданию трафика продолжилась на нём. Только вот была одна существенная деталь. Данный плагин основывался на ещё одном плагине, что, как можно догадаться, впоследствии сыграет злую шутку.
Ещё одна частая проблема, с которой игроки сталкивались много месяцев
Так как изначальные планы по созданию простейшего трафика постепенно сменились на создание относительно продвинутого, по нашим меркам, ИИ машин, всё больше и больше мы стали сталкиваться с ограничениями плагина, на базе которого был сделан наш плагин для трафика. Пришлось залезать под капот этих плагинов и изменять их под себя там, где это было возможно.
Но, как уже можно догадаться, это вело лишь к обрастанию системы многочисленными костылями, так как она не предназначалась под весь тот функционал, который мы хотели реализовать. Отсюда и очень долгие фиксы багов в функционале, который изначально не предполагался.
Затем мы начали делать нашу вторую карту Кёльн и решили расширить оригинальную карту Серпухов. В этот момент стало очевидно, что систему трафика надо переделывать, опять. Дальнейшие правки трафика были крайне трудоёмкими, систему надо было сделать более гибкой.
Многополосные дороги в Кёльне прибавили разработчикам хардкора
В 2019 году трафик был переделан в третий раз. По сути, мы переписали функционал плагинов в более-менее нормальный, читаемый и редактируемый код, а сами плагины стали частью истории. Полной трансформации подверглись скрипты управлением трафиком, весь AI автомобилей. Не сказать, что теперь всё было идеально, но во всяком случае, удалось решить все ключевые проблемы.
Скорее всего, в таком виде бы всё и осталось, но мы начали делать три новые карты: Окрестности Мурома для Bus Driver Simulator, Чернобыльская зона и Южный Китай для Bus World (о нём ниже). Карты Мурома и Чернобыльской зоны получались просто огромными — мы стремились к большему масштабу, чтобы достоверней отразить размеры реальной местности, а в Китае получилась особенность с геометрией карты — серпантины с постоянными перепадами высот.
В общем, использовать старую систему трафика оказалось невозможно. Пришлось переделывать всё заново. Речи об использовании сторонних плагинов уже не было. Мы поняли, что нам лучше сделать всё с нуля так, чтобы мы могли гибко использовать это для наших задач и больших виртуальных пространств.
Протяжённость дорог в окрестностях Мурома побила все предыдущие рекорды
Многострадальная система трафика была сделана с нуля (или практически с нуля) целых 4 раза. Кажется ужасным, что в итоге на неё было потрачено целых 4 года, а большую часть этих усилий пришлось выкинуть на помойку. При этом, конечный игрок, конечно, не увидит всех этих изменений, так как многие изменения были именно под капотом игры.
Итоги пяти лет для Bus Driver Simulator
Когда игра выходила в ранний доступ в ней была всего часть одной карты, 2 автобуса, 8 сценариев и огромное количество багов разной степени проблемности.
На конец 2021 года для Bus Driver Simulator сделано 4 карты (Серпухов, Кёльн, Окрестности Мурома, Солнечногорск), 14 автобусов (считая модификацию одного из автобусов), 17 сценариев и порядка 50 маршрутов в добавленном режиме карьеры. Игра постепенно глобально преобразовалась, в неё было добавлено много дополнительного функционала, вроде мини-карты, радио или поддержки пользовательских перекрасок.
Гараж с выбором автобусов и возможностью их модифицирования
Bus Driver Simulator обзавёлся поддержкой многих популярных рулей и контроллеров, а также вышел (правда в несколько урезанном виде) на консолях Sony PlayStation 4, Xbox One и Nintendo Switch.
Никто не предполагал, что начавшаяся как одна не очень значительная инди-игра в нашей карьере, станет флагманской на целых пять лет. Это был сложный проект, на котором мы учились и росли.
От Bus Driver Simulator к Bus World
За прошедшее время, к сожалению, то, что мы сделали для Bus Driver Simulator, устарело. Графика, физика, интерфейс, подача происходящего, словом всё это хотелось бы сделать на более современном уровне, при этом добавить больше динамики и какую-то изюминку. Потому была начата разработка Bus World, приемника Bus Driver Simulator.
Тут стоит отметить, почему это решено было сделать уже в новой игре. В очередной раз переделывать всё это для Bus Driver Simulator уже не представлялось возможным. На то был целый ворох причин:
1. Новая концепция, в основе которой — рассказать истории о различных катастрофах и важной роли в них водителей. Фишкой Bus World хотелось сделать различные катастрофы, вроде взрыва реактора на Чернобыльской АЭС или наводнения, в условиях которых игроку и нужно будет действовать. Такая деталь, как катастрофы, довольно сильно меняют игровой процесс. Геймплей перестаёт быть таким медитативным, каким он был в Bus Driver Simulator, добавляется экшен. Мы понимали, что части игроков это придётся по вкусу, а другой части может и не совсем.
Чрезвычайно опасные торнадо Южного Китая
2. Больше упора на сельские дороги. Bus Driver Simulator — симулятор городских перевозок. Bus World во многом тоже. Но вместе с асфальтом мы изначально хотели добавить туда езду по сельским не асфальтированным дорогам, а позже добавили в игру и грязь. Фундаментально смысл игры не поменялся, а вот ощущения уже несколько другие.
Одна из неасфальтированных дорог в Bus World
3. Переход на новый рендер-движок HDRP. Очень важным фактором стал переход на новый рендер пайплайн HDRP, что серьезно повысило качество графики и немного сгладило некоторые проблемы, вроде дрожащих деталей на больших дистанциях. Однако, по ряду причин, работать с ним гораздо сложнее, чем со стандартным рендером.
Обратной стороной HDRP является повышение требований к железу. После перехода на него системные требования увеличились довольно сильно. Если бы мы перешли на новый рендер в Bus Driver Simulator, то неизбежно бы случилась неприятная ситуация, когда часть игроков со старыми компьютерами просто была бы отрезана от возможности играть дальше.
Выпуск Bus World в качестве отдельной игры не «отрежет» доступ к Bus Driver Simulator игрокам со слабыми компьютерами, а значит, они и дальше смогут спокойно играть в Bus Driver Simulator, а по мере возможностей, сделать осмысленный переход на Bus World.
Системные требования к Bus World, естественно, будут указаны на странице игры в Steam, так что игроки со слабым железом смогут заранее прикинуть, подойдёт ли им эта игра и, более того, смогут вернуть деньги за покупку, если игра им не подойдёт (возврат денег согласно политики Steam). Так что, если бы мы перешли на новую графику в Bus Driver Simulator, то это было бы просто некорректно с нашей стороны по отношению к части нашей аудитории.
В Bus World на Чернобыльской карте предстоит совершать рейсы до аварии и после неё
4. Для всех игроков (независимо от того, купили они Bus Driver Simulator или нет) стоимость игры Bus World можно сделать меньшей, чем если бы этот новый контент, над которым мы сейчас работаем и выпустим в Bus World вроде новых карт и автобусов, выпускался бы в качестве DLC к Bus Driver Simulator, так как при выпуске отдельной игры мы получаем гораздо больше внимания от блогеров, Steam, прессы.
Таким образом, привлекаются новые покупатели, а следовательно, чтобы окупить затраты на разработку нового контента не обязательно ставить такую высокую цену, как у платных дополнений, продажи которых рассчитаны только на уже имеющуюся базу игроков.
5. Подход к подаче сценариев. Мы хотели изменить подачу происходящего в игре, добавить заставки и внедрить зачатки сюжета, по-другому вести игрока по мере прохождения игры. Это, опять же, меняет ощущение от игры.
Чернобыльская карта - самая большая, которую мы когда-либо делали
6. Как ни крути, но Bus Driver Simulator — игра слишком нишевая. Пора выпускать что-то новое, с другим качеством и на более широкую аудиторию.
7. Популярность Bus Driver Simulator падает. И оно понятно, игре уже не один год.
В общем, причин для разработки новой игры накопилось достаточно. Да и в процессе разработки Bus World стала обрастать новым дополнительным функционалом.
Проблемы при разработке Bus World
Конечно, и при разработке Bus World всё оказалось крайне непросто. Например, крайне болезненным оказался переход на новый рендер HDRP для улучшения качества графики.
Езда по серпантинам требует внимания и осторожности
Изначально казалось, что переход займёт ну если ни неделю, то месяц. Но фактически он привёл нас к целому году дополнительной работы, из-за чего выход игры приходится постоянно откладывать.
Во-первых, после перехода отвалилась часть графики — пришлось переделывать.
Во-вторых, оказалось, что некоторые плагины не совместимы с новым рендером — это привело к переделыванию некоторых систем.
В-третьих, что самое ужасное, требования к железу после перехода выросли примерно в 8 раз, после чего пошли многие месяцы работы над оптимизацией игры, чтобы добиться приемлемых значений. Работа была проведена колоссальная в этом вопросе и всё ещё есть куда стремиться. В целом, это заслуживает отдельной статьи.
Реакции игроков
По большому счёту, мы привыкли к реакции обычных игроков на те или иные обновления или новости, однако иногда случались и непонятные для нас ситуации. Иногда бывало, что, казалось бы, отличную новость или обновление, смешивали с говном, следуя довольно странной логике.
Так, перед выпуском карты Окрестности Мурома, мы сообщили о том, что интегрируем в неё ту самую последнюю версию системы трафика, которую изначально делали исключительно для нашей новой игры Bus World. С одной стороны, карта Мурома была слишком большой, чтобы интегрировать туда старую систему, а с другой стороны, нам нужно было обкатать нашу новую систему на деле и то была прекрасная возможность.
Заменять систему трафика на старых картах было бы бессмысленно, так как потребовало несколько месяцев работы, которую обычные игроки в большинстве своём бы и не заметили. Но на нас вылилось много хейта за то, что мы не внедрили её на старые карты. И некоторые из игроков стали занижать рейтинг отличной карты Окрестности Мурома в Steam именно за это.
Вместе с картой "Окрестности Мурома" в игру включены новые сценарии, среди которых один новогодний
Конечно, это не единственный случай, но, возможно, самый показательный. Порой, делая что-то хорошее для игроков, можно получить. И, к сожалению, просчитать подобное иногда бывает сложно. То, что логично и очевидно для разработчиков, может быть совершенно нелогично и неочевидно для игроков.
Будет неправильно, если не упомянуть, что это может работать и в обратную сторону. Масса игроков может и восхвалить новость, которая не несёт под собой чего-то значительного.
Вместе с тем, порой некоторые игроки и неслабо помогали нам с различными вопросами: тестировали игру, давали советы по реализации чего-либо, предоставляли важную информацию и даже помогали с контентом.
Bus Driver Simulator стал таким, каким стал, во многом благодаря сообществу активных игроков. Это невозможно отрицать.
Заключение
Вот таким стал беглый взгляд на 5 лет истории наших автобусных симуляторов с позиции их разработки.
На носу выход Bus Driver Simulator: Countryside на консолях и выход Bus World в ранний доступ Steam. До этого момента остаётся уже не так много времени, и это станет новым этапом в развитии наших автобусных игр.
На сегодня это всё. Надеемся, вам было интересно почитать о нашем опыте разработки игр. А если вам интересны наши автобусные проекты, вступайте в группу VK.
Спасибо за внимание!
Немного шаманства с шейдерами в юнити
Тут фреймрейт и качество получше: http://i.imgur.com/bn7RR5d.gifv
Выбор хостинг-провайдера и сервера — почти как выбор первой машины. Только виртуальной машины. Да, ездить будет плюс-минус любая, но на какой скорости и как далеко проедет — вопрос. Разберем на примере PQ Hosting, как выбрать хостера, чтобы реже вспоминать про технические работы на сайте.
Что значит хостинг-провайдер? Любой сайт или сервис должен быть физически размещен на сервере с постоянным доступом к интернету. Предоставление такого сервера и называется хостингом.
Первое, что нужно проверить, можно ли «собрать» свою конфигурацию сервера. Обратите внимание на соотношение ядер процессора (CPU), объем оперативной памяти (RAM), тип дискового пространства (SSD или HDD) и сети.
Современные хостинг-провайдеры предоставляют два типа серверов: виртуальные и выделенные. VPS/VDS — виртуальная эмуляция сервера с гибкими настройками. Вы можете выбрать нужную мощность и емкость оборудования — и платить только за них. Оптимальный вариант для сайта небольшого интернет-магазина или компании, которая продает какие-то услуги.
А вот если у вас проект-гигант с высокой нагрузкой и посещаемостью, эмулятором не обойтись. Нужен выделенный сервер — физическая машина, на которой будет храниться ваш сервер.
Например, PQ Hosting специализируется на виртуальных VPS/VDS на твердотельных дисках NVMe. У них выше скорость обработки информации, и они подходят для проектов с большим количеством операций и частым обновление баз данных. Из других преимуществ NVMe: ему нужно меньше энергии, чем традиционному жесткому диску, накопитель работает бесшумно, не нагревается и реже выходит из строя.
Репутация хостинг-провайдера на рынке и отзывы пользователей — важные показатели его надежности. Лучше всего смотреть, что пишут про хостера, на специализированных платформах, например, hostobzor.ru или hostinghub.ru.
К слову, про репутацию: Пикабу в этом году отмечает 15-летие (вау), а PQ Hosting, который основал Иван Некулицы, скоро отпразднует шестилетие. За этого время Пикабу вошел в топ-30 самых популярных развлекательных сайтов Рунета. А PQ Hosting пополнил международный интернет-регистратор RIPE NCC, покорил 38 стран и кардинально расширил продуктовую линейку.
Где физически находятся ваши серверы и как управляется дата-центр. У многих хостинг-провайдеров нет своих дата-центров, они арендуют их у других операторов. Обратите внимание на два момента. Во-первых, какая у ЦОД сертификация — если ISO и PCI-DSS, то это гарантия соблюдения современных требований к безопасности данных. Во-вторых, когда у оператора были падения и как о них сообщали пользователям.
Для некоторых бизнесов важно разместить сервер в ЦОД в определенной стране с определенным законодательством. Чаще списки ограничиваются 10–20 странами, но некоторые хостинги предлагают на выбор до 38 вариантов для VPS/VDS-серверов: от популярных Нидерландов и Германии до более редких вроде Канады и Швейцарии. Выделенные серверы доступны в дата‑центрах в Германии, Нидерландах, Франции и США.
Одна из фишек компании PQ Hosting — собственное оборудование. Все серверы для размещения в ЦОД она закупает напрямую у производителей. Сейчас это процессоры на базе Intel Xeon и твердотельные диски NVMе с технологией защиты данных RAID 10.
Всего есть 12 фиксированных различных конфигураций от «Алюминия» (1 ядро, 1 Гбайт ОЗУ, 25 Гбайт диск) за 4,7 евро (~460 рублей) в месяц до «Обсидиана» (32 ядра, 64 Гбайт ОЗУ, 510 Гбайт диск) за 151 евро (~14 780 рублей) в месяц.
Кроме того, PQ Hosting предоставляет защиту от DDoS-атак, ежедневное резервное копирование данных и поддержка шифрования. А доступ ко всей информации будет только у людей, которым вы его откроете.
Она должна быть доступной и компетентной, чтобы оперативно решать возникающие проблемы. Особенно если речь идет об виртуальном сервере.
У PQ Hosting круглосуточная поддержка через все удобные каналы связи: телефон, электронная почта, мессенджеры. Не так давно компания запустила своего телеграм-бота для управления сервером — @PQHosting_bot. Он поможет перезагрузить или выключить сервер, заказать новый или посмотреть статус оплаты.
Еще раз перечислим преимущества:
38 стран размещения серверов в проверенных дата-центрах;
• собственное оборудование и высокая скорость передачи данных — 10 Гбит/с;
• круглосуточные администрирование, защита от DDos-атак;
• большой выбор способов оплаты и гибкая сетка тарифов.
А чтобы выбрать оптимальный тариф под свои нужны, оставьте заявку на сайте для бесплатной консультации →
Реклама ИП Некулицы, ИНН: 504816473362