Войти
ПрограммированиеФорумОбщее

[Unity]: Готовые решения которые вы используете в своих проектах. (3 стр)

Страницы: 1 2 3
#30
16:01, 5 окт. 2017

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


#31
16:26, 5 окт. 2017

fornetjob
> Ну, для этого надо для начала хотя бы один проект сделать, а дальше уже можно
> смотреть на экономическую целесообразность рескинов
да, но каков уровень этих проектов ? если в них задействовано 1% от возможностей и потенциала - то какой смысл вылизывать текущие наработки ? особенно, если следующие проекты кроме наработок с платежками, рекламой и возможно гуи никак не связаны.
имхо отличная история у madfingergames - ребята начали с три в ряд, но каждый следующий проект был на порядок сложнее предыдущего

#32
17:01, 5 окт. 2017

greencrazycat
> если в них задействовано 1% от возможностей и потенциала - то какой смысл
> вылизывать текущие наработки
Система деплоймента, кодогенерация, сериализация, базейка, партиклы, пулинги, переводы, системы скиллов, диалогов, квестов и инвентаря, локаторы ресурсов и сервисов, генераторы этапов и волн, гуй, анимация, аналитика, игровые сервисы, куча различных сборок для показа разного рода рекламы и т.д., это всё повторяется от игры к игре, вне зависимости от типа игры. И инструменты к этому всему, а также опыт использования растёт от игры к игре.
И это только обвяз, чтобы получилась игра, помимо программистов к игре привлекаются геймдизайнеры, художники/аниматоры, сценаристы, звукорежиссёры, тестировщики. Если предполагается контент, то ещё и левел-дизайнеры.
И со всеми этими людьми тоже нужно учиться работать.

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

#33
17:09, 5 окт. 2017

fornetjob
> И инструменты к этому всему, а также опыт использования растёт от игры к игре.
также и с архитектурой - сначала хватает компонетов и КОП подхода - но со временем этого может оказаться мало

#34
17:15, 5 окт. 2017

greencrazycat
> также и с архитектурой - сначала хватает компонетов и КОП подхода - но со
> временем этого может оказаться мало
Ну да, вы работаете-работаете и тут понимаете что есть кисс, драй, ягни и солид, гоф, тдд, бдд и почему-то начинаете противопоставлять ООП и КОП?
Так то меня ещё лет 15 назад гоняли на собеседованиях по этим темам и считалось, что каждый уважающий разработчик должен это знать, а ещё закончить МФТИ, к примеру.
Геймдев от энтерпрайза в этом отношении отстаёт. Я не знаю точно, агил для геймдева в России уже прошёл или ещё не наступил.
Вообще, в энтерпрайзе, шесть лет назад набирали силу бигдаты, функциональные языки программирования, неблокирующие алгоритмы, десять тысяч операций в секунду и т.д.
В геймдеве эти задачи если и применимы, то где то на серверной части, поэтому с точки зрения 1% потенциала нужно переходить в энтерпрайз.

#35
17:33, 5 окт. 2017

fornetjob
> fornetjob
разделяй логику и визуализацию и вуаля - всё что работает в интерпрайзе можно затащить в гемдев, что часто и делают.
для гуи например по стопам ассета nData уже есть немало решений, которые позволяют принцип MVC/MVVC для гуи применить в юнити
но для программистов не знакомых с MVC/MVVC  начать работать с такими ассетами бывает довольно тяжко, "зачем мне это я же всегда могу закинуть ссылку на геймобжект ?" :) и потом в проекте появляются "супер" объекты с десятками ссылок, и в один прекрасный момент всё это сыпиться, или тупо сбрасывается при переходе на новые версии, не говоря уже о сложности сопровождения таких монстров

#36
18:00, 5 окт. 2017

greencrazycat
> MVVC
Вы имели в виду "MVVM"?

greencrazycat
> но для программистов не знакомых с MVC/MVVC  начать работать с такими ассетами
> бывает довольно тяжко, "зачем мне это я же всегда могу закинуть ссылку на
> геймобжект ?" :) и потом в проекте появляются "супер" объекты с десятками
> ссылок, и в один прекрасный момент всё это сыпиться, или тупо сбрасывается при
> переходе на новые версии, не говоря уже о сложности сопровождения таких
> монстров
Это имеет значение если мы собираемся писать авто-тесты для гуя (или требует тимлид). Если без тестов, то можно как удобно. Без опыта можно себе коленку прострелить по гораздо менее значительным поводам, чем не использование паттернов в форме с тремя контролами и двумя кнопками.

#37
18:11, 5 окт. 2017

fornetjob
> Вы имели в виду "MVVM"?
ага
fornetjob
> Это имеет значение только если мы собираемся писать авто-тесты для гуя.
не только, так можно разделять саму работу с гуи (так работа с гуи часто весьма трудозатратна)
fornetjob
> Без опыта можно себе коленку прострелить по гораздо менее значительным поводам
да - юнити хорош своей гибкостью и стрелять по ногам очень удобно - как раз одна из задач архитектуры очертить некоторые рамки для пострелушек, что бы не завалить насмерть проект :)

#38
18:20, 5 окт. 2017

greencrazycat
> как раз одна из задач архитектуры очертить некоторые рамки для пострелушек, что
> бы не завалить насмерть проект
Доведение проекта, пусть и с костылями, до завершающей стадии - вопрос достаточно рутинный, если проблемы с гуём, это максимальное что угрожает проекту.
Рамки в случае юнити выглядят забавно, где 80% кода, это ассеты и сборки сторонних производителей, рефакторинг которых попросту бессмыслен.

#39
18:36, 5 окт. 2017

fornetjob
> Доведение проекта, пусть и с костылями, до завершающей стадии - вопрос
> достаточно рутинный, если проблемы с гуём, это максимальное что угрожает
> проекту.
это во многом зависит от проекта, мне приходилось видеть проекты в продакшене - без архитектуры, без комментариев, без использования шаблонов и ситуации когда новый программист (куда же делся старый) сначала берет недели на "изучение" того что есть, затем выносит гордый вердикт - усе плохо и надо переписывать чуть ли не с 0
но фигня вопрос - проект то в продакшене, только ничего путного с ним никто сделать не может (или не хочет), а заказчику так не надо и он жаждет увидеть новый функционал еще вчера, у гемдиза горят глаза и чешутся руки - все на подъеме и только программисты нервно икают - пытаясь при крутить очередной костыль и не уронив при этом старые костыли :)
fornetjob
> Рамки в случае юнити выглядят забавно, где 80% кода, это ассеты и сборки
> сторонних производителей, рефакторинг которых попросту бессмыслен.
это да - но если брать работу например с профилем игрока в сетевой игре (покупки, апгрейды, абилки, айчивки, аварды и прочие а...) - то тут имеет смысл задуматься всё ли можно решить компонентами и КОП

#40
20:45, 5 окт. 2017

greencrazycat
> это во многом зависит от проекта, мне приходилось видеть проекты в продакшене -
> без архитектуры, без комментариев, без использования шаблонов

Уменьшение затрат на образование -> падение уровня образование -> индусокод

Но вообще, если уж отклонились от темы, то не пойму один момент.
Геймдев стал проще софта?

Страницы: 1 2 3
ПрограммированиеФорумОбщее

Тема в архиве.