?

Log in

No account? Create an account

ru_decline


Сообщество посвященное онлайн игре Decline


Ура!
e_maksimov
Благодаря Роману Бондареву игра доступна по адресу decline.ru ! Огромное спасибо Роману, что берег домен все эти годы, что подталкивал к работе над игрой. К релизу я начал двигаться только благодаря его активности.

палим контору полностью
e_maksimov
Раз такое дело, что адрес тестового сервера пошел в народ, то нет смысла прятать: http://decline.com.ru .

Тестовые логины - цифры от 1 до 4, пароли такие же как логины :) Возможность добавлять замки пока отключил - карта забита. Маги еще не лечат и не телепортируют, мирные соглашения не работают, кланов нет, сообщения в замках не работают, атака на замок не работает. По замеченным глюкам и бага просьба отписываться в сообщество или в личку.

Вопрос про телепорты-супертелепорты
e_maksimov
В первой Деке был телепорт юнитов из замка и в замок? Был возможен супертелепорт юнитов из замка и в замок? Смутно припоминается, что телепорт из замка был, а из юнитов в замке выбиралось войско с самой большой атакой. Ошибаюсь?

Обновление
e_maksimov
На тестовом сервере подключил закупку войск, демобилизацию и атаки на юниты вне замков. Завтра подключу атаку на замки. Юниты атакующие пустой замок пока не будут получать повреждений, формулу расчета нужно восстанавливать или заново создавать.

Много текста и вопрос по интерфейсу
e_maksimov
На днях подниму сервер, пока в облаке, для тестов хватит, посмотрим по нагрузке, а под релиз хочу взять выделенный физический, по деньгам разница копеечная. Многие уже успели поинтересоваться насчет владельца хостинга и кто из игроков будет иметь к доступ к базе данных - отвечаю сразу всем и надеюсь, что больше этот вопрос не станут задавать. Честное слово, уже немного раздражает личная неприязнь к отдельным игрокам или админам. Хостинг тестового сервера коммерческий, Селектел, сервера расположены в Москве и Питере, доступ к серверу только у компании-владельца и у меня, никто, повторяю, никто другой доступа к базе данных иметь не будет. Тем более Игроки. Сам я Играть не буду, только на этапе тестов буду гонять юнитов между замками тестового аккаунта. Доступ к данным смогут получить только если взломают сервер, от этого никто гарантии не даст, но взломать будет непросто, по ряду причин. Выделенный сервер под релиз планируется брать так же у этого хостера, если за период тестов он не покажет себя с плохой стороны.

Постараюсь за выходные-праздники выложить готовое. Предупреждаю сразу, это уже не прототип, но еще многие возможности не доступны через веб-интерфейс. Меню аккаунта в зачаточном состоянии - логи, сообщения и настройки не подключены, возможности магов и могров в интерфейсе отсутствуют, за мирные соглашения вообще еще не брался, как и за дарков. Некоторые формулы взяты из реализации Лего, некоторые из Слоттовской, что смог быстро разобрать, надо думать, какой баланс хотим получить, в одиночку у меня мозги на это дело не возбуждаются, да и сначала надо логику скриптов доделать. Внутренний форум и регистрацию через интерфейс подключу в последнюю очередь, как наименее важные, а раз так, то желающим учетки для тестов придется раздавать вручную - обращайтесь в личку/аську/скайп или оставляйте здесь координаты для связи.

Есть вопрос, мелкий, но противный - не люблю версткой заниматься. Достаточно большое количество народа пользуется смартфонами-планшетами для доступа в сеть, у многих устройств разрешение не ахти какое. Актуально ли для основного скина игры делать разрешение менее 800 точек по горизонтали или забить и делать покрупнее? В принципе, карта и основные меню замка влазят без особых проблем, но в закупке/демобилизации юнитов приходится мельчить, а все потому, что хочется и эти меню втиснуть в центральную колонку верстки, а не занимать ими все поле, как в классическом интерфейсе Деки. Мне кажется, что так будет удобнее на планшетках, что бы лишний раз по менюшкам не тыкать. Вот такой скриншот в натуральную величину, как оно, нормально или идея все втиснуть в 800 точек откровенна плоха?
CL_SKIN

Сдувая пыль с архивов
e_maksimov
Нашел в закромах клиента Моргота, второго, который с плагинами - скачать бесплатно и без СМС! Чудом сохранившийся архив, переживший десяток переездов, несколько раз восстановленный с подохших винчестеров и почему-то не удаленный при бесчисленных попытках избавиться от хлама. Если не ошибаюсь и правильно понимаю лежавшие по соседству скрипты, то на этой карте только те замки, которыми на тот момент времени управляла маленькая команда - два человека, но полтора игрока (полноценного из них легко вычислите по названиям и логинам). Картинки замков не соответствуют насу, а лишь показывают расу, но в подписи видно правильный нас. Судя по коду, это был эксперимент по экспорту данных в клиент, нужно было визуально оценить контролируемую территорию и расстояния до противника.

Докладываю
e_maksimov
Движок игры в моей реализации состоит из двух частей: фронтэнд и бэкэнд.

Фронтэнд обеспечивает взаимодействие с пользователем, он получает запросы игроков и отсылает им результат обработки в том виде, из доступных, который игрок затребует. Сейчас он обучен отдавать в HTML, можно научить отдавать еще и в JSON или выдавать сериализованные данные для использования в клиенте - вопрос фантазии, времени и необходимости. Процессов фронтэнда может быть множество, им не требуется между собой взаимодействовать, а раз так, то можно легко нарастить производительность игры, вплоть до задействования нескольких серверов только под нужды фронтэнда. Скрипты фронтэнда могут выполнятся практически на любом вебсервере допускающем выполнение PHP и некоторых его модулей, к примеру, на моем тестовом сервере крутится под Lighttpd в fast-cgi. На фронтэнд можно навесить PHP-акселератор, поставить перед ним тот же ngnix для отдачи статики и прочие ништяки. Нам такие фичи вряд ли пригодятся, но, как уже писал, я баловался с технологиями и пробовал различные решения одной задачи.

Бэкэнд - это демон, единственный процесс постоянно висящий в памяти сервера и выполняющий просчет игровых событий. Практически вся игровая логика, правила игры и ее формулы внутри этого демона.

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

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

К чему это я все написал? Демон в целом готов, привести формулы к нужному виду можно и позже. Осталось допилить фронтэнд, работа простая, но муторная в плане написания шаблонов HTML-интерфейса и до конца февраля вряд ли успею запустить тестирование, а всякие служебные интерфейсы-бэкапы и отчеты сделаю по ходу тестирования.

Хочу узнать Ваше мнение по поводу новой концепции Деки, высказывайтесь в комментах!
e_maksimov
Я - криворукий долбоеб, изначально запостил в свой блог, вместо сообщества, поэтому, если не трудно, комментируйте здесь.

Оригинал взят у e_maksimov в Хочу узнать Ваше мнение по поводу новой концепции Деки, высказывайтесь в комментах!
Для дальнейшей работы нужно знать мнение желающих поиграть, поэтому высказывайтесь, кто как видит игру, с чем согласен, что не нравится и какие будут предложения. Сразу предупреждаю, не факт, что все пожелания будет приняты, но разумные и обоснованные предложения и замечания постараюсь учесть.

Итак, как представляется игра, по пунктам.
а) Каждый игрок владеет, в идеале, единственным аккаунтом у которого есть логин и пароль, емайл для связи и секретный вопрос для восстановления пароля. Игроки играющие за несколько аккаунтов будут выявляться и наказываться. Логин и е-майл игрока нигде в игре не раскрывается, что обеспечит чуть больше безопасности от взлома е-майла или подбора пароля.
б) Один аккаунт управляет множеством своих замков. При вводе логина-пароля к аккаунту игрок сначала попадает в список его замков, в которые он может перейти, переход между замками аккаунта не требует повторного ввода логина-пароля.
в) Выбрав замок игрок увидит практически тот же самый интерфейс для управления замком и юнитами, что был ранее.
г) Возможность создания нового замка будет предоставляться каждому аккаунту один раз в сутки, автоматически. Зашел в игру - ткнул в кнопку и регнул замок с тем логином, какой хочешь (если он не занят), координаты нового замка выбираются случайным образом. Не использовал возможность - она сгорает.
д) Принадлежность замков конкретному аккаунту скрыта от остальных Игроков. Обмен сообщениями осуществляется между конкретными замками, на внутреннем форуме (если таковой нужен) сообщения так же пишутся от имени замка, а не логина аккаунта.
е) Замки одного аккаунта фактически разделены между собой, имеют свою переписку, системные сообщения и историю, могут состоять в различных кланах и наполнение меню кланов (переписка, списки замков и т.д.) в каждом замке так же будет у каждого свое.
ж) Мирные соглашения можно заключать-разрывать как между замками одного аккаунта, так и с чужими замками, в том числе замками клана.

Какие минусы видятся в таком подходе:
а) Трудности с командной игрой. Либо каждый играет только за себя и входит исключительно в свои замки, либо другому игроку надо раскрыть свои логин-пароль от аккаунта и он получит полный доступ к аккаунту и всем его замкам. Настоящим командам это не доставит проблем, но таковых за все время Деклайна можно по пальцам перечесть. Как по мне - так это нормально, я всегда играл в команде где было полное доверие между участниками, а как на это смотрят другие игроки? Если это им не нравится, то возможное решение может быть таким:
а.1) Возможность предоставлять генералам клана доступ ко всем клановым замкам. Это усилит значение кланов и вообще логично по игре.
а.2) Сделать функцию разделения доступа к конкретному замку для владельцев других замков. Как это может выглядеть: у замка в настройках можно задать список тех замков, чьи владельцы получают право управлять замком. Изменить этот список может только владелец аккаунта, остальные управляющие замком доступа в это меню не имеют. При таком механизме аккаунты игроков не раскрываются, только логины замков и, возможно, IP игроков имеющих доступ к замку - детали обсуждаются, но я бы IP не стал раскрывать, пусть игроки думают кому доверяют свои замки :) Соответственно, владелец замка в любой момент может запретить доступ посторонних к замку без необходимости менять свои логины-пароли-емайлы.

Еще вопрос по мирным соглашениям. Как мне видится, удобнее будет автоматически заключать соглашения с новыми замками аккаунта и при вступлении в клан со всеми замками-участниками клана. Разорвать мирное соглашение можно в одностороннем порядке, но при этом разрыв начнет действовать только через сутки и у второй стороны будет время отреагировать. Если разрыв подтвердила вторая сторона, то он начинает действовать сразу, без суточного ожидания. Такая система пойдет? Я смутно помню, как было сделано в изначальном Деклайне.

Аллёна! Ты где, на?
e_maksimov
Вообще кому-то Дека еще интересна? А то я погряз в рефакторинге и пишу код ради себя, а не ради выкатить игру в народ. Нужна обратная связь от желающих, что бы пинали меня к релизу.

Рефакторинг
e_maksimov
Играюсь с REDIS v2.2.8, по ощущениям уже зрелая вещь. После появления нормальных транзакций пропал последний довод против использования в движке игры. Переписать игровую логику под key-value БД будет не просто, но значительное повышение производительности того стоит.
Tags: