Например потому что $qw=$row['other']; и является результатом запросов к базе с использованием переменной $id, которая в свою очередь приходит из GET. При этом вашему скрипту все равно определена ли $id и пришел-ли GET, он всеравно пытается выполнять запрос с её использованием:
Как там процесс продвигается? Не только у вас, но и у всей команды?
Тоже интересно. Имхо, чтобы заманить сегодня людей в текстовые онлайн-игры даже для мобильных платформ, они должны быть просто виртуозными, либо с клубничкой.
Держите в курсе
Ну а что тут комментировать. Если ваши задачи требуют именно такой реализации, то пусть будет, если работает.
Вообще же, по-человечески, id и названия пунктов меню, как и параметр, например, parеnt, хранящий id родительского пункта меню хранятся в бд. Вся таблица извлекается при заходе на страницу и выстраивается в иерархическое меню без всяких инклудов. А поведение меню программируется на JS чтобы вложенные пункты меню "выпадали" без необходимости переходить по ссылке родительского пункта меню
Не совсем понял что требуется: ускорить выполнение скипта, или сделать экшн бар выполнения.
С ностоящими процессами пыха работеть не умеет, но есть ряд костылей, реализующих принцип внутрипроцесной многозадачности, которые для ряда задач дают существенный выигрыш в скорости выполнения. http://www[dot]ibm[dot]com/developerwork[dot][dot][dot]itask/index[dot]html
И так, разобравшись в общих чертах с созданием локаций, начнем расписывать главное: саму логику real-time mmorpg. Главное отличие этого типа игры заключается в том, что персонажи взаимодействуют "в живую" и игра не подобна шахматам, когда вы сделали ход и ожидаете хода соперника и только после него вы сможете продолжить игру. Соответственно, в массовых боевках с участием 10+ игроков вы можете ждать своего хода по пол-часа. Что это означает для разработчика с технической точки зрения и как обеспечить такую функциональность приложения?
Начнем рассматривать организацию "риалтайма" по модели MVC, начав с уровня данных.
На стороне данных, как мы решили у нас будет быстрая СУБД, поддерживающая индексы, временные таблицы и хранимые процедуры - PostrgreSQL/Mysql.
Учитывая наши цели, спроэцируем их на уровень данных, чтобы стали понятны задачи решаемые бд.
Мы имеем 2000 игроков онлайн. Для уровня данных это как минимум означает 2 вещи: большое количество операций (в основном - запись, удаление, апдейт) и большое количество соединений с бд. Учитывая этим моменты, примем решение о том, что при заходе в игру, она будет поддерживать постоянное соединение с сервером. Это дает серьезную нагрузку на сервер субд, но иное решение для риал-тайм игры будет стоить дороже.
Второй важный момент, - нам будет необходима очень большая скорость операций с таблицами бд. На этапе проектирования базы, мы максимально тщательно протестируем скорость чтобы спрогнозировать возможность поддержки нужного числа операций, структура будет максимально оптимизирована под большего число записей, удалений, апдейтов, для быстрого доступа к данным в таблицах будем использовать числовые индексы.
Для выполнения стандартных операций взаимодействия с бд, напишем хранимые процедуры, которые в нашем случае значительно ускорят все операции.
С теорий уровня данных вроде всё ясно.
Подумаем теперь, как с ним будет взаимодействовать приложение. Опишем взаимодействие в виде отдельных операций приложения с самого начала игры (опишу несколько фривольно, дабы было проще понять самому и разъяснить читающим сами принципы работы приложения. Так что пока - без уровня представления>логика>уровень данных...).
0. Игрок заходит в игру: обратились к бд, проверили логин, пароль, если совпали, отдали из бд локацию и координаты персонажа.
1. Передаем карту локации в клиент. Отображаем персонажа на карте... и сразу стоп! У нас мморпг, к тому же риал-тайм. Стало быть нам нужно отобразить и "двигать" всех персонажей вех игроков, находящихся в локации. Стало быть игра должна опрашивать сервер и выдавать координаты всех персонажей в локации скажем каждые 500 мс. (больше - уже не риалтайм).
Задачи - извлечь максимально быстро координаты персонажей, отдать максимально быстро, отобразить максимально быстро и не загнуться при обновлении каждые 500 мс.
Варианты решения задачи:
а). Данные храним в базе, все операции производятся уровнем логики и уровнем данных на стороне сервера. В браузер отдаем массив координат персонажей.
При заходе в игру и каждые 500 мс. аяксом активируем процедуру извлекающую данные по id локации, содержащие координаты всех персонажей в локации в виде массива. Уровень представления расставляет все фигурки по заданным координатам (анимацию пока не трогаем, поговорим о ней позже). + Не зависим от клиента, точно передадим ему данные. - Всю работу делает сервер бд.
б). Данные хранятся на сервере в виде XML-файлов. Мы также можем хранить данные о местоположении персонажей игроков в виде XML. Тут реализаций может быть масса. И мы передоверим часть работы компьютеру игрока. Мы можем хранить в бд лишь данные о конечной локации персонажа при выходе из игры. После захода в игру, берем с бд всего лишь локацию, и в соответствии с ней забираем аяксом нужный XML-файл. В нем, как не трудно догадаться, хранятся постоянно обновляемый список всех персонажей в локации и их координаты. JSом разбираем файл, отображаем персонажей на карте, проделывая процедуру регулярно. Возможно потом нам удастся оптимизировать и ускорить эти операции на стороне клиента через применения workers, webstorage/websql. + Весьма очевиден: мы не нагружаем бд, постоянно спрашивая "где я?" и "кто рядом?", ей и так придется работать на полную катушку, занимаясь другими вещами. - Тоже очевиден: мы, при всех усилиях ничего не знаем о компьютере клиента и передоверие этой части работы браузеру может сильно тормозить игру (особенно если игроков в локации много и файлик будет большем). В случае с "тормозами" при первом методе, игра будет одинаково медленно идти у всех игроков, а, в случае с независимым парсингом XML на стороне клиента, тормоза будут у каждого разные. - Ещё один минус. Если местоположение игрока определяется jsом, то, фактически браузер может передать xml любого содержания. И нужно будет проверять его средствами сервер на то, "не шагнул ли персонаж слишком далеко, или туда, куда нельзя". В случае с хранением координат в бд такого можно не делать. Процедура проверки будет в 2 этапа:
1. Сверяем координаты куда шагнул игрок с разрешенными на карте (карта лежит в бд).
2. Сверяем файл присланный клиентом с файлом-старой копии, хранящийся на сервере, на предмет того не затронуты ли ходом координаты других игроков. Также смотрим не шагнул ли игрок дальше, чем ему разрешено.
Тут буду рад выслушать комментарии, советы и любые идеи. Пока лично я считаю, что придется тестировать оба метода.
2. Допустим, зашел игрок в мир. Показали ему всех игроков в локации. Что дальше?
Дальше игрок нажимает кнопку чтобы передвинуть персонажа. JS смотрит в какую точку хочет переместиться персонаж:
Карты у нас хранятся на сервере. Когда персонаж входит в игру, мы передаем клиенту массив координат и сами текстуры и спрайты. Кэшированием картинок занимается уже сам браузер. (Подумать над тем? позволяют-ли нам существующие технологии при использовании JS хранить локации на стороне клиента! Почитать в сторону indexdb, webstorage, управления кэшированием).
Логика получает координаты куда хочет переместится персонаж, спрашивает у бд, можно-ли переместить туда персонажа (нет ли там непроходимого спрайта, или другого игрока)... . Стоп. А нужно-ли нам это действие? Нет, не нужно. Ведь мы получили карту локации при заходе в игру, мы получаем каждые 500мс. координаты всех персонажей в локации. Значит, -
а) смотрим можем ли переместить персонажа в заданную точку локации (нет-ли непроходимых текстур-спрайтов).
б) делаем стандартный запрос к бд или xml-файла у веб-сервера, после чего сверяем нет ли в точке, куда мы ходим другого персонажа (если есть, ... то подумаем потом что делать, если есть. Пока будем считать, что если есть - выводим меседж, что ход невозможен.)
в) Если "пусть свободен" - переставляем туда нашего персонажа: перезаписываем в бд новые координаты либо перезаписываем в xml файл строку с новыми координатами, после чего отправляем этот файл на сервер.
Для начала все. Мы описали теоретическую логику реализации "жизни" в мире игры, указав две возможные реализации "перемещения" персонажа по миру. Прошу комментировать, оценивать, уточнять и предлагать оптимальные варианты.
Увеличилось в сравнении с чем и за какой период?
Только некоторые варианты волне нормально объясняющие увеличение занятого пространства:
1. На сайте есть встроенные в цмс средства кеширования данных
2. На сайте есть приложения, запускающиеся по расписанию: рассылки, бекапы, логи, архиваторы.
3. на сайте есть средства заливки изображений неограниченного размера. 10 мб это далеко не самый большой аватар который может пытаться залить пользователь или администратор
4. На сайте есть скрипты, генерирующие контент/файлы при посещении страниц. Распространенный пример: скрипт, создающий уменьшенные копии изображений товаров при первом посещении страницы/галереи.
5. Средства хостера, сохраняющие файлы в вашу папку: архиватор каталога, бекап бд, логи веб- и субд-серверов, статистика и т.д.