1) Требования к хранению игрового поля на сервере Данные о сгенерированном поле должны храниться в реляционной базе данных со следующей схемой: Hexagon(#hex_sysnum, hex_type, hex_num) Vertex(#v_sysnum, v_type) Is_vertex(#hex_sysnum, # v_sysnum, pos_num) Road(#v_sysnum_begin, #v_sysnum_end) Типы данных для атрибутов: hex_sysnum, v_sysnum, v_sysnum_begin, v_sysnum_end , hex_num– INTEGER pos_num, hex_type, v_type – BYTE для атрибутов hex_type и v_type введены кодификаторы: hex_type: 1 – «лес» 2 – «карьер» 3 – «каменоломня» 4 – «поле» 5 – «шахты» прим. т.к. в правилах не нашел тип местности для «руды» назвал так 6 – «море» - прим. есть вариант не создавать кодификатор такого типа, а просто соотнести ему NULL 7 – «столица» v_type: 1 – «Поселение» 2 – «Город» 3 – «Замок» 4 – «Рынок» 5 – «Гавань» 6 – «Специализированная Гавань» Прим. аналогично пустая вершина соответствует NULL Комментарии к атрибутам: hex_sysnum, v_sysnum – системные номера гексагонов и вершин, являются уникальными для каждого гексагона\вершины (нумеруются последовательно 1,.. правила нумерации во 2-ом разделе) v_sysnum_begin, v_sysnum_end – системные номера 2-ух вершин через которые построена дорога hex_num – номер, которым пронумерован гексагон, может быть одинаковым для нескольких гексагонов с разными типами hex_type и v_type – типы гексагонов и вершин соответственно pos_num – положение вершины в гексагоне (1 - , и так далее до 6 по часовой стрелке ) Прим. эта предварительная структура БД относится только к построению гексагонов 2) Алгоритм генерации игрового поля на сервере Прим. Требуется изменение правил игры (пункт 2) для возможности построения этого типа игрового поля (пока не получилось для 21+5*n - не понял эту схему построения) Все игровое поле представляет собой квадрат (одинаковое количество рядов и гексагонов в ряду ), который состоит из континента и окружающей его со всех сторон «моря» - особого типа гексагонов. Континент должен состоять из 19 + 6*n ,где n={3..20} гексагонов любого типа кроме «воды» и имеет форму составного гексагона («длина» каждой из 6 сторон континента n гексагонов, «длина» диагонали и 2*n-1 гексагонов и 2*n-1 рядов соответственно) размер которого можно изменять меняя начальный параметр n ( т.е. добавляя или убирая «слои» ) Алгоритм генерации игрового поля состоит в следующем : 1) Происходит расчет размеров всего поля по формуле (2*n+1)2 , генерируется «квадрат» из рядов гексагонов типа «море» (с «нечетным» «размером сторон») и им присваиваются системные номера по порядку слева направо по ряду, и так по всем рядам сверху вниз от 1 до (2*n+1) 2. Для всех этих номеров создаются записи в БД, также создаются записи для (2*n+1)2 *6 вершин и приписываются к гексагонам (общие вершины можно определять с помощью системного номера гексагона и положения уже приписанных вершин или создавать вершины в процессе создания гексагонов по рядам), далее в процессе создания поля они приписываются к соответствующему гексагону в соответствующие позиции (м.б. с одним из типов гаваней или типом «Рынок» в зависимости от гексагона) 2) Определяется системный номер центрального гексагона по формуле (n2+1)/2, ему присваивается тип «Столица» а его вершинам тип «Рынок» 3) Далее создается необходимое количество «слоев» вокруг центрального гексагона по принципу(2 варианта) : а) Проверяются все вершины гексагонов последнего созданного слоя, и если у какого либо из смежных гексагонов вершин типом является «море» то он меняется на один из типов «суши». б) С помощью известных размеров диагонали и формы гексагона-континента рассчитываются номера гексагонов, принадлежащих континенту и им присваиваются типы «суши» Типы «Гавань» и «Специализированная Гавань» присваиваются вершинам, являющимся смежными с 2-мя гексагонами суши и 1-м типа «Вода» (алгоритм выбора какая именно пока не ясен: или случайным образом или по алгоритму, дописанному в правилах) Игровые номера гексагонов генерируются случайным образом в пределах от 2 до 12 с повторениями, но число повторений должно быть обратно пропорционально вероятностям выпадения каждого номера Тип суши у «материковых» гексагонов должен распределяться равномерно. 3) Требования к формату передачи данных от сервера к клиенту для генерации (обновления) игрового поля на клиенте. Данные должны передаваться в формате JSON и иметь следующую структуру (иерархия соответствует формату списка): (Примечание: каждый объект\массив в этой структуре должен иметь поле “Object_Type”\имя , которое его идентифицирует.) Внешний объект-контейнер (“Object_Type” : “Generation” или “Refresh”) содержащий в себе данные для генерации\обновления поля в зависимости от типа: Массив Hexagons (только в случае «Генерации»!), содержащий объекты типа Hexagon Объект Hexagon (“Object_Type” : “Hexagon”), содержащий поля: HEX_TYPE, HEX_SYSNUM, HEX_NUM, V1_SYSNUM, V2_SYSNUM, V3_SYSNUM, V4_SYSNUM, V5_SYSNUM, V6_SYSNUM (где V1_SYSNUM … V6_SYSNUM – системные номера вершин гексагона (названия аналогичны положению вершин из 1) )) Массив Vertexes , содержащий объекты типа Vertex Объект Vertex (“Object_Type” : “Hexagon”), содержащий поля: V_SYSNUM, V_TYPE Массив Roads (только в случае «Обновления»!), содержащий объекты типа Road Объект Road (“Object_Type” : “Road”), содержащий поля: V_SYSNUM_BEGIN, V_SYSNUM_END Примечание: (При обновлении должны пересылаться только объекты, отображение которых нужно обновить) Примечание: Механизм обновления\генерации необходимо обсудить!!!