1) графический программист не нужен при поддержке и производстве. А вот при разработке он в любом случае нужен.
2) Готовых решений для продакшена почти не существует, в любом случае придется переделывать. Обычный программист не разберется в технологиях графики.
3) Графических программистов очень мало по всему миру, и их часто нанимают целой командой для этапа разработки, так делают даже крупные компании.
4) То что учится трудно и мало инфы - тут согласен. Но уже появляются хорошие статьи.
5) Нужно учитывать что будущее за полным gpu-рендером, и нужно понимать как работает gpu. Этап перехода уже почти завершен.
6) Для графики есть ограничение - 20мс на кадр. Если нужно добавить новую фичу которая жрет 5мс, придется все старое сначала оптимизировать, чтобы влезло.
7) Игра Gollum - прекрасный пример где не наняли графического программиста. Хотя использовали "крутой" unreal5
Делают галоши на заводе. Игры разрабатывает команда разработчиков, включая офис-менеджеров.
Сопромат никак не поможет программированию. От дизайнера требуется формальная логика, которую только программист сможет перевести в строгую логику, учитывая все варианты и тех. ограничения.
Доверять писать код дизайнерам, тем более бизнесс-логику - это безумие. Cкрипты давно устарели.
Дизайнеры даже теперь диздоки не пишут - ибо бесполезно, результат все равно непредсказуем.
Обычно сначала разрабатывается технология, делается прототип, вычисляются сроки. Показываем множество вариантов, они уже по ним разрабатывают оптимальное решение. Поэтапно изменяя прототип по фидбеку по каждой детали.
Потом дается прототип с множеством параметров, чтобы провести точную настройку. У всех дизайнеров супер-способность крутить "крутилки", не понимая их функцию, получая красоту.
А от том как работает вся игра никто не знает, кроме QA.
Но это все касается исключительно разработки. На производстве и поддержке никто вам не даст время на ресерч. Там свои особенности и инструменты.
Сортировка на gpu, различные сортирвки для отрисовки прозрачки, и не зависячищие от порядка, всякие аналоги-ZBuffer, быстрейшая сортировка для целочисленных массивов, сортировка для балансировки kd-деревьев, сортировка pointcloud для автоматического лодирования, стохастическая сортировка.
В основном это эвристические алгоритмы, так как они самые быстрые, но они не универсальны. И их просто так не реализовать, нужно дорабатывать под конкретные задачи и являются объединением сразу нескольких алгоритмов.
Лучший алгоритм сортировка - это отсутствие необходимости сортировать.
Есть разработка, а есть производство. Учить алгоритмы - означает возможность хотя бы прочитать научный пейпер со сложнейшей математики и реализовать его. А не зубрить алгоритмы сортировок - вы обязаны по-умолчанию их знать и уметь применять и создавать свои собственные.
Разработка - это итерационный поиск нового оптимального решения, где нужно реализовать сразу множество решений и выбрать лучшее.
Произвоство - это реализация оптимального решения и поддержка его. У производства есть четкие сроки.
Это две разные области со своими задачами и технологиями.
Утверждать что разработка не нужна, придумывать ничего не нужно, и так сойдет, и что все можно собрать из готовых решений - такое может сказать только кодер вообще без опыта
Разработка нового решения почти всегда выгоднее использования готовый решений, из-за специфики программирования.
Это работает только в математике с равномерным распределением с полным независемостью бросков. В хаотическом мире, вероятность что количество решек выпадет такое же количество что и орлов = 0.
А вероятности критической серии провалов и побед - стремится к нулю по нормальному распределению.
Сам процесс кидание влияет на распределение вероятности и будет сильная зависимость от начальных условий и среды.
При это, если бросать достаточно долго, монетки начнут давать те же результаты, из-за гиперцикла.
В казино вероятность тоже зависима от результата. Чем больше автомат проиграл, тем меньше шанс на следующий выигрышь.
Сама вероятность не предсказывает будущее, от нее не зависит поведение монетки, и это не физическая величина
Зачем что-то выдумывать? В Data-driven все тесты примитивны их даже можно автоматически генерировать, логика уже отделена, и есть верификации с транкзациями.
Ну так DateDriven и sharedLogic пришли как раз из веба. Вся логика в на беке - и будет бизнес-логикой, покрытая тестами. Плюс иммутабельная база данных с транкзациями.
В sharedLogic писали сразу на js, запускали ее как на клиенте так и на беке, чтобы подтвердить транкзакции. Крайне надежное и красивое решение. SharedLogic пишется в процедурном стиле и без асинхронщины.
Проблема там только, что не всегда получится отделить логику, которая завязана на View.
Задача программиста - в поиске локального минимума колмогоровская сложности системы, в том числе чтобы уместить миллионы строк в голову. Делается это по-сути с помощью оптимизации графа во время декомпозиции, а для этого есть только эвристический алгоритмы.
Для поиска оптимального решения, нужно сделать сразу несколько решений:
1) С минимальным изменением кода и с костылями. Такие решения допустимы во время хотфиксов, но вещает тех.долг. На практике такое решение потребует значительно больше времени даже чем другие.
2) Идеальное решение. Решение по правилам чистого кода, без костылей с неограниченым рефакторингом и времени, либо решение согласно пейперу.
3) Гениальное решение. Решение с минимальными изменениями, после которого кода становится меньше чем было. Быстрое и простое, которое одновременное решает множество проблем.Такое решение теоритически существует всегда.
4) Ленивое решение. Решение ничего не делать, задача решиться сама собой. На удивление , это самое частое решение, если гениальные решений были до этого.
Комбинация из 4-х решений и даст оптимальное решение. Грязный код не позволит сделать 2, 3 4, в нем возможно только решение 1.
Опыт подсказывает что вы правы. Но как расширить команду? Максимум могу только 2-х менеджерить и няньчить
1) графический программист не нужен при поддержке и производстве. А вот при разработке он в любом случае нужен.
2) Готовых решений для продакшена почти не существует, в любом случае придется переделывать. Обычный программист не разберется в технологиях графики.
3) Графических программистов очень мало по всему миру, и их часто нанимают целой командой для этапа разработки, так делают даже крупные компании.
4) То что учится трудно и мало инфы - тут согласен. Но уже появляются хорошие статьи.
5) Нужно учитывать что будущее за полным gpu-рендером, и нужно понимать как работает gpu. Этап перехода уже почти завершен.
6) Для графики есть ограничение - 20мс на кадр. Если нужно добавить новую фичу которая жрет 5мс, придется все старое сначала оптимизировать, чтобы влезло.
7) Игра Gollum - прекрасный пример где не наняли графического программиста. Хотя использовали "крутой" unreal5
Полностью не согласен, как графический программист.
Лучшие статьи по динамическому хаосу. А можно побольше про синергетику и эмерджетность?
1) OpenSource
2) Полная бесплатность
3) Полное отсутствие доната и рекламы.
Противоречит ли это вашим убеждением![]()
?
Продолжительное время работал на немалькие американские компании. У них там все так работаю. Буквально платили за ничего не делание.
У вас просто не было ни разу опыта разработки и нет ни одного пет-проекта. Вы бы так не рассуждали.
Делают галоши на заводе. Игры разрабатывает команда разработчиков, включая офис-менеджеров.
Сопромат никак не поможет программированию. От дизайнера требуется формальная логика, которую только программист сможет перевести в строгую логику, учитывая все варианты и тех. ограничения.
Технические ограничения первичны дизайна.
Доверять писать код дизайнерам, тем более бизнесс-логику - это безумие. Cкрипты давно устарели.
Дизайнеры даже теперь диздоки не пишут - ибо бесполезно, результат все равно непредсказуем.
Обычно сначала разрабатывается технология, делается прототип, вычисляются сроки. Показываем множество вариантов, они уже по ним разрабатывают оптимальное решение. Поэтапно изменяя прототип по фидбеку по каждой детали.
Потом дается прототип с множеством параметров, чтобы провести точную настройку. У всех дизайнеров супер-способность крутить "крутилки", не понимая их функцию, получая красоту.
А от том как работает вся игра никто не знает, кроме QA.
Но это все касается исключительно разработки. На производстве и поддержке никто вам не даст время на ресерч. Там свои особенности и инструменты.
Уже который год перечитываю эти статьи. Насколько же они гениальны
Есть эвристика, можно просто заранее закешить важные числа, чтобы каждый раз не считать с начала.
Каждый год по одной, в среднем.
Сортировка на gpu, различные сортирвки для отрисовки прозрачки, и не зависячищие от порядка, всякие аналоги-ZBuffer, быстрейшая сортировка для целочисленных массивов, сортировка для балансировки kd-деревьев, сортировка pointcloud для автоматического лодирования, стохастическая сортировка.
В основном это эвристические алгоритмы, так как они самые быстрые, но они не универсальны. И их просто так не реализовать, нужно дорабатывать под конкретные задачи и являются объединением сразу нескольких алгоритмов.
Лучший алгоритм сортировка - это отсутствие необходимости сортировать.
Есть разработка, а есть производство. Учить алгоритмы - означает возможность хотя бы прочитать научный пейпер со сложнейшей математики и реализовать его. А не зубрить алгоритмы сортировок - вы обязаны по-умолчанию их знать и уметь применять и создавать свои собственные.
Разработка - это итерационный поиск нового оптимального решения, где нужно реализовать сразу множество решений и выбрать лучшее.
Произвоство - это реализация оптимального решения и поддержка его. У производства есть четкие сроки.
Это две разные области со своими задачами и технологиями.
Утверждать что разработка не нужна, придумывать ничего не нужно, и так сойдет, и что все можно собрать из готовых решений - такое может сказать только кодер вообще без опыта
Разработка нового решения почти всегда выгоднее использования готовый решений, из-за специфики программирования.
Это работает только в математике с равномерным распределением с полным независемостью бросков. В хаотическом мире, вероятность что количество решек выпадет такое же количество что и орлов = 0.
А вероятности критической серии провалов и побед - стремится к нулю по нормальному распределению.
Сам процесс кидание влияет на распределение вероятности и будет сильная зависимость от начальных условий и среды.
При это, если бросать достаточно долго, монетки начнут давать те же результаты, из-за гиперцикла.
В казино вероятность тоже зависима от результата. Чем больше автомат проиграл, тем меньше шанс на следующий выигрышь.
Сама вероятность не предсказывает будущее, от нее не зависит поведение монетки, и это не физическая величина
Зачем что-то выдумывать? В Data-driven все тесты примитивны их даже можно автоматически генерировать, логика уже отделена, и есть верификации с транкзациями.
Scrum - для производства, а не для разработки нового.
При разработке важна бесконечная итеративность, а результат всегда непрдсказуем.
Ну так DateDriven и sharedLogic пришли как раз из веба. Вся логика в на беке - и будет бизнес-логикой, покрытая тестами. Плюс иммутабельная база данных с транкзациями.
В sharedLogic писали сразу на js, запускали ее как на клиенте так и на беке, чтобы подтвердить транкзакции. Крайне надежное и красивое решение. SharedLogic пишется в процедурном стиле и без асинхронщины.
Проблема там только, что не всегда получится отделить логику, которая завязана на View.
Крутой результат за 10ч. Единый стиль, рутины минимум. Интересно посмотреть что будут делать с этим на gamejam.
Задача программиста - в поиске локального минимума колмогоровская сложности системы, в том числе чтобы уместить миллионы строк в голову. Делается это по-сути с помощью оптимизации графа во время декомпозиции, а для этого есть только эвристический алгоритмы.
Для поиска оптимального решения, нужно сделать сразу несколько решений:
1) С минимальным изменением кода и с костылями. Такие решения допустимы во время хотфиксов, но вещает тех.долг. На практике такое решение потребует значительно больше времени даже чем другие.
2) Идеальное решение. Решение по правилам чистого кода, без костылей с неограниченым рефакторингом и времени, либо решение согласно пейперу.
3) Гениальное решение. Решение с минимальными изменениями, после которого кода становится меньше чем было. Быстрое и простое, которое одновременное решает множество проблем.Такое решение теоритически существует всегда.
4) Ленивое решение. Решение ничего не делать, задача решиться сама собой. На удивление , это самое частое решение, если гениальные решений были до этого.
Комбинация из 4-х решений и даст оптимальное решение. Грязный код не позволит сделать 2, 3 4, в нем возможно только решение 1.
А как работают архитекторы в крупных компаниях?
Они так же смотрят каждый мердж реквест и чинят сами тех.долг?