+387.51
176 читателей, 37 постов

Урезанное обновление Adventure in Equestria

+80
в блоге Gamedev is Friendship!
Долгожданная «Урезанная» обнова.

Пишите, что думаете, что добавить? Многого не ожидайте, ибо урезанная.

Ссылка на игру

В игре так же появилась функция посмотреть предыдущие диалоги:
Чтобы посмотреть покрутите колесико вверх;
Чтобы закрыть колесико вниз.
Группа VK: vk.com/adventureinequestria
Тизер обновления

"Объясняю кажду строчку" разработка игры (не о пони) в прямом эфире.

Дорогие табунчане, я открыл своё шоу на ютубе. Где буду пару раз в неделю стримить то, как я делаю игру. Нет, не про пони. Для этого мои руки слишком кривые. Я уже и так много о нём написал в последнее время, так что просто дам ссылки.
Канал на ютубе
Статья на DTF, где я рассказываю во всех подробностях
Весь код буду выкладывать на гитхаб
А согласовывать и обсуждать всё будем на дискорд-сервере
Ссылка на мою статью о той штуке, на которой я буду писать
Чёрную метель я допишу, не бойтесь

Генератор спрайтов-примитивов (заглушек) для понных и иных игр

+167
в блоге Gamedev is Friendship!
День добрый.

Увидев на Табуне очередной пост о том, что для разработки игры страсть как необходим художник, я впал в задумчивость, подобно зависшей Свити Белль, о судьбах Родины начинающего разработчика игр.
Выйдя из задумчивости, я за пару новогодних дней склепал на C# эту утилиту.

sys.tereshenkov.ru/cgi-bin/pic2sprite/pic2sprite.sh

и разместил её у себя на сервере, сделав доступной для всех желающих.

В чём смысл затеи?
Утилита принимает картинку (с ПК или ссылкой), анализирует цвета и генерирует спрайт заданного типа (квадрат, круг и т.д.) с цветовым распределением, соответствующим исходной картинке.

Зачем это чудо мысли нужно?
Вот сел человек делать игру — глаза горят, руки рвутся делать набигающие домики и грабежи корованов — а спрайтов нет. Он либо начинает рисовать сам, тратя драгоценное время, либо дергает спрайты из Яндекс.Картинок (что в итоге даёт разнородные наборы по стилю и форме, и сильно портит вид игры), либо создаёт пост поиска художника, не имея еще рабочего прототипа игры, и соответственно, не имея базу для привлечения художника.
Используя же данный инструмент — автор сможет, на основе найденных где-то картинок, сделать пусть примитивные, но узнаваемые и однотипные спрайты нужного размера, наполнить ими свой проект и уже показывать публике что-то с чем-то, а не просто «нарисуйте мне, поззя».

Смотреть примеры применения на основе поней→

Haze and Blaze – Понячий Low-Poly Слэшер [Тех. Пре-Альфа]

+71
в блоге Gamedev is Friendship!
«Пора», – решил я пару дней назад. Починил несколько багов, что лежали на поверхности, подкрутил тайминги и теперь выкладываю на ваш суд свои труды четырех последних месяцев.




Читать Дальше...

Геймдевовских вопросов псто...

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

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


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

Пишется на С++, хотя сомневаюсь, что это будет актуально.

А вопросы вот такие.1) у каждого объекта есть состояние, которое отвечает за то, что объект делает. Некоторые состояния, скажем, удар или применение вещи, требуют анимации. Как лучше сделать связь необходимого момента анимации и действия?
2) на данный момент «применение» вещей реализовано через создание при нажатии клавиши невидимого объекта-применятеля, который при обсчете прикосновений что-то делает, например, вызывает диалог. Адекватно ли такое решение?
3) точно так же, адекватно ли решение для нанесения урона в драке создавать невидимый ранящий объект?
4) каким образом лучше реализовать скриптовую систему? На данный момент идея состоит в том, что у каждого объекта будет таблица [триггер — действие], которая будет опрашиваться каждый такт. Триггер — некое условие, скажем, нажатие клавиши или истечение определенного времени на истекающем таймере. Действие — некая команда. Основной вопрос возникает в моментах, где необходимо использовать множественные условия — непонятно, как это лучше обрабатывать. Хранить условия в строках и парсить строку?
5) есть ли какой-то способ разнести логику системы обработки касаний? То есть, на данный момент ей требуется у каждого объекта узнать его роль и, сопоставляя эти роли, решать, что будет дальше. В таком раскладе функция обработки разрастется до гигантских размеров. Как это можно логично упростить?