Crossroad in the Void: when the Ancients rise, бывшая TGE (The Great Experiment) Опции

[AlexYeCu]

А GUI контролы, ты сам делал или библиотеку какую-то использовал?

В основном сам, хотя в ряде мест используется loveframes — текстовые поля, кнопки на стартовом экране и при генерации партии, etc. Подумываю со временем перетащить на loveframes и «инвентарные» интерфейсы — хоть код более читабельным будет. Подсказки по ПКМ делал сам: те, что были в loveframes не подошли.

Список заклинаний окончательный?

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

Каким образом работают книги по навыкам?

Смотря какие. Магические — точно как в might and magic. Три отличия: могут требовать более одной (до 4-х) школы (подобное было в mm9), пять градаций по мастерству вместо 4-х, большее количество школ.
А если те, где описаны приёмы боя, защиты, алхимия, etc. — они просто информационные, вроде алхимических рецептов в mm.

Какие локации планируются?

Зависит от того, наберу ли команду. Сами по себе локации являются текстовыми двумерными массивами из нескольких слоёв (каждый слой — отдельный массив). Т.е. на одну локу надо:
1. бэкграунд (и массив с ним), набор гексов-декалей (и снова массив), набор объектов вроде деревьев, камней и прочего — это всё делается в редакторе.
2. Расставить здания (а сами здания надо нарисовать, а к ним в другом мини-редакторе сделать описания вида какие гексы занимают, где вход и т.д.).
3. Расставить сундуки и мобов (пока что ручками, плюс мобов ещё рисовать).
4. Прописать мобам ai, фракции, партии, прописать магазинам жильцов и ассортимент и т.д.
5. В будущем пунктов будет ещё больше: триггеры событий и квестов, дополнительные объекты вроде бочек, телепортов, пъедесталов, ловушек, кнопок.

[Сулейман]

В основном сам, хотя в ряде мест используется loveframes — текстовые поля, кнопки на стартовом экране и при генерации партии, etc. Подумываю со временем перетащить на loveframes и «инвентарные» интерфейсы — хоть код более читабельным будет. Подсказки по ПКМ делал сам: те, что были в loveframes не подошли.

Ага ну я тоже только эту библиотеку контролов нашел, будем пробовать ее, спасибо.

2. Расставить здания (а сами здания надо нарисовать, а к ним в другом мини-редакторе сделать описания вида какие гексы занимают, где вход и т.д.).

Чисто из того что пока нарыл - хотя движком и тайловыми играми занимаюсь всего неделю, так что могу и фигню сказать) Мне кажется лучше отделить графику от логики. Тригерры и все характеристики навесить на гексы. А поверх наложить спрайты зданий. Таким образом один объект в игре - спрайты со своей координатой плюс набор тайлов с тригеррами и свойствами. Обрабатывать только тайлы. То есть ты можешь чисто сетку тайлов создать со всей логикой, а стены, двери и всю остальную графику потом навесить по координатам тех же тайлов в редакторе - с этим проблем быть не должно. И не придется ничего описывать дополнительно.

4. Прописать мобам ai, фракции, партии, прописать магазинам жильцов и ассортимент и т.д.

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

[AlexYeCu]

Тригерры и все характеристики навесить на гексы.

Пока триггеры описываются как-то так:

Код

    localtriggers={
    {x=29,y=10,dir=6,id=1},
    {x=37,y=13,dir=6,id=2},
    };

Т.е. x и y координаты, поворот (персонаж должен повернуться к двери), id (в данном случае для удобства, т.к. достаточно индекса в таблице).
За счёт специальных гекс можно задать координаты, можно поворот (если использовать 6 гекс), но как задать id? Как указать, что при заходе на этот триггер надр отображать соответствующей интерьер и неписей? Да чтоб без дикого оверхэда?

И не придется ничего описывать дополнительно.

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

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

Ну как сказать… прописать ai и всё остальное значит добавть строку вида:

Код

table.insert(chars_mobs_npcs,{uid=0,person="mob",control="ai",defaultai="agr",ai="agr",dangerai="agr", x=15,y=15,rot=5,class="goblin",fraction="greens",party=1});

или

Код

table.insert(chars_mobs_npcs,{uid=4,person="npc",control="ai",defaultai="building",ai="building",dangerai="none",x=1,y=1,rot=6,class="goblin",fraction="bloggers",  party=2, name="Schors", chat=3,face = 7, shop=1});

Потом все эти строки скармливаются функции helpers.addMob(); которая, в свою очередь,заполняет таблицу нужными значениями, опираясь на полученные данные. Т.е. в ООП это было бы что-то вроде создания экземпляра класса моб. Просто я не люблю ООП, а уж его реализацию на метатаблицах в lua так и вовсе.

В дальнейшем вся информация для создания записей в таблице будет задаваться в редакторе. Это не сложно, просто сейчас есть более важные задачи.

[AlexYeCu]

Планируемые классы:

acolyte—wizard—mage—archmage
—necromancer—lich
—druid—archduid
—shaman—ubershaman
—sorcerer—warlock
—battlemage—masterarcher
healer—cleric—bishop—priest
—heretic—heresyarch
—druid—archduid
—shaman—ubershaman
—sorcerer—warlock
—initiate—monk—yeromonk
—ninja—sinobi
warrior—landsknecht—knight—champion
—crusader(templair)—paladin
—crusinant—deathknight
—mercenary—savage—barbarian
—fighter(?)—gladiator
—shooter—marksman—sniper
—hunter—ranger
—battlemage—masterarcher
—initiate—monk—yeromonk
—ninja—sinobi
rogue—robber—thief—masterthief
—killer—assasin
—trouvиres(трубадур)—ministrel—bard
—sicophant—seccol(сексот)—spy
—initiate—monk—yeromonk
—ninja—sinobi

Список примерный, приводится из расчёта на три продвижения.
Пояснения: у мага два основных пути, светлый и тёмный. Кроме того, он может выбрать путь друида, шамана или варлока. Эти классы очень похожи между собой (магия стихий и себя до мастера, алхимия до гранда), отличия в некоторых дополнительных воможностях, квестах на продвижение и т.д.
Клерик — аналогично (см. последнюю строчку).
Воин — три основных направления, в латники, бездоспешные или стрелки. Плюс дальнейшее деление.
Вор — путь, собственно, вора, путь убийцы, путь шпиона, путь барда (чисто социальный класс, не для первого прохождения, плюс требует толковых писателей для реализации).
Клерики, воины и воры при выполнении некоторых условий могут стать монахами.
Маги, возможно, боевыми магами (т.е. лучник-недомаг).
Список пока очень примерный, по нему не реализовано почти ничего.

[Сулейман]

Ну как сказать… прописать ai и всё остальное значит добавть строку вида:

А что мешает ее вынести в шаблон с модулем, модуль назвать goblin. И делать вызов в духе Factory.create("goblin"), внутри функции просто делаешь require('goblin'), и создаешь таблицу копию этого гоблина, ну и ID ему присваиваешь конечно. И вот у тебя один шаблон гоблина, который можно вставить куда угодно.

Просто я не люблю ООП, а уж его реализацию на метатаблицах в lua так и вовсе.

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

[IQUARE]

sinobi

*shinobi

Ninja и shinobi - одно и то же, просто в разных вариантах чтения.
Грейд, может, по-другому назвать

initiate—monk—yeromonk

Может, monk - initiate - master ?

[Сулейман]

Плюс затраты стамины и готовности на перемещение.

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

Как указать, что при заходе на этот триггер надр отображать соответствующей интерьер и неписей?

Сделать гекс перед ним прозрачным? Если я правильно понял, речь идет про заглядывание в окно или дверной проем?

[AlexYeCu]

А что мешает ее вынести в шаблон с модулем, модуль назвать goblin. И делать вызов в духе Factory.create("goblin"), внутри функции просто делаешь require('goblin'), и создаешь таблицу копию этого гоблина, ну и ID ему присваиваешь конечно. И вот у тебя один гоблин которого можно вставить куда угодно.

А смысл? Это ничему не поможет. Совсем.

Отказ от ООП хорош, если ты можешь заменить его чем-то столь же удобным для тебя.

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

Тебе фабрика объектов нужна на метатаблицах, а не ООП.

Не люблю я метатаблицы. Мне вообще не очень непонятно, на кой сдалась эта кривая абстракция (ну т.е. там есть области применения, но довольно узкие). С моей точки зрения выглядит всё это так: есть язык lua без ООП. Фанаты ООП начинают ныть: «дайте нам ООП!». Появляются метатаблицы, фанаты начинают лепить из lua C++. Ок, им удобно: код выглядит похожим на сишный, счастье-радость. Но я-то не сишник! По мне всё это лишние абстракции: ну не вижу я разницы между вызовом функции и «типа метода типа класса» в lua. Да, можно и через них писать, но зачем? Ладно, если язык весь из себя ООП и по другому там писать — занятие для шибко упорных. Так нет же.

[Сулейман]

Появляются метатаблицы, фанаты начинают лепить из lua C++.

Ну конечно все было не так). Метатаблицы нужны для переопределения встроенных операций - без этого тяжко. Вот к примеру два вектора хочу складывать, можно и метод написать, но зачем, если через плюс это удобнее делать. А наследование (заметь не ООП) просто красиво реализуется через __index. К тому же С++ обзавидуется возможности в рантайме создавать цепочки наследуемых объектов (не классов, а объектов!) это просто кучу возможностей открывает.
Планирую так сделать стек активных объектов с перекрытием команд. То есть верхний объект стека обрабатывает кнопку Esc, чтобы сбросить выделение к примеру, а кнопку P нет, пока он активен главное меню по Esc не вызывается, а пауза на Р продолжает вызываться.

ну не вижу я разницы между вызовом функции и «типа метода типа класса» в lua.

Так нет разницы, или ты про то что не видишь смысла создавать функции в таблицах, когда можно создать глобальные?

А смысл? Это ничему не поможет. Совсем.

Почему? А еще можно будет написать Factory.create('goblin_wizard'), а визарда ты еще не написал, но как напишешь он будет появляться на локации, а пока вместо него будет обычный гоблин. Да и изменить набор параметров существа в отдельном файле все проще чем рыскать по коду и искать где ты там его создавал.

[AlexYeCu]

Ninja и shinobi - одно и то же, просто в разных вариантах чтения.
Грейд, может, по-другому назвать

Да знаю, но какое название для личинки ниндзи взять?

Может, monk - initiate - master ?

Вариант, но иеромонах лучше звучит, на мой взгляд. В любом случае это пока временно — может кто явный просчёт какой увидит, может у кого идея появится.

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

Смотри, у самих гекс как бы нет вообще ничего. Вот массив карты, к примеру: {1,1,1},{1,2,1},{1,1,3}. Тут он в строчку, но вообще рассматривай как 3x3. Вот из этого массива у нас уже есть тип гексы и её 2d-координаты. Берём тип гексы и смотрим в других массивах:
- высоту гексы (0 на уровне земли, 1 — можно перелететь или перепрыгнуть, видно что за ней, 2 —всё нельзя, -1 — ямка, -2 — большая глубина, т.е. всё просматривается и простреливается, но заходить нельзя).
- затраты st и rt за гексу (та самая сложность местности).
-какой звук воспроизводить, если наступили на гексу этого типа.
-просматривается ли (и простреливается ли) гекса. Пока это работает совместно с проходимостью, но потом, возможно, буду и по отдельности использовать.

Сделать гекс перед ним прозрачным? Если я правильно понял, речь идет про заглядывание в окно или дверной проем?

Не совсем. Вот смотри, есть дом. У дома — дверь. Мы отправляем чара на гексу с дверью, в конце пути открывается интерьер дома с портретами неписей внутри. Так вот, чтобы знать, в какой дом мы зашли, и нужна таблица localtriggers, просто координаты гекс сравниваются с координатами из этой таблицы, если совпали — берём id соответствующего дома. Как-то так. Потом, возможно, перенесу функционал задания триггеров в редактор (дом поставили — в файл уровня записался соотв. триггер), пока это ручками в коде делается. Единственный пользователь редактора (я) вроде не возражает.

[Сулейман]

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

А можно просто у тригерра сделать поле: action. И присвоить ему функцию openHouse. А полю actionParams, массив параметров, где сейчас будет храниться id дома.

При срабатывание тригерра выполняется примерно такой метод.

Код

function trigger:Activate()
self:action(unpack(self:actionParams));
end

[AlexYeCu]

Ну конечно все было не так). Метатаблицы нужны для переопределения встроенных операций - без этого тяжко.

Да я в курсе. Шучу просто.

Так нет разницы, или ты про то что не видишь смысла создавать функции в таблицах, когда можно создать глобальные?

Зачем функции запихивать в таблицы — это я в курсе. А вот зачем в метатаблицы — на работе так и пишу. Но я б не сказал, что это здорово добавляет удобства. Сколько добавляет, столько и отнимает — ну не сишник я, у меня чуть иначе мозги работают.

Почему? А еще можно будет написать Factory.create('goblin_wizard'), а визарда ты еще не написал, но как напишешь он будет появляться на локации, а пока вместо него будет обычный гоблин. Да и изменить набор параметров существа в отдельном файле все проще чем рыскать по коду и искать где ты там его создавал.

А чего мне рыскать? Я ж писал как оно сейчас — есть таблица mobs_stats, в ней изменяемые переменные мобов (stats, resistances, loot, названия и т.д.), есть функция addMob(), которая дописывает недостающее (100500 параметров, какие на момент создания моба нулевые или дефолтные), есть таблица с координатами мобов (и всякими там ai и прочим) — её потом тоже оберну в функцию. В итоге различия разве что в синтаксисе.

Вообще, если любопытно, кидай в личку icq/gtalk/xmpp. Ты, вроде, тоже гексагональными играми увлекался — посмотришь код, может обмен опытом устроим.

А можно просто у тригерра сделать поле: action. И присвоить ему функцию openHouse. А полю actionParams, массив параметров, где сейчас будет храниться id дома.

И как ты до этого поля доберёшься? Ты учти, дом занимает десятка два гекс. При этом его центральная гекса может быть где угодно. И гекса двери где угодно.

При срабатывание тригерра выполняется примерно такой метод.

А как мы определим, что тригер сработал?
Ты предлагаешь увеличить массив карты минимум на треть, чтобы помимо x, y ещё и id-триггера был?

[Сулейман]

И как ты до этого поля доберёшься? Ты учти, дом занимает десятка два гекс. При этом его центральная гекса может быть где угодно. И гекса двери где угодно.

В этом случае у тебя нет объекта дом как такого. Есть клетка на которой висит триггер. В редакторе ты выделяешь клетку и вешаешь ей триггер просто как еще один параметр, лучше массив триггеров. Понятное дело не сам триггер, а ссылку на него.

А как мы определим, что тригер сработал?

А сейчас как определяем? Я бы сделал это в проверке клетки куда наступает герой, там же где ты проверяешь свойства клетки, берешь добавленные ей триггеры и у всех вызываешь функцию Activate(), разумеется у триггера должно быть поле checkCondition(actor), которое будет вызываться, чтобы проверить срабатывает он или нет в данном случае. Ну вот видишь я "неисправимый оопешник", у нас получился неплохой объект. Но куда более хороший чем в C++, так как тут мы легко оперируем функциями как данными.

Ты предлагаешь увеличить массив карты минимум на треть, чтобы помимо x, y ещё и id-триггера был?

Ты беспокоишься о размере занимаемой памяти?
Нет я конечно сумел забить 70 мегабайт оперативки наплодив с миллион объектов типа вот таких гексов, но это не то чтобы критично. Потом правда при выводе графики я забил гиг и до сих пор не понимаю как - ведь картинки не должны были повторно создаваться, они просто брались из определенной переменной для отрисовки. Но серьезно не знаю, зачем может понадобиться миллион игровых объектов. Сейчас карта 180*150 тайлов каждый из которых хранит флаги состояний и имя картинки, плюс еще объекты местоположения для каждого тайла и более сложные юниты в сумме занимают около 50 мегабайт.

Если оптимизировать отрисовку карты как матрицы - то 1000*1000 жрет около 6 метров.

[AlexYeCu]

В этом случае у тебя нет объекта дом как такого. Есть клетка на которой висит триггер. В редакторе ты выделяешь клетку и вешаешь ей триггер просто как еще один параметр, лучше массив триггеров. Понятное дело не сам триггер, а ссылку на него.

Есть две гексы: одна, по которой отрисовавыется спрайт дома, вторая — на которой триггер входа.

А сейчас как определяем? Я бы сделал это в проверке клетки куда наступает герой, там же где ты проверяешь свойства клетки

Оно и сейчас так. Просто триггеры в отдельной 1-d таблице. Сколько домов может быть на карте? 20? 30? Плюс десяток сундуков, плюс всякие там фонтаны-пъедесталы. Ну ок, 100 записей в таблице. Перебрать их не проблема. А для каждой гексы, которых, допустим, 100x100 на карту хранить значения — что-то как-то много.
А уж записывать таблицу триггеров автоматом при сохранении карты — да элементарно.

UP: про сундуки соврал, сундуки и сумки отдельная таблица.

[Сулейман]

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

[AlexYeCu]

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

Хм, вон оно что. Мы немного разное под триггерами понимали. На самом деле, для триггеров домов я проверяю только одну гексу: финальную гексу маршрута. И ту гексу, на которой стою, если получена команда «войти».
Если же речь о гексе, на которую наступил и что-то произошло, тогда да, тут надо отдельную 2d-таблицу с id событий делать. Таблицу именно карты не хочется захламлять зря, я все подобные вещи отдельно выношу.

[AlexYeCu]

Lua 5.3

Поддержка UTF-8 и набора библиотечных функций для манипуляции данными в этом формате (utf8.char, utf8.codes, utf8.codepoint, utf8.len, utf8.offset);

Ждём, когда всё это найдёт отражение в LOVE и loveframes. Новость отличная.

[AlexYeCu]

Кстати, не завалялось ли у кого ttf шрифта с Антагаричским (Эрафийским) алфавитом? С тем, что в книге заклинаний и на дорожных указателях в MMVII?

[tolich]

https://www.dropbox.com/s/w687zgd8jq4o4se/Erathia.ttf - поддерживающий только латиницу шрифт энротскими буквами, вдруг кому-нибудь понадобится.

[AlexYeCu]

https://www.dropbox.com/s/w687zgd8jq4o4se/Erathia.ttf - поддерживающий только латиницу шрифт энротскими буквами, вдруг кому-нибудь понадобится.

404