Добрый день, вот решил выучить пхп. И написать мобильную браузерку, неделя мануалов и видео. В итоге старт и куча вопросов. Поехали: 1. Уже есть авторизация, локации инвентарь мобы, много чего .На многих страницах по 1-3 SELECT^а к БД а то и больше, загружают они в основном данные типа INT и пару варчаров. Вопрос это много и как может повлиять на БД? Пример game.php загружает 3 таблицы юзер, локация и моб. Страницы обновляются минимум через 5 секунд(лимит на переход по локам) 100 юзеров = 60 запросов в секунду. Но в этих запросов очень мало данных, по 4-7 столбцов (загруз. стр. примерно 0.0032сек). 2. Метод GET. Передаю данные ид моб и уровень. Как сделать чтоб юзер в строке не смог изменить эти переменные. (т.к находясь в одной локе может нападать на других мобов или лвл менять). Решение какое правильное? 2/1. Заносить в БД в инфу перса моба и лвл (Сделано, НО + 1 UPDate на странице) 2/2 Передавать данные через ссесию (сделал, но убрал. *см. вопрос ниже*) 3/3 Шифровать данные каким то ключем который будет обновляться раз в минуту И потом расшифровывать перед $_GET (хз под вопросом). 3. Вопрос как много информации можно передавать в ссесиях? Щас только четыре переменных. Был бой написан на ссесиях(около 20 переменных), Загружались все данные из БД только раз, потом бой на ссесии 4-6 обновлений страницы(атака) и в конце боя UPDaйд базы. УБрал Сейчас все на БД но это много Selectов и апдейтов. 4. Вопрос. Карта локаций. Как правильно построить текущию карту локаций 3*3 В каждой таблице локации есть столбец картинка, Я загружал текущию картинку и все остальные 8 окружающих локаций(по ним же переход осуществляется в). Но этот процесс занимает 8 дополнительных селектов к бз. Код не прошу а указать куда капать дальше.
Все игры должны строиться только на парадигме "тонкого клиента". То есть клиент не говорит серверу "сейчас я внесу этому мобу 300 дамаги, давай-ка, поправь его стату". Потому что можно подделать данные и сказать серверу, что ты вносишь 9000 дамаги. Клиент должен говорить серверу "сейчас я стукну этого моба, а ты скажи мне, сколько дамаги я ему нанес, ок"? Так что инфа должна храниться строго на серваке. Например, в сессиях. Столько, сколько тебе нужно. Сессия - не кука. Сессия - это файлик на сервере. Что хочешь, то и храни, дело твое.
В вашем вопросе нет ни одной четко определенной величины, какой ответ вы хотите на него получить? Если у вас 1000 клиентов делают одновременно один и тот же же запрос и получают один и тот же ответ от субд - да, это не правильная реализация. И не потому что идёт запрос в базу данных, результат в данном случае будет кешироваться (должен быть кеширован при правильном запросе) вопрос в том что в данном случае этого запроса вообще быть не должно и данные должны лежать либо в файловом кеше, либо в памяти в хранилище типа ключ-значение. Эта реализация вообще исключит какую-либо нагрузку на субд. Другое дело какие данные помещать в память, а какие нужно держать и запрашивать из таблиц субд. Это уже зависит от конкретной реализации. Никак. Он сможет и будет подделывать запросы независимо от того каким методом вы передаете данные: уйдете ли в сокеты или задействуете https. Ваш сервер должен проверять действия клиента и решать может ли действие быть совершено или пришёл поддельный запрос. Для удобства считайте что любой пришедший запрос поддельный и нуждается в валидации. Вот типичный пример при котором рационально использовать хранилища типа ключ-значение. Абстрагировавшись от деталей реализации в коде, часто приходится сохранять на сервере данные об изменяемых характеристиках персонажа. Можно делать апдейты в субд, которые попадают в общую очередь запросов к субд, а можно записать данные конкретно по hp/mana конкретного персонажа в память по ключу personal:12345, где id персонажа 12345. Соответственно, метод отдающий объект с данными этого персонажа может сначала проверять наличие такого ключа в хранилище в памяти, если он найден, - использовать эти данные. Если не найден - запрашивать их у субд. Такой подход позволит разгрузить субд от бесконечной очереди запросов и производить в неё отложенную запись. Шифруйте или передавайте хешами, ради бога. Но при разработке всегда исходите из того что данные пришедшие в запросе были подделаны. Ответили Это детали вашей реализации. Важно помнить что вы не должны запрашивать неизменяемые данные у субд. Вместо этого они могут кешироваться и отдаваться из файлового кеша или мемкеша. В случае если локация каким-то образом изменилась, соответственно должен быть изменён и кеш.