У меня вопрос такого характера, как создавать высоконагруженные проекты?.. высоко, в моем понимании, от 10 000 уников в сутки... В моем случае это BBMMORPG. Больша просьба не разглогольствовать на тему, что я не подниму проект на такой уровень и т.д... меня интересует только техническая сторона! Это значит что меня интересует все, от оптимизации кода и sql до структурного разделения разделов HDD и выбора ОС. Также хочется услышать советы и предложения по разработке... например я не очень представляю как сделать восстановление здоровья с отображением оного в окне пользователя, а также каогда его нет в сети... Еще хочется услышать какие подводные камни могут быть при разработке... PS Проект я делаю чисто для себя, может чему-нибудь научусь ))
Когда я был на конференции, ребята из одного инвестиционного фонда читали лекцию, причем, просто, в обеденный перерыв. Они сказали одну очень очевидную и важную вещь: Напишите проект так, что бы им могли пользоватся хотя бы 10 человек. И он начнет приносить доход, вы перепишете его для 100 человек, потом для 1000, потом снова... чем вы будете писать для 10000 и _никогда_ не напишете. С тех пор, я не оптимизирую ненаписанные программы, и другим не советую.
Ну, если сначала на 10 человек, то можно и каждую секунду отправлять аякс запрос на сервер ))))) только потом переписывать на 100 человек... не проще ли сразу делать на 1000? тогда хоть смысл есть
Здоровье должно востанавливаться со временем. Время идет от последнего дагма. Например 1 пункт/минута. Полоска же делается простым AJAX'ом - делается запрос скрипт на получение здоровья. Скрипт вычисляет, сколько должно быть здоровья, и отдает тебе эту цифру. Может заодно и БД править. Чтобы придумать алгоритм, нужно пофантазировать. А технически можно реализовать любую фантазию.
реализовать можно... но если у меня восстанавливается 1ед. здоровья в сек, то делать запрос каждую секунду - бред...
каунтдаун считается жсом на клиенте. на сервере есть дата последнего обновления и скорость восстановления. Критично обратное, если кто-то постепенно умирает.
Нет. Востанавливать здоровье при запросе. Количество едениц зависит от времени, которое прошло с последнего дагма. Если запрос пришел через час, то востановить сразу на 60 ед. =)
Проект проекту рознь. Если это обычный сайт, то высокой нагрузкой можно действительно считать 10к уников, но если это игра, то 1к уников - уже высокая нагрузка, имхо. Сам понимаешь, у игр соотношение хосты/хиты в сотни раз больше, чем у обычных сайтов. +1. Сейчас пишу игру, пишу чтобы работало (ну, естественно, стараюсь не допускать ресурсоемких ляпов). Когда игра будет готова и её ресурсов будет не хватать, то тогда и буду думать (если не проще будет докупить сервер).
Кроном в базе плюсуешь каждую секунду здоровье и все. А клиент по запросу получает текущее состояние и видит увеличение здоровья, которое делает js. С виду оптимальное решение, но на деле не очень надежное. Здоровье может просматриваться в сотне мест, в том числе и из чужого аккаунта, и что, везде проверять, восстановилось ли оно или нет? И везде таймеры ставить?
Никаких таймеров. Проверка здоровья при конструкции экземпляра игрока. Дальше брать оттуда. Сразу выбирать нужные данные, проверять необходимость изменения условием if в php - это никаких затрат ресурсов. PHP: <?php if ($health < $h_max) {...
парни вы че... есть признак здоровье. он вычисляется функцией. time*delta. как на клиенте так и на сервере. каждый раз тыркать в базу - ЕБАНИТЕСЬ. кол-во вычисляется при ОТДАЧЕ контента, т.е. мы знаем когда стартовало и на сколько прибавлять. пир запросе данных функции вычисляются, новые результаты запоминаются и контент отдатся. лазить куда либо по хрону там или еще как кого дергать - БРЕД и не понимание такого рода программинга.
Для начала нужно понимать, стоит ли реализовать функционал восстановления жизни именно с помощьью таймеров. У меня было реализовано при помощи другого механизма и игрокам нравилось, потому что "не так как в комбатсе". Немо, по поводу нагрузок. Олег правильно говорит, не стоит писать сразу проект, ориентированный на высокие нагрузки. Я тебе скажу, что у меня собственный сервер (не очень сильный, не очень слабый - серединка) вешался уже при 100 онлайн. Поэтому основной упор стоит делать не на оптимизацию кода, а на железки (хотя совсем забрасывать оптимизацию тоже не дело). Во-первых очень тщательно контролируй каждый запрос к БД. Используй кэширование для выдачи статичных данных (к примеру информацию об игроке можно выдавать из кэша). ОС FreeBSD, тут даже не думать. По поводу конкретных железок не скажу, но мы в конце года покупали машинки от Sun Microsystems по сотняшке тысяч долларов каждая. Правда это было года два назад или три, когда я работал в NeverLands.Ru. Не забудь про backup'ы. У нас игра пару раз падала из-за того что отказывали жёсткие диски и информацию приходилось из RAID сливать. Тут советую смотреть в сторону SAS и мониторить состояние дисков. Мы их меняли достаточно часто...
Короче начал читать про здоровье, и запарился. Напишу свой вариант, может он и был сверху - не читал. Короче тот вариант, что пишется последняя активность и тому подобное - ясен пень. А вот со стороной клиента я не согласен: тут можно сделать на чистом JS или вообще Flash. По обычному таймеру, алгоритм вычисления которого используется и на сервере, вычисляет на стороне клиента здоровье в реальном времени, и прогресс-бар тут же увеличивается без каких-либо запросов куда-то там. Если пользователь апдейтит страницу - на сервере же значение высчитывается от количества едениц в секунду на текущее время, отдается и браузер опять сам считает в реальном времени. Вот это идеальный вариант, без нагрузки и AJAX. IMHO.
Архитектуру нужно думать, но не слишком задумываться. Переписывать потом придется многое все-равно. Это аксиома любого стартапа - сколько времени ты бы в проектировку не вложил, стартап или помрет или его придется переписывать. Ясно дело, что переписывать легче хорошо спроектированный код, но это уже вопрос профессионализма архитектора - сплошные велосипеды, ничего выдумывать не нужно - сел и поехал.
надо на сколько это возможно больше описать модель игры на JS ну и полностью модель игры на PHP и их синхронизировать как можно реже, как можно бОльшими объемами данных, собранными из малых, которые ставятся в очередь и в определенные моменты отправляются на сервер. Так можно больше выдержать, чем обновлять то жизнь то броню то еще какую нить хрень....
Велосипеды - они общие. На них ехать нужно, а не свои придумывать. Написание кода для более легкого рефакторинга не зависит от того, что это за проект, что он будет делать, и даже хайлоад он или нет и т.д. и т.п. =) По сути вопрос топикстартера - как написать код, который потом легко переделывать. А это опыт именно программирования, а не именно написания игр. Четкий пример выше был выше про то "где таймеры ставить". Конечно, у mmorpg есть свои нюансы, но именно их и нужно спрашивать, а не абстрактное "с чего начать". Хотя и на последний вопрос можно ответить - со сценария. И не абстрактного "про корованы", а очень подробного, со всеми скринами игры. На основе этого формируем объекты и их взаимодействие и все вероятные входные действия. Истинные джедаи все это UML-ят, падаваны хреначат "на глазок" скрестив пальцы ничего не забыть.
kostyl, работает только в статике. Например, когда есть долгий процесс какого-то роста, апгрейда и т.д. и т.п. Как только появляется процесс взаимодействия с другими игроками - кушаем только сервер. Так же изначальный сильный акцент на клиентских технологиях очень часто приводит к огромным дырам в безопасности, когда за клиентскими проверками забывается внесение таких же серверных проверок.