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

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

Ранее упоминалось что в начальной версии ммо будет реализован без упора на графическую часть и без использования flash, в дальнейшем, при готовой основе эту оболочку нарастить будет не сложно. Потому ограничиваемся JS+AJAX.

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

Это смелое решение накладывает на нас следующий большой блок работ. Если в случае с предложенным ранее вариантом, можно было просто отрисовать локации в Coral, задать jsom координаты "активных ссылок" на них и расположить поверх слои с интерактивными нпс и проч., то в случае с полноценным двухмерным миром игры работы будет на порядок больше. А именно, - в числе прочего, необходимо будет писать редактор мира, через который дизайнер сможет создавать игровые локации в которых и будет кипеть жизнь.

Путем многочасовых раздумий и рисования карандашом, представляю логику построения редактора двухмерного игрового мира для mmo.
Все оказалось не таким страшным, как представлялось ранее:
В основе визуальной части мира будет лежать база текстур (вода, суша, земля,..) и спрайтов (объекты, деревья, колодцы и проч.) доступных с интерфейса редактора.
Вторая базовая составляющая, - это сама локация, в данном случае, - четко ограниченный двухмерный блок (<div> в реализации редактора), имеющий четко определенное количество минимальных вложенных в него "точек" на карте в виде квадратных блоков. То есть получается своеобразная сетка координат, состоящая из ячеек, которые мы, как не сложно догадаться, "населяем" текстурами и спрайтами.

Хотя мир у нас будет двухмерный, некоторую реализацию трёхмерности нам в него ввести придется, если не в эстетичных, то в технических целях.
Карта будет трех-слойной. 1 Слой - "Земля". На нем будут размещены все спрайты и текстуры, раскрашивающие мир. 2 слой - "жилой". На нем не будет размещено ровным счетом ничего. Это будет технический слой, разграничивающий в системе координат "жилые области" от нежилых. Думаю не сложно догадаться, что в нем мы укажем области по которым смогут перемещаться игроки, (суша) а по которым не смогут (вода, скалы, и проч.). 3 слой оставим про запас. Пусть это будет "небо". На нем будем размещать некоторые "летающие" спрайты, а, возможно и игроков. Он будет охватывать всю локацию без ограниченных областей.

Вот собственно и все. Теперь перечислим базовые функции, который должен иметь редактор игровых локаций (пока только касательно отрисовки и формирования карты).
1. Блок с картой. Изначально пустая размеченная область фиксированного размера.
2. Интерфейсный блок со спрайтами,
3. Интерфейсный блок с текстурами,
4. Кнопка (или список, вид реализации пока не важна) для выбора слоя карты с которым работает дизайнер.

Возможности:

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

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

PHP, MySQL/PostgreSQL, Apache/Nginx, HTML5, JQuery.
Серверная часть должна выдерживать одновременную игру 5000 игроков.
Система должна получится легко расширяемой для дальнейшего развития при желании и улучшении с применением, например, Flash-графики и 3d-контента.
Изначально же все будет реализовано максимально просто, а графика будет статична с минимальным количеством визуальных эффектов.
Предлагаю максимально строго придерживаться MVC-модели разработки приложения.
Уровень доступа к данным предлагаю реализовывать на основе PDO, это значительно упростит перенос приложения на PostgreSQL или другие субд если возникнет в этом необходимость.

Документация:

Раз будем создавать простую но расширяемую платформу, - сразу позаботимся об обеспечении её переносимости и документированности.
Первое время разработка будет вестись прямо на форуме, без применения SVN, сред разработки и баг-трекеров, поскольку далеко не у всех начинающих разработчиков есть опыт работы с ними. К тому же на начальном этапе разработки в них нет такой большой необходимости.
Любой создаваемый класс и объект должен быть документирован. За стандарт составления документации предлагаю принять phpdocumentor. У кого нет опыта работы с ним - почитайте мануалы, начав с википедии, либо посмотрите как будут писать документацию другие.

Вот в принципе и все для начала. Местами требования и установки расплывчатые, но все охватить в одном посте не получится и нет смысла пытаться.

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

Обозначим простую тему и жанр игры. Пусть это будет (определится опросом) mmorpg.
В нашей простой игре будет всего две противостоящих расы: ___ и ____, как ни странно, два пола персонажей.
Идем по пути краткого обзора того, как будет видеть игровой процесс игрок.

Фаза вступления в игру

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

Игровой мир: локации.

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

3 типа локаций:
1. Разрешено пвп (можно вызывать игроков свой расы на дуэль).
2. Запрещено пвп
3. Разрешено нападение на игроков не своей расы.

Взаимодействие с не игровыми персонажами:

Нип это элемент или персонаж с которым может взаимодействовать игрок.
Не игрового персонажа можно добавлять через систему управления. Базовые параметры добавления:
1. Имя
2. Изображение
3. локация
4. координаты на локации
5. активен/нет.
6. тексты диалогов.
7. действия в ответ на действия игрока: текстовый ответ, передача предмета, нападение.
8. предметы
9+ Все параметры, как у игрока, за исключением динамических.

Виды взаимодействия с нипом:

1. диалог
2. бой
3. передача предмета

Взаимодействие с другими игроками:

С игроками можно вступить во взаимодействие только через его ник в чате локации.
2 вида взаимодействия: обмен инвентарем и дуэль. Отправку приватного сообщения в чате для удобства не будем считать взаимодействием с игроком

Описание логики боя:

В случае вступления игрока в бой с противником игроком или монстром загружается 2D-изображение с фоном локации боя (сразу ставим галочку, что у нас теперь есть 3 изображения для локации:1. на мини-карте, 2. большая карта локации, 3. фоновая подложка для дуэли) и статичными картинками противников.
Если бой ведут игроки, то они поочередно наносят удары друг другу, выбирая "удар" из списка доступных.
Если бой ведется с монстром, то приложение делает ходы за монстра.
Каждый ход подсчитываем здоровье бойцов, если у кого-то 0, заканчиваем бой, увеличиваем опыт победителя на N единиц.

Победа:

После смерти противника игроку открывается окошко с доступным инвентарем поверженного (ставим галочку - у каждого монстра и нипа должен быть список предметов "лута"), персонажу прибавляется N опыта (ниже - характеристики персонажа).

Поражение:

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

Характеристики персонажа:

В нашем приложении их набор будет минимальным.
1. Здоровье
2. Сила (усиливает удар на значении силы)
3. Броня (ослабляет удар на значение брони)
4. доступные удары (упрощенно скажем что просто наност разный урон)
5. Шанс критического удара (шанс на то, что урон от удара будет удвоен)
6. Уровень (Упростим задачу: по достижении каждого уровня увеличиваем каждую характеристику персонажа на N);
7. Опыт (Текущее количество опыта. По достижении опыта определенного для N уровня, поднимаем уровень персонажа на 1).

Предметы:

Любые предметы будут иметь простейшие характеристики:
1. +N к любым характеристикам персонажа.
2. Многоразовость. Если 0, то доступен в использовании, как удар. После использования удаляем его у игрока.

Управление игрой:

Пока просто перечислю функции
1. Добавление локации.
2. Добавление нипа.
2.1 Добавление текстов
2.2 Добавление предметов
3. Удаление персонажа
4. Бан персонажа с сохранением в базе.
5. Молчанка в чате.
6. Убийство игрока
7. Передача 4, 5, 6 полномочий конкретным игровым аккаунтам.

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

1.Вносим поправки-пожелания в "регламент" разработки выше.
2.Лаконично обсуждаем и вносим предложения в "описание геймплея", своего рода диз-док нашей простой игры. В сторону его усложнения двигаться не будем, поскольку цели у нас учебные.

Начинаем проектирование с разработки бд и уровня доступа к данным.
Повторно оговоримся, что мы не используем встроенные функции php для работы с субд, а используем PDO. Для доступа к данным в выигрышных ситуациях пишем и используем хранимые процедуры.

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

Привет!Помогите выбрать красивую анимацию для рекламного агентство дайте ссылки