Gamedev is Friendship!

+387.51
170 читателей, 35 постов

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

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

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

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

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

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

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

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

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

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




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

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

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

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


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

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