вот о чем подумал: может пытаться вкатываться в уже занятые ниши действительно не стоит, а стоит попробовать себя в чем-то пока экзотическом? Например сделать игру на Rust, bevy engine? Как думаете, есть перспективы в этом направлении?
Да хз, смотря чего ты вообще хочешь то На непопулярных движках меньше команд, а значит меньше работы. Вообще все движки, это просто инструменты, надо знать базу
Что входит в базу-то? Шейдеры, физика, геймплей? Команду можно попробовать и свою собрать, пока естественно индюшатину делать. Rust - хайповый, на этом хайпе можно попытаться выехать, за счёт рекламы в тех же сообществах, краудфандинга
- game loop - построение кадра - шейдерный конвейер - основы 3д/2д графики(особенности и ограничения realtime графики) -Как устроены технически -работа с анимациями(технически, из чего они состоят ) -игровые интерфейсы(принцип работы) -ввод/вывод -работа с памятью(кеширование, сохранения/загрузка) -работа со звуком - основы оптимизации reatime графики
В целом все это представляю
Это только техничка Игра же не технодемка, нужно ещё заморочиться с геймплеем, понять как все это монетизировать и собрать все воедино, что бы цельцый продукт, а не слепленный в комок на скорую руку проект
Но это уже не задачи программиста, по крайней мере не только его
Верно, но в зависимости от задачи придется менять архитектуру проекта, а это очень больно и дорого, если изначально нет взаимопонимания между кодом, потом и геймдизайном.
Естественно. Поэтому для начала в проекте никого кроме дизайнера и кодера и не должно быть
Вот тут немного не понял. Арт добавляется в самом конце, про какое взаимопонимание идёт речь?
Я имею ввиду технические ограничения и особенности Например нужно процедурно подгружать ассеты и контент, который может по разному работать на разных платформах
И в чем тут проблема? Художник нарисует разные ассеты значит. И либо отдельные версии под каждую платформу, либо чекать и выбирать. Или я что-то неправильно понял?
Это утверждение верно, если у тебя статичные модельки на сцене и немного мешей с костями и анимациями. Но обычно в средних и больших проектах полно всякой всячины. Представь ситуацию, что есть мобильная 3д игра по сетке, где есть требование 20-30 skinned mesh рендеров мобов, которых можно рубить на кусочки(дополнительная нагрузка на физику), где также динамически генерятся кусочки уровня и в зависимости от подписки игрока может меняться визуал чего угодно на уровне+ постоянно идёт проверка с сервера не читерит ли игрок. Это лишь один примеров из моего опыта на одном проекте, где геймдизайнеры и проггеры закладывали трудозатраты только на свои задачи, не учитывая артовую часть(которая тянет за собой не малые бюджеты .ms) Привело это к тормозам и перегревам девайсов, трем месяцам переделок и трате куче бабла.
Мало нарисовать ассет, надо его упаковать во всех ипостасях, нужно ещё грамотно учитывать хранение на диске, загрузка в оперативную память, использование в рантайме, выгрузка и повторное использование или удаление.
Что мешало изначально протестировать код и физику на болванках, без арта? И выяснить максимально допустимую нагрузку?
Это как бы базовые вещи, давно уже стандартизированные, что тут может быть непонятно?
То что проекты эволюционируют и разрастаются и на втором, третьем году может придется выкручиваться как получится. Обычно это ряд комплексных факторов, идеальной разработки не существует. По крайней мере, я в таких компаниях не работал В середине разработки может случиться: - измениться руководящий состав(издатель, продюсеры, арт.дир) и их отношение к проекту - измениться финансирование - уход ключевых сотрудников - после тестов может выясниться, что игра требует серьезных доработок/изменений - может изменится контракт на разработку и придется переделывать всё(было такое, но не в игре, а в VR проекте) - проект тупа может вырасти и начать поджирать ресурсы.(мобильная игра в первый год была 300 мб и выдавала 60 ФПС, а через три года успешного запуска стала 800мб и еле выдавать 30фпс)
За 10 лет не увидел ни одного стандарта. Это может в enterprise решениях могут быть стандарты, в играх не видел. Максимум гайдлайны, носящие рекомендативный характер
Я все равно не понимаю, к чему это? Проблемы решаются по мере поступления, какой-то запас делается изначально
Ну стандарты, конечно, громко сказанул☺️ Но всё-таки, если посмотреть на игры одного класса, у всех примерно одинаково сделано
Как ты это понял? Именно технически
Может я не понимаю вопроса, но если движок читает определенные форматы, то разве это не значит, что во всех продуктах этого движка эти форматы и используются?
Дело не в форматах, а как именно сами разработчики решат распорядиться ресурсами движка и особенностями проекта
На например, если движок может читать уровни напрямую из Блендера того же, зачем мне напрягаться и придумывать велосипед? Только если оптимизация не потребуется, а это уже тесты, либо пара минут гугления по форумам
Что я просто понять-то должен, что я этого не осилю, или что?
Это ведь все от проекта зависит. Какие устройства, какие ограничения и т.д. По ним и надо смотреть
Даже расписывать не хочу Если коробки в блендере делаешь, то ок. Если персонажа загонишь через блендеровские кости и экспортер, твои коллеги, кто используют что то кроме блендера хапнут горя
Читать уровни из Блендера звучит как тот самый пример, который выстрелит автору в ногу. К тому же сильно быстрее, чем остальные варианты)
Про хруст 3.5 красноглазых знают. Хочеться левой резьбы - иди в годот
Обсуждают сегодня