Вчера меня посетила гениальная идея. Правда Басти по своему обыкновению тут же плеснула ложку дегтя
в бочку моего самолюбования, сказав что эту идею давным-давно придумал Глайдер. Это свойство всех галактических
идей, придумать что-то новое невозможно.
Так или иначе, идея мне очень понравилась. Настолько, что я мог бы потратить на ее реализацию примерно 40
часов в августе.
Последние несколько дней все мы находились в шоке от заявлений вицеГМа Саргоны. Нет, впрочем не все.
Некоторые из нас всегда знали, что концентрация игры на одном сервере может привести к краху по образцу ПМС. Выход
виделся в существовании мелких локальных серверов, которые, не составляя конкуренции Саргоне, помогут пережить
период до создания нового Большого сервера.
Этот подход ныне видится мне в корне ошибочным. Потому что все всегда упирается в личность ГМа. ГМ должен быть монстром со сьехавшей крышей, отдающим свое личное время на потеху неблагодарной публике. Все что получает ГМ
взамен - возможность тиранить игроков, подвергая их Утиным Реформам или не давая регистрировать завоеванное в боях
имя расы.
А нужен ли нам ГМ? Эта таинственная личность, существование которой так нарушает ролеплейную обоснованность
гелакси? ГМ нам не нужен!
Давайте разберемся в чем заключаются ГМские функции. Это:

1. Поддержка работы сервера и канала к нему. Оплата канала и хостинга. Требуется именно хостинг для приложений, относительно дорогостоящее удовольствие.
2. Набор и запуск новых игр. Решения об откатах и наказании нарушителей правил.
3. Разработка ПО сервера, и, в случае Романа, еще и клиента.

Пункт 2. легко автоматизируется или делегируется локальному ГМу. Пункт 3., по крайней мере в части серверного ПО, можно организовать на энтузиазме народных масс. Остается пункт 1 - нужен хостинг приложений и человек который следит за его работой, как минимум регистрирует баги и всячески администрит сервер. Значит, если мы хотим отказаться от ГМа, нам нужно отказаться от сервера!

РАСПРЕДЕЛЕННАЯ GALAXY

1. Общий обзор.

Хранилище данных игры находится на веб-сайте. Хозяин веб-сайта (это может быть коллегия) выступает в роли координатора, решающего, какие игры и кому можно запускать, опираясь на хранилище данных. Каждый игрок получает имя и пароль для доступа к хранилищу.
Клиентская часть получает из хранилища набор данных для каждого игрока, рассчитывает на клиенте события игры в
видимой игроком части Галактики и отдает данные в хранилище.

2. Генерация хода.

В cоответствии с расписанием, клиенты начинают получать новый набор данных за следующий ход.

3. Мошенничество.

Каждый клиент обсчитывает ход самостоятельно. Это ведет к избыточным расчетам, но делает невозможным подтасовку
данных - расчеты будут проверены другими клиентами.

4. Рандом.

Каждой планете на каждом ходу присваивается некое случайное число. Результат битвы, опирающийся на это
число, должен одинаково воспроизводиться на всех клиентах.

5. Совместимость и интерфейс.

Клиент конвертирует скачанные данные в отчет и запускает вьюер. При отправке приказа, вьюер посылает
его в клиент по SMTP.

ОБСУЖДЕНИЕ

Я даже не сомневаюсь, что сейчас выйдет кто-нибудь и загубит на корню этот проект. Да еще скажет, что
такие проекты уже обсуждали трижды за историю. Начинайте!
*** Edited 6/17/2006 12:08:18 AM UTC by ***

К сожалению придется достать свой револьвер, с целью выстрелить идее в лоб.
Ключевой пункт -
>4. Рандом.
При распределенном клиенте мы сталкиваемся с проблемой ПРЕДСКАЗУЕМОСТИ рэндома для клиента. Т.е мы сможем получить РЕАЛЬНЫЙ результат битвы ДО хода (если знаем точно состав флотов). А это... не гэлэкси.
>0. Глобально
клиент чтобы обсчитывать ход должен получать более полную информацию о галактике (в том числе то, что хозяин видеть не должен ни при каких) - например, точный состав инкамов...

>Т.е мы сможем получить РЕАЛЬНЫЙ результат битвы ДО хода >(если знаем точно состав флотов)

Мы - можем, заглянув в базу. Игроки не могут, поскольку до хода не будут знать случайного числа.

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

Зачем клиенту знать состав инкама, пока он еще не прилетел? Клиент, вешающий инкам должен будет рассчитать скорость и записать в базу ход прибытия. На этом ходу состав инкама станет доступным клиенту противника.

Скажу свое слово.

Роман Махненко в течении долгого времени писал GVNG5, но не выпустил не то что релиза, а даже RC.

Так ведь он писал клиент.

А в идее MapleKSI каждый клиент еще и сервером будет являтся в какой-то мере.

Идея мертворожденная, потому что писать такой клиент кто-то возьмется только за деньги. Гонорар отпадает ввиду необходимости поддержки, значит за зарплату.

>Роман Махненко в течении долгого времени писал GVNG5

А ведь говорили ему, что если есть ГКОММ то больше ничего не надо.

> в идее MapleKSI каждый клиент еще и сервером будет >являтся в какой-то мере

я не предлагаю отказа от существующих клиентов - вьюеров. новый клиент будет stand-alone добавкой к ним, осуществляющей расчеты и связь с базой данных

То есть речь идет о переписывании сервера. Эта задача тоже непроста, но гораздо проще написания нового клиента.
*** Edited 6/17/2006 1:17:28 PM UTC by MapleKSI***

Пнятно, ты предлагаешь писать сервер который будет у каждого клиента.

Так вот эту серверную часть тоже надо писать.

Причем для обработки присылаемых данных и рассовывания ее по БД на сервере тоже должна быть своя серверная часть. И опять ее надо писать.

Нафантазировать можно что угодно, смотрите на вещи реально.

>Так вот эту серверную часть тоже надо писать.

Надо. Но сервер написать проще чем клиента - посмотри сколько за историю гелакси написано серверов и сколько клиентов. Я не думаю что total effort будет больше чем у тебя на поддержке Legend.

Т.е. будет 3 стадии:
1. Обработка приказов на текущий ход на клиенте.
2. Связь с хранилищем, передача изменений в хранилище,
получение данных для генерации хода.
3. Генерация хода, связь с хранилищем, отправка и получение результатов хода.

Идея интересная и реализуемая.

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

Не то, чтобы это заменит "большой" классический сервер, но попробовать стоит.

Хай!

Возможно я что-то не понял, но как в эту теорию вписываются сони?

Допустим некий Sonya поставил производить на планете двух ходовый кораблик. И заснул. К базе не подключается и вооюще почту перестал принимать ( крайний случай - умер ). Его планету никто не видит. В обычной ситуации сначала его кораблик построится, а потом он будет удалён из игры, но перед этим собьёт парочку дронов. А при такой обработке, его корабль просто никогда не построится.

Насколько я понял, у каждого клиента есть все данные для обсчета хода, так? Что тогда игроку будет мешать посмотреть, скажем, не простроил ли непробу его враг?