Форум PHP программистов > Как организовать систему квестов в онлайн игре

igolka97

21.02.2015 - 20:57

Ребята, привет.

Кароче, на сей раз передо мной встала следующая задача:
Надо организовать систему квестов в онлайн игре. Тоесть вручение заданий по достижению какой либо цели (получил новый LVL или купил какой нибудь предмет), а так же завершение этого задания, по достижению какой либо заданной цели. В чем вопрос - все данные хранятся в разных таблицах, и каждый раз запускать огромный foreach по с огроменной цепочкой if-ов не ризон ваще делая 100500 запросов по базе данных

И вот сижу уже который день думаю как это все организовать? Кто сталкивался с таким уже? Можеи есть какие то статьи на примете? Гугл уже весь облазил, ничего кроме самих онлайн игр и тутореалов по созданию квест игр на flash не нашел

Или может есть проекты с открытым кодом на гитхабе? Или объясните в двух словах? Кароче, дайте кто что может..

Valick

21.02.2015 - 21:44

собственно непонятно в чём проблема
никаких "foreach с огроменной цепочкой if-ов" конечно же не надо
доступность квеста для определённого игрока происходит по ряду признаков (уровень, наличие пердмета в инвентаре, выполнение предыдущего задания или цепочки заданий и тд) всё это храниться в БД, и в принципе не составляет труда сделать выборку по этим критериям

есть квест
у него есть описание
есть условия доступности
и есть условия выполнения

есть таблица юзеров

и должна быть таблица связи юзеров и квестов

_____________
Стимулятор ~yoomoney - 41001303250491

igolka97

21.02.2015 - 23:04

Цитата (Valick @ 21.02.2015 - 21:44)

собственно непонятно в чём проблема
никаких "foreach с огроменной цепочкой if-ов" конечно же не надо
доступность квеста для определённого игрока происходит по ряду признаков (уровень, наличие пердмета в инвентаре, выполнение предыдущего задания или цепочки заданий и тд) всё это храниться в БД, и в принципе не составляет труда сделать выборку по этим критериям

есть квест
у него есть описание
есть условия доступности
и есть условия выполнения

есть таблица юзеров

и должна быть таблица связи юзеров и квестов

Я понял так, что цели должны быть в бд, и выполнять такой запрос:

SELECT * FROM `user_quests` WHERE `user_id` = `id` JOIN `quests_info` ...

и тд?

Valick

21.02.2015 - 23:26

igolka97, ну типа да. По идее вся логика игрового движка должна быть на уровне СУРБД.
просто сами квесты необходимо унифицировать, по идее квесты убить 10 медведей, убить 7 волков, или собрать 15 ромашек, с точки зрения логики выполнения ничем не отличаются, БД вообще фиолетово кого вы убиваете или что вы собираете. Основное тут количество квестовых предметов. Правда в первом и втором случае - это действие, а в третьем - это наличие в инвентаре. Но сточки зрения кода опять же нет разницы, просто разные таблицы.
При унификации квест как сущность должен учитывать всё что я описал, а вот присутсвовать в квесте могут не все части.
Например вернёмся к нашим баранам.
Можно просто убить 10 баранов, а можно убить 10 баранов собрать с них 5 шкур.
Т.е у нас экшен из одной таблицы и итем из другой таблицы.
На самом деле это всего лишь упрощённая модель.
Нпример при принятии квеста может выдаваться какой-то квестовый предмет (например ритуальный нож для убийства баранов, и килы по баранам будут засчитываться только если их убили этим ножом), а может и не выдаваться, но модель должна учитывать оба варианта, точнее самый полный вариант.

_____________
Стимулятор ~yoomoney - 41001303250491

igolka97

21.02.2015 - 23:48

Цитата (Valick @ 21.02.2015 - 23:26)

igolka97, ну типа да. По идее вся логика игрового движка должна быть на уровне СУРБД.
просто сами квесты необходимо унифицировать, по идее квесты убить 10 медведей, убить 7 волков, или собрать 15 ромашек, с точки зрения логики выполнения ничем не отличаются, БД вообще фиолетово кого вы убиваете или что вы собираете. Основное тут количество квестовых предметов. Правда в первом и втором случае - это действие, а в третьем - это наличие в инвентаре. Но сточки зрения кода опять же нет разницы, просто разные таблицы.
При унификации квест как сущность должен учитывать всё что я описал, а вот присутсвовать в квесте могут не все части.
Например вернёмся к нашим баранам.
Можно просто убить 10 баранов, а можно убить 10 баранов собрать с них 5 шкур.
Т.е у нас экшен из одной таблицы и итем из другой таблицы.
На самом деле это всего лишь упрощённая модель.
Нпример при принятии квеста может выдаваться какой-то квестовый предмет (например ритуальный нож для убийства баранов, и килы по баранам будут засчитываться только если их убили этим ножом), а может и не выдаваться, но модель должна учитывать оба варианта, точнее самый полный вариант.

хм...
Итак: тогда на каком уровне выполнять этот запрос?
Я представляю себе это примерно так:

Загружаем страницу, выполняя запрос, есть ли доступные задания, относительно LVL,
Если есть, до добавляем номер этого квеста в таблицу незавершенных квестов пользователей
Дальше каждый раз при загрузке любой страницы делаем запрос из таблицы незавершенных квестов, и присоединяем к ней информацию о квестах.
Остался вопрос, как сравнивать, на каком уровне и в какой форме сделать условие завершенности задания? Надо будет для каждого условия делать еще по запросу в разные таблицы, там где хранится информация о пользователе и его действии?

Valick

22.02.2015 - 04:06

Цитата (igolka97 @ 21.02.2015 - 22:48)

Если есть, до добавляем номер этого квеста в таблицу незавершенных квестов пользователей

только после того как пользователь нажмёт кнопку "принять квест"
до этого момента квест будет просто доступен, никаких других проверок кроме доступности проводить не надо

Цитата (igolka97 @ 21.02.2015 - 22:48)

Остался вопрос, как сравнивать, на каком уровне и в какой форме сделать условие завершенности задания?

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

_____________
Стимулятор ~yoomoney - 41001303250491

igolka97

22.02.2015 - 15:42

Цитата (Valick @ 22.02.2015 - 04:06)

Цитата (igolka97 @ 21.02.2015 - 22:48)

Если есть, до добавляем номер этого квеста в таблицу незавершенных квестов пользователей

только после того как пользователь нажмёт кнопку "принять квест"
до этого момента квест будет просто доступен, никаких других проверок кроме доступности проводить не надо

Цитата (igolka97 @ 21.02.2015 - 22:48)

Остался вопрос, как сравнивать, на каком уровне и в какой форме сделать условие завершенности задания?

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

Я вот все никак не въеду...
Добавим мы в таблицу инфу о том, что нам предстоит выполнять какой либо квест. Надо ли в эту таблицу вместе с квестом вносить информацию о требуемых действиях?
К примеру, для завершения квеста нам надо убить 4 волка, и набрать 9 lvl, тем временем как медведей убивать не надо вообще, но их надо будет убивать в другом квесте. То структуру таблицы я представляю себе так:

| id | user_id | quest | wolves | bears | LVL |
|----|---------|-------|--------|-------|-----|
|  3 |    1    |   5   |    4   |   0   |  9  |

Тоесть это все для того, что бы убивая волка я вычитал из 4 по 1 до 0. Тобишь если все нули то квест выполнен. Или я еще вижу один вариант, со следующей структурой:

| id | user_id | quest | wolves | bears | LVL |
|----|---------|-------|--------|-------|-----|
|  3 |    1    |   5   |    0   |   0   |  0  |

И наоборот, как только я убиваю волка то плюсую поле `wolves` на wolves++ :D
и потом уже сравнивать их с таблицей информации о квестах. Как грамотнее? Или я вообще все не так понял? :(

Valick

22.02.2015 - 16:31

Нет, оба варианта не верны. Написание движка игры - это очень сложный процесс, и поверьте организация квестов далеко не саме сложное. Нельзя вот так взять на ровном месте и начать кодить. Точнее можно то оно можно, но вот что из этого получиться...
Сам квест должен "собираться" по средствам SQL запроса по данным из нескольких таблиц. Всего этих таблиц может быть очень много. А вот данные принадлежащие определённому квесту не обязательно должны быть во всех таблицах.
К примеру таблица квеста содержит идентификатор квеста, название квеста, и уровень при котором его можно принять. А вот с целями гораздо сложнее.
Допустим надо убить 5 волков и 3 медведя.
следовательно в таблице quest_kill будет две записи:
id квеста (начинающий охотник), id моба(волк), количество мобов(5)
id квеста (начинающий охотник), id моба(медведь), количество мобов(3)

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

то же самое с наградой за квест, она может собираться из нескольких таблиц, ведь за выполнение квеста можно молучать не только оыт и золото, но и различные предметы(доспехи, рецепты, ингридиенты и тд)

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

P.S. я как бы уже второй день вас пытаюсь отговорить от идеи писат движок самому

_____________
Стимулятор ~yoomoney - 41001303250491

igolka97

22.02.2015 - 16:45

Цитата (Valick @ 22.02.2015 - 16:31)

Нет, оба варианта не верны. Написание движка игры - это очень сложный процесс, и поверьте организация квестов далеко не саме сложное. Нельзя вот так взять на ровном месте и начать кодить. Точнее можно то оно можно, но вот что из этого получиться...
Сам квест должен "собираться" по средствам SQL запроса по данным из нескольких таблиц. Всего этих таблиц может быть очень много. А вот данные принадлежащие определённому квесту не обязательно должны быть во всех таблицах.
К примеру таблица квеста содержит идентификатор квеста, название квеста, и уровень при котором его можно принять. А вот с целями гораздо сложнее.
Допустим надо убить 5 волков и 3 медведя.
следовательно в таблице quest_kill будет две записи:
id квеста (начинающий охотник), id моба(волк), количество мобов(5)
id квеста (начинающий охотник), id моба(медведь), количество мобов(3)

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

то же самое с наградой за квест, она может собираться из нескольких таблиц, ведь за выполнение квеста можно молучать не только оыт и золото, но и различные предметы(доспехи, рецепты, ингридиенты и тд)

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

P.S. я как бы уже второй день вас пытаюсь отговорить от идеи писат движок самому

Где бы еще найти нужный мне движок.. Ведь речь то идет, совсем не о волках, и совсем не о медведях)) Может где есть просто готовый модуль для подобных решений? а я бы просто переписал бы его под себя

Valick

22.02.2015 - 17:06

https://www.google.com/search?q=%D0%B4%D0%B...=utf-8&oe=utf-8

https://www.google.com/search?q=%D0%B4%D0%B...%B3%D1%80%D1%8B

http://devana.eu/

_____________
Стимулятор ~yoomoney - 41001303250491

Guest

23.02.2015 - 00:19

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