Замечу следующее.

Мы изучали разные варианты боя. Скажу так (хотя наши разработки я просто не могу показать). Вариант 4 очень близок (хотя отличается как карманный пудель от овчарки) от того к чему мы пришли в ходе изучения. Да и на западе есть такие аналоги.

Но замечу следующее. Ввести юнит проив юнита мы еще могли. А вот такое кардинальное изменение в бою... ИМХО нет. По крайней мере не в этом проекте.

Но у автора есть ряд идей близких к пониманию игровой механики. Но... в общем ребят. Сначала написал большой пост. потом все стер. Ничего пока не могу рассказать. Есть наработки, но показывать пока их на всеобщее обозрение я не готов.

Скажу что в игре должна быть свобода игры - когда считаю нужным. Save zone. Бой желательно делать зависимым от игрока - придавать drive игре. Рейтинговые идеи (на жаргоне это называется "качели") тоже не новы и используемы. И часто правильны. Вопрос в том как и где их применять.

И еще. Вариант 4 имеет место и право на жизнь, только если отсутвует идея м интерактивным онлайн боем, с простым и настраиваемым (на время моего отсутствия) ИИ. А такая идея у нас есть.

Таблица констант - это уже массив адресуемых переменных со всеми вытекающими последствиями, связанными с обработкой их адресов.
И я уже это делал и третий раз предлагаю тебе это сделать - это я про те два цикла. Можешь написать на любом языке - всё-равно почувствуешь разницу.

Зато в твоем случае нужна куча проверок для определения той ветки, на которой эти константы считаются
так что не будет там существенного выигрыша
Если ты все же настаиваешь - приведи алгоритм, о котором ты говоришь. Например, для определения урона юнитом i по юниту j. Чтобы мы понимали друг друга...

Собственно я счастлив. Раз уж мои измышления (в основном заполнявшие время по дороге "из дому на работу") потянули на пуделя, то ваше коллективное творчество должно быть больше чем просто мечта. Жаль нельзя на данном этапе ознакомится, но видимо рано или поздно удастся потестить? И кстати - пост по поводу вкладывания реала почитайте внимательно... В принципе, подозреваю, что в рунете иначе просто не выжить. Если же подойти к этому разумно (продавая эквивалент затраченного времени, а не игровое преимущество в чистом виде), то можно и нынешнюю вольницу сохранить и чуть-чуть свое материальное положение улучшить.

Отказываемся от индексов i и j.
Для этого заменяем вложенные циклы по i и j блоками исходного кода, в которых они будут являться констатами: первый блок 1, 1, второй 1, 2 и т.д. Последний 66, 66.
В каждом блоке для i-го юнита прописываем уже результат произведения ЭУ на "К юнит против юнита" в виде одной константы исходного кода (в виде цифр).
В каждом блоке проверяем на ноль продовый вес i-го стека, и если он не нулевой, добавляем в сумматор урона j-го юнита (если он не нулевой) произведение той константы на продовый вес и на ранее расчитанную величину, обратную количеству стеков в j-й армии.

Исходник, конечно, будет внушительных размеров, но процесс пойдёт с максимальной скоростью, так как будет идти без обработки адресов индексов и таблицы "К юнит против юнита"...

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

ЗЫ только не говорите на затраты времени для инкремента адреса - это не занимает ресурсы АЛУ.

Согласен. Убрав вычисление индексных переменных увеличим скорость.

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

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

Твой пример с циклами никакого отношения к выборке не имеет. Ускорение получается за счет изъятия операция со счетчиками. Именно лишняя операция инкремента счетчика (взятьИзПамяти-увеличить-положитьВпамять) дает тормоз в цикле.

2Olin: Так, теперь давай считать
фактический_урон(i,j) = число_юнитов*базовый_урон(i,j)*К_атаки(i)*К_защиты(j)
число_юнитов - число юнитов, наносящих урон, переменная, float
базовый_урон(i,j) - константа, float
К_атаки(i) - поправка на религию атакующего, float
К_защиты(j) - поправка на религию и арты защитника, float

Пусть у атакующего N юнитов, защитника - M
Для того, чтобы вычислить полный урон по юниту j, тебе понадобится N вычислений фактического урона и столько же сумм. Для всех юнитов защитника еще и проделать М раз. Сохранением результатов пренебрегаем

те, сложность = (сложность_факт_урон(i,j)*N+float_sum*(N-1))*M

Соотвественно, для расчета уронов по атакеру

сложность = (сложность_факт_урон(j,i)*M+float_sum*(M-1))*N

т.е, всего сложность = сложность_факт_урон(j,i)*M*N*2 + float_sum*(N-1)*M + float_sum*(M-1)*N =

= сложность_факт_урон(j,i)*M*N*2 + float_sum*M*N*2 - float_sum*M - float_sum*N

Сложность фактического урона:
+вычисление адреса константы базового урона ( = целочисленный инкремент при последовательном обходе)
+умножение float К_атаки
+умножение float К_защиты
+умножение float число_юнитов

Итого:
6*M*N умножений float
2*(M-1)*(N-1) сложений float
2*M*N инкрементов указателя на базовый урон

справочника под рукой нет, но на глаз
умножение = 200 тактов
сложение = 60 тактов
инкремент = 10 тактов (худший случай)

Итого обращение к массиву составляет примерно 20/(1200+120) = 0.015, те 1.5% от общих вычислений. И это на уровне, близком к ассемблеру! Чем выше уровень языка, тем слабее будет линейная зависимость вычислений...

А теперь поверь мне, ни один программист в здравом уме не будет ради 2% раздувать код в 66*66 раз.
И дело тут уже не в производительности (2% ничего не решают - общий запас должен быть около 50% от железа), а в сопровождении этого монстра...
Счетчик там не нужен. Переменной цикла может выступать указатель на строку таблицы базового урона, условием окончания - границы таблицы. см STL

2 SergD
Согласен.

2 7serg7
Трудно возразить конкретно - в-целом пропорции похожи.

Итого: признаю, что по быстродействию преимущество констант над переменными несущественно.

Осталось: дополнительные пораундовые расчёты - зло. Да ещё имеющие порядок сложности N*N - тем более.

собственно опять вас уважаемые занесло. с точки зрения рассчетов - оптимальный вариант - нынешний, с прослоем. Сложил,разделил, умножил, вычел. Любой другой - учитывающий излишки урона при ударе, уже усложнение. НСБ стала значительным усложнением. Нет смысла обсуждать алгоритмы игровые с данной позиции.

Фигасе оптимальный вариант!

Вынудить игроков увеличивать количество стеков - в разы увеличить количество однотипных просчетов.

З.Ы. Пораундовая модификация ЭБ не дает сколь-нибудь существенного увеличения нагрузки на систему. Будь Nr gеременной, или просто указателем на таблицу пораундовых коєффициентов - никоим образом систему это не усложнит.

З.З.Ы. Что же касается ввода денег в игру, то премиум и есть продажа реального времени за бабло.

По поводу денег в игре - посмотрите на альфу (на такую вещь как золотые и серебряные кредиты). Игровой ресурс, покупаемый за реал.

Видел. Крутил. Торговал.

Утверждаю что сами по себе деньги не страшно. И то как это задумано.