Ещё один проект рогалика на Python:заметки, вопросы, идеи
Модераторы: Sanja, Максим Кич
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Кстати, хочу дать один совет - активно используй assert! Любая функция, абсолютно любая, должна начинаться с проверки входных данных с его помощью - это сэкономит тебе кучу нервов, если ты не используешь тестирование. Ну а если дополнить это ещё и assert'ом возвращаемого значения, то это вообще снимет с тебя кучу рутинной работы по отлову мелких багов, которые ещё к тому же могут быть и не замечены сразу.
Может поделишься хотя бы общей концепцией игры? Интересно ведь.
Скрытый текст: ПОКАЗАТЬ
Всё вышесказанное - ИМХО, если не указано обратное.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Описал боевую систему. Осталась, конечно, балансировка численных параметров, но зато хоть понятно, что балансировать. Неясно, что делать с оружием дальнего боя, но вроде оно не должно сильно отличаться от обычного. Магии прямого действия почти не будет. Формулы для количества снятого урона пока останутся примитивными.
Подумал, что при "целом" тайминге нужно либо смириться с тем, что очерёдность действий будет не меняться (два бойца будут бить друг друга строго по очереди), либо что-то поменять.
Феникс, всё верно. Просто не хотелось тратить время на проверку данных, а надо. Задумку пока не хочется описывать целиком.
Если вкратце — это будет roguelike с неравномерной случастью мира и сильным крёном в сторону rpg, имеющий несколько ключевых фич. С сеттингом пока проблемы. Думаю, будет некоторая графика, звук и тексты, но движок пока не готов.
Фичи:
Подумал, что при "целом" тайминге нужно либо смириться с тем, что очерёдность действий будет не меняться (два бойца будут бить друг друга строго по очереди), либо что-то поменять.
Феникс, всё верно. Просто не хотелось тратить время на проверку данных, а надо. Задумку пока не хочется описывать целиком.
Если вкратце — это будет roguelike с неравномерной случастью мира и сильным крёном в сторону rpg, имеющий несколько ключевых фич. С сеттингом пока проблемы. Думаю, будет некоторая графика, звук и тексты, но движок пока не готов.
Фичи:
- Боевая система, основанная на разделении игрока на части.
Наличие слуха и обоняния у игрока.
Наличие раздичных промежуточных игровых целей (к примеру, превратить пустыню в сад, или помочь одной армии победить другую).
- Apromix
- Мастер
- Сообщения: 1236
- Зарегистрирован: 04 июл 2011, 10:44
- Откуда: Украина, Черновцы
- Контактная информация:
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Одна мысль по поводу предметов. Броня как пример. У нас есть на кукле несколько слотов для экипировки брони: шлем (+7), кираса (+20) и перчатки (+3). Вместе это будет +30 к защите. А я предлагаю такую формулу - защита / кол-во слотов , то есть у нас будет только +10 к защите (30 / 3 = 10). Думаю хорошо будет работать там, где бронь - это проценты, скажем вероятность попасть по игроку или отразить атаку ну и т.д. Ну и второй бонус - больше можно придумать разных предметов
- Cfyz
- Сообщения: 776
- Зарегистрирован: 30 ноя 2006, 10:03
- Откуда: Санкт-Петербург
- Контактная информация:
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Apromix, что-то непонятное с предложенным вариантом. Если сумма делится на количество использованных слотов, то это выглядит странно, так как чуть ли не любая броня меньше максимально одетой будет только ухудшать результат. А если сумма делится на общее количество возможных слотов, то это просто вносит фиксированный коэффициент, можно сразу все модификаторы брони на него поделить.
Пытается раскуклиться
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
100%, да, ассерты очень сильно помогают. Особенно в native языках программирования, ну а в релиз компиляции от них и избавиться можно полностью. Не знаю, как в питоне.Феникc писал(а):Кстати, хочу дать один совет - активно используй assert! Любая функция, абсолютно любая, должна начинаться с проверки входных данных с его помощью - это сэкономит тебе кучу нервов, если ты не используешь тестирование. Ну а если дополнить это ещё и assert'ом возвращаемого значения, то это вообще снимет с тебя кучу рутинной работы по отлову мелких багов, которые ещё к тому же могут быть и не замечены сразу.
Разумеется, тру-вэй - это стопроцентное покрытие кода тестами, но если ещё не приучил себя к ним, то хоть так поберегись.
Проверка параметров выдает баги сразу и порой в самых неожиданных местах. Где ты ни за что бы не подумал, что вот здесь может случиться ошибка. Кстати, не только входных параметров, внутри функции тоже. Без фанатизма, конечно.
Такие проверки обычно работают только в дебаг режиме, и автоматически полностью выпиливаются в релизе. За счет препроцессора, в питоне вроде тоже это возможно.. if __debug__ def assert код проверки, else def assert пустота Ж) Как-то такTookser писал(а): Феникс, всё верно. Просто не хотелось тратить время на проверку данных, а надо. Задумку пока не хочется описывать целиком.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Думаю, Tookser говорит не о процессорном времени. Впрочем, это и не особо важно, потому как в любом случае проверки сберегут и время разработчика (за счёт раннего выявления и исправления багов) и процессорное (те же невыявленные баги могут сильно сократить КПД, вплоть до нуля, если ошибка окажется фатальной). Ну и в питоне (как и везде, в общем-то) assert - это, по сути, if, который в случае неверного условия поднимает AssertionError. Не думаю что это даст большое падение производительности, особенно учитывая что питон и так ею не блещет.Anfeir писал(а):Такие проверки обычно работают только в дебаг режиме, и автоматически полностью выпиливаются в релизе. За счет препроцессора, в питоне вроде тоже это возможно.. if __debug__ def assert код проверки, else def assert пустота Ж) Как-то такTookser писал(а): Феникс, всё верно. Просто не хотелось тратить время на проверку данных, а надо. Задумку пока не хочется описывать целиком.
И таки да, ассерты могут быть выключены. https://wiki.python.org/moin/UsingAssertionsEffectively
If Python is started with the -O option, then assertions will be stripped out and not evaluated. So if code uses assertions heavily, but is performance-critical, then there is a system for turning them off in release builds. (But don't do this unless it's really necessary. It's been scientifically proven that some bugs only show up when a customer uses the machine and we want assertions to help there too.)
Последний раз редактировалось Феникc 31 янв 2015, 10:50, всего редактировалось 1 раз.
Всё вышесказанное - ИМХО, если не указано обратное.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Я имел в виду время разработки. Ещё стоит использовать type() и isinstance().Anfeir писал(а):Такие проверки обычно работают только в дебаг режиме, и автоматически полностью выпиливаются в релизе. За счет препроцессора, в питоне вроде тоже это возможно.. if __debug__ def assert код проверки, else def assert пустота Ж) Как-то такTookser писал(а): Феникс, всё верно. Просто не хотелось тратить время на проверку данных, а надо. Задумку пока не хочется описывать целиком.
Сейчас перепишу часть кода для использования флагов.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
время разработки от ассертов только уменьшится
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Добавил первые assert'ы. Дописал часть кода для использования мобами системы флагов. Часть флагов на теле моба будет определять его интеллект, возможно. В связи с добавлением флагов отрефакторил и сократил код для ИИ.
Добавляю новые assert'ы и привыкаю к их виду.
Добавляю новые assert'ы и привыкаю к их виду.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Подумал о деревьях, клеточных автоматах и неожиданно увлёкся ими. Они очень красивые. Больше всего мне понравился wireworld и циклические клеточные автоматы (которые разноцветные).
Для рогалика могут пригодиться, к примеру, при рассадке динамической растительности (леса, рощи, рост мха, джунгли)… и всё. Обидно, но придумать какое-то оригинальное их применение не получается. Разве что генерация уровней, или какие-нибудь головоломки вроде "пройди по зелёным клеткам". Ещё можно таким образом обрабатывать разный огонь и тому подобное.
Для рогалика могут пригодиться, к примеру, при рассадке динамической растительности (леса, рощи, рост мха, джунгли)… и всё. Обидно, но придумать какое-то оригинальное их применение не получается. Разве что генерация уровней, или какие-нибудь головоломки вроде "пройди по зелёным клеткам". Ещё можно таким образом обрабатывать разный огонь и тому подобное.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Где-то на форуме есть даже тема про генерацию карты клеточными автоматами, можешь поискать.
Всё вышесказанное - ИМХО, если не указано обратное.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Там мало, автор дальше примитивного рандомного рытья тоннелей не дошел, хотя обещал поразить нас мощью алгоритма.Феникc писал(а):Где-то на форуме есть даже тема про генерацию карты клеточными автоматами, можешь поискать.
Если честно, клеточные автоматы - это здорово. Но уж больно академическая задача, чем практическая.
А настройка генерации будет выглядеть вот так:
Скрытый текст: ПОКАЗАТЬ
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
Лучше, думаю, использовать их как что-то вторичное, вроде добавления зелени. К примеру, циклический клеточный автомат может генерировать зоны растительности, которые потом можно засаживать деревьями с настраиваемой частотой.
Примерно придумал фабулу игры. Если коротко, будет небольшой изменяемый город и некоторое количество квестов. Акцент в сюжете будет делаться на непрямое влияние на мир, некоторую самостоятельную активность мира, небольшой размер квестов.
Стоит подумать, как реализовать запахи и звук. Либо это будет просто стрелка на компасе, указывающая на источник запаха/звука, либо что-то более сложное. Более сложное делать не хочется (не будет иметь значения для игрока, поэтому стоит продумать, как сделать разные запахи/звуки так, чтобы они различались. И стоит ли делать отличие между звуком и запахом, в примитивной модели со стрелками на источник звука/запаха они одинаковы. И как реализовать разную силу запаха/звука, и прочее. И будут ли они храниться отдельно, или нет. И как там будет с производительностью.
Единственное, чем в примитивной модели отличаются звук и запах — это отсутсттвие направления у очень низких звуков. Тогда задача упрощается.
Примерно придумал фабулу игры. Если коротко, будет небольшой изменяемый город и некоторое количество квестов. Акцент в сюжете будет делаться на непрямое влияние на мир, некоторую самостоятельную активность мира, небольшой размер квестов.
Стоит подумать, как реализовать запахи и звук. Либо это будет просто стрелка на компасе, указывающая на источник запаха/звука, либо что-то более сложное. Более сложное делать не хочется (не будет иметь значения для игрока, поэтому стоит продумать, как сделать разные запахи/звуки так, чтобы они различались. И стоит ли делать отличие между звуком и запахом, в примитивной модели со стрелками на источник звука/запаха они одинаковы. И как реализовать разную силу запаха/звука, и прочее. И будут ли они храниться отдельно, или нет. И как там будет с производительностью.
Единственное, чем в примитивной модели отличаются звук и запах — это отсутсттвие направления у очень низких звуков. Тогда задача упрощается.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
У Бискупа в Адоме посаженые травы плодятся по правилам Конвеевского автомата Life.
Re: Ещё один проект рогалика на Python:заметки, вопросы, иде
В катаклизме звуки, который ты слышишь вне пределов видимости рисуются знаками вопросов по черному фону в приблизительной точке откуда идет звук. Верю что там алгоритмом специально случайно сдвигают знак. Весьма удобно и наглядно.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 24 гостя