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

День добрый.

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

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

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

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

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

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

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




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

Небольшое видео про обновление.
Уже совсем скоро...
vk.com/adventureinequestria

Тезисы, ссылки, планы

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


Читать дальше →

Vote pls steamcommunity.com/sharedfiles/filedetails/?id=766510803 — 78 место в топе.

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

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


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

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

Всем привет.
Хорошие новости.
Мы попали в топ 100 в Steam Greenlight.
Если еще кто-то не поддержал, прошу поддержать) Всем спасибо :3

steamcommunity.com/sharedfiles/filedetails/?id=766510803
vk.com/adventureinponyland