Делают галоши на заводе. Игры разрабатывает команда разработчиков, включая офис-менеджеров.
Сопромат никак не поможет программированию. От дизайнера требуется формальная логика, которую только программист сможет перевести в строгую логику, учитывая все варианты и тех. ограничения.
Доверять писать код дизайнерам, тем более бизнесс-логику - это безумие. Cкрипты давно устарели.
Дизайнеры даже теперь диздоки не пишут - ибо бесполезно, результат все равно непредсказуем.
Обычно сначала разрабатывается технология, делается прототип, вычисляются сроки. Показываем множество вариантов, они уже по ним разрабатывают оптимальное решение. Поэтапно изменяя прототип по фидбеку по каждой детали.
Потом дается прототип с множеством параметров, чтобы провести точную настройку. У всех дизайнеров супер-способность крутить "крутилки", не понимая их функцию, получая красоту.
А от том как работает вся игра никто не знает, кроме QA.
Но это все касается исключительно разработки. На производстве и поддержке никто вам не даст время на ресерч. Там свои особенности и инструменты.
Сортировка на gpu, различные сортирвки для отрисовки прозрачки, и не зависячищие от порядка, всякие аналоги-ZBuffer, быстрейшая сортировка для целочисленных массивов, сортировка для балансировки kd-деревьев, сортировка pointcloud для автоматического лодирования, стохастическая сортировка.
В основном это эвристические алгоритмы, так как они самые быстрые, но они не универсальны. И их просто так не реализовать, нужно дорабатывать под конкретные задачи и являются объединением сразу нескольких алгоритмов.
Лучший алгоритм сортировка - это отсутствие необходимости сортировать.
Есть разработка, а есть производство. Учить алгоритмы - означает возможность хотя бы прочитать научный пейпер со сложнейшей математики и реализовать его. А не зубрить алгоритмы сортировок - вы обязаны по-умолчанию их знать и уметь применять и создавать свои собственные.
Разработка - это итерационный поиск нового оптимального решения, где нужно реализовать сразу множество решений и выбрать лучшее.
Произвоство - это реализация оптимального решения и поддержка его. У производства есть четкие сроки.
Это две разные области со своими задачами и технологиями.
Утверждать что разработка не нужна, придумывать ничего не нужно, и так сойдет, и что все можно собрать из готовых решений - такое может сказать только кодер вообще без опыта
Разработка нового решения почти всегда выгоднее использования готовый решений, из-за специфики программирования.
Это работает только в математике с равномерным распределением с полным независемостью бросков. В хаотическом мире, вероятность что количество решек выпадет такое же количество что и орлов = 0.
А вероятности критической серии провалов и побед - стремится к нулю по нормальному распределению.
Сам процесс кидание влияет на распределение вероятности и будет сильная зависимость от начальных условий и среды.
При это, если бросать достаточно долго, монетки начнут давать те же результаты, из-за гиперцикла.
В казино вероятность тоже зависима от результата. Чем больше автомат проиграл, тем меньше шанс на следующий выигрышь.
Сама вероятность не предсказывает будущее, от нее не зависит поведение монетки, и это не физическая величина
Зачем что-то выдумывать? В Data-driven все тесты примитивны их даже можно автоматически генерировать, логика уже отделена, и есть верификации с транкзациями.
Ну так DateDriven и sharedLogic пришли как раз из веба. Вся логика в на беке - и будет бизнес-логикой, покрытая тестами. Плюс иммутабельная база данных с транкзациями.
В sharedLogic писали сразу на js, запускали ее как на клиенте так и на беке, чтобы подтвердить транкзакции. Крайне надежное и красивое решение. SharedLogic пишется в процедурном стиле и без асинхронщины.
Проблема там только, что не всегда получится отделить логику, которая завязана на View.
Задача программиста - в поиске локального минимума колмогоровская сложности системы, в том числе чтобы уместить миллионы строк в голову. Делается это по-сути с помощью оптимизации графа во время декомпозиции, а для этого есть только эвристический алгоритмы.
Для поиска оптимального решения, нужно сделать сразу несколько решений:
1) С минимальным изменением кода и с костылями. Такие решения допустимы во время хотфиксов, но вещает тех.долг. На практике такое решение потребует значительно больше времени даже чем другие.
2) Идеальное решение. Решение по правилам чистого кода, без костылей с неограниченым рефакторингом и времени, либо решение согласно пейперу.
3) Гениальное решение. Решение с минимальными изменениями, после которого кода становится меньше чем было. Быстрое и простое, которое одновременное решает множество проблем.Такое решение теоритически существует всегда.
4) Ленивое решение. Решение ничего не делать, задача решиться сама собой. На удивление , это самое частое решение, если гениальные решений были до этого.
Комбинация из 4-х решений и даст оптимальное решение. Грязный код не позволит сделать 2, 3 4, в нем возможно только решение 1.
Можно выявить количественную меру сложности кода. Она зависит от количество условий, количество связей, количество мутабельных переменных.
Мера критичности зависит от вероятности регрессии багов и времени исправления.
Еще посмотреть статистику на релизе, там даже самые редкие баги выплывут с 100% вероятностью. Если разброс большой, то это проблема.
Если баг который долго чинили, через время опять переокрывается - симптом проблемы. Если исправление бага приводит к цепочки других багов - симптом катастрофы.
Так было бы удобно, можно в реальном времени смотреть проблемы кода и сколько времени эти проблемы тратят времени.
Если перенести все физические величины на натуральные значения - это бы упростила создание мат. моделей.
Но суть системы СИ и констант в другом. Например мера силы - это Ньютон. Сила зависит от массы, перемещения и времени. Масса - это кг. перемещение - это метры, время - секунды.
F = k*M^*S^*T^. Где ^ - это неизвестная степень. k - коэффициент, который находится с помощью опытов. Достаточно запомнить что ньютон = кг*м*с^-2; Это и будет неизвестной степенью. Либо можно и не запоминать, разнообразие степеней мало, как и физических величин. Можно додуматься по зависимостям, прямой или обратной. Все равно все нелинейные и степенные функции одинаковы в комплексном пространстве.
Все физические процессы и законы - это подобные степенные функции, точнее нелинейные дифференциальные уравнения высокого порядка.
Скорость и ускорение - это не физические величины, а составная мера, производные от перемещения.
Собственно так и можно придумать свою меру и единицу измерения. Физические формулы и законы не имеет смысла зубрить.
Этим методом еще проверять физичность результата. Если там корявые степени - значит было перемножены не те величины, массу нельзя умножить на метры, например. Или сравнивать теплое с мягким.
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.
А как работают архитекторы в крупных компаниях?
Они так же смотрят каждый мердж реквест и чинят сами тех.долг?
Можно выявить количественную меру сложности кода. Она зависит от количество условий, количество связей, количество мутабельных переменных.
Мера критичности зависит от вероятности регрессии багов и времени исправления.
Еще посмотреть статистику на релизе, там даже самые редкие баги выплывут с 100% вероятностью. Если разброс большой, то это проблема.
Если баг который долго чинили, через время опять переокрывается - симптом проблемы. Если исправление бага приводит к цепочки других багов - симптом катастрофы.
Так было бы удобно, можно в реальном времени смотреть проблемы кода и сколько времени эти проблемы тратят времени.
А какой-нибудь пример можно?
На практике проблем не возникает, достаточно сравнительной меры. Физических величин всего 7. И есть способы как найти главные параметры.
Те же инженеры с 3d-принтером, которые измеряют различные типы прочности. Они используют тот же метод.
Другой пример, если математику нужно измерить площадь льдины на полюсе, но он забыл линейку.
То он вводить свою меру - метр с хуем, либо локоть = k*м.
Тогда он может вычислить площадь в системе СИ. А коэффициент точно узнать, сравнив с эталоном.
Проблема только в ошибках измерения, чем меньше мера - тем больше ошибка будет накапливаться. Поэтому береговую линию не измерить.
Если перенести все физические величины на натуральные значения - это бы упростила создание мат. моделей.
Но суть системы СИ и констант в другом. Например мера силы - это Ньютон. Сила зависит от массы, перемещения и времени. Масса - это кг. перемещение - это метры, время - секунды.
F = k*M^*S^*T^. Где ^ - это неизвестная степень. k - коэффициент, который находится с помощью опытов. Достаточно запомнить что ньютон = кг*м*с^-2; Это и будет неизвестной степенью. Либо можно и не запоминать, разнообразие степеней мало, как и физических величин. Можно додуматься по зависимостям, прямой или обратной. Все равно все нелинейные и степенные функции одинаковы в комплексном пространстве.
Все физические процессы и законы - это подобные степенные функции, точнее нелинейные дифференциальные уравнения высокого порядка.
Скорость и ускорение - это не физические величины, а составная мера, производные от перемещения.
Собственно так и можно придумать свою меру и единицу измерения. Физические формулы и законы не имеет смысла зубрить.
Этим методом еще проверять физичность результата. Если там корявые степени - значит было перемножены не те величины, массу нельзя умножить на метры, например. Или сравнивать теплое с мягким.