ViGaCi

Правильно поменять палитру - это уметь надо. Были бы навыки в рисовании, не было бы смысла покупать ассеты

Работаю над игрой с графикой в стиле пиксель арт. В настройках проекта есть режим "Letterbox integer scale". Благодаря нему каждый программный пиксель соответствует отображаемому пикселю и соответствующим образом масштабируется (например, 1 программный пиксель = 3 отображаемых). Но есть у этого режима один недостаток — чёрные полоски по краям экрана. Чтобы сохранить преимущества "Letterbox integer scale" и сделать адаптивный экран, предпринял следующие шаги: В настройках проекта ставим: Fullscreen mode > Scale out Добавляем плагин Platform Info Добавляем переменную, которая будет модификатором масштабирования Переходим в события: On start of layout и устанавливаем значение модификатора PlatformInfo.CanvasDeviceHeight / (высоту области просмотра, она же ViewportHeight) И заключительное действие ниже: Set layout scale to (1 / (модификатор) × floor(модификатор)) И получаем Pixel Perfect графику с адаптивным разрешением экрана.

А вот представьте какой нибудь условный Скайрим, в котором есть языковая модель + генератор голоса. И загрузить каждому NPC знания об игровом мире, истории, действиях персонажа игрока и тому подобное. Вместо заскриптованных диалогов с прописанными заранее вариантами ответа игрок своим голосом общается с NPC и получает от него голосовой ответ. Это же просто... какой-то совершенно другой уровень погружения в игровой процесс.

Вау)) Чаще всего встречается обратная ситуация, т.е. клиент разработчику даётся проще, чем сервер. Я вот как раз один из таких разработчиков. Очень завидую людям, которые умеют кодить сервер для многопользовательских игр. Кстати, у меня вопрос: какую роль в этой игре будет играть клиент — только отображение того что рассчитывает сервер или часть игры будет обрабатываться клиентом и отправляться на сервер? Если второе, тогда как защитить игру от читеров? Ну то есть, что делать если игрок с помощью дополнительных программ будет менять, например, характеристики кораблей? P.S.: по описанию очень крутой проект! Желаю только не выгореть в процессе разработки))

Задача выше, действительно, несложная. Просто для примера её привёл. Хотя даже в этом случае ИИ должен представлять как работает календарь, чтобы дать верный ответ. По идее же ведь ChatGPT это всего лишь языковая модель, которая предугадывает, какое слово должно быть написано следующим. Эдакий T9 на стероидах. И как ему удаётся решать логические задачи — вот уж вопрос.

А меня вот больше всего впечатляет как ChatGPT может решать задачи на логику. Причём, именно те задачи, которые придумываю я сам. Ну то есть, подсмотреть готовый ответ ИИ не может по определению. Ну вот к примеру: Событие Б произошло на 40 день после того, как случилось событие А. Событие А произошло 12 марта. Когда произошло событие Б? Чтобы решать подобные задачи ИИ должен иметь хотя бы элементарную картину мира. И он справляется с этими задачами на ура.

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

Подсмотрел в своё время эту логику в игре Art of War 3. Долгое время думал, как такое можно реализовать на Construct 2/3. Сначала пробовал сделать всё чисто на массивах. Получалось "грязно", с большим количеством событий и сложной логикой. Потом как-то случайно наткнулся на howtoconstruct на плагин "EasyStar.js". С его помощью удалось реализовать всё то же самое, только в пару событий.

Отдельного канала для видео с наработками по играм на Construct 3 у меня нет. Видео выкладываю только для уроков на этом форуме. *** Хотел бы спросить у читателей дневника по созданию RTS — что именно для вас представляет наибольшую ценность: описание алгоритмов со скринами событий исходники с примерами реализации механик видео демонстрацией прогресса разработки информация по геймдизайну Если вы следите за разработкой — пожалуйста, напишите своё мнение. Так я смогу понять, чему следует уделять больше внимания.

СТРОИТЕЛЬСТВО теория и реализация Все постройки в RTS стратегиях можно разделить на несколько основных типов: административные (добыча ресурсов и обслуживание зданий) производственные (производство юнитов) оборонительные (защита базы) Есть два разных способа строительства: строительный юнит (здания можно строить в любом месте карты, куда только сможет добраться строительный юнит). зона строительства (здания строятся автоматически, но строительство возможно только в определённом радиусе от штаба или других зданий). Разработка В игру добавлены здания: штаб (главное здание) завод (производит юниты) экстрактор (производит минералы, которые расходуются на строительство зданий и производство юнитов) электростанция (производит энергию, которая расходуется на обслуживание зданий и содержание юнитов) турель (защитная постройка, атакует вражеских юнитов) Здания бывают разных размеров: 3x3 клетки (Штаб, Завод) 2x2 клетки (Электростанция, Экстрактор) 1x1 клетки (Турель) Механика строительства: игрок нажимает на кнопку "построить здание" выбирает одну из предложенных в списке построек размещает постройку в зоне строительства подтверждает строительство здание строится в течении некоторого времени Чтобы построить здание, необходимо: достаточное количество ресурсов постройка должно находится в зоне строительства количество зданий этого типа не должно превышать лимит (зависит от уровня штаба) Зона строительства Штаб и Электростанция формируют вокруг себя зону строительства если ячейка находится на клетке с препятствием / тумане войны / клетку занял юнит, то такая клетка исключается из зоны строительства здания нельзя строить рядом друг с другом (тайлы вокруг зданий тоже исключаются из зоны строительства)

Реализация интересная, но есть нюанс. Получается, что по диагонали танк видит дальше, чем по прямой: Радиус обзора ведь неспроста называют радиусом: Есть более простой вариант реализации тумана войны, чем тот, который я описал в дневнике. Это туман войны, реализованный с помощью спрайтов и банального сравнения дистанции этих спрайтов по отношению к юнитам. Но огромный минус такой реализации в том, что мы получаем огромное количество объектов, которые при большом количестве юнитов (мы же всё таки про RTS говорим) будут оказывать чудовищное влияние на производительность. Fog (don't use).c3p

ГЕЙМДИЗАЙН ресурсы Настало время поговорить про геймдизайн. В классических RTS стратегиях существует несколько основных механик, связанных с ресурсами. Рассмотрим каждую из них. Age of Empires В игре существуют рабочие юниты, которые занимаются добычей ресурсов и строительством построек. Существует несколько видов ресурсов: пища (единственный возобновляемый ресурс; используется для найма юнитов, в первую очередь рабочих). древесина (очень доступный и распространённый ресурс). камень (очень востребован на поздних стадиях игры для строительства замков и укреплений). золото (используется в том числе на рынке для обмена на другие ресурсы). Различные комбинации вышеперечисленных ресурсов используются как для строительства и улучшения зданий, так и для подготовки юнитов. Самые жаркие бои проходят, как правило, за контроль над залежами камня и золота. Command & Conquer В игре есть один единственный ресурс, который используется сразу для всего (строительства и найма юнитов). Ресурсы добываются специальными юнитами из расположенных на карте источников. После добычи юниты несут ресурсы на базу, после чего их уже можно использовать. Постройки можно строить в небольшом радиусе от других построек базы. Для работы зданий необходима электроэнергия, которая производится в электростанциях. Игрок может намерено атаковать электростанции противника, чтобы отключить защитные постройки или саботировать производство юнитов. Total Annihilation В игре существуют два вида ресурсов: металл (используется для строительства зданий и производства юнитов). энергия (используется для обслуживания зданий и содержания юнитов). Ресурсы неисчерпаемы, их добыча происходит непрерывно при наличии соответствующих строений и не требует никаких юнитов, производящих доставку ресурсов в хранилища. Металл добывается после строительства экстрактора на соответствующем месторождении ресурса. Металл также можно добывать, создавая его из энергии с помощью преобразователей энергии в металл. Минус в том, что на конвертацию энергии в металл расходуется колоссальное количество энергии. Энергия добывается с помощью солнечных батарей, ветряных генераторов, приливных генераторов (их можно размещать только в воде), геотермальных станций (их можно размещать только на термальных отверстиях), термоядерных реакторов. Эффективность ветряных генераторов и приливных генераторов зависит от особенности местности: так, на одной карте ветров может и не быть, а на другой они очень сильные. Похожая ситуация и с приливами. Новые идеи Слепо копировать чужие механики — не очень хорошая идея. Каждому разработчику хочется привнести в жанр что-то своё, чтобы вдохнуть новую жизнь в классические игровые механики. И я здесь не исключение. Чего мне (как игроку) больше всего не хватает в классических RTS стратегиях, так это цепочек производства. Я говорю про такую механику, где у игрока один завод производит боеприпасы, другой делает стволы для танков и артиллерии, а третий собирает готовую технику из тех модулей, которые имеются в данный момент на складах. На данный момент эта идея находится на стадии обдумывания. Для начала необходимо реализовать набор хотя бы базовых построек, который встречается в любой RTS игре, но об этом речь пойдёт уже в следующем уроке.

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

ТУМАН ВОЙНЫ В стратегических играх сбор информации о противнике является важной частью геймплея. Туман войны — очень распространённая в RTS механика, смысл которой состоит в дом, чтобы симулировать обстановку на поле боя в ходе реальной войны. Когда нет (и быть не может) всей полноты информации и нужно принимать решения, исходя из имеющихся данных. Туман войны бывает двух видов: статичный динамичный Статичный туман полностью непрозрачный. Он рассеивается по мере того, как юниты игрока приближаются к границам тумана. Такой туман симулирует битву на неизвестной местности, когда первым делом необходимо исследовать карту. Динамичный туман полупрозрачный. Он накрывает собой всю карту, куда не дотягивает радиус обзора ваших юнитов и зданий. Такой туман симулирует военные операции на тактическом уровне, когда известна карта местности, но неизвестны точные данные о местонахождении подразделений противника, его огневых позиций и т.д. Чтобы не попасть в засаду или окружение необходимо постоянно проводить разведку. Разработка Для юнитов добавлена переменная Vision, которая обозначает дальность видимости (в клетках) каждого конкретного юнита. Туман войны реализован с помощью тайлмапа и массива, в котором при помощи волнового алгоритма рассчитывается, какие клетки тайлмапа следует очистить, в соответствии с местоположением каждого юнита на карте и дальностью его обзора. При старте игры происходит вызов функции, которая используя волновой алгоритм заполняет массив числами (+14 очков за диагональные тайлы, +10 за все остальные). В дальнейшем этот отдельный массив используется как база данных для определения того, какие тайлы вокруг юнита нужно очистить, а какие оставить (в зависимости от дальности обзора). Вызов функции обновления тумана войны (т.е. тайлмапа) происходит в тот момент, когда юнит игрока перемещается с одной клетки на другую. Поскольку цикл внутри функции может стать «тяжёлым» (например, в процессе движения больших групп юнитов) я ограничил частоту вызова функции при помощи таймера на 0.25 сек. Это полезно делать в тех случаях, когда речь идёт о визуальных изменениях, коими являются такие механики как туман войны. Игрок разницу в такой задержке вряд ли увидит, но вот для производительности разница ощутимая.

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