Ну все же смысл копирайта не в том, чтобы оно окупалось, смысл чтобы создавались новые произведения. А достигается это тем, что автору дают эксклюзивное право заработать. Причем не на всем и не всегда. Это компромисс. Никто не обещал, что оно окупится. Правообладатели любят ставить телегу впереди лошади. Сначала - информация свободная и для всех, это ее свойство, это то, на чем строится наша цивилизация. И только потом, в отдельных случаях, для определенных типов вещей мы даем отдельным людям специальные права, чтобы они могли зарабатывать на этом и тем самым были заинтересованы в производстве оных.
Тем не менее правообладатели так же абьюзят это во все поля. Защита смежных прав дана им для того, чтобы они пилили новые произведения и обогащали общество, а не перепаковывали сказки братьев Грим и продавали в тридорога. Одно существование патентных троллей и страйков на птичье пение говорит о том, что система работает неверно.
Так что да, человек прав - законы по защите авторских прав концептуально направлены на увеличение доступного контента (чтобы вознаграждать авторов), а не на то, чтобы ради абстрактных авторских прав мы по гроб жизни были кому то обязаны. Если владельцы авторских прав начинают действовать против общественных интересов - законы должны быть скорректированы.
Еще и как способен - фото и принтеры передают привет. Вообще не думаю, что правообладатели действительно этого бояться, скорее просто хотят срубить бабла. Все понимают, что правила в целом будут меняться, и пытаются выгнуть в свою сторону.
А зачем это WB вбивала в промте "Бэтмэн" ? Небось хотела украсть? Так то надо всех художников тогда засудить - "аппарат то есть". Кароч интересная дискуссия, где начинается и заканчивается ответственность MJ за использование образов, и почему ответственность за это не должны нести люди, публикующие эти образы. Но все идеи по поводу того, что нужно купить образ, чтобы обучаться на нем нужно пресекать на корню - иначе получается, что любой человек должен немедленно забыть про бэтмэна после прочтения комикса (а то он обучится, как выглядит Бэтмэн и сможет его нарисовать)
Сеть это всегда крайняя боль. Зато вот такая командная архитектура, при всей сложности, довольно тестопригодная - можно дешево получить и снапшоты, и тестовые последовательности, и тестировать локально, и операции тестами покрыть. Так как все детерминировано, работать будет каждый раз одинаково.
Так никто вроде и не обвинял ИИ в составлении доносов. ИИ - просто инструмент. Который будет использован для поиска. Доносы будут отправлять специально обученные люди.
Вы правы, но это ведь звучит как "нормально делай - нормально будет".
1 Детерминированность - это не имманентное свойство системы, это абстракция, ее создает программист. Одна ошибка - и ты ошибся. Конечно, если за всем следить - все будет хорошо, но чем больше мы используем сложных типов, чужих типов и т.д - тем больше шанс косяка. 2. Да, но п3 3. Да, но MS явно в документации говорит, к примеру, что реализация хеш функции - не гарантированная и использовать его как стойкий хеш, сравнивать ее между разными машинами и архитектурами нельзя, она может быть разной. Отсюда и словари для каких то типов данных могут иметь разный порядок. Это кажется несущественным, если игра под windows, но может оказаться следующая версия dot net, сборка под другую платформу, серверные функции на linux серверах - и приехали. Представьте, все идеально работает, а через пол года портируешь на Mac и ломается при каждом использовании предмета. 4. Как раз противоположный - словари нужно сравнивать по явному стейту, приводя его в нормализованное состояние. И не использовать итерацию по всем (как раз ее порядок может быть разным). У MS есть криптографические реализации для стабильной сериализации данных. Ну или OrderedDict использовать. 5. 6. 7. 8. Все так 9. Конечно, но есть и эффекты на стыке. К примеру где то полет стрелы - просто эффект, а где то симулируют полет снарядов - значит недостаточно только показывать его, частица честно должна лететь и искать коллизии. Иногда отделить одно от другого сложно. Но да, в общем случае это ошибка скорее. 10. Да. Вообще есть чисто техническая проблема - для реализации такой штуки, нужно сделать модель без зависимостей, чтобы гарантировать, что она не потащит что-то недетерминированное. И использовать в коде view - обычный рандом, а в коде модели - специальный детерминированный. Не все языки позволяют легко это сделать. Например сделать отдельную dll (assembly definition). Но даже в этом случае легко случайно импортировать что-то недетерминированное неявно или не заметить. Или наоборот - использовать детерминированный рандом в визуальной части - ты его использовал в коде 10 механик, легко перепутать. Собственно думаю пример с сакурой (сакура поэтичная была, в статье был пример про эффекты дерева, но случай вроде реальный) 11. Да. Непосвященному может показаться, что float работает хорошо и детерминированно, пока внезапно он не начнет плохо работать на прод сервере, потому что он на другой плотформы от тестового. А уж мобилки зачастую имеют просто другие реализации тех же библиотек. 12. Да, но иногда идея писать свою реализацию поиска пути и триангуляции делоне для разбиения полей может быть плохой. 13. Вычисление хеша может быть разным. Словарь использует хеш.
В общем да - часто сам себе злобный буратино, но и игры ведь сложные, и людей много разных над ними работает, и много чего под капотом неявного. Я именно сетевых РТС таких не делал, но у нас сейчас ровно такая архитектура для стейта (команды применяются локально и отправляются на сервер, где он применяет их независимо на стейт и проверяет корректность). И у нас были и проблемы со словарями, и с сериализацией и самописными хешами, и с порядком операций, и с подписками (на клиенте view часть и несколько логических подписана, а на сервере - только логические и порядок из-за этого разный). В другом проекте была проблема с точкой и запятой при передаче float по сети. Большая часть ошибок максимально тупые, но от этого не менее ошибки.
В теории - да, если действия применяют одно за другим. Если ты добавил 3 элемента в словарь А и такие же 3 элемента в словарь Б, они "как бы идентичны". Но во первых порядок операций может нарушаться, а во вторых есть скрытые параметры, которые ты не контролируешь.
Например, клиент собирает команды (отправки юнитов по клику мыши) и добавляет их в словарь/список, в конце кадра - отправляет их другим клиентам, а через Х кадров они все применяют эти команды.
Но клиент А собирает команды в свой словарь сам, один за другим. Словарь растет на ходу. Потом словарь сериализуется, отправляется по сети, десериализуется на клиенте Б. И тут элементы добавляются не так - словарь создается сразу нужно длины, у него из-за этого другой размер и конфигурация бакетов. Плюс сама сериализация/десериализация может изменить порядок, и даже добавление элемента одного за одним даст разный порядок.
Формально после операции у вас 2 одинаковых словаря, но если вы попробуете итерировать по ним - получите разные списки. Аналогично список - к примеру команды должны выполнятся от дальнего юнита к ближнему. Поэтому каждый раз когда команда попадает в список на следующий кадр - ее нужно отсортировать. Клиент А получит Клик - сортировка - клик - сортировка - клик - сортировка. Клиент Б получит - получение команды - сортировка. Все это может усугубляться сложными архитектурами, многопоточностью и т.д. Формально - ты добавил 2 объекта и они одинаковые. По факту - ты добавил их в разном порядке и хэш не будет тем же самым.
Там может быть все что угодно - случайно использовал детерминированную операцию в эффекте, а эффект не работает на Low параметрах графики. У одного игрока лист с сакуры упал, а у другого - нет - рассинхрон (реальная история) Случайно использовал недетерминированную операцию (рандом внутри) - рассинхрон. Результат сериализации/десериализации разный - рассинхрон. У нас была ошибка из-за того, что разные имплементации Unity для windows и android/ios давали разный результат сериализации float - с точкой и с запятой. Разные клиенты используют разные версии общих библиотек - рассинхрон. У тебя JIT компиляция и 2 устройства используют разные архитектуры -> разные оптимизации для хэшей -> разный порядок в словаре.
Звучит очень тупо, но только после того, как найдешь проблему.
Интересно посмотреть на показатели, но сам концепт выглядит предельно круто. Консорциум институтов при поддержке Швейцарского правительства для меня звучит априори более доверенно, чем рандомные корпорации кремниевой долины (хотя Open AI как некоммерческая организация тоже звучал раньше неплохо). Лучше побольше.
Как зависимость, которую вы настроите руками в сцен, а unity сама подставит. То есть это буквально инъекция в поля, просто с некоторыми ограничениями (SO и префабы все же не прямые аналоги объектов от Di с разным ЖЦ)
С другой стороны, используя DI мы сталкиваемся с фундаментальными ограничениями - обычно объекты нужно конструировать через DI. Иначе DI просто используется как сервис локатор. Но в Unity как минимум для View слоя есть своя система порождения и свое внедрение зависимостей (конструирование уровня из сцен / префабов / коммитов - по сути это live time система внедрения зависимостей) Соответственно они немного конфликтуют и для конструирования объектов нужны какие нибудь костыли (спец методы, спец объект на сцене, спец хуки, экстра код), которые по сути сводят на нет удобство DI
В идеале DI предназначен делать так, чтобы объект не знал, что ему нужен DI - ему просто давали его зависимости. Чем больше обвеса (атрибуты, внедрения через поля, хаки для старта в unity объектах) - тем меньше толку.
Если в итоге DI требует boiler plate чтобы работать на уровне объекта (то есть знает про DI) - проще просто засунуть service locator в SO и доставать зависимость из него - код получится проще.
Да, прямые зависимости на SO конечно кривенько и аналогия не совсем прямая. С другой стороны любая другая система зависимостей аналогично требует костылей, производительности и хаков поверх. При этом все равно сущности view уровня будут собираться через обычные SerializedField, поэтому использовать вторую систему и синхронизировать их вместе - тоже такое.
Вообще глобальное ограничение Di - это то, что ты неявно собираешь всю иерархию не через new, но через DI, иначе это по факту ServiceLocator Но в Unity уже и так есть свои костыли для порождения игровых объектов и компонентов и хорошие средства для работы с ними.
Ну это инструмент. Думаю игру типа BAR или Supreme Commander просто не сделать иначе.
Но проблем с этим действительно много и без хороших инструментов дебага это очень больно разбирать.
С другой стороны, если правильно организовать, можно дешево делать записи симуляций и воспроизводить места с проблемами - запись игры будет всего лишь списком примененных команд от всех игроков. Можно получить срез любого состояния в любое время. В теории
Для небольших проектов без мультиплеера стоит рассмотреть очень простую альтернативу - Unity сам по себе довольно мощный DI контейнер, который сам резолвит зависимости между компонентами, префабами и ScriptableObjects. Это конечно не вся палитра инструментов, но в целом можно использовать SO как глобальные сервисы (Это основное, зачем людям нужны зависимости).
Титаническая работа. Я - разработчик игр, и с трудом представляю, какой объем терпения и упорства нужен, чтобы так дебажить чужой код. Респект.
Что касается архитектуры - это на самом деле типичное решение для стратегий, хотя прежде всего для реалтаймовых (хотя пошаговым тоже никто не запретит так делать)
Это основано прежде всего на том, что состояние игры слишком комплексное, поэтому его просто дорого передавать по сети. Банально играть будет очень болезненно, потому что развертывание состояния будет сравнимо с загрузкой сейва (ну не всего, там еще графика и ассеты грузятся). Для РТС это вообще невозможно - сеть захлебнется передать состояние 10000 юнитов (а такие стратегии есть).
Поэтому вместо отправки состояния его считают локально и оно детерминировано, а синхронизируют лишь команды от игроков - в кадр номер A выбрать юниты в области от XY 1 до XY 2, отправить в точку XY 3. Если одинаковые команды применяются детерминировано на состояние, то оно остается синхронным. Для проверки, что состояния не разошлись, можно отправлять вместе с командами хеш состояния и сравнивать. Таким образом через сеть требуется отправлять только ваши клики мышкой и нагрузка на сеть зависит только от CPM. Изящная архитектура, но накладывает серьезные ограничения на логику. Помимо приведенных вами кейсов (sort, random, словари) типичная проблема так же разная реализация float и тригонометрии на разных архитектурах. Поэтому часто используют целочисленную арифметику, в том же StarCraft используется разбиение пространства на полигоны, но с целочисленными координатами.
Ну все же смысл копирайта не в том, чтобы оно окупалось, смысл чтобы создавались новые произведения.
А достигается это тем, что автору дают эксклюзивное право заработать. Причем не на всем и не всегда. Это компромисс.
Никто не обещал, что оно окупится.
Правообладатели любят ставить телегу впереди лошади.
Сначала - информация свободная и для всех, это ее свойство, это то, на чем строится наша цивилизация.
И только потом, в отдельных случаях, для определенных типов вещей мы даем отдельным людям специальные права, чтобы они могли зарабатывать на этом и тем самым были заинтересованы в производстве оных.
Тем не менее правообладатели так же абьюзят это во все поля.
Защита смежных прав дана им для того, чтобы они пилили новые произведения и обогащали общество, а не перепаковывали сказки братьев Грим и продавали в тридорога. Одно существование патентных троллей и страйков на птичье пение говорит о том, что система работает неверно.
Так что да, человек прав - законы по защите авторских прав концептуально направлены на увеличение доступного контента (чтобы вознаграждать авторов), а не на то, чтобы ради абстрактных авторских прав мы по гроб жизни были кому то обязаны.
Если владельцы авторских прав начинают действовать против общественных интересов - законы должны быть скорректированы.
Еще и как способен - фото и принтеры передают привет.
Вообще не думаю, что правообладатели действительно этого бояться, скорее просто хотят срубить бабла. Все понимают, что правила в целом будут меняться, и пытаются выгнуть в свою сторону.
А зачем это WB вбивала в промте "Бэтмэн" ?
Небось хотела украсть?
Так то надо всех художников тогда засудить - "аппарат то есть".
Кароч интересная дискуссия, где начинается и заканчивается ответственность MJ за использование образов, и почему ответственность за это не должны нести люди, публикующие эти образы.
Но все идеи по поводу того, что нужно купить образ, чтобы обучаться на нем нужно пресекать на корню - иначе получается, что любой человек должен немедленно забыть про бэтмэна после прочтения комикса (а то он обучится, как выглядит Бэтмэн и сможет его нарисовать)
Сеть это всегда крайняя боль.
Зато вот такая командная архитектура, при всей сложности, довольно тестопригодная - можно дешево получить и снапшоты, и тестовые последовательности, и тестировать локально, и операции тестами покрыть.
Так как все детерминировано, работать будет каждый раз одинаково.
Доверили - это все же проактивное действие.
Но говорят именно так, да
Да, в расследовании крайне важно не выйти на самого себя
Нас ждет очередной упадок дизайна, эка невидаль
Так никто вроде и не обвинял ИИ в составлении доносов.
ИИ - просто инструмент. Который будет использован для поиска.
Доносы будут отправлять специально обученные люди.
Уважать =/= верить.
Кивать многие будут, но в реальности даже сарай не доверят.
Вы правы, но это ведь звучит как "нормально делай - нормально будет".
1 Детерминированность - это не имманентное свойство системы, это абстракция, ее создает программист. Одна ошибка - и ты ошибся.
Конечно, если за всем следить - все будет хорошо, но чем больше мы используем сложных типов, чужих типов и т.д - тем больше шанс косяка.
2. Да, но п3
3. Да, но MS явно в документации говорит, к примеру, что реализация хеш функции - не гарантированная и использовать его как стойкий хеш, сравнивать ее между разными машинами и архитектурами нельзя, она может быть разной. Отсюда и словари для каких то типов данных могут иметь разный порядок. Это кажется несущественным, если игра под windows, но может оказаться следующая версия dot net, сборка под другую платформу, серверные функции на linux серверах - и приехали. Представьте, все идеально работает, а через пол года портируешь на Mac и ломается при каждом использовании предмета.
4. Как раз противоположный - словари нужно сравнивать по явному стейту, приводя его в нормализованное состояние. И не использовать итерацию по всем (как раз ее порядок может быть разным). У MS есть криптографические реализации для стабильной сериализации данных. Ну или OrderedDict использовать.
5. 6. 7. 8. Все так
9. Конечно, но есть и эффекты на стыке. К примеру где то полет стрелы - просто эффект, а где то симулируют полет снарядов - значит недостаточно только показывать его, частица честно должна лететь и искать коллизии. Иногда отделить одно от другого сложно. Но да, в общем случае это ошибка скорее.
10. Да.
Вообще есть чисто техническая проблема - для реализации такой штуки, нужно сделать модель без зависимостей, чтобы гарантировать, что она не потащит что-то недетерминированное. И использовать в коде view - обычный рандом, а в коде модели - специальный детерминированный. Не все языки позволяют легко это сделать. Например сделать отдельную dll (assembly definition). Но даже в этом случае легко случайно импортировать что-то недетерминированное неявно или не заметить. Или наоборот - использовать детерминированный рандом в визуальной части - ты его использовал в коде 10 механик, легко перепутать. Собственно думаю пример с сакурой (сакура поэтичная была, в статье был пример про эффекты дерева, но случай вроде реальный)
11. Да. Непосвященному может показаться, что float работает хорошо и детерминированно, пока внезапно он не начнет плохо работать на прод сервере, потому что он на другой плотформы от тестового. А уж мобилки зачастую имеют просто другие реализации тех же библиотек.
12. Да, но иногда идея писать свою реализацию поиска пути и триангуляции делоне для разбиения полей может быть плохой.
13. Вычисление хеша может быть разным. Словарь использует хеш.
В общем да - часто сам себе злобный буратино, но и игры ведь сложные, и людей много разных над ними работает, и много чего под капотом неявного.
Я именно сетевых РТС таких не делал, но у нас сейчас ровно такая архитектура для стейта (команды применяются локально и отправляются на сервер, где он применяет их независимо на стейт и проверяет корректность).
И у нас были и проблемы со словарями, и с сериализацией и самописными хешами, и с порядком операций, и с подписками (на клиенте view часть и несколько логических подписана, а на сервере - только логические и порядок из-за этого разный).
В другом проекте была проблема с точкой и запятой при передаче float по сети.
Большая часть ошибок максимально тупые, но от этого не менее ошибки.
В теории - да, если действия применяют одно за другим.
Если ты добавил 3 элемента в словарь А и такие же 3 элемента в словарь Б, они "как бы идентичны".
Но во первых порядок операций может нарушаться, а во вторых есть скрытые параметры, которые ты не контролируешь.
Например, клиент собирает команды (отправки юнитов по клику мыши) и добавляет их в словарь/список, в конце кадра - отправляет их другим клиентам, а через Х кадров они все применяют эти команды.
Но клиент А собирает команды в свой словарь сам, один за другим. Словарь растет на ходу.
Потом словарь сериализуется, отправляется по сети, десериализуется на клиенте Б.
И тут элементы добавляются не так - словарь создается сразу нужно длины, у него из-за этого другой размер и конфигурация бакетов. Плюс сама сериализация/десериализация может изменить порядок, и даже добавление элемента одного за одним даст разный порядок.
Формально после операции у вас 2 одинаковых словаря, но если вы попробуете итерировать по ним - получите разные списки.
Аналогично список - к примеру команды должны выполнятся от дальнего юнита к ближнему. Поэтому каждый раз когда команда попадает в список на следующий кадр - ее нужно отсортировать. Клиент А получит Клик - сортировка - клик - сортировка - клик - сортировка. Клиент Б получит - получение команды - сортировка.
Все это может усугубляться сложными архитектурами, многопоточностью и т.д.
Формально - ты добавил 2 объекта и они одинаковые. По факту - ты добавил их в разном порядке и хэш не будет тем же самым.
Там может быть все что угодно - случайно использовал детерминированную операцию в эффекте, а эффект не работает на Low параметрах графики.
У одного игрока лист с сакуры упал, а у другого - нет - рассинхрон (реальная история)
Случайно использовал недетерминированную операцию (рандом внутри) - рассинхрон.
Результат сериализации/десериализации разный - рассинхрон.
У нас была ошибка из-за того, что разные имплементации Unity для windows и android/ios давали разный результат сериализации float - с точкой и с запятой.
Разные клиенты используют разные версии общих библиотек - рассинхрон.
У тебя JIT компиляция и 2 устройства используют разные архитектуры -> разные оптимизации для хэшей -> разный порядок в словаре.
Звучит очень тупо, но только после того, как найдешь проблему.
Интересно посмотреть на показатели, но сам концепт выглядит предельно круто.
Консорциум институтов при поддержке Швейцарского правительства для меня звучит априори более доверенно, чем рандомные корпорации кремниевой долины (хотя Open AI как некоммерческая организация тоже звучал раньше неплохо).
Лучше побольше.
Как зависимость, которую вы настроите руками в сцен, а unity сама подставит.
То есть это буквально инъекция в поля, просто с некоторыми ограничениями (SO и префабы все же не прямые аналоги объектов от Di с разным ЖЦ)
С другой стороны, используя DI мы сталкиваемся с фундаментальными ограничениями - обычно объекты нужно конструировать через DI. Иначе DI просто используется как сервис локатор.
Но в Unity как минимум для View слоя есть своя система порождения и свое внедрение зависимостей (конструирование уровня из сцен / префабов / коммитов - по сути это live time система внедрения зависимостей)
Соответственно они немного конфликтуют и для конструирования объектов нужны какие нибудь костыли (спец методы, спец объект на сцене, спец хуки, экстра код), которые по сути сводят на нет удобство DI
В идеале DI предназначен делать так, чтобы объект не знал, что ему нужен DI - ему просто давали его зависимости. Чем больше обвеса (атрибуты, внедрения через поля, хаки для старта в unity объектах) - тем меньше толку.
Если в итоге DI требует boiler plate чтобы работать на уровне объекта (то есть знает про DI) - проще просто засунуть service locator в SO и доставать зависимость из него - код получится проще.
Да, прямые зависимости на SO конечно кривенько и аналогия не совсем прямая.
С другой стороны любая другая система зависимостей аналогично требует костылей, производительности и хаков поверх.
При этом все равно сущности view уровня будут собираться через обычные SerializedField, поэтому использовать вторую систему и синхронизировать их вместе - тоже такое.
Вообще глобальное ограничение Di - это то, что ты неявно собираешь всю иерархию не через new, но через DI, иначе это по факту ServiceLocator
Но в Unity уже и так есть свои костыли для порождения игровых объектов и компонентов и хорошие средства для работы с ними.
Ну это инструмент.
Думаю игру типа BAR или Supreme Commander просто не сделать иначе.
Но проблем с этим действительно много и без хороших инструментов дебага это очень больно разбирать.
С другой стороны, если правильно организовать, можно дешево делать записи симуляций и воспроизводить места с проблемами - запись игры будет всего лишь списком примененных команд от всех игроков.
Можно получить срез любого состояния в любое время.
В теории
Для небольших проектов без мультиплеера стоит рассмотреть очень простую альтернативу - Unity сам по себе довольно мощный DI контейнер, который сам резолвит зависимости между компонентами, префабами и ScriptableObjects. Это конечно не вся палитра инструментов, но в целом можно использовать SO как глобальные сервисы (Это основное, зачем людям нужны зависимости).
Так внутренние попяченные ДНС сервера так же могут резолвить com адреса, в чем проблема?
Эта проблема уже по сути решена через нац систему доменных имен.
Просто будут резолвится такие адреса, какие нужно.
Титаническая работа.
Я - разработчик игр, и с трудом представляю, какой объем терпения и упорства нужен, чтобы так дебажить чужой код. Респект.
Что касается архитектуры - это на самом деле типичное решение для стратегий, хотя прежде всего для реалтаймовых (хотя пошаговым тоже никто не запретит так делать)
Это основано прежде всего на том, что состояние игры слишком комплексное, поэтому его просто дорого передавать по сети. Банально играть будет очень болезненно, потому что развертывание состояния будет сравнимо с загрузкой сейва (ну не всего, там еще графика и ассеты грузятся).
Для РТС это вообще невозможно - сеть захлебнется передать состояние 10000 юнитов (а такие стратегии есть).
Поэтому вместо отправки состояния его считают локально и оно детерминировано, а синхронизируют лишь команды от игроков - в кадр номер A выбрать юниты в области от XY 1 до XY 2, отправить в точку XY 3. Если одинаковые команды применяются детерминировано на состояние, то оно остается синхронным. Для проверки, что состояния не разошлись, можно отправлять вместе с командами хеш состояния и сравнивать.
Таким образом через сеть требуется отправлять только ваши клики мышкой и нагрузка на сеть зависит только от CPM.
Изящная архитектура, но накладывает серьезные ограничения на логику.
Помимо приведенных вами кейсов (sort, random, словари) типичная проблема так же разная реализация float и тригонометрии на разных архитектурах. Поэтому часто используют целочисленную арифметику, в том же StarCraft используется разбиение пространства на полигоны, но с целочисленными координатами.
Дебажить - одно удовольствие.