Как бы да, "нормально делай - нормально будет". Просто хочется копнуть и разобраться на шаг поглубже, понять чем именно те или иные концепции ущербны и выяснить что деталями реализации, а не концепциями.
Просто в какой-то момент (например, при мультиплатформе), понимаешь, что float-операции это тоже внешняя реализация и приходится делать свою, на int-ах, но не отказываться от неё совсем. Так же как и хэш и словари - если внешнее решение имеет расхождения - пора их анализировать и может быть переходить на своё.
Я так-то больше на десктопе работаю, в Делфи (то же самое что Плюсы, только помногословнее). Поэтому для меня иметь свою реализацию словаря это нечто само-собой разумеющееся и легко выполнимое. А дальше я тащу его на Мак или Линукс/Андройд и он работает идентично. Проблемы со внешними зависимостями от внешних факторов обычно (xml сериализатор вот системный использовали, пока не погорели с ним и перешли на "свой" попроще). А так, да, много чего сам писал в образовательных целях, и поиски пути, и Делоне, и Венгерский, и генетику, и всяко-разное. Самостоятельно посчитать хэш - тоже не так сложно, тем более сейчас, в эпоху LLM.
Тонну косяков на отладке тоже собрал, конечно. Хорошо помогает инструментарий, TDD и автоматизация. Например симулировать час игры, а потом его реплей и сверять на идентичность, и так 50 раз. Или иметь пару сотен игровых тестов. Пока вот только к мультиплеер-тестам не придумал как подступиться - заводить отдельного Overseer-а и им рулить пачкой псевдо-игроков ..
Попробую разобраться по шагам. (спойлер, многоплатформенность не упоминается до пункта 11).
Не уверен, как именно в детерменированном мире порядок операций может нарушаться. Только что если какая-то многопоточность участвует, но тогда она и так всё поломает из-за конкурентности (или сделет всё в разы сложнее).
Если мы собираем команды в словарь у игрока А, а потом его разматываем в список, чтобы этот список снова положить в словарь только у игрока Б, то тут да, мы сами себе злобные Буратины, т.к. операции (собрать-всписок-выполнить у А, и собрать-всписок-передать-собрать-всписок-выполнить у Б) получаются не тождествены.
Однако, если операции делать идентично, то непонятно откуда тут возьмется недетерминированность, т.к. и размер бакета и хэш-метод одинаковые и детерминированные. Де-сериализация идентична если её выполнять у всех идентично.
Вывод, словари нельзя сравнивать просто по составу элементов. У словаря больше внутреннего состояния. Его тоже надо сравнивать для настоящей одинаковости.
Получение команд в список и их выполнение кусками у А и передача к Б для выполнения пачкой - опять же косяк подхода и стабильность сортировки тут не при чем и ситуацию не спасет. Всё банально сведется к тому, что А обработает отсортированных юнитов кусками типа [2,7]+[8]+[1,3], а Б обработает точно так же отсортированных всех [1,2,3,7,8].
Сложность архитектур не нарушает детерминированности, если только в ней не замешаны недетерминированные элементы, или не нарушена идентичность симуляций у клиентов.
Многопоточность - это да, тут надо прям осторожно со словарями и вообще (но если учесть пункт 4 то всё ок). Но тогда и корнем сложностей надо называть её, а не сортировки и словари.
Кстати, стабильность сортировки тут не поможет, она же всего лишь гарантирует неизменность порядка элементов от начального, а не то, что "одинаковые" элементы будут отсортированы идентично. Тут тогда компаратор надо докручивать.
Графику надо отделять от логики, это практически первая заповедь. В идеале, игра должна работать вообще без дисплея (что, кстати, открывает отличные просторы для автотестов, тренировки ИИ и прочих симуляций. Люто рекомендую).
Про лист сакуры - красиво. Я тоже такие проблемы ловил )) Но это всё же скорее личные заслуги того кто это накосячил )))
Мультиплатформенность это проблема. Обычно из-за тонкостей реализации IEEE-754, 8087CW, и всякой тривиальщины типа настроек локали (разделителя разрядов по умолчанию итп). Но крови попьёт немало.
Внешние библиотеки надо применять только для общения с внешним миром (сеть, звук, инпут, графика, итп). Игровая логика должна быть от них отделена строго-настрого. Кстати да, мы тоже горели на том, что например использовали Виндовую "умную" сортировку имен в списках вместо своей.
Jit и словари, вот тут похоже на корень проблемы, но опять же он в разных реализациях, а не в словаре как таковом.
Получается, что внутренние проблемы как обычно в нарушении идентичности из-за некоторых промахов архитектуры (выполнять кусками vs выполнять пачкой), в выполнении чего-то с привязкой к графике/звуку итп. А внешние - в неподконтрольных разнородных библиотеках и различиях их реализаций. Условно, но если использовать внешние Sin/Cos, то и на них можно погореть. Словари из библиотек лишь пример того, что на разных платформах может нередко работать по разному (а сортировки как-бы совсем не при делах). Будете носить с собой свой словарь - будет идентичен. Так же и с int вместо float.
В общем интересная тема, такое лучше за пивом обсуждать.
У нас основные проблемы с синхронизацией были от того, что не все действия игрока (инпуты) проходили через планировщик. Некоторые действия могли применяться в зависимости от состояния тумана войны, без учета того что туман у игрока А другой нежели у игрока Б. OpenAL нам жизнь попортил, оказывается он иногда втихаря переставлял флаги 8087CW и округление начинало работать по разному на разных клиентах. Иногда, конечно, и random портил всё, когда по ошибке вызывали его, а не игровой детерминированный рандом. Но у нас RTS. Как можно столько косяков оставить в TBS мне сложно представить ..
Как разработчик RTS, хотел бы уточнить, а чем именно проблематична нестабильная сортировка и словари в разрезе С/С++ и детерминированности? Вроде как и то и другое сортирует и раскладывает по бакетам всё равно детерминировано (только нестабильно), там же нету random внутри, или есть какой-то изъян?
Плохо продумать можно всё что угодно, тут не поспоришь )) Есть общепринятые подходы, обмен инпутами это один из них, еще со времен изобретения мультиплеера в RTS :-)
Собственно только эти читы (посмотреть что делает соперник) и возможны при параллельной симуляции. Нельзя добавить себе ни 20 танков, ни неубиваемого юнита, ни бесконечные ходы юниту, ни отстроеный город, ни исследования, ни плодородных земель, ничего такого.
Главные фишки подхода - автоматическая устойчивость к читам, "бесплатные" реплеи и малый объем передаваемой информации между игроками. Запилить его совсем не проще, чем сохранять всю игру и перекидывать каждый ход между игроками.
А логика, вероятно, не отличается потому, что просто DRY. Как ни крути, но после получения инпута (локально или по сети) и состояния (если бы перекидывали сейвы), симуляция одинаковая.
Похоже что вы правы. Несмотря на реверанс в эту сторону упомянутый в FAQ. Во всех остальных случаях в тексте Соглашения, действительно, многократно повторяется про совокупный доход.
Лучше конечно проконсультироваться с вендором, но по идее, 5000$ это касается именно доходов от использования программ написанных на Delphi CE, а не в целом.
То есть пока условный продавец Пятерочки пользуется Delphi CE только для своих проектов и имеет с них менее 5000$ в год - всё ок. Как только он получает с них более 5000$, или вдруг начинает использовать их в своей работе для блага Пятерочки - CE больше не положена.
У Delphi был ряд действительно не самых удачных версий с разнообразными глюками как IDE, так и, что хуже, компилятора. Я поэтому пережидал на проверенных XE5, XE8. Сейчас вот и 11 и 12 достаточно стабильные.
LSP, конечно, по прежнему глючит, Ctrl+Space тоже иногда отваливается, и компилятор почти всегда не в состоянии скомпилировать проект с первого раза, но на качество работы и сборки это влияет не столь сильно - полный ребилд за 20сек не так страшен.
Но вообще подумываю, что пора дробить проект на части (DLL или BPL), т.к. 500к строк кода Делфу явно нагружают больше, чем ей хотелось бы.
Помню его, он еще Delphi MVP был когда-то (а может и сейчас им всё еще является). Давно не общались.
В будущем надеюсь Knights Province продавать, чтобы отбить хоть какие-то расходы, так что не опенсорс. Сейчас есть страничка на Стиме, но она скорее как плейсхолдер. Всё никак не доходят руки перевести игру в Early Access. Последние лет 10 просто выкладываю мажорные сборки на сайт, а минорные в Дискорде и Реддите.
В 2008 на Delphi начали писать ремейк движка умирающей игры Knights and Merchants. Добавили мультиплеер и редактор карт и еще кучу всего. Проект и игра до сих пор живы - KaM Remake. Исходники есть на гитхабе.
В 2013 форкнул свой проект на движке и перешел в 3D. До сих пор пишу по 1-2 тысячи коммитов в год. Долгострой - Knights Province.
Полагаю, что ваше рац.предложение приследует какаую-то другую цель, отличную от цели РКН
тогда и от "сервера" придется избавляться :-)
Отличный ответ, спасибо!
Как бы да, "нормально делай - нормально будет". Просто хочется копнуть и разобраться на шаг поглубже, понять чем именно те или иные концепции ущербны и выяснить что деталями реализации, а не концепциями.
Просто в какой-то момент (например, при мультиплатформе), понимаешь, что float-операции это тоже внешняя реализация и приходится делать свою, на int-ах, но не отказываться от неё совсем. Так же как и хэш и словари - если внешнее решение имеет расхождения - пора их анализировать и может быть переходить на своё.
Я так-то больше на десктопе работаю, в Делфи (то же самое что Плюсы, только помногословнее). Поэтому для меня иметь свою реализацию словаря это нечто само-собой разумеющееся и легко выполнимое. А дальше я тащу его на Мак или Линукс/Андройд и он работает идентично. Проблемы со внешними зависимостями от внешних факторов обычно (xml сериализатор вот системный использовали, пока не погорели с ним и перешли на "свой" попроще). А так, да, много чего сам писал в образовательных целях, и поиски пути, и Делоне, и Венгерский, и генетику, и всяко-разное. Самостоятельно посчитать хэш - тоже не так сложно, тем более сейчас, в эпоху LLM.
Тонну косяков на отладке тоже собрал, конечно. Хорошо помогает инструментарий, TDD и автоматизация. Например симулировать час игры, а потом его реплей и сверять на идентичность, и так 50 раз. Или иметь пару сотен игровых тестов. Пока вот только к мультиплеер-тестам не придумал как подступиться - заводить отдельного Overseer-а и им рулить пачкой псевдо-игроков ..
Спасибо за развернутый ответ!
Попробую разобраться по шагам. (спойлер, многоплатформенность не упоминается до пункта 11).
Не уверен, как именно в детерменированном мире порядок операций может нарушаться. Только что если какая-то многопоточность участвует, но тогда она и так всё поломает из-за конкурентности (или сделет всё в разы сложнее).
Если мы собираем команды в словарь у игрока А, а потом его разматываем в список, чтобы этот список снова положить в словарь только у игрока Б, то тут да, мы сами себе злобные Буратины, т.к. операции (собрать-всписок-выполнить у А, и собрать-всписок-передать-собрать-всписок-выполнить у Б) получаются не тождествены.
Однако, если операции делать идентично, то непонятно откуда тут возьмется недетерминированность, т.к. и размер бакета и хэш-метод одинаковые и детерминированные. Де-сериализация идентична если её выполнять у всех идентично.
Вывод, словари нельзя сравнивать просто по составу элементов. У словаря больше внутреннего состояния. Его тоже надо сравнивать для настоящей одинаковости.
Получение команд в список и их выполнение кусками у А и передача к Б для выполнения пачкой - опять же косяк подхода и стабильность сортировки тут не при чем и ситуацию не спасет. Всё банально сведется к тому, что А обработает отсортированных юнитов кусками типа [2,7]+[8]+[1,3], а Б обработает точно так же отсортированных всех [1,2,3,7,8].
Сложность архитектур не нарушает детерминированности, если только в ней не замешаны недетерминированные элементы, или не нарушена идентичность симуляций у клиентов.
Многопоточность - это да, тут надо прям осторожно со словарями и вообще (но если учесть пункт 4 то всё ок). Но тогда и корнем сложностей надо называть её, а не сортировки и словари.
Кстати, стабильность сортировки тут не поможет, она же всего лишь гарантирует неизменность порядка элементов от начального, а не то, что "одинаковые" элементы будут отсортированы идентично. Тут тогда компаратор надо докручивать.
Графику надо отделять от логики, это практически первая заповедь. В идеале, игра должна работать вообще без дисплея (что, кстати, открывает отличные просторы для автотестов, тренировки ИИ и прочих симуляций. Люто рекомендую).
Про лист сакуры - красиво. Я тоже такие проблемы ловил )) Но это всё же скорее личные заслуги того кто это накосячил )))
Мультиплатформенность это проблема. Обычно из-за тонкостей реализации IEEE-754, 8087CW, и всякой тривиальщины типа настроек локали (разделителя разрядов по умолчанию итп). Но крови попьёт немало.
Внешние библиотеки надо применять только для общения с внешним миром (сеть, звук, инпут, графика, итп). Игровая логика должна быть от них отделена строго-настрого. Кстати да, мы тоже горели на том, что например использовали Виндовую "умную" сортировку имен в списках вместо своей.
Jit и словари, вот тут похоже на корень проблемы, но опять же он в разных реализациях, а не в словаре как таковом.
Получается, что внутренние проблемы как обычно в нарушении идентичности из-за некоторых промахов архитектуры (выполнять кусками vs выполнять пачкой), в выполнении чего-то с привязкой к графике/звуку итп. А внешние - в неподконтрольных разнородных библиотеках и различиях их реализаций. Условно, но если использовать внешние Sin/Cos, то и на них можно погореть. Словари из библиотек лишь пример того, что на разных платформах может нередко работать по разному (а сортировки как-бы совсем не при делах). Будете носить с собой свой словарь - будет идентичен. Так же и с int вместо float.
В общем интересная тема, такое лучше за пивом обсуждать.
У нас основные проблемы с синхронизацией были от того, что не все действия игрока (инпуты) проходили через планировщик. Некоторые действия могли применяться в зависимости от состояния тумана войны, без учета того что туман у игрока А другой нежели у игрока Б. OpenAL нам жизнь попортил, оказывается он иногда втихаря переставлял флаги 8087CW и округление начинало работать по разному на разных клиентах. Иногда, конечно, и random портил всё, когда по ошибке вызывали его, а не игровой детерминированный рандом. Но у нас RTS. Как можно столько косяков оставить в TBS мне сложно представить ..
Как разработчик RTS, хотел бы уточнить, а чем именно проблематична нестабильная сортировка и словари в разрезе С/С++ и детерминированности? Вроде как и то и другое сортирует и раскладывает по бакетам всё равно детерминировано (только нестабильно), там же нету random внутри, или есть какой-то изъян?
Плохо продумать можно всё что угодно, тут не поспоришь ))
Есть общепринятые подходы, обмен инпутами это один из них, еще со времен изобретения мультиплеера в RTS :-)
Собственно только эти читы (посмотреть что делает соперник) и возможны при параллельной симуляции. Нельзя добавить себе ни 20 танков, ни неубиваемого юнита, ни бесконечные ходы юниту, ни отстроеный город, ни исследования, ни плодородных земель, ничего такого.
Главные фишки подхода - автоматическая устойчивость к читам, "бесплатные" реплеи и малый объем передаваемой информации между игроками. Запилить его совсем не проще, чем сохранять всю игру и перекидывать каждый ход между игроками.
А логика, вероятно, не отличается потому, что просто DRY. Как ни крути, но после получения инпута (локально или по сети) и состояния (если бы перекидывали сейвы), симуляция одинаковая.
Тесты (юнит, игровые, "сценарии" для мультиплеера) были бы отличным подспорьем, если бы команда видела стабильное будущее на 3-4 года вперед.
В Циве же есть сейвы, наверняка даже бинарные. Вот это и есть необходимая сериализация. Почистить их только от переменных игроков, и можно сравнивать.
Это, кстати, может быть нематерная отсылка к сериалу The Good Place.
Delphi "теряет популярность" уже лет 20, и всё никак не потеряет, даже вот показывает рост в TIOBE последнее время.
Тернарный оператор штука не самая нужная, конечно, но лучше когда она есть хотя бы для паритета с другими языками программирования.
Похоже что вы правы. Несмотря на реверанс в эту сторону упомянутый в FAQ. Во всех остальных случаях в тексте Соглашения, действительно, многократно повторяется про совокупный доход.
Лучше конечно проконсультироваться с вендором, но по идее, 5000$ это касается именно доходов от использования программ написанных на Delphi CE, а не в целом.
То есть пока условный продавец Пятерочки пользуется Delphi CE только для своих проектов и имеет с них менее 5000$ в год - всё ок. Как только он получает с них более 5000$, или вдруг начинает использовать их в своей работе для блага Пятерочки - CE больше не положена.
У Delphi был ряд действительно не самых удачных версий с разнообразными глюками как IDE, так и, что хуже, компилятора. Я поэтому пережидал на проверенных XE5, XE8. Сейчас вот и 11 и 12 достаточно стабильные.
LSP, конечно, по прежнему глючит, Ctrl+Space тоже иногда отваливается, и компилятор почти всегда не в состоянии скомпилировать проект с первого раза, но на качество работы и сборки это влияет не столь сильно - полный ребилд за 20сек не так страшен.
Но вообще подумываю, что пора дробить проект на части (DLL или BPL), т.к. 500к строк кода Делфу явно нагружают больше, чем ей хотелось бы.
Помню его, он еще Delphi MVP был когда-то (а может и сейчас им всё еще является). Давно не общались.
В будущем надеюсь Knights Province продавать, чтобы отбить хоть какие-то расходы, так что не опенсорс. Сейчас есть страничка на Стиме, но она скорее как плейсхолдер. Всё никак не доходят руки перевести игру в Early Access. Последние лет 10 просто выкладываю мажорные сборки на сайт, а минорные в Дискорде и Реддите.
В 2008 на Delphi начали писать ремейк движка умирающей игры Knights and Merchants. Добавили мультиплеер и редактор карт и еще кучу всего. Проект и игра до сих пор живы - KaM Remake. Исходники есть на гитхабе.
В 2013 форкнул свой проект на движке и перешел в 3D. До сих пор пишу по 1-2 тысячи коммитов в год. Долгострой - Knights Province.
"Интерфейс на Delphi к llama-server и whisper.cpp." - можете рассказать поподробнее с какими целями и что получается?
Мне кажется это больше похоже на обычную газетную верстку.