rPman

Когда используешь чужой движок, то результат будет ровно таким, каким предполагает этот движок и никаким иным, хорошие движки конечно дадут вам несколько способов решения но все равно, ограничивают - это плата за удобство.

Если же вы хотите чего то странного, то добро пожаловать в написание своего.

Пример
https://www.youtube.com/watch?v=kEB11PQ9Eo8

+Normal Damage*SuperDamageMultiplier/N

если супер дамаг может быть и для крита, отдельно и его добавь

Делайте ногу из однотонных примитивов, а контур дорисовывайте уже потом по итоговому их объединению.

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

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

Благодаря наличию огромного количества качественных движков, для разработчика уже нет особой разницы 2D или 3D графика. Может быть больше нагрузка на художника, который будет подготавливать модели, ведь 2D модель можно нарисовать как обычную картинку, что несравнимо проще, а для 3D доступен только трехмерный вариант.

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

Выглядеть это будет почти натурально, зато не придется делать МОРЕ лишних движений и вычислений, особенно если вы хотите много таких танков.

Вам же ради изучения?

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

Т.е. начните с 2D-платформеров, классическое игровое поле (некая виртуальная картинка больше экрана), почитайте про спрайты.

Затем переходите к изометрии, тут простыми спрайтами не всегда можно обойтись (правда близард когда делали diablo очень неплохо соптимизировали движок), прочувствуете всю силу объема, на начальных уровнях.

Затем можете попробовать сделать простую 3D игру, это перевернет ваше представление об игре но благодаря опыту, собранному в предыдущих этапах (что такое игровой цикл например) это будет проще чем если с этого начинать

Само собой, никто не заставляет вас пилить работу с графикой самостоятельно! боже упаси, пользуйтесь возможностями современного железа.

Параллельно попробуйте сделать из вашей игры многопользовательскую, получите нехилый опыт и огромный пласт проблем, например защита от читерства (в играх с 'не полной информацией' читеры могут вытаскивать ее из памяти или сетевой коммуникации, например в стрелялках читеры видят противника сквозь стены, кстати технически от этого легко защититься, просто обычно разработчики на это закрывают глаза, по скудоумию или специально)

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

Возможно создать html5+javascript игру виде одного файла, закодировать ее в data url с base64 кодировкой, сделать из полученной строки qr-код

к сожалению в стандарте размер этого кода слишком маленький, поэтому рабочих примеров не ждите но никаких технических сложностей тут нет.

пример игр 1кб тут https://js1k.com/

Метод может быть тем же самым, которым камера определяет видимость объекта, т.е. достаточно запустить тот же самый алгоритм для каждого источника освещения (с учетом ширины луча и направленности, в т.ч. всю сферу), Само собой, есть статические объекты и динамические, в т.ч. сами источники света. Статические вообще рассчитывают на этапе генерации карты, заранее.

Отдельно строится битмап тени объекта а затем накладывается на текстуры в направлении света, на которые оно попадает. Буквально, накладывая полупрозрачные текстуры, либо если это позволяют шейдеры, догенирировать их на лету.

На этом этапе можно уменьшать детализацию тени, вместо того чтобы строить подробную проекцию объекта, можно взять его область расчета коллизии (она обычно на порядок проще и объект неплохо в нее стараются вписать)

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

Что значит не делает, графическое задание условий и алгоритма применяют в некоторых случаях, когда логика простая.

Посмотрите например на yahoo pipes.
Точно помню у майкрософта была целая студия, даже с нейронными сетями предлагают готовый графический язык.

Вот буквально недавно смотрел презентацию, даже такая узкая ниша как автоматизация торговли на биржах, stock sharp запилили опенсорс дизайнер https://stocksharp.ru/products/designer/

Нет такого 'я пишу на c++', вы пишете используя какой-то фреймворк/библиотеку/подход, используя определенные среды разработки (варианты с vim/notepad++ не рассматриваем).

Так вот, если ваш фреймворк поддерживает кросплтформенность - то да, можете. Иначе - сил на попытки истратите больше чем на саму разработку.

Еще есть вариант с использованием достижений (задания/квесты), количество выполненных - оценка для рейтинга. Можно систему рейтингов сделать зависимой (достижения могут быть выполнены только после выполнения предыдущих, можно даже сделать дерево достижений, чтобы игрок мог выбирать, чем именно заниматься)

Я не знаю, пробовали ли вы этот вариант, основанный на утверждениях:
1. полностью вся карта игрового мира изменяется не сильно
2. обычно карту можно попытаться поделить на зоны или в тупом варианте ячейки (или точнее варианты перемещения между ними), которые так же меняются очень редко и не сильно
Простейший пример: пусть зоны — просто квадратные ячейки внутри простой сетки, размер ячейки сравним со средним размером препятствия на карте.
Более сложный пример: многоугольная область поделена на зоны по границам больших препятствий, и перпендикулярно пересекающие типичные пути движения юнитов (грубо говоря магистрали их движения), такую статистику в процессе игры собрать не сложно, сложнее выбрать размер зоны, как враиант — фиксировать количество таких зон от среднего количества юнитов в игре…
Тогда из соседних ячеек пути перемещения обычно либо в обход через соседние ячейки либо через соединяющую грань между этими двумя.
Размеры ячеек должны быть подобраны таковыми, чтобы вмещать некоторое (не сильно большое) количество препятствий… десятки или сотни.

Заранее просчитываем (и постепенно обновляем по мере изменения мира, это не обязательно делать в реальном времени, хотя тогда будут возможны забавные артефакты в движениях) возможные пути перемещения между такими зонами (каждая грань — список пересекаемых зон возможными путями), а в момент, когда необходим точный путь, просчитываем его только в пределах этих ячеек, добавив в алгоритм поиск точки на грани между ячейками, ближайшей к пути (та еще задачка).

Весь путь считать не актуально, достаточно рассчитывать в пределах 1-2 ячеек вперед (по уже известным вам алгоритмам) и получать ответ, есть ли вообще возможность попасть к цели. Добавить к алгоритму пересчет пути в зависимости от игровых объектов актуальных для расчета коллизий (тут проблема — возможны ли заторы).

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

Я бы просто добавил кнопку «Пожаловаться на нецензурную лексику».

я бы показывал эту кнопку около сообщения прямо в чате, если появилось подозрение на мат. Сюда же можно добавить кнопку 'пожаловаться на спам' и т.п., дело в том, что если алгоритм не банит а только предлагает это сделать, то это развязывает руки при его разработке/обучении и позволяет сделать его лучше.