Как создать игру мечты, опубликовать её и не умереть в процессе. (комментарии) (6 стр)

Рико
> Программисты и бухгалтера летать не могут.
Любой человек вообще летать не может.

122
> Что же ты так.
Два главных движках современности (самописные и никому не интересные говнодвижки не считаем) - UE4 и Юнити. UE4 - блюпринт. Юнити версия 2019.3 анонсировали свой блюпринт.
Девиз - "ни одной строчки кода".
Десять лет и о программистах в индигеймдеве никто не вспомнит.
Я помню времена когда на программистов на геймдев.ру молились. Фраза "Я пишу свой движок" звучала примерно так как " Я увидел бога".
Сейчас она вызывает смех.
Десять лет. Встретимся через десять лет. На том же месте.

Rikk
Rikk
> Любой человек вообще летать не может.
Ты не в теме. Поверь  многие умеют летать. Но не программисты и бухгалтера.

Рико
> самописные и никому не интересные говнодвижки не считаем
Рико
> в геймдеве я тупее лавки в старом дворе застроенном хрущёвками
Цитата из соседней темы.
И вот эта лавка решает, какие движки нужны.
Дожили.

> Десять лет. Встретимся через десять лет. На том же месте.
Ты уж сам определись.
Ты нуб ничего не понимающий в гд или ты суперпрофи способный к прогнозам на 10 лет.

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

видимо вы правы.
я недавно хотел создать тему и спросить совета у опытных людей как поступитт с триггерами в юнити: у меня в игре будет много интерактивных объектов: двери, шкафы, столы, стойки серверов, замки дверей, разный лут и т.д. иными словами в сцене видимо потребуется не одна сотня сферических триггеров (видимо как самых экономичных по вычислениям), поэтому встал вопрос скрипта, который активирует эти триггеры в определённом радиусе от игрока. При выходе из триггера он автоматически отключается.
потом думаю дай ка попробую предварительно просто кинуть на сцену много триггеров разом, и я накопипастил из 30 рядов по 40 шт, т.е. 1200 нульобъектов.
Ну и надобность в теме отпала, потому что никакой оптимизации даже не требуется - различия в нагрузке процессора мне выявить не удалось, хотя у меня древний серверный xeon 4 ядра/8потоков. Так что когда то на кр580 процессоре я считал такты (самые дешёвые команды были по 4 такта, самая длинная - 18, как щас помню обмен двух байтов между ВС и стеком) , а сейчас этим не заморачиваюсь вовсе)

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

nonamezerox
> То же и с кинематографом и литературой, оказалось что голого ядра драматических
> ситуаций разработки времен античности оформленного в визуальный ряд вполне
> достаточно для массовой публики.
На самом деле, оказалось ещё и то, что хавчик формирует вкусы.

Рико
> Я помню времена когда на программистов на геймдев.ру молились. Фраза "Я пишу
> свой движок" звучала примерно так как " Я увидел бога".
> Сейчас она вызывает смех.
> Десять лет. Встретимся через десять лет. На том же месте.

В Стиме доля UE & Unity по-моему была меньше 50%.
Конечно для мобильных игр там этих движков больше но там и игры очень примитивные.

MSA2
> Ну и надобность в теме отпала, потому что никакой оптимизации даже не требуется

Это только для ПК, ноутбуков, сейчас работает, в мобилках без оптимизации никуда.

harbinger
Это понятно. Но я пока не планирую делать игру под мобилы, жанр не тот. Для пк бы добить, остальное видно будет.

harbinger
> в мобилках без оптимизации никуда.
Тем более важно понимать, где нужно оптимизировать, а где - исправлять ошибки.

Рико
> Два главных движках современности (самописные и никому не интересные
> говнодвижки не считаем) - UE4 и Юнити. UE4 - блюпринт. Юнити версия 2019.3
> анонсировали свой блюпринт.
> Девиз - "ни одной строчки кода".
> Десять лет и о программистах в индигеймдеве никто не вспомнит.
> Я помню времена когда на программистов на геймдев.ру молились. Фраза "Я пишу
> свой движок" звучала примерно так как " Я увидел бога".
> Сейчас она вызывает смех.
> Десять лет. Встретимся через десять лет. На том же месте.
Интересная теория,вот только смысл строить стены,когда фундамент гнилой,это как-то.
Если копнуть глубже,идея сама по себе может и не плохая,но надо понимать,что все не так просто. Допустим какие-то типичные продукты,для которых подходит полноценно блупринты и обеспечивают возможность сделать полноценную игру с этим оно подойдет,а что вы будете делать,если идея не стандартная,если без колхоза вы в принципе не можете нормально реализовать игру,что тогда? Пойдете на УЕ4,в котором даже для прототипа надо команду полноценную,а не 1,5 барана,которые только из ассетов собирать умеют. В данном случае все барахло,написанное школотой кривыми руками на коленке из ассетов вы пытаетесь сравнивать с нормальными играми,которые делают грамотные люди,а не стадо балбесов. Да и я такое слышал много раз,в 2020 году обещали летающие машины и много еще чего,а где оно? В розовых мечтах? Реальность все равно отличается. Да и юнити,в котором даже их продвинутые демки делают,когда сами разрабы для своих же демок мало того,что используют 33 тонны костылей на кв метр,так еще и из своего же инстументария используют аж пару функций,а все остальное из левых модификаций.Ну да,ведь это самый умный подход и отлично подходит для всех,а в большей степени для тупой школоты,которая ничего кроме ассетов собирать не умеет. В любом случае как бы вы не поливали самопальные движки они все равно не вымрут до тех пор,пора доступные на рынке аналоги не будут достаточно гибки во всех моментах,в которых они используются. Я не спорю,что свой движок и работа на нем - это не проще вариант,вероятнее он выйдет сложнее и дороже,но опять же,в вопросе времени надо учитывать и вопрос реализации и качества продукта,а не только время. Есть вагон ситуаций,когда колхоз на юнити займет куда больше времени на реализацию,чем самопальный движок,остальное же зависит от такого кол-ва факторов,которые даже статистическими погрешностями сравнивать смысла нет.К слову на УЕ4 много что можно блупринтами сделать,но это не значит,что только на них делают или будут делать. Есть масса вещей,где код удобнее и нагляднее. А каким образом вы представляете реализацию технических моментов через блупринты - я даже не представляю. И тем более не представляю программиста,который не пошлет вас на *вырезано цензурой*,когда вы предложите технические моменты блупринтами писать.
П.С. Все же не надо забывать,что блупринты создавались не для того,чтобы их использовали везде и во всем,а совсем для другого. Настраивать материалы - пожалуйста. Блупринт в этом плане удобнее. Но технические вещи делать через блупринт - это просто маразм. В больших системах мало того,что хрен что поймешь,да еще и в случае ошибок будешь до посинения искать.

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

Rikk
> поезд на воздушной подушке и катер
И что в этом нового? АВП лохматые уже давным давно,да и магни ж/д технически никаких новых идей не несет. К тому же учитывая положительные стороны надо бы про отрицательные тоже не забывать.
Rikk
> а я представляю но это супер секрет и никому не выдам
Чтож,очень рад за вас. А я вот не представляю,что найдется хоть один человек с опытом и достаточной квалификацией,который будет заниматься подобным маразмом. Даже если считать,что блупринты заведомо проще,это не меняет того факта,что технические моменты на нем реализовывать будет тупо неудобно. Опять же,я не говорю,что это невозможно,но я слабо понимаю,насколько надо быть извращенцем,чтобы такое делать. В итоге это только для баранов и школоты,разработчики с опытом такой ерудной заниматься не будут.
Rikk
> дальше будешь списывать уроки
Ага,то есть клепать клоны и шлак. Как остроумно. Видите ли,проблема в том,что зачастую качественные игры несут в себе потенциально новую идею,с новыми реализациями,которые еще не использовали.А в этом вы что копировать будете?
П.С. Вы походу не понимаете,почему это тупо. А все достаточно просто. Видите ли,нельзя временные рамки считать только в одну сторону. По идее блупринты проще и требуют меньшей квалификации,вот только реализация сложных систем на блупринтах тем,у кого квалификация низкая мало того,что займет дофига времени,будет глючной тормозной и вообще не факт,что будет работать. А теперь вопрос - если брать все это для расчета максимальной производительности труда и быстрой разработки - не очевидным вариантом окажется написание технически сложного кода не на блупринте,а чистым кодом,который мало того,что нормальным специалистом будет написан в разы быстрее,гарантированно будет работать,будет возможность нормального тестирования и отладки. Блупринты хорошо подходят для простых систем,где все достаточно наглядно и прозрачно,для сложных это дело в большинстве случаев станет такой кашей,в которой даже написавший хрен что разберет. Про отладку даже говорить не буду,нет ничего более бестолкового,чем блупринты при отладке.
П.П.С Для конвеерного шлака,с шаблонной идеей и левыми ассетами такое дело прокатит,вот только это совсем не то,к чему следовало бы стремиться. Мало что ли утиля на рынок выходит?