M.A.X.    Вы вошли как гость
Российский Клуб игроков M.A.X.
 
[Новости]   [Новичку]   [Энциклопедия]   [Документы]   [Файлы]   [Игроки]   [Архивы]   [Архив форума]  
[Новый сайт]   [M.A.X. Gold]   [Партии]  

 
 
 
Архив форума  МаксГолд
[Основной форум] [Голосования] [МаксГолд] [Off-Topic]
 


Мысли  -  Burn,  09.02.2011  17:41:41

да-а, если ты так программишь, как задачи формулируешь, то бедный Hruks, как он вообще в этом коде разобрался? (это к первому сообщению больше относится, писалось пару дней назад)

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

появились вопросы:

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

Далее, второе, алгоритм обхода связной общности юнитов не ясен. Опять же, как он работает сейчас?

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

--------------------------
Дальше я попробую поспорить с некоторыми предпосылками

Предпосылки:
-Юниты на сетке, связность заранее не известна
-Поиск связности идёт рекурсивно по карте присутствия (unu)
-Обрабатывается по одному ресурсу за раз без приоритетов


Мне кажется, что в предложенной идее есть откровенные недостатки.
Что если формировать базу как совокупность модулей, попутно добавляя информацию о их взаимном расположении, для того чтобы связность была заранее известна? В этом случае все события типа постройка/удаление модулей будут разделяться на две категории:
-события, меняющие структуру цепочки модулей (соответственно, требующие полного перерасчёта итогов внутри структуры)
-события, не меняющие структуру цепочки модулей (не требующие полного перерасчёта, обрабатываются существенно проще).

Теория:

Связность - характеристика отдельной цепи модулей, в общем случае этих цепей может быть множество. Пока есть предложение нумеровать цепи в порядке возрастания, т.е. начальная шахта - элемент 1 цепи 1, начальный генератор - элемент 2 цепи 1.
Постройка любого модуля (напр. коннектора) в чистом поле сформирует новую цепь, т.е. этот коннектор будет элементом 1 цепи 2.
Постройка любого модуля (напр. хранилища) по соседству с уже существующими модулями - просто добавляет очередной элемент в существующую цепь, т.е. это хранилище будет элементом 3 цепи 1.
Проверка на соседство достаточно простая - по граничным клеткам ([x-1,y] [x+1,y] [x,y-1] [x,y+1] - для одноклеточного модуля, для 4-хклеточного аналогично) проверяем наличие уже существующих модулей, если они все принадлежат одной цепи, то новый модуль автоматически получает номер последнего+1 элемента этой цепи. Если разным - то происходит поглощение одной цепи другой с объединением итоговых запасов.

Лирическое отступление: вся эта нумерация сделана для упрощения пересчета при разрыве цепи на части, но детально эта тема пока не проработана, так что, возможно, есть более простые решения.
Также не ясно, как организовывать нумерацию при закольцовывании цепи.


События, меняющие структуру цепи.
------------------------------------
постройка нового модуля (вывод инженера, конструктора, либо событие постройки коннектора) ->
________проверка на объединение цепей ->
________________F(полный пересчет итогов цепи)
________________ИНАЧЕ добавление локальных параметров нового модуля к итогам, т.е. переход к Событиям ВНУТРИ цепи.

разрушение модуля ->
________проверка на разрыв цепи (пока нет даже примерного алгоритма) ->
________________F(полный пересчет итогов цепи) для всех цепей.
________________ИНАЧЕ удаление локальных параметров модуля, т.е. переход к Событиям ВНУТРИ цепи.
-------------------------------------


События ВНУТРИ цепи (без полного пересчёта итогов цепи):
----------------
вкл. шахты -> проверка доступной энергии -> F(добавление в итоги) ИНАЧЕ сообщение недостаток энергии
вкл. энергомодуля -> проверка кол-ва бензина -> F(добавление в итоги) ИНАЧЕ сообщение недостаток бензина
вкл. рафинарии -> проверка доступной энергии, кол-ва золота -> F(добавление в итоги) ИНАЧЕ сообщение недостаток того, чего не хватает
аналогично для заводов, пехотных заводов, лабораторий и экосфер

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


Выкл. модуля -> проверка на соотв. выключение связанных с ним модулей (напр. вырубили энергостанцию, должна быть остановлена шахта) (вот здесь уже нужна рекурсия или какой-то другой механизм) -> проверка на совершённость события (т.е. ту же энергостанцию могли взорвать враги, это уже свершившийся факт, либо мог попытаться остановить сам игрок - в этом случае дополнительное сообщение Что ж вы делаете, гражданин?) -> F(добавление в итоги) отрицательных величин.


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

Простите великодушно, небольшая заминка. Докончу в следующий раз. (с)