Последние сообщения

21

Планы / Re: Запуск сервера

Последний ответ от evg - Апрель 21, 2017, 05:34:30

Не в этой жизни

22

Планы / Re: Запуск сервера

Последний ответ от Kamikadze - Апрель 13, 2017, 08:47:08

Ого-го! Дело-то не стоит оказывается)) 

Еще не скоро будет запущена, точно не в этом месяце

Судя по статистике и не в этой декаде

23

Планы / Re: Голосование и обсуждение п...

Последний ответ от Kamikadze - Февраль 16, 2016, 21:34:18

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

А зарабатывать можно:
на скинах - т.е. разные иконки замков, юнитов, смайликов для чата и всяких таких финтифлюшек.
на необьязательном функционале - т.е. та-же платная регистрация кланов, платная регистрация замка после 1 замка в день, причем с возрастающей ценой.
Премиум аккаунты которые будут иметь приятные бонусы - как писал диаволо 2-3-5 регистраций в день, какие-то удобные финтиклюшки интерфейса, автоматическая балансировка налогов, как вариант удвоенное кол-во золота в новозарегенном замке.

24

Планы / Re: Голосование и обсуждение п...

Последний ответ от Diavolo - Февраль 12, 2016, 06:01:59

Всем, привет. Я считаю, что деньги должны платиться за пользование клиентом на основе абонентской платы, либо подписки на год (пол года). Рассчитать стоимость оплаты данной суммы можно будет исходя из стоимости разработки данного клиента. Так же считаю, что можно брать оплату за регистрацию дополнительного аккаунта, чтобы иметь возможность создавать большее количество замков в сутки (либо дать возможность создавать в одном акке 2 замка в сутки, вместо одного). В любом случае, если ты платишь деньги, ты должен получать хоть какое-то преимущество.
А за пользование игрой в стандартном режиме оплат никаких не должно быть. Иначе новых игроков не появится.

25

Планы / Голосование и обсуждение платн...

Последний ответ от evg - Февраль 10, 2016, 21:05:30

Хотелось бы узнать мнение игроков по поводу платных возможностей. Готовы ли игроки платить и за что? Голосуйте, комментируйте, предлагайте свои варианты. Желательно, что бы эти возможности не давали платному аккаунту преимуществ перед обычными. Вопрос возник из-за нежелания некоторых игроков играть без клиента и из-за предложения других игроков заказать разработку клиента сторонним профессиональным программистам.

[Текущая реализация]

26

Работа сервера игры / Технические подробности реализ...

Последний ответ от evg - Февраль 10, 2016, 11:38:25

В данном топике буду выкладывать описание "потрохов" игры и отвечать на вопросы по реализации.

Текущая реализация

Хостинг:
Cервер игры развернут в облачном сервисе компании Selectel на площадке дата-центра в Санкт-Петербурге. Виртуалке доступно для использования 8 ядер CPU Intel Xeon L5520 2.27GHz и до 32Gb RAM, сейчас стоят лимиты на общую загрузку ядер совокупно не превышающую 100% загрузки одного ядра и 1Gb ОЗУ.

Потребление ресурсов:
При средней активности игроков, потребление облачных ресурсов составляет менее 10 часов 100% совокупной нагрузки одного ядра CPU в месяц и около 400Mb ОЗУ, что обходится в месяц в 300-400 рублей, с форумом получается 600-800 рублей в месяц. При большой активности игроков расходы возрастают до 1000 рублей в месяц. Сейчас появились более дешевые варианты хостинга, но Selectel радует надежностью, скоростью каналов, распределенным DNS и безопасностью, простои по вине хостера за несколько лет составили считанные минуты, а затраты пока не те, что бы их уменьшать жертвуя чем-то.

Игра состоит из нескольких компонентов:

• Фронтенд: Скрипт PHP исполняемый в режиме FastCGI под http-сервером Lighttpd.


• Бэкенд: Linux-демон, так же на PHP, запущен как сервис.


• Очередь команд и хранилище: БД Redis, используется один экземпляр (инстанс). Во время перехода и раз в несколько минут (только во время простоя демона), данные из памяти сохраняются на диск, что уменьшает риск потерять данные при сбое. После просчета перехода выполняется резервное копирование базы.

Схема работы фронтенда:

• Во фронтенд поступают HTTP-запросы от игроков, API запросов едино и для HTML-интерфейса в браузере, и для JS-интерфейсе в браузере и для отдельных клиентов (последние пока не реализованы).


• После валидации запроса и проверки авторизации игрока, происходит ветвление. Если команда:
  
  
  
  • не изменяет состояния игры (запрашивается список замков в аккаунте, запрашивается область карты вокруг замка), то данные для ответа запрашиваются напрямую из БД.
  
  
  • изменяет состояние игры (делается ход юнитом, изменяется налог в замке и т.п.), то фронтенд:
    
    
    
    • сериализует данные команды, результат помещает под уникальным порядковым номером в очередь организованную в Redis (используется rPush);
    
    
    • в цикле запрашивает в Redis появление статуса обработки для команды с таким порядковым номером (используется hExists), период опроса 500 микросекунд (0.0000500 сек);
    
    
    • после появления статуса "команда в обработке" проверяет в цикле (используется hGet) его значение до тех пор, пока статуса не изменится на "команда выполнена", период опроса 500 микросекунд (0.0000500 сек);
    
    
    • После смены статуса на "команда выполнена" фронтенд забирает результат выполнения команды из промежуточного хранилища (используется hGet) в Redis.
    
    
    
    
  
  
  
  


• Данные десериализуются, оформляются в ответ, если игрок использует браузер, то формируется HTML-представление, ответ отсылается игроку.

Схема работы бэкенда:
В очередь команд создается запрос (используется blPop), таймаут ожидания команды в очереди 5 секунд. Если:

• очередь пуста в течение таймаута, то демон выполняет служебные операции по расписанию (удаляются истекшие сессии авторизациии, запускается garbage collector и т.д.) или засыпает на 500 микросекунд (0.0000500 сек), затем опрос очереди повторяется;


• в очереди появляются команды, то в ответ на запрос извлекается команда с наименьшим порядковым номером, затем:
  
  
  
  • в Redis проставляется статус "команда в обработке" (используя hSet) для команды с таким порядковым номером;
  
  
  • данные команды десериализуются, из Redis извлекаются данные необходимые для валидации команды, команда валидируется;
  
  
  • из Redis извлекаются данные необходимые для выполнения команды, команда выполняется;
  
  
  • изменения игрового состояния сохраняются в Redis;
  
  
  • результат выполнения сериализуется и помещается в промежуточное хранилище результатов (используется hGet);
  
  
  • статус в Redis изменяется "команда выполнена" (используя hSet), очищаются временные переменные, опрос очереди повторяется.
  
  

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

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

В следующей версии:
За прошедшее время наработан некий опыт, стали доступными или появились в стабильных версиях некоторые возможности в Redis и PHP-расширениях, поэтому в новой версии произойдут следующие изменения:

• В текущей версии API и HTML-интерфейса имеется лаг при движении  глаза и мага в областях с большим количеством юнитов. Поэтому, в API игры будут внесены изменения. Для глаза ответ на команды "движение" и "обновление", отосланных с параметрами по-умолчанию, не будет содержать список видимых им юнитов, этот список можно будет получить только при установке клиентом нового флага "осмотреться" в отсылаемой команде. И наоборот, для мага установкой новых флагов "без раненых" и "без партнеров" в отсылаемых командах "движение" и "обновление" можно будет отключить получение в ответе списка видимых им раненых юнитов и магов доступных для телепорта или супертелепорта.


• Вместо штатных для PHP функций сериализации/десериализации будет использоваться библиотека двоичной сериализации igbinary, она быстрее, сериализованные структуры получаются компактнее, что позволит уменьшить потребление памяти Redis.


• Данные игры, данные очереди команд, данные результатов выполнения команд, архив сообщений и статистика с логами игры будут разнесены по разным экземплярам (инстансам) Redis, что позволит распределить нагрузку на БД по нескольким ядрам процессора, снизит фрагментацию памяти и уменьшит потребление памяти процессами Redis, в том числе за счет возможности использовать различные настройки для различных экземпляров Redis, что позволит оптимальнее храненить разные типы данных. Возможно, что архив сообщений будет вынесен в SQL-базу, так как к архиву не требуется быстрый доступ и не целесообразно держать его в ОЗУ.


• В ряде случаев сейчас используется несколько отдельных последовательных запросов к разным ключам Redis, например при чтении или изменении параметров юнита (атака, защита, здоровье и т.д.), для подобных последовательных запросов при чтении и записи будет использоваться пакетный режим, при котором одним запросом обращение сразу к нескольким ключам, что снизит накладные расходы на доступ к БД.


• Механизм очереди и хранилища ответов будет основан на публикациях в каналах Redis (Pub/Sub), это позволит отказаться от циклов и задержек между повторными запросами, снизит потребление ресурсов сервера.


• Будет изменена организация хранения некоторых данных игры и логов на более оптимальную.


• Скорее всего, http-сервер будет заменен на nginx и будет задействован APC (PHP Cache). По крайней мере, на тестовом сервере именно такая конфигурация.


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

В результате, при увеличении активности игроков задержки (лаги) будут расти медленнее, увеличится устойчивость игры к DoS-атакам некоторого вида, упростится администрирование иры. Потенциально, при большом количестве активных игроков и большого размера карты снизятся затраты на аренду ресурсов в облаке, хотя для большого количества игроков имеет смысл арендовать выделенный сервер с фиксированной арендной платой и производительностью.

27

Планы / Re: Запуск сервера

Последний ответ от evg - Февраль 09, 2016, 13:10:44

Ого-го! Дело-то не стоит оказывается)) 

Еще не скоро будет запущена, точно не в этом месяце

28

Планы / Re: Запуск сервера

Последний ответ от Diablo - Февраль 08, 2016, 15:14:57

Ого-го! Дело-то не стоит оказывается)) 

29

Планы / Re: Запуск сервера

Последний ответ от evg - Февраль 08, 2016, 07:57:35

Новая карта будет запущена на отдельном сервере, параллельно с текущей.

30

Планы / Re: Запуск сервера

Последний ответ от Kamikadze - Февраль 07, 2016, 19:40:24

Ураа, будет новая терра и до меня уже никто не доползет