Здрасте! Как-то за последним боем, я задумался, а как работает алгоритм пересчета боя...
Циферок то многовато, вот проц сервака и тормозит наверно..А отсюда 54321 и вылазит...

И вот я подумал, а не разгрузит ли сервак "деноминация" весов???

Гораздо ведь легче посчитать 2,5кк на 3,7кк, чем 2,5ккк на 3,7ккк.....
Вы как думаете господа разрабы????

Пищу для размышлений я вам дал, а вы уж думайте - куда меня послать!!!

С уважением, Sokol_2009
Сфера Льва

Не легче.

Во-первых меньшие армии действительно легче обсчитать чем большие.
Во-вторых я давно предлагал нечто подобное
В-третьих надо ещё уточнить что для каждого мира надо применить свой коэффициент деноминации, после чего все миры в принципе можно будет объединить в 2-3 мира

То что караван ползет со скоростью самого медленного верблюда ты в курсе, да?
По этому даже если на самого быстрого верблюда вместо газотурбинного двигателя поставишь ЖРД, все равно караван будет ползти со скоростью самого медленного верблюда.
Так что не будет быстрее. И не будет легче.

рассуждения ни о чём. я могу сказать когда на соте 300 армий из одного юнита и когда столько же грабель по 3ккк продвеса, сота очень по разному тормозит

И причем тут операции умножения и сложения выполняемые процессором?
Ты прав, ты ни о чем рассуждаешь.

при том что из-за нагрузки на процессоры серверов больше багов и тормозов в игре

Как это причем??? Фича 54321 вылезает чаще всего при окончании раунда, когда серваку приходится пересчитывать кто кому сколько убил. Перемножаются коэффициенты атаки, арты и прочее....Тебе известно сколько операций процессору приходится делать для пересчета чисел??? Сравнение каравана верблюдов тут ни к месту...А вот попробуй просто на бумаге пересчитать 135*248 и 135678*248956. Сколько времени у тебя уйдет?? Ясное дело, что в первом случае меньше операций будет и соответственно быстрее, чем во втором.

А теперь возьми в расчет типы данных, используемые в программировании....
Например в Паскале:
==========================
тип диапозон значений
==========================
Shortint - 128 .. 127
integer - 32768 .. 32767
Long - 2147483648 .. 2147483647
byte 0 .. 255
Word 0 .. 65535
==========================
Т.е. если взять типы long армии до 2ккк пересчитаются механизмами языка программирования, а для армий размером выше 2,2ккк потребуются дополнительные преобразования. Соответственно число операций процессора намного выше, так же как и использование оперативной памяти.

В нашем последнем логе было убито 2 волны в 13ккк хлопом в 40ккк...Вот и представь как процессору приходится напрягаться...А если при этом еще и присылают кучу прослоев, каждый из которых отдельно бьется и пересчитывается????

Если я не прав хотелось бы услышать аргументы, а не просто - "не легче" (с).

Даже если предположить, что операция умножения выполняется 300 тактов (на самом деле даже операция деления выполняется намного быстрее) то за 1 секунду 1 процессор с 1 ядром и частотой 3ГГц выполнит 10 миллионов таких операций. Предположим, что для расчета удара 1 армии нужно 10 операций умножения * количество стеков. Т.е. в самом плохом случае будет что на расчет удара 1 армии мы будем тратить меньше 1000 операций умножения (100 стеков * 10) (операциями сложения и вычитания мы пренебрегаем, так как они выполняются по нескольку штук за 1 такт). Умножим все на количество армий на соте (300). Получим 300000 операций умножения для расчета удара. И это в самом плохом случае. Т.е. учитывая быстродействие процессора, мы можем рассчитать за секунду 10.000.000 / 300.000 = 33 соты игроков. У которых одновременно на сотах стоит/летает по 300 армий на которых происходит сражение.
Все это сферический конь в вакууме, так как мы не учитываем латентность памяти, которая значительно медленнее чем процессор и его кеш. И не учитываем латентность и скорость диска, с которого вся информация предварительно считывается, который и является тем самым главным тормозом.
И на самом деле, процессор сервера большую часть времени просто НИЧЕГО не делает,так как ждет данные от контроллера рейда, потому что для того что бы рассчитать бой, его параметры (армии их состав и количество) перед расчетом нужно прочитать с диска.

Да, забыл совсем, когда команда обновления приходит на сервер, перед обновлением твоей соты, вычисляются всяко-разные зависимые события и пересчитываются всяко-разные зависимые соты, т.е. соты игроков на которых ты летишь или которые на тебя летят. Так вот тут как раз и появляются лишние чтения с диска (и записи на диск тоже) которые дополнительно тормозят процесс.
А операции умножения тут не при чем, процессор ведь не на бумаге умножает.

так или иначе если провести значительную деноминацию форса и ресов и отключить бонус на локалки (который приводит к слишком быстрому накоплению армий у игроков и дисбалансу ресурсов) во всех мирах, багов и тормозов в игре будет меньше

Вижу, что тебе объяснять бесполезно, подожду ответа разрабов.

превед, тупицы
как оно быть манагером среднего звена?

Не будет проще.
Операции идут не с целыми числами. Поэтому изменение порядка просто передвинет запятую, количество цифр останется тем же.

Я не имел ввиду передвижение запятой, а именно уменьшение цифр......
Т.е. к примеру армия весом в 2 345 678 234 станет весом в 2 345 678. Не думаю что народ будет возмущаться по поводу потери 234 продовеса, а механизм пересчета уже упростится...

А вы один из разработчиков, или хотя бы знакомы с механизмом пересчета??
Я к тому, что вы точно знаете, или это ваше предположение.

А то тут видите ли, многоуважаемый СноуБласт утверждает, что все тормозится потому что медленно с диска читается, при этом видимо не зная что и число 867 234 567 и число 2 098 345 345 занимают в памяти 4 байта и считываются одинаково, в то время как умножение этих чисел на другое занимает разное время...

Если вы точно знаете,то я умолкаю. Ибо я точно не знаю механизмов и рассуждаю с позиции программирования, с коим немного знаком.