Ещё один проект рогалика на Python:заметки, вопросы, идеи

Темы, связанные с проектированием и программированием roguelike-игр

Модераторы: Sanja, Максим Кич

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 24 янв 2015, 11:48

Написал примитивную реализацию карты. Если игра запустится на моей версии питона, в неё можно будет играть :) управление пока вводом команд с клавиатуры вроде move 1 -1, так как пока вообще не мучался с интерфейсом. Потом разберусь с libtcode. Никогда раньше не занимался графикой в программах, интересно будет, я думаю. Думаю, будет достаточно стандартной ASCI рогаликовой карты по центру по типу Brogue (много оттенков, яркие цвета, активное использование света и цвета фона), строчки с какой-то информацией сверху или снизу, и достаточно приличного по ширине столбца сбоку, который будет содержать что-то вроде компаса. Мне кажется, это несложно сделать с помощью данной библиотеки.
Ещё не сделал инвентарь и носимые предметы. Не знаю, нужно ли это, и если да, то на каком уровне абстракции (нужны ли персонажи-негуманоиды, персонажи с произвольным количеством слотов).
Столкнулся с проблемой: неудобно сопоставлять один и тот же ИИ разным монстрам и наоборот (нужно смотреть в список и так далее). Решение — называть ИИ и корпусы по типу Dingo_corpse и Dingo_AI, пусть даже с введением избыточных названий. К сожалению, не знаю, как сделать автоматическое указание на класс X_AI из класса X_corpse, и будет сделано это не очень хорошо.
Сейчас у меня не совсем простое наследование классов: некоторые классы сначала вызывают в своём конструкторе метод-конструктор своего родителя, и только потом выполняют свой. Это помешает мне создавать монстров с автоматически прописываемым AI, если я не буду прописывать во все классы монстров тем или инфм способом ту некрасивую конструкцию, что так режет мой глаз и вызывает метод-конструктор родителя. Ещё, конечно, можно сделать более удобный генератор карты, который будет прописывать это автоматически, но пока его нет.

Возможные ветки развития
  • Интерфейс. Важная часть, если буду напирать на атмосферу, самая важная, но плохо тестируемая с моим текущим аппаратным обеспечением. Интересна из-за её новизны.
    Генератор подземелья. Будет создавать подземелье с монстрами и всем-всем, позволяя задавать параметры в удобном виде. Лучше всего задавать всё текстовым файлом, но это как пойдёт. Важен, если я не хочу писать большие вызовы функций в питоне и хочу генерировать много случайного. Менее важен, если я буду делать много частично заданных заранее карт.
    Основные фичи игровой механики. Их 3 (или даже 4), все будут в том или ином виде, смертельно хочется закодить их прямо сейчас, но я сдерживаюсь. Всё потому, что есть
    Простые фичи (которые даже и не фичи, а базовый набор рогалика), вроде предметов, инвентаря, стрельбы.
    И наконец наполнение, которое включает в себя карты и генераторы уровней, связи уровней, монстров, изображения и звук, хитрые типы атак и всё такое. Может быть, даже магия, но лучше в каком-то менее прямом понимании, чем фаерболы и магические щиты.

Аватара пользователя
Oreyn
Сообщения: 297
Зарегистрирован: 07 авг 2013, 14:59

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Oreyn » 24 янв 2015, 16:57

Типов AI по идее не должно получатся слишком много - милишник, дистанционщик и суппорт.
И если у тебя динго отличается от других тем что ест трупы и лечится, добавь тушке флаг "VULTURE" и туда же реализацию.
В итоге когда ты будешь наполнять контент игры, вместо того чтобы копировать реализацию питания падалью из динго в гоблина скавенжера (уже подзабыв как она работает там и делая ошибки), ты просто докидываешь новому юниту флаг и базовый АИ подхватывает новую способность.

Это же касается и всяких "спец. абилок" в бою, вместо конкретных реализаций в отдельных AI ты выносишь их в базовые функции. И абстрагируешься от конкретики "паук кидает паутину", и идешь к обобщенному что у тушки моба могут быть "спец. абилки". И general AI решает ему сейчас базовую атаку сделать, или какую-то абилку применить (например рандомно, или специально пытается сначала потратить абилки).

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 24 янв 2015, 17:30

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

Получается, класс АИ будет только один? Это хорошо и удобно. Нужно ещё придумать, как хранить флаги (на оптимизацию нельзя забивать вечно), но в целом, всё будет удобно и просто. Какие-то ИИ, возможно, будут написаны специально для конкретных монстров, и будут записываться там же. Вот только тогда разрастётся та часть кода, которая отвечает за "сенсоры" (тушки могут получать информацию разными способами. Впрочем, там лишь добавление простых ифов в методы) и проверку доступности того или иного ИИ для данного тела (при его начальной установке или смене). Понимаю, что это лишнее усложнение, но оно может потребоваться для реализации тех или иных фич. Признаюсь, что очень хочется писать свой ИИ для каждого моба отдельно. Тогда лучше будет задавать ИИ числом, которое либо указывает нужный ИИ из уникальных, либо равно -1 и тогда АИ задаётся набором флагов.

Аватара пользователя
Oreyn
Сообщения: 297
Зарегистрирован: 07 авг 2013, 14:59

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Oreyn » 24 янв 2015, 18:12

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

UPD: Технически подходы можно и совмещать. Особенности которые могут встречаться у нескольких мобов реализуешь в "теговом" конструкторе в базовом АИ/тушке. Уникальный АИ/особенность который будет только в одном специфическом мобе - в своем класе потомке от базового АИ.

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 24 янв 2015, 18:49

Да, так можно. Еще правильней сделать конструктор наследником базового класса АИ.

Ещё питон позволяет делать множественное наследование, и так тоже можно конструировать мобов, но как-то оно не совсем хорошим кажется. Ошибаюсь, возможно. Спать нужно.

Аватара пользователя
Cfyz
Сообщения: 767
Зарегистрирован: 30 ноя 2006, 10:03
Откуда: Санкт-Петербург
Контактная информация:

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Cfyz » 24 янв 2015, 20:08

Oreyn писал(а):Да и учти, что я возможно слишком увлекаюсь этим подходом с тегами, и агитирую других. Такое оправданно если в итоге "трупоеденье" встретится больше чем в одном мобе. <...> Если же ты четко уже представляешь весь список мобов, и то что конкретная особенность и абилка будет только у одного моба, это будет только лишний уровень абстракции.
Посмею возразить. Не трупоедение, так что-то другое точно будет у нескольких типов монстров, так что реализация свойства через флаг (тег) будет "бесплатной" даже если флаг в итоге окажется только у одного типа.
Tookser писал(а):Ещё питон позволяет делать множественное наследование, и так тоже можно конструировать мобов, но как-то оно не совсем хорошим кажется.
Наследование для решения этой задачи неподходящий инструмент. Наследование подразумевает, что один из объектов -- строго подмножество другого, что не выполняется для свойств игровых существ. Их особенности могут образовывать произвольно пересекающиеся группы, превращая иерархию наследования в натуральный костыль.

Вместо наследования в таких случаях обычно применяется агрегация (композиция). Это когда вместо выбора существа строго из набора возможных вариантов (комбинации базовых классов), оно реализуется как мешок отдельных частей. Например, вместо того, чтобы наследоваться от "ICanEatCorpses", существо получает соответствующую реализацию компоненты, ответственной за еду. Само собой, надо понимать, что ООП это не обязательно сразу классы и методы. Одним из простых вариантов (самым простым?) будет именно система флагов. Отдельные флаги вкупе с соответствующими им ветками условий будут играть роль возможных компонент существа.

Главными особенностями агрегации по сравнению с наследованием являются:
1. Свобода выбора при конструировании объекта-существа: оно выбирается из произвольной комбинации взаимозаменяемых компонент, а не из того, что получилось унаследовать.
2. Простота доработки. Изменения в отдельной компоненте или цепочке компонент не затрагивают все остальные аспекты существа, которым не посчатливилось попасться на пути наследования.
Пытается раскуклиться

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 24 янв 2015, 22:37

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

Интересно, можно ли заменить n-часовой рефакторинг n-часовым созерцанием своего кода? Понятно, что будет не лучше, но насколько не лучше? (разумеется, не собираюсь делать так).
Не вижу, где нужны декораторы в рогалике. Логирование, может быть.
Как можно изучать libtcod без возможности его запуска? Поищу видеоуроки, конечно, да и текстовые туториалы есть на сайте автора, но это всё не сравнится с живым кодом.

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 26 янв 2015, 11:14

Немного потестировал игру на старом питоне 2.5. Работает пока лишь часть модулей (после исправления нескольких очевидных ошибок натыкается на dictionary comprehension, который либо неправильно написан, либо не поддерживается этим питоном). Поправил несколько ошибок. Инвентарь нужно будет сделать как набор методов, а не как список.
Почитал о Libtocod. Всё достаточно просто и понятно, и не думаю, что возникнут принципиальные проблемы с интерфейсом вида "карта, строка лога сверху и столбец параметров справа" как в Brogue (к сожалению, мой столбец получается более нагруженным). Хочется читать гейм-дизайн, писать диздок на маловажные и пока малопонятные вещи и не кодить активно.

Аватара пользователя
Jesus05
Сообщения: 1839
Зарегистрирован: 02 дек 2009, 07:50
Откуда: Норильск, сейчас Санкт-петербург.
Контактная информация:

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Jesus05 » 27 янв 2015, 05:32

Tookser писал(а): ...
Хочется читать гейм-дизайн, писать диздок на маловажные и пока малопонятные вещи и не кодить активно.
Не сдерживай себя, читай гейм-диз и пиши диздок.

Аватара пользователя
Apromix
Мастер
Сообщения: 1188
Зарегистрирован: 04 июл 2011, 10:44
Откуда: Украина, Черновцы
Контактная информация:

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Apromix » 27 янв 2015, 21:32

Tookser писал(а):Как можно изучать libtcod без возможности его запуска?
Странно все это... Есть прекрасная разработка на этом сайте - Terminal. Почему не использовать его?

Аватара пользователя
Феникc
Сообщения: 679
Зарегистрирован: 27 ноя 2010, 15:01
Откуда: Челябинск

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Феникc » 28 янв 2015, 03:43

Apromix писал(а):Странно все это... Есть прекрасная разработка на этом сайте - Terminal. Почему не использовать его?
Удваиваю, это действительно проще. Ещё и в будущем будет потенциал для, например, локализации или перехода на тайлы, причём платить за это сейчас не придётся. Документация вся нативно на русском, да ещё и автор регулярно появляется даже вот в этом самом треде, так что никаких проблем быть не должно. Не понимаю, зачем тебе libtcod, чего в нём есть такого, чего нет в BearLibTerminal?
Всё вышесказанное - ИМХО, если не указано обратное.

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 29 янв 2015, 04:17

Apromix писал(а):
Tookser писал(а):Как можно изучать libtcod без возможности его запуска?
Странно все это... Есть прекрасная разработка на этом сайте - Terminal. Почему не использовать его?
Феникc писал(а):
Apromix писал(а):Странно все это... Есть прекрасная разработка на этом сайте - Terminal. Почему не использовать его?
Удваиваю, это действительно проще. Ещё и в будущем будет потенциал для, например, локализации или перехода на тайлы, причём платить за это сейчас не придётся. Документация вся нативно на русском, да ещё и автор регулярно появляется даже вот в этом самом треде, так что никаких проблем быть не должно. Не понимаю, зачем тебе libtcod, чего в нём есть такого, чего нет в BearLibTerminal?
Думаю, действительно BearLibTerminal будет удобнее. Пора начинать писать.
Задумался над организацией предметов. Понятно, что достаточно просто сделать предметы, просто увеличивающие параметры, хотя даже тут есть небольшое "но" (дальше много слов о том, что к моей игре не относится).
Скрытый текст: ПОКАЗАТЬ
Если предмет требует каких-то параметров для надевания (и сам увеличивает другие параметры при этом), при примитивной проверке требуемых параметров только при надевании может возникнуть следующая ситуация. Для надевания желаемого комплекта вещей можно временно надеть "кольцо +100 к интеллекту", надеть вещи, требующие много интеллекта, а потом снять кольцо и заменить его "кольцом +200 к атаке". Тогда либо нужно принять такую возможность, либо при каждом надевании/снятии вещи проверять, можно ли снять и надеть каждую вещь из надетых, и блокировать действие в противном случае.
Но куда сложнее сделать разные посохи/оружие с дополнительными эффектами. Пока не буду делать много разных предметов, а сделаю только надевающиеся увеличители статов, зелья и книги. Система предметов будет зависеть от боевой системы.

Cfyz, согласен с тем, что композиция будет лучше. Просто реализовываться она будет через множественное наследование, может быть, это нужно делать не так (можно и по флагам, так даже удобнее - набор методов можно будет произвольно задавать по флагам).

Медленно читаю "Next level", и при каждой попытке программирования натыкаюсь на несформулированные требования. Нужен диздок.

Аватара пользователя
Uvadzucumi
Сообщения: 365
Зарегистрирован: 29 ноя 2011, 07:13
Откуда: Дубай, ОАЭ (Минск, Беларусь)
Контактная информация:

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Uvadzucumi » 29 янв 2015, 08:59

Tookser писал(а):
Скрытый текст: ПОКАЗАТЬ
Если предмет требует каких-то параметров для надевания (и сам увеличивает другие параметры при этом), при примитивной проверке требуемых параметров только при надевании может возникнуть следующая ситуация. Для надевания желаемого комплекта вещей можно временно надеть "кольцо +100 к интеллекту", надеть вещи, требующие много интеллекта, а потом снять кольцо и заменить его "кольцом +200 к атаке". Тогда либо нужно принять такую возможность, либо при каждом надевании/снятии вещи проверять, можно ли снять и надеть каждую вещь из надетых, и блокировать действие в противном случае.
была такая система в одной онлайн игре (и сейчас, как понимаю, она есть), это было заточено как часть геймплея. можно было одеть вещь, дающую +к статам, потом одеть другую с требованиями к минимальным статам и снять первую. в результате все игроки держали целый гардероб итемов для переодевания. т.к. чтобы одеть броню на свой левел - нужно было около 10-15 предметов в определенном порядке одевать/снимать. причем, там был такой механизм, что если тебя ранили в ногу, то штаны снимаются! в результате одеть назад ты уже не сможешь их, без гардероба в рбюзаке. т.е. я это к тому, что система требований шмота к минимальным статам только добавляет гемороя игроку а плюсов я как то не вижу совсем, раз все равно одеть вешь можно. если игра РПГ, то, IMHO, лучше сделать навык владения тем или иным предметом и от него плясать. причем, навык владения кольчужной броней маг, например, выучить не может совсем, но может лучник, у мечника он уже изначально изучен, причем чем выше прокачен навык, тем больше бонусов дает броня и т.д.
Меня окружали милые, добрые люди... медленно сжимая кольцо

Tookser
Сообщения: 155
Зарегистрирован: 08 апр 2010, 11:09

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Tookser » 29 янв 2015, 10:06

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

Аватара пользователя
Oreyn
Сообщения: 297
Зарегистрирован: 07 авг 2013, 14:59

Re: Ещё один проект рогалика на Python:заметки, вопросы, иде

Сообщение Oreyn » 29 янв 2015, 10:23

По системе бонусов от надетых предметов, есть два подхода - событийный (надели - накинули бонус) и калькуляционный (каждый раз при обращении к стату считаем сумму от всех возможных источников бонусов). Каждый со своими достоинствами и недостатками. Я делал событийный, плюс выносил само понятие модифицируемого стата в класс. Который управляет значениями базовым и результирующим, бонусами абсолютным (+1) и относительным (+10%).

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

По поводу диздока - опять таки целиком поддерживаю.

Ответить

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость