Честно, не в курсе нюансов и вообще далек от C++ разработки и всего что с ней связано, но когда я туда контрибьютил, вроде как основной проблемой здесь было то, что закрытые либы (которые есть только в виде DLLей) юзают старый тулкит и поэтому ядро тоже как бы завязано на старом тулките. Ну, что-то такое, хз, может это и бред всё и просто не нашлось шарящего чела, который все это завез бы ))
Блин, а мы тут уже успели накомментить, что это всё костыли и что так вообще не делается )) Ну, тогда задумка, как говорится, хорошая, но реализация так себе.
К читам устойчивости нет совсем никакой, потому что ничего не запрещает:
поставить мод, который открывает всю карту, показывает все ресурсы и тд и тп
как хочешь слать какие хочешь бродкасты, их валидность практически никак не проверяется (ну, кроме базового "существует ли такой юнит", но не "может ли этот юнит ходить так далеко")
Вообще, вот сейчас, после коммента челика выше, мне кажется, что даже не стоит тут искать намеренно какие-то плюсы и причины, почему так было сделано, потому что код там действительно выглядит так, будто они на имеющуюся синглплеерную базу натягивали мультиплеер ))
Вообще, конечно, далеко не факт, что дело в одновременных/поочередных ходах. Уже просто не помню, как они там обрабатываются, поэтому не буду утверждать наверняка, но есть вероятность, что это везение, либо эффект плацебо))
Это как раньше, еще до того как поняли почему VP вылетает в мультиплеере, были всякие "туториалы как пофиксить МП", где советовали графику попроще поставить, какие-то еще там настройки в игре подкрутить, и якобы оно становится стабильней)) По факту это всё, конечно, не меняет того, что где-то в коде в логике работы "чего-то" есть реальный десинк по типу "рабочий, который установлен в автоматический режим обработки клеток, при нахождении клеток-кандидатов с одинаковым Score, выбирает из них рандомную, потому что в коде использован sort вместо stable_sort".
Но если вот обрезать функционал (оффнуть ботов, варваров, руины, конгресс и т.д.), то, конечно, шанс словить десинк явно меньше, просто потому что меньше уникальной логики будет раниться. Просто не уверен, что это относится к одновременным/поочередным ходам, потому что если логика с багом, то она все равно рассинхронит игру вне зависимости от того, в каком режиме ходов ее отранили.
А, да? Я уже просто так давно в ваниллу не играл, что уже забыл где ванилла, а где VP 🙃 Ну, вообще в VP тогда логика выглядит как-то более справедливо ))
Когда чудо строится, у тебя есть показатель "производство" в городе + кол-во уже вложенного "производства" в чудо. Каждый ход "производство" из города вкладывается в прогресс постройки чуда. Если в один ход оба игрока заканчивают одно и то же чудо, то построится оно у того, у кого было по итогу вложено больше "производства".
Например: - Игрок А строит чудо размером в 15 производства со скоростью 5 производства за ход; ход 1: 5/15, ход 2: 10/15; ход 3: 15/15 - Игрок Б строит чудо со скоростью 6 производства за ход: ход 1: 6/15, ход 2: 12/15, ход 3: 18/15
По итогу чудо появится у игрока Б. Это не только в МП так, в СП против ботов логика та же.
А насчет подхода - ну, можно с уверенностью сказать, что: - такой подход в теории может быть менее требователен к интернет-ресурсам - и запилить его было явно намного проще и быстрее, чем какой-либо другой
Лично я подозреваю, что второй пункт оказался решающим, потому что по сути в такой схеме логика для МП практически не отличается от логики СП. Вот прям если DLL посмотреть, то логика МП от СП отличается разве что редкими ифчиками по типу `if isMultiplayer`. В другой схеме переписывать с виду там прям очень много пришлось бы.
Насчет последующих частей особо не вкурсе; когда интересовался, где-то читал, что для VI части нет DLLника открытого, как для V, подозреваю, его до сих пор тоже нет и, наверное, никогда и не будет. Так что с моддингом там по идее похуже и в целом кишочки уже и не поковыряешь, как в V, чтобы понять в деталях, как оно все работает.
Ну, да, вот как так вышло в коммерческом закрытом проекте, конечно, большая загадка для меня тоже. Я и сомневаюсь, что это было сделано намеренно, но и тяжело представить, что никто не додумался даже банально флаги компиляции вот эти покрутить.
Было много идей, как отслеживать рассинхроны, как пофиксить их все сразу, но все идеи требовали огромное количество времени на реализацию. Изкоробки там есть примитивный механизм отслеживания, но он покрывает только определенный набор переменных, а их там огромное и огромное количество, поэтому работал он так себе.
Какой-то вариант наподобие того, что Вы предложили, тоже думали, в принципе с небольшими корректировками его можно было бы реализовать, но, опять же, вопрос времени. Просто так все переменные не имеет смысла считать, там же много и тех, которые актуальны только для текущего игрока. Как-то если разделить все важное от неважного, разработать какой-то механизм работы с этим ... Ну, короче, все можно, но заниматься некому )
1: если направить клиент в проксю с фэйковым сертом и если в клиенте не запиннен реальный сертификат чтобы проверять подлинность; ну или если изначально самому сформировать этот запрос без перехватывания и отправить его курлом. 2: вот это возможно если только эндпоинт не защищен никак, там жеж при установке хука можно и секрет задать, и серт даже.
Кратко говоря, в момент нажатия кнопки телега подкапотом отправляет запрос с этим callback_data, который далее уйдет на ваш бэкэнд. Вот если этот запрос перехватить и отредактировать, ну или в целом изначально послать запрос самому без нажатия на кнопку, то в callback_data соответственно можно засунуть что угодно.
Если на сервере можно поставить docker, то наверняка там можно поставить и https://nixos.org/. Рекомендую глянуть что это такое, - в конкретном случае развернуть свой vim через nix + home-manager намного удобней, чем через docker вот эти все приседания делать. Ну и плюс это будет нативно, а не в контейнере.
революционная вещь! то, чего все ждали!
а в действительности оказывается, что оно и не нужно, как и любой другой android-super-mega-utils-pack, так как проще и даже быстрее (потому что дело это совсем не хитрое) будет написать свой экстеншн, чем искать каждый раз готовый в этой куче.
Будет обидно, если не «хайпанёт» и вы бросили универ зря (почти уверен, что так и случится).
А по игре — имхо, не хватает физики (неподвижный шар в центре экрана это фэйл) и теней. По «достоинствам» (или как эти надписи на стенах воспринимать): «разнообразное оружие» — увидел только одно; «минимализм» & «только черный и белый» — имхо, что-то лишнее; «процедурно-генерируемый уровень» — сомневаюсь, что кому-то из игроков это интересно.
Честно, не в курсе нюансов и вообще далек от C++ разработки и всего что с ней связано, но когда я туда контрибьютил, вроде как основной проблемой здесь было то, что закрытые либы (которые есть только в виде DLLей) юзают старый тулкит и поэтому ядро тоже как бы завязано на старом тулките. Ну, что-то такое, хз, может это и бред всё и просто не нашлось шарящего чела, который все это завез бы ))
Хороший материал для еще одной статьи )
Блин, а мы тут уже успели накомментить, что это всё костыли и что так вообще не делается )) Ну, тогда задумка, как говорится, хорошая, но реализация так себе.
К читам устойчивости нет совсем никакой, потому что ничего не запрещает:
поставить мод, который открывает всю карту, показывает все ресурсы и тд и тп
как хочешь слать какие хочешь бродкасты, их валидность практически никак не проверяется (ну, кроме базового "существует ли такой юнит", но не "может ли этот юнит ходить так далеко")
Вообще, вот сейчас, после коммента челика выше, мне кажется, что даже не стоит тут искать намеренно какие-то плюсы и причины, почему так было сделано, потому что код там действительно выглядит так, будто они на имеющуюся синглплеерную базу натягивали мультиплеер ))
Вообще, конечно, далеко не факт, что дело в одновременных/поочередных ходах. Уже просто не помню, как они там обрабатываются, поэтому не буду утверждать наверняка, но есть вероятность, что это везение, либо эффект плацебо))
Это как раньше, еще до того как поняли почему VP вылетает в мультиплеере, были всякие "туториалы как пофиксить МП", где советовали графику попроще поставить, какие-то еще там настройки в игре подкрутить, и якобы оно становится стабильней)) По факту это всё, конечно, не меняет того, что где-то в коде в логике работы "чего-то" есть реальный десинк по типу "рабочий, который установлен в автоматический режим обработки клеток, при нахождении клеток-кандидатов с одинаковым Score, выбирает из них рандомную, потому что в коде использован
sortвместоstable_sort".Но если вот обрезать функционал (оффнуть ботов, варваров, руины, конгресс и т.д.), то, конечно, шанс словить десинк явно меньше, просто потому что меньше уникальной логики будет раниться. Просто не уверен, что это относится к одновременным/поочередным ходам, потому что если логика с багом, то она все равно рассинхронит игру вне зависимости от того, в каком режиме ходов ее отранили.
А, да? Я уже просто так давно в ваниллу не играл, что уже забыл где ванилла, а где VP 🙃 Ну, вообще в VP тогда логика выглядит как-то более справедливо ))
Спасибо за прочтение! =)
Там на выбор 3 варианта:
- одновременные
- по очереди
- "гибридные", т.е. одновременные в мирное время и по очереди если объявлена война
Когда чудо строится, у тебя есть показатель "производство" в городе + кол-во уже вложенного "производства" в чудо. Каждый ход "производство" из города вкладывается в прогресс постройки чуда. Если в один ход оба игрока заканчивают одно и то же чудо, то построится оно у того, у кого было по итогу вложено больше "производства".
Например:
- Игрок А строит чудо размером в 15 производства со скоростью 5 производства за ход; ход 1: 5/15, ход 2: 10/15; ход 3: 15/15
- Игрок Б строит чудо со скоростью 6 производства за ход: ход 1: 6/15, ход 2: 12/15, ход 3: 18/15
По итогу чудо появится у игрока Б. Это не только в МП так, в СП против ботов логика та же.
А насчет подхода - ну, можно с уверенностью сказать, что:
- такой подход в теории может быть менее требователен к интернет-ресурсам
- и запилить его было явно намного проще и быстрее, чем какой-либо другой
Лично я подозреваю, что второй пункт оказался решающим, потому что по сути в такой схеме логика для МП практически не отличается от логики СП. Вот прям если DLL посмотреть, то логика МП от СП отличается разве что редкими ифчиками по типу `if isMultiplayer`. В другой схеме переписывать с виду там прям очень много пришлось бы.
Насчет последующих частей особо не вкурсе; когда интересовался, где-то читал, что для VI части нет DLLника открытого, как для V, подозреваю, его до сих пор тоже нет и, наверное, никогда и не будет. Так что с моддингом там по идее похуже и в целом кишочки уже и не поковыряешь, как в V, чтобы понять в деталях, как оно все работает.
Ну, да, вот как так вышло в коммерческом закрытом проекте, конечно, большая загадка для меня тоже. Я и сомневаюсь, что это было сделано намеренно, но и тяжело представить, что никто не додумался даже банально флаги компиляции вот эти покрутить.
Ну, кстати, насчёт завайбкодить идея хорошая. Происходило бы это все сегодня, думаю, попробовали бы.
Если есть свободное время и желание, можно всегда заслать PR, требования к коду там достаточно лояльные, все будут только рады )
Было много идей, как отслеживать рассинхроны, как пофиксить их все сразу, но все идеи требовали огромное количество времени на реализацию. Изкоробки там есть примитивный механизм отслеживания, но он покрывает только определенный набор переменных, а их там огромное и огромное количество, поэтому работал он так себе.
Какой-то вариант наподобие того, что Вы предложили, тоже думали, в принципе с небольшими корректировками его можно было бы реализовать, но, опять же, вопрос времени. Просто так все переменные не имеет смысла считать, там же много и тех, которые актуальны только для текущего игрока. Как-то если разделить все важное от неважного, разработать какой-то механизм работы с этим ... Ну, короче, все можно, но заниматься некому )
1: если направить клиент в проксю с фэйковым сертом и если в клиенте не запиннен реальный сертификат чтобы проверять подлинность; ну или если изначально самому сформировать этот запрос без перехватывания и отправить его курлом.
2: вот это возможно если только эндпоинт не защищен никак, там жеж при установке хука можно и секрет задать, и серт даже.
Кратко говоря, в момент нажатия кнопки телега подкапотом отправляет запрос с этим callback_data, который далее уйдет на ваш бэкэнд. Вот если этот запрос перехватить и отредактировать, ну или в целом изначально послать запрос самому без нажатия на кнопку, то в callback_data соответственно можно засунуть что угодно.
Если на сервере можно поставить docker, то наверняка там можно поставить и https://nixos.org/. Рекомендую глянуть что это такое, - в конкретном случае развернуть свой vim через nix + home-manager намного удобней, чем через docker вот эти все приседания делать. Ну и плюс это будет нативно, а не в контейнере.
так а о чем статья то вообще?
революционная вещь! то, чего все ждали!
а в действительности оказывается, что оно и не нужно, как и любой другой android-super-mega-utils-pack, так как проще и даже быстрее (потому что дело это совсем не хитрое) будет написать свой экстеншн, чем искать каждый раз готовый в этой куче.
А по игре — имхо, не хватает физики (неподвижный шар в центре экрана это фэйл) и теней. По «достоинствам» (или как эти надписи на стенах воспринимать): «разнообразное оружие» — увидел только одно; «минимализм» & «только черный и белый» — имхо, что-то лишнее; «процедурно-генерируемый уровень» — сомневаюсь, что кому-то из игроков это интересно.