И свап что ли весь забивается, раз до краша доходит? Можно увеличить. Хотя я вот с 4 гигами живу вообще без него, zram хватает. Ускорения по сравнению со свапом на SSD не чувствую, скорее просто эстетически приятно, что нет лишнего IO и занятого места
Если хочется пожертвовать дисковым кэшем, чтобы программы меньше сваповались, то не обязательно делать это вручную и полностью. Можно просто единожды настроить значение swappiness поменьше, например 10. Это популярное решение для отзывчивости десктопа. На моём ноуте с 4 гигами она после этого резко улучшилась
Python 3.10.7 (main, Nov 24 2022, 19:45:47) [GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> def add(a: int, b: int) -> int:
... return a + b
...
>>> add(1, 2)
3
>>> add(3, 4)
7
>>> # Несмотря на аннотации,
>>> # в рантайме может случиться и такое:
>>> add("5", "6")
'56'
Для меня хорошо работает писать дневник. То есть без явного намерения обязательно перечитать эти мысли позже. Но по факту спустя несколько месяцев я всё равно с большим интересом их перечитываю. Просто повспоминать что-то. Да и почти всегда любопытно оказывается, что какие-то идеи и тенденции начинали в дневнике наклёвываться заранее ещё за несколько месяцев до того как воплотиться в реальные события в жизни.
Выигрыша особого нет. Как сказал @hbrmrk, готовые бинарники могут быть даже быстрее, например если локально компиляция без LTO. Плюсы Gentoo в основном в кастомизации системы, вычищении опциональных зависимостей, уменьшении поверхности атаки, гибком управлении обновлениями, совмещении разных версий пакетов.
Общие объекты в квестах встречаются регулярно - например одинаковые персонажи или локации.
Согласен. Но большинство этих параллельно доступных квестов обычно никаких особых последствий для персонажа/локации не имеют. Скажем, есть локация Х, есть 20 квестов, которым нужно просто побывать в ней в какой-то момент, и есть 1 важный сюжетный квест, после прохождения закрывающий к ней доступ. В этой модели порядок прохождения 20 "обычных" квестов для нас ни на что не влияет, поэтому значимых для нас вариантов прохождения не 21!, а всего лишь 1'048'576 (сумма сочетаний по k вовремя пройденных квестов из 20, для возможных k от 0 до 20).
Например ветки квестов гильгий в TES.
Верно. Но они обычно слабо связаны с внешним миром. Например, в Обливионе ветки гильдий магов и воров не связаны, благодаря чему возможен мем, что архимаг выкрадывает посох сам у себя. Или в Скайриме тёмное братство, убивающее императора, никак не влияет на ход гражданской войны.
А сложность этой изолированной ветки внутри гильдии - см. первый абзац. Обычно на доступность контента влияет только прогресс по основному сюжету гильдии. А условные 10 одновременно доступных побочных квестов друг на друга не влияют.
А нужно ли проверять каждую перестановку? По сути нас волнуют только перестановки внутри наборов квестов, у которых есть общий стейт: использование одного и того же персонажа/предмета/локации, захардкоженное влияние на доступность другого квеста, и т.п. И то, только тогда, когда у хотя бы одного квеста есть сайд-эффекты и этот стейт мутируется: персонаж погибает, квест блокируется и т.п. Наверное, как-то можно отфильтровывать такие ситуации и сильно уменьшить пространство для перебора. А если даже так всё слишком запутанно, слишком много тестов влияют друг на друга и слишком долго всё просчитывается, то может это уже повод дизайнеру задуматься. Потому что и игроку уследить за такими сложными и неочевидными взаимодействиями кучи квестов будет тяжело, и самому дизайнеру поддерживать, чтобы дальше ничего не сломалось.
Не вижу, как тут решается проблема с переписыванием. Что код при изменении квеста надо было переписывать, что этот файлик со скриптами надо будет.
Но в целом согласен, что такой отдельный декларативный файлик удобнее, чем хардкод. Во-первых, быстрое редактирование без перекомпиляции проекта. Во-вторых, в теории им теперь действительно могут заниматься геймдизайнеры/модеры, не являющиеся программистами. В теории даже в блокноте. Знать им потребуется только синтаксис JSON (или другой формат, который вы выберете) и набор сущностей/полей, которые в нём можно объявлять. Его лучше задокументировать. В идеале - составить JSON Schema, тогда и валидация будет автоматизирована, и ИДЕшка при редактировании будет сама все поля подсказывать.
геймдизайнер не сможет по своей прихоти создать новый вид квестов самостоятельно
Эту проблему наверное можно решить, если предоставить скриптам более низкоуровневое API. Не готовые захардкоженные типы квестов, а набор всех доступных действий в игре: "разговор", "убийство" и т.п. Тогда квесты становятся просто контейнерами действий, плюс метаданные с name и description. Условный DeliveryQuest из статьи становится просто Quest, содержащим два Разговора:
И геймдизайнер может комбинировать действия как угодно в нужные ему квесты.
Этот мой пример с массивом действий всё ещё не особо гибкий: он определяет строгую последовательность действий, без альтернативных или опциональных шагов. Также он никак не описывает зависимости между разными квестами. Чтобы сделать всё правильно, есть смысл присмотреться к этому комментарию.
Дисклеймер: я далёк от геймдева, просто увидел заголовок и заинтересовался идеей какой-то обобщённой системы для квестов, которую можно втыкать в различные игры как библиотечку.
Что бросилось в глаза:
TextParser по факту не парсит язык) А просто определяет тип объекта и дальше дёргант класс квеста/спавна, чтобы он сам всё распарсил. Мне кажется, это неправильно, и квестам/спавнам совершенно не нужно отвечать за парсинг своей текстовой репрезентации. Не по SRP это, незачем им про неё знать вообще.
А для чего вообще собственный язык и парсер, если можно взять условный JSON/YAML/XML и готовую библиотеку, которая его распарсит? В языке из статьи например есть баг, что название квеста не может содержать слово "description" (парсер, увидев его, подумает, что название закончилось и надо переходить к описанию). В JSON примеры из статьи выглядели бы так:
И свап что ли весь забивается, раз до краша доходит? Можно увеличить. Хотя я вот с 4 гигами живу вообще без него, zram хватает. Ускорения по сравнению со свапом на SSD не чувствую, скорее просто эстетически приятно, что нет лишнего IO и занятого места
Если хочется пожертвовать дисковым кэшем, чтобы программы меньше сваповались, то не обязательно делать это вручную и полностью. Можно просто единожды настроить значение swappiness поменьше, например 10. Это популярное решение для отзывчивости десктопа. На моём ноуте с 4 гигами она после этого резко улучшилась
Опечатка? Что-то по смыслу не сходится
Для меня хорошо работает писать дневник. То есть без явного намерения обязательно перечитать эти мысли позже. Но по факту спустя несколько месяцев я всё равно с большим интересом их перечитываю. Просто повспоминать что-то. Да и почти всегда любопытно оказывается, что какие-то идеи и тенденции начинали в дневнике наклёвываться заранее ещё за несколько месяцев до того как воплотиться в реальные события в жизни.
С++ не кроссплатформенный? А на чём, по-вашему, рантайм для C# написан?
Выигрыша особого нет. Как сказал @hbrmrk, готовые бинарники могут быть даже быстрее, например если локально компиляция без LTO. Плюсы Gentoo в основном в кастомизации системы, вычищении опциональных зависимостей, уменьшении поверхности атаки, гибком управлении обновлениями, совмещении разных версий пакетов.
Согласен. Но большинство этих параллельно доступных квестов обычно никаких особых последствий для персонажа/локации не имеют. Скажем, есть локация Х, есть 20 квестов, которым нужно просто побывать в ней в какой-то момент, и есть 1 важный сюжетный квест, после прохождения закрывающий к ней доступ. В этой модели порядок прохождения 20 "обычных" квестов для нас ни на что не влияет, поэтому значимых для нас вариантов прохождения не 21!, а всего лишь 1'048'576 (сумма сочетаний по k вовремя пройденных квестов из 20, для возможных k от 0 до 20).
Верно. Но они обычно слабо связаны с внешним миром. Например, в Обливионе ветки гильдий магов и воров не связаны, благодаря чему возможен мем, что архимаг выкрадывает посох сам у себя. Или в Скайриме тёмное братство, убивающее императора, никак не влияет на ход гражданской войны.
А сложность этой изолированной ветки внутри гильдии - см. первый абзац. Обычно на доступность контента влияет только прогресс по основному сюжету гильдии. А условные 10 одновременно доступных побочных квестов друг на друга не влияют.
А нужно ли проверять каждую перестановку? По сути нас волнуют только перестановки внутри наборов квестов, у которых есть общий стейт: использование одного и того же персонажа/предмета/локации, захардкоженное влияние на доступность другого квеста, и т.п. И то, только тогда, когда у хотя бы одного квеста есть сайд-эффекты и этот стейт мутируется: персонаж погибает, квест блокируется и т.п. Наверное, как-то можно отфильтровывать такие ситуации и сильно уменьшить пространство для перебора. А если даже так всё слишком запутанно, слишком много тестов влияют друг на друга и слишком долго всё просчитывается, то может это уже повод дизайнеру задуматься. Потому что и игроку уследить за такими сложными и неочевидными взаимодействиями кучи квестов будет тяжело, и самому дизайнеру поддерживать, чтобы дальше ничего не сломалось.
Анализ зависимостей и выполнимости квестов звучит как задачка на графы. Видел недавно интересную статью как раз про квесты и графы.
Не вижу, как тут решается проблема с переписыванием. Что код при изменении квеста надо было переписывать, что этот файлик со скриптами надо будет.
Но в целом согласен, что такой отдельный декларативный файлик удобнее, чем хардкод. Во-первых, быстрое редактирование без перекомпиляции проекта. Во-вторых, в теории им теперь действительно могут заниматься геймдизайнеры/модеры, не являющиеся программистами. В теории даже в блокноте. Знать им потребуется только синтаксис JSON (или другой формат, который вы выберете) и набор сущностей/полей, которые в нём можно объявлять. Его лучше задокументировать. В идеале - составить JSON Schema, тогда и валидация будет автоматизирована, и ИДЕшка при редактировании будет сама все поля подсказывать.
Эту проблему наверное можно решить, если предоставить скриптам более низкоуровневое API. Не готовые захардкоженные типы квестов, а набор всех доступных действий в игре: "разговор", "убийство" и т.п. Тогда квесты становятся просто контейнерами действий, плюс метаданные с name и description. Условный DeliveryQuest из статьи становится просто Quest, содержащим два Разговора:
И геймдизайнер может комбинировать действия как угодно в нужные ему квесты.
Этот мой пример с массивом действий всё ещё не особо гибкий: он определяет строгую последовательность действий, без альтернативных или опциональных шагов. Также он никак не описывает зависимости между разными квестами. Чтобы сделать всё правильно, есть смысл присмотреться к этому комментарию.
UPD: невнимательно прокопипастил ChatQuest, должно быть так:
Дисклеймер: я далёк от геймдева, просто увидел заголовок и заинтересовался
идеей какой-то обобщённой системы для квестов, которую можно втыкать в
различные игры как библиотечку.
Что бросилось в глаза:
TextParserпо факту не парсит язык) А просто определяет тип объекта идальше дёргант класс квеста/спавна, чтобы он сам всё распарсил.
Мне кажется, это неправильно, и квестам/спавнам совершенно не нужно
отвечать за парсинг своей текстовой репрезентации. Не по SRP это, незачем
им про неё знать вообще.
А для чего вообще собственный язык и парсер, если можно взять условный
JSON/YAML/XML и готовую библиотеку, которая его распарсит?
В языке из статьи например есть баг, что название квеста не может
содержать слово "description" (парсер, увидев его, подумает, что название
закончилось и надо переходить к описанию).
В JSON примеры из статьи выглядели бы так:
Интересно, почему решения именно такие.