XGM.guru предоставляет обширные ресурсы для разработчиков игр: инструменты, модели, текстуры и руководства для платформ как Unreal, Unity, Godot. Это идеальное место для обмена знаниями и опытом, участия в проектах и вдохновения на новые идеи. Присоединяйтесь к нашему сообществу и вносите свой вклад в мир разработки игр, повышая свои профессиональные навыки и находя новые возможности для творчества.
Некоторые люди меня знают, как ярого противника идеи, что маркетинг играет определяющую роль в успехе игры. И на минутку, я маркетолог с 10-летним опытом, в том числе с опытом выпуска новых и успешных продуктов на рынок.
Инди разработчик ищет ответ на главный вопрос: "Что нужно сделать, чтобы мою игру покупали хорошо?". А эксперты прибегут и скажут: "маркетинг, вот что тебе нужно".
Странные эксперты. Обычно эксперты говорят, что если игра плохая, то ей никакой маркетинг не поможет
Джун, владеющий теорией хорошо знает, что код надо писать расширяемым, что нужно соблюдать читаемость, паттерны, не допускать ботлнеков. Но сеньор вам сразу скажет, что джун этого не достигнет. И причина проста - недостаток опыта.
Ну или не для программистов: любой начинающий художник с хорошей базой академической вам расскажет, что такое светотень, колористика, перспектива, но его работы все ещё сосут и ответ снова в очевидном - опыт.
На мой вкус дурацкие аналогии. Как это вообще вытекает из этого "Ваши игры проваливаются не потому что вы плохо их рекламируете, а потому что они сделаны непродаваемыми"? Сова на глобусе.
Джуны сплошь говно штампуют, а сеньоры онли хиты? Угу...
Будет ли он предварительно изучать рынок, анализировать тренды и пытаться попасть в целевую аудиторию или слепо пойдет делать игру для себя. Результат будет приблизительно одинаковым.
Все зависит от критериев оценивания результата. Можно условно не заработать на игре ничего, но получить ключевой опыт для будущих проектов или аудиторию.
PUVer, только ты забываешь маленькую деталь, большое внимание - это ещё и большая ответственность и планка ожиданий. Допустить факап для именитых студий - это иногда равно смерти, поэтому такой репутационный маркетинг ещё и работает на повышение планки качестве
Не так давно наткнулся на такой подход программирования в играх как ECS (Entity Component System). Далее начал читать статьи и смотреть различные ролики по этой теме. Из названия понятно что это разделение на сущности, компоненты и системы. Но почему он становится более предпочтительным в разработке игр нежели всем…
Делаю свой текущий проект на ECS (Entitas), и честно говоря, какого-то дичайшего восторга не испытываю. Концепция, безусловно, интересная. При работе с огромным количеством юнитов - даже незаменимая. Однако на маленьких масштабах я бы не сказал, что прям супер полезная.
Одна из фишек - одна и та же сущность может одновременно быть несколькими разными объектами, потому что набор висящих на ней компонентов будет по-разному интерпретироваться разными системами. Но мне, по факту использования, эта фишка пока особо не пригождалась.
Лично мне в душу запахло именно структурирование кода - разбиение его на маленькие системки, и их последовательный вызов. Да, системки вот прям маленькие - не больше 50 строк, а в среднем - вообще по 20-30 строчек.
KaneThaumaturge, используя jass/vJass я из синтаксиса языка максимум массивами пользовался. Статью писать лень, а тут темы появились и решил так кратко пройтись
KaneThaumaturge, как я понял, идея в том чтоб убрать автоматику из жтого вашего ООП и вручную более оптимально ложить структурированные данные в память.
Разве это не то как реализовано ООП в vJass? Там как раз instance структуры это всего лишь индентификатор к массивам.
Я вот не совсем представляю ECS для использования с БД, получается каждое обращение к компоненту сущности это новый запрос в БД? Ну мб я че-то не понял. Мало инфы как-то, ссылки я видел, но пост будто бы ни о чем. Перенос бы уже информацию сюда и структурировал.
GAMEDEV
Комментарии проекта Game Dev
Выбор редакции
Вот почему маркетинг не спасёт вашу инди игру
Джуны сплошь говно штампуют, а сеньоры онли хиты? Угу...
Entity Component System (ECS)
Одна из фишек - одна и та же сущность может одновременно быть несколькими разными объектами, потому что набор висящих на ней компонентов будет по-разному интерпретироваться разными системами. Но мне, по факту использования, эта фишка пока особо не пригождалась.
Лично мне в душу запахло именно структурирование кода - разбиение его на маленькие системки, и их последовательный вызов. Да, системки вот прям маленькие - не больше 50 строк, а в среднем - вообще по 20-30 строчек.