Почему это важно? Почему просто не сделать список доступных игр? Всё очень просто: люди могут чувствовать себя некомфортно, ожидая оппонента неопределённое, часто достаточно долгое время. Конечно, это не проблема, если у вас есть большое сообщество игроков и, следовательно, большой онлайн, в этом случае вы сможете найти оппонента довольно быстро. Но это критично для маленьких инди-команд, где типичный онлайн вашей игры будет, вероятно, менее 10 человек. В нашем случае публичный список игр, в которых люди ждут оппонента, постоянно пуст, но люди всё же играют со своими друзьями, приглашая их в свои игры, о чём свидетельствует пополняющаяся таблица лидеров сетевой игры:
Привет!
Из того, что сходу приходит в голову, хочется отметить следующее.
В текущей версии игры в базе данных каждому вопросу соответствуют свои четыре варианта ответа, что приводит к необходимости их вносить, даже если они уже были внесены (например, названия планет или имена писателей). На ранних этапах разработки игры была ещё идея сформировать некие древовидные категории ответов (например Космические тела -> Тела Солнечной системы -> Планеты солнечной системы -> Планеты-гиганты -> Юпитер), и затем, однажды заполнив это дерево ответов, повторно использовать их в разных вопросах. Это, несомненно, лучше с точки зрения недублируемости данных, но я столкнулся с проблемой того, что в реляционной БД сделать такую структуру довольно нетривиально (если интересно, можно почитать на эту тему в обсуждении по ссылке в конце, если вкратце, то есть разные решения, но все они компромиссные, в некоторых быстрое обновление базы, но медленное чтение, в некоторых наоборот). Поэтому я решил сделать всё проще и сделал как сейчас :)
В качестве альтернативы SQLite именно для вот такого решения задачи, с созданием иерархии категорий ответов, думаю, хорошо подошла бы какая-нибудь NoSQL база данных, допустим, Mongo или eXist, но, во-первых, я не нашёл библиотек для работы с этими базами из Godot, а во-вторых, как уже было сказано, решил не усложнять задачу и вообще отказаться от этой древовидной структуры.
Что касается поиска и сортировки, то пока что я, к сожалению, настолько глубоко в настройку БД не лез, понадеялся, что настройки по умолчанию будут работать нормально. В любом случае, вопросов в базе пока ещё не так много.
Привет. Большое спасибо за релиз игры и исходников.
Хотелось бы уточнить один момент. Игре, очевидно, очень подходит использование реляционной встроенной БДшки - можно удобно менеджить вопросы, проблемы с локализацией, судя по коду, решаются очень красиво и легко. Но интересно на что еще при разработке игры стоит обратить внимание помимо SQLite для управления большим колличеством подобных данных, с которыми часто приходится работать на высоком уровне (поиск по критериям, сортировка)? Может есть какие-нибудь еще решения? Я не говорю, что меня не устраивает это, просто хочу рассмотреть и альтернативы если имееются. Заранее спасибо!