Имнетересно ли Вам мое мнение?

О том какая должна быть сфера или стратегическая игра?

А собственно кому мы все это пишем? конечно же интересно. заодно, если бы разработчикм предложили хотя бы общую канву для размышлений, появилось бы больше конструктива - отсеклись бы сразу "лишние" фантазии.
Пока мне мой вариант - ограничения веса армий и "сверху" и "снизу" кажется весьма интересным. Плюс - в данной схеме можно ввести продажу ресурсов за реал, для нежелающих целенаправленно развиваться, и данная продажа не вызовет ни дисбаланса, ни возмущения. Балбес все равно проиграет все возможные бои, заинтересовавшийся же человек просто станет еще одним интересным противником. А в нынешнем варианте "бесконечного накопления" лично мне сфера уже неинтересна...

Ты ещё и спрашиваешь?

Мы тут все извелись в догадках...

Ну юзеров ты напугать этим можешь... но не программистов. Ибо ерунда. Потому что (если ты только не писал ядро на ассемблере) данные обычно хранятся отдельно от кода, и все равно в регистр грузятся по адресу... А так как таблица коэффициентов - константа отнюдь не кода, то различие между ней и переменными еще более условно. Кроме того, ядро сервера написано явно на ПХП... И о разнице между константой и переменной в интерпретированном языке рассуждать... немодно
ЗЫ: разница в циклах между immediate и pointer исчезла где-то на уровне 486х процессоров... все обрабатывается параллельно... ибо pipeline... Оптимальный состав возможен лишь при наличии одного экстремума в функции эффективности боев, или при относительной стабильности данной функции... Если же диапазон значений достаточно велик, и есть несколько оптимальных конфигураций и анти-конфигураций... расчет не поможет, а усредненную армию разобьет первый же умный игрок - в чем, собственно, и цель...

...потер...

Мне казалось, что речь идет именно о беспрослойном варианте боя, с большой вариацией уронов и уязвимостей, и вдобавок многораунде с вариацией эффективности... А в многораунде прослой не сильно поможет... Вместо него можно ввести "оттяжку огня" разными видами юнитов, но это сложнее чем просто оставить "прикрышку" из чемоданов
[upd]поздно потер... йа не заметил

переслал в ПМ
там же тема, в которой обсуждение данного вопроса

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

Все, мы уже здесь завязали. Дальнейшие обсуждения в другой теме
а зачем? Ограничения есть и сейчас, чем они плохи?

Лично я когда-то на трёх видах Ассеблера немного писал (для разных типов микропроцессоров).
И очень подозреваю, что таблица "К юнит против юнита" загружена ещё в исходнике и непосредственно откомпиллирована в код в виде полноценных констант. Я бы так сделал.
Поэтому для сомневающихся повторно советую провести эксперимент с циклами. Даже на ПХП.


2 karnoza
Ты классный топик создал - очень хорошее и широкое название.

Олин, я бы тоже многое сделал по-другому
Но как-то Райла обмолвился, что таблица юнитов у них в БД, и таблица К в БД... Так что - если я я конечно ничего не путаю - ты в корне неправ... При чем в предпосылках...

зы: но даже в нормальных языках среднего/низкого уровня таблицы зашивают в сегмент данных, и в принципе ничем от переменных они не отличаются.. Зашивание чисел прямо в код сильно усложняет проектирование и сопровождение. + сильно раздувает код.
Сам подумай: для того чтобы расчитать, сколько юнит 3 наносит урона, нужно:
а) залезть по индексу юнита в таблицу, вытащить оттуда константы и на основании их получить урон
б) диагностировать тип юнита, после в отдельной ветке использовать константы для вычисления...
Что проще,быстрее, надежнее?

Первое впечатление: армию будут дробить на кучу мелких частей и посылать многочисленными волнами. Победа, как и сейчас, - за экономически мощным игроком.
Рассудить нас может только Enzo.
Raila не программист. Его инфа правильна. А я добавлю: а потом эту БД используют на этапе компилляции для получения исполняемого кода.
Обращаться к БД в виде SQL-запросов в реальном масштабе времени... застрелиться можно!
А если это единственно возможный путь для возможности одновременной обработки тысяч боёв?
Ради этого стоит и долго запрягать и код раздуть. Зато быстро поедет.

Олин, не смеши народ.
Напиши программу так и так и просчитай эффективность.

Ты про SQL-запросы?

Можешь просто с таблицей констант и вшитыми в код константами.
Предположим, что SQL они действительно не используют