Куб Счастья

Дизайн-документ технической стороны игры

1. Отказ от гарантий

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

2. Задачи документа

Дизайн-документ подготовлен с целью изыскать технические возможности модернизации любимой игры миллионов "Сферы Судьбы" (tm). Дизайн-документ не претендует на объективность и не является исчерпывающим. И, ни в коем случае, не имеет своей целью внести политическую смуту в содружество двух Сфер: Ореона и Кассиопеии. Всё описанное ниже - есть всего лишь плод литературной фантазии, и не помещён в топик литературного творчества лишь в силу своей технической направленности.

3. Термины и определения

3.1. Что такое "Куб Счастья"?

"Куб Счастья" - это то, что будет со "Сферой Судьбы", после того, как она проведёт техническую модернизацию.

3.2. Что такое "Игровой процесс"?

Игровой процесс - это процесс игры.

3.2. Что такое "Клиентская часть"?

Клиентская часть, клиент (физическая единица) - компьютер пользователя, который соединяется с сервером для совершения игрового процесса.

Клиентская часть, клиент (программная единица) - программный продукт, который установлен на компьютере пользователя и непосредственно совершает акт приёма/передачи данных с целью совершения игрового процесса.

Клиентская часть является неотчуждаемой собственностью пользователя.

3.4. Что такое "Серверная часть"?

Cерверная часть, сервер (физическая единица) - компьютер, с которым происходит соединяется клиент для совершения игрового процесса.

Cерверная часть, сервер (программная единица) - программный продукт, управляющий действиями клиента.

Серверная часть - © Copyright 2003-2004 by DestinySphere GmbH.

3.4. Что такое "Протокол обмена"?

Протокол обмена - это набор правил общения клиента и сервера. Протокол обмена является высокоуровневой надстройкой над протоколом HTTP (rfc2616).

3.5. Что такое "Коммуникационные элементы"?

Коммуникационные элементы - это средства коммуникации игроков друг с другом. Это форумы, блоги, wakka, почтовые списки рассылок, чаты, любое средство, способствующее взаимному общению игроков.

4. Требования к элементам "Куба Счастья"

4.1. Требования к игровому процессу

Пишите в комментах - буду просматривать и редактировать топик.

4.2. Требования к клиентской части

Клиент работы с "Кубом Счастья" является лицом игры, поэтому важно не уронить его в грязь.

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

*) Высококачественная графика vs. компактный размер
*) Высококачественная графика vs. малая требования к процессору
*) Многофункциональность vs. доступность
*) Кроссплатформенность vs. сложность реализации
*) Всё выше перечисленное vs. бесплатность
и прочее.

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

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

1) Он-лайн клиент, основанный на флеше, в облегчённом варианте.
2) Он-лайн клиент, полностью свободный от флеша, - для каналов с низкой пропускной способностью.
3) Офф-лайн клиент с расширенными возможностями - 3D гарфика,у добное управление, возможность не находиться постоянно он-лайн, встроенный в интерфейс форум - то есть работа без надобности открывать браузер. Вариант для премиум-аккаунтов.
4) Офф-лайн клиент, основанный на электронной почте. Команды игрока передаются электронным письмом на сервер, где они исполняются в конвеерном порядке. Визуализация - отсутствует. Вариант для маньяков.

Средства, при помощи которых можно реализовать подобные клиенты:
1) Флеш - для клиента первого типа.
2) HTML+JavaScript+VBScript+GIF+JPEG - для второго типа.
3) С++, Python, Java, Delphi - для интерфейса третьего типа.
4) Любая почтовая программа, либо web-интерфейс любой почтовой системы.

Функциональность клиентов будет полностью определяться функциональностью протокола обмена.

Требования к кроссплатформенности - мягкие. Основная цель - обеспечить пользователей системы Windows удобным интерфейсом.

4.3. Требования к серверной части

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

Конфигурация кластера может значительно разниться в зависимости от объёма суммарной нагрузки, а также от распределения этой нагрузки на различные элементы системы.

Но, определённо, в состав кластера должны входить:

1) Сервер баз данных, хранящий списки пользователей, состояние их игровых аккаунтов, архив сообщений и промежуточные данные.
2) Коммуникационный сервер - отвечающий непосредственно за коммуникацию с клиентом. Отвечает на запросы, далает доступными коммуникационные элементы - форумы, чаты.
3) AI сервер - компьютер, который будет производить вычисления, связанные с игровым процессом.

Возможные варианты программного обеспечения серверов баз данных:

*) MySQL
*) PgSQL
*) Oracle
*) Firebird (InterBase)

Возможные варианты программного обеспечения коммуникационного сервера:

*) Apache+PHP
*) MS IIS +ASP

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

*) С/С++
*) Java
*) Python
*) Perl
*) PHP

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

Программное обеспечение должно работать на *NIX-подобных операционных системах (BSD, Linux), возможно решение, основанное на платформе NT.

4.4. Требования к протоколу обмена

Оптимальность протокола обмена данными - является приоритетной задачей, от оптимальности решения которой во многом зависит эффективность работы остальных элементов системы.

Протокол обмена должен удовлетворять следующим требованиям:

*) Быть максимально компактным - это даст значительную экономию сетевого траффика.
*) Обеспечивать контроль целостности данных - чтобы исключить неправильное отображение игрового процесса клиентом.
*) Иметь простой синтаксис - удобный для расшифровки клиентом.

Очевидна неуместность использования технологии XML-RPC (в случае, когда этот вариант не является единственно возможным). XML представление данных удобно в случае, когда их формат заранее не может быть оговорен с 100% вероятностью. Если разработанный протокол будет достаточно строгим, глубоко структурированным, то необходимость в расширяемом языке - отпадёт.

Поскольку каждый из типов клиентов нацелен на выполнение вполне конкретных задач, то, логично, что "диалектов" протокола должно быть несколько - по числу возможных типов клиентов:

1) Протокол для флеш-клиента должен собой представлять обмен XML-данными.
2) Протокол для чистого HTML клиента ограничен стандартами MIME.
3) Протокол для офф-лайн клиента должен быть байт-ориентированным. Расшифровка такого типа данных для клиента, написанного на современных прикладных языках программирования не является проблемой.
4) Для почтового взаимодействия нужен протокол, максимально близкий к человеческому языку - для удобства пользователя.

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

4.5. Требования к коммуникационным элементам

Коммуникация между игроками - это важнейшее условие приятного игрового процесса.

По мнению автора документа, наиболее удобно коммуникация участников может быть организованна при помощи "комьюнити", огранизованной потобно тому, как это сделано на http://www.livejournal.com/community/ru_php/ Дискуссии, организованные подобным древовидным образом наиболее наглядны.

Средства коммуникации должны органично вписываться в он-лайн клиент. На всю систему должна быть единая система коммуникации "игрок - игрок" или "игрок - группа игроков". Сообщения, отправленные прямо из клиента должны быть PM форума.

Средство коммуникации должно работать также и в связке с офф-лайн клиентом.

IRC и ICQ чаты не являются частью системы и должны работать автономно.

5. Заключение

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

Автор был бы благодарен за любые комментарии, и очень надеется, что совместные усилия поклонников проекта "Сфера Судьбы" (tm) сделают этот проект лучше.

Автор ещё раз хочет выразить свою лояльность к Администрации Проекта и ещё больше надеется на комментарии с их стороны (Бан не предлагать).

Протокол обмена является высокоуровневой надстройкой над транспортным протоколом. А вот уже транспортный протокол отпределяется из возможностей клиента.

Да, я понимаю, моё высказывание по поводу исользования HTTP действительно есть немного диковатым. И его нужно обосновать.

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

НТТР есть просто более удобным для людей, которые, возможно, будут играть через прокси. И всё. А так - да. Обоими руками за - такой протокол будет более компактным и удобным для общения.

lllumukcyc, если уж подражаешь ЕСКД, то подражай до конца. А то ошибок просто куча. Я уж не говорю что такой жесткий 'Дизайн-документ технической стороны игры' вообще никуда не годится. И еще - у меня возникло подозрение, что ты понятия не имеешь что такое кластер.
Думаю твое рвение лучше направить в нужное русло. Свяжись со мной по ICQ, а то вот как Xelag прочтет все что вы тут пишите, и не будет у нас никаких альтернативных клиентов.

Виноват. Писал на скору руку. Не проверил после себя. Я и не думал, что всё будет так серьёзно, я начинал писать с целью иронизировать над антогонизмом понятий "Сфера Судьбы" - "Куб Счастья". Потом к середине стал более или менее серьёзен. Надо было отправить в "АниСферу", но оно какое-то несмешное получилось.

Это литературное творчество - убийство времени, пока отстраиваются главные ворота.



Напрасно Я не дурак - у меня просто шутки дурацкие.

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

Я, действительно, знаком с кластерами только понаслышке. Мне в жизни, к сожалению, не доводилось иметь с ними ничего общего.



Я не хочу вносить смуту. Тем более, на таком высоком уровне. Я понимаю, моя просьба может показаться очень непоследовательной, но я не буду возражать, если данный топик не просто закроют, но и удалят с глаз долой вообще. (ещё бы! смотреть на мои ошибки! Позор на мои седины! )

Я могу выразить свои мысли технически стройно, без шуток и приколов.

Я не уверен в своем чувстве юмора, поэтому переношу в Антисферу.
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
Ух перенес, Ха Ха Ха Ха Ху Хи Хо Ху

Здорово! Мочи Флеш, в нем весь вред !!! Это все Создатели, лавры млин первопроходцев. Нам Хранителям по барабану, что хранить. Табличный интерфейс, али ваще чат с одной командной строкой.

Ничё так... тока для "сатиры" это немного серьёзно может, в "антипиар" и назвать "то, чего не будет"?

Если флешку хранить локально (т.е. скачивается с сервера один раз и запускается на машине клиента), то она совершенно не будет забивать канал. Информации будет передаваться ровно столько, сколько и при использовании офф-лайн клиента, написанного на C++/Delphi/прочем.
Единственное различие - оффлайн-клиент может сохранять информацию на диске (макросы, историю, входяшие сообщения и всё, что можно и нужно сохранять), а во флеш-клиенте это не реализуемо.

А вот табличный интерфейс, если его сделать криво, может очень сильно забить траффик. Например, если в генерируемом HTML-коде будет много пробелов (для красивых отступов).
Но в любом случае масса <tr><td></td><td></td></tr>неизбежна.

Флешку нельзя сохранить локально по нескольким причинам:
1) Не будет работать аутентификация (не понятно, на какой домен выставлять куки)
2) Без браузера флешка вообще не будет способна скачать из сети ни единого файла
3) А как же реклама? Ведь если не будет необходимости каждый раз скачивать флешку - не будет надобности скачивать каждый раз рекламу.

Если писать офф-лайн клиент, то писать разумно, с нуля. Писать на основе компактного сетевого протокола.



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

Точно так, как чем круче скин, тем тормознутее работает под ним программа.

Есль инструменты, заточенные под графику (такие, как Флеш), а есть такие, которые заточены под текстовую информацию - такие как HTML и еже с ним.



Но можно ещё делать и в связке HTML+CSS, если умно делать, то будет всё очень даже хорошо.

Тот есть каскадные таблицы стилей могут весьма облегчить код.

тебя надо за флуд забанить!!!и за мультоводство!!!!

Доказательства - в чемодан если они есть и с чемоданом в ДВ. Без доказательств не вопить. Гальв

Не тебе решать, кого банить, а кого - нет.

Что касается флуда - то флудер - ты.

А откуда ты знаешь, что он мульт? и чей? или кто у него есть?
Приведи хоть одно доказательство - иначе ты еще и балабол.