Все ку
Собственно тут философский вопрос возник во время работы
Я уже год ковыряю django (это не особо важно, то же самое можно и на laravel и прочих фреймворках делать) пишу потихоньку текстовую игру, иногда тут проблемы по технической реализации задаю, мне отвечают, за что спасибо всем участникам.
Написал разные приколы(инвентарь героя, выпадение вещей, всякие разные мелкие плюшки) и дошел до реализации заданий, тут то и осел.
Предположим у меня сюжетная линии имеет 73 основных задания и 34 побочных(разумеется награды за задания разные: золото, серебро, предметы экипировки, зелья и прочая чепуха)
Ранее задавал вопрос о реализации заданий и как хранить такую логику в бд(задания с разными типами наград и тп) мне предложили хранить разные типы заданий в отдельных таблица(изначально я склонялся к сериализации и прочим подобным методам) в итоге решил делать так как посоветовали
Собственно вопрос
Есть 73 выше упомянутых задания и 34 побочных (часть из них можно выполнять попутно,часть по мере закрытия предыдущих и тп)
В моей голове появлялось несколько вариантов реализации с технической точки зрения
1) налепить 1000 if elif
2)названия,id выполненных хранить в массиве и каждый раз при принятии нового задания вытягивать завершенные - это по идее сократит кол-во условных конструкций
В итоге я не пойму как сделать правильно, является ли мои способы реализации оптимальными или они вообще бредятина
Просто реализовывая мои способы код превратится в сущий ад, который не то что кто-то другой разобрать не сможет, а я уже на след. день схвачусь за голову
Для каждого задания составляется свой граф.
Определяются общие узлы между этими графами (если они есть), перекрёстные триггеры (также, при необходимости).
У основного "бегунка" по графу (их может быть несколько!) есть:
1. id основного/текущего задания и
2. id узла на графе этого задания (следующая ожидаемая контрольная точка прогресса выполнения текущего задания).
Вот эти 2 параметра - Вы всегда храните как текущее состояние игрока в отношении заданий.
Средний
