1) Потому что GC.getNEW_PARAMETR() возвращает число, хранящееся в переменной. А GC.getDefineINT("NEW_PARAMETR") сначала ищет по названию нужную переменную, а только потом возвращает число.
Когда я начинал осваивать SDK, то сделал чтоб юниты по диагоналям передвигались не так далеко как по вертикалям и горизонталям, и сделал я это через GC.getDefineINT("NEW_PARAMETR"). Игроки, которые играли в мой мод, сразу стали жаловатся что ИИ стал дольше думать. Когда я сделал все через GC.getNEW_PARAMETR(), жалобы исчезли.
2) Расчет лучшего тайла для города делается в конце каждого хода игроков. Я сделал так чтоб этот алгоритм выполнялся перед ходом поселенца. ИИ запоминает что выбрал лучший тайл, и если не произошли события, которые могут повлиять на выбор, то алгоритм не выполняется.
Возмжность апгредить юнита в другого проверяется через рекурсивную функцию для каждого юнита каждый ход. Я этот алгоритм вызываю при запуске мода для каждого юнита и сохраняю результат в единственный битовый масив. Этат алгоритм настолько медленный, что мой мод стал долго запускаться. Поэтому я этот алгоритм сделал многопоточным. При запуске моего мода можно посмотреть загрузку процессора, если загрузились все ядра - значит выполняется этот алгоритм.
Многие расчеты я тоже делаю при запуске мода или игры, и уже в самой игре использую заместь алгоритмов заранее вычесленый результат.
Есть еще метод замены ветвлений (if else) на математические выражения (современные процессоры не любят ветвления).
Например
if (x > 0) {y += x;}
заменяется на
y += x * (x > 0);.
Правда, код после этого делается плохо читаемым, поэтому оптимизацию ветвлений я всегда сопровождаю коментариями оригинального кода
y += x * (x > 0);//if (x > 0) {y += x;}.
А в каком файле (и название функции) находится альтернатива Pathfinding в моде Caveman2Cosmos? Хочу себе такое зделать.
Ответить с цитированием
