Попробую сформулировать. Замечу, что я в новых кодовых базах не ковырялся. По идее, многое из того, что я сейчас напишу, тривиально, а значит уже реализовано в той или иной базе, их на сурсфорже хватает. При описании я исхожу из того, что движок более-менее универсален, а не заточен под механику конкретного мада.
1. Техническая часть.
1.1. Разделение единого движка на несколько отдельных демонов. Демон логина, демон поддержки базы и бэкапов, демон чат-каналов. Дабы неполадки с одним из них не портили базу игроков, зон, и в случае с неполадками какой-то третьестепенной функции не рушили бы всю игру.
1.1.1 Выделение отдельно потока обработки мира вне действий игроков (например, обработка зон, где сейчас нет игроков, таймеров предметов и т.п.) и отдельно - обработки действий игроков.
1.1.2 Поддержка выделения в отдельный поток/процесс группы событий (см. поддержка инстансов).
1.1.3 Наличие интерфейса для работы с внешним приложением, например движком сайта.
1.2 Полноценная поддержка какого-либо вменяемого языка сценариев (вообще для этого давно придумали lua). Вероятно, многие части геймплейного кода, не требовательные к времени выполнения, следует вообще писать на этом же языке сценариев.
1.3 Полное отделение геймплейных модулей от технических.
1.4 Вынесение всех параметров, прежде всего геймплейных, в конфигурационные файлы. Таблицы опыта и базовых статов, забитые прямо в код, преследуют меня в кошмарах.
1.4.1 Как мне кажется, можно даже реализовать систему, при которой добавление более-менее тривиальной игровой возможности, вроде "скилл/спелл/эффект уменьшающий/наращивающий параметр снимающий/накладывающий заранее описанный эффект" вообще не требовало бы программирования как такового, по крайней мере за пределами последовательного вызова цепочки стандартных функций (что чисто логически не отличается от задания параметров вызова этих функций в конфиге).
1.5 Тут тема холиварная, но все же БД для хранения зон, аккаунтов, персонажей и т.п., как мне кажется, логичней и удобней. Просто в файлах только параметры настройки, которые читается, но не пишутся.
1.6 "Горячая" перезагрузка всего, что можно без больших потерь в производительности и вменяемости архитектуры кода.
2. Геймплейная часть кода.
2.1 Думаю, попытка сделать движок сверхуниверсальным, и заложить в него, например, не-комнатную механику мира, ни к чему хорошему не приведет. Однако довольно значительную универсальность заложить в "движок завтрашнего дня" вполне можно.
2.2. Отсутствие жестко прописанного в коде классов и рас. Безклассовую систему можно рассматривать как систему с одним классом. Безуровневую - как систему с одним уровнем. Класс, расу - как наборы умений и бонусов/штрафов к параметрам или ограничений на значения параметров. Например, если расе недоступен такой то класс. то значит, параметр "класс" у персонажа, у которого параметр "раса" равен определенному значению, ограничен списком, соответствующим этому значению.
2.3 Отсутствие жестко прописанного количества выходов из комнат и их направлений. Делай хоть 26 - по всем ребрам и углам "куба". Или шесть классических. Или четыре, если действие строго на плоскости. Или 72, если ты рехнулся, и хочешь сделать четырехмерный мад с выходами по всем ребрам и углам... ж) А если серьезно, то варианты 4 (квадрат), 8 (квадрат и углы), 6 (классика) и 10 (классика +диагонали) точно имеют право на существование.
2.4 Настраиваемое количество слотов и типов предметов, надеваемых в те или иные слоты. (Кто-нибудь видел не-слотовую в плане одевания CRPG?).
3. "Одновременность" обработки команд. То есть, команды игроков поступившие примерно в одно время, должны рассматриваться как "одновременные действия". Вплоть до возможности убить друг друга последними ударами. ж) Кого как, а меня заколебала ситуация, когда исход боя решают пинг и спам. Как это реализовать - вопрос отдельный. Возможно, делить поступившие команды, даже в потиковом маде, на "порции", которые считаются "одновременными действиями". Конечно, это можно отключить, например установив длительность кванта равной нулю, в этом случае команды обрабатываются строго последовательно.
3 Собственно, геймплей и все с ним связанное.
3.1 Возможность выбрать варианты взаимоотношения комнат, расположенных по вертикали. Если есть выход вниз - игрок туда упадет, или просто имеет возможность спуститься? Это, на мой взгляд, должно определяться флагами "двери". Не хочется вам "третьего измерения" - не ставьте двери, которые означают, что "это пространство внизу/наверху".
3.2 Наличие квестового фреймворка (
вопрос уже обсуждался на форуме).
3.3 Наличие поддержки всяческой социальщины. Как-то списка друзей/игнора, создание каналов для приватного общения, создания команд и т.п.
3.4 Поддержка кланов.
3.4.1 Поддержка параметров кланов с из развитием, деградацией.
3.4.2 Ассоциирование кланов с зонами (как конкретно обрабатывать такую ассоциацию - это уже в рамках конкретного мада решать).
3.4.3 Автоматическое создания кланов игроками (ессно настраиваемая, отключаемая при желании, с одобрением администрации, если надо...)
3.5 Механизм инстансов, то есть создание копии участка мира и независимая обработка всего там происходящего, с установкой правил входа/выхода в такой участок.
3.6. Поддержка динамической генерации участков мира (пример - генерируемые заново локации в Diablo). Например, в "Былинах" реализовать это трудно из-за жесткой нумерации комнат и системы их хранения.
3.7 Персональных дома игроков. Само создание, механику, стоимость - это пусть владельцы мадов сами думают, как чего. Но вот сама возможность создать группу комнат и прописать их ассоциацию с конкретным персонажем и/или аккаунтом - это может быть довольно глубоко в код закопано. Не уверен, что прав, но все же.
3.8 Поддержка, скиллов, с разбиением на группы, которые можно по-разному обрабатывать, устанавливать разные правила получения/сброса и т.п. По сути, перки/фиты и спеллы - те же скиллы, просто с другой механикой хранения и условиями применения.
3.8.1 Скиллы можно применять не только к персонажам, но и к комнатам, предметам, кланам, зонам...
3.8.2 Скиллы могут применяться не только постоянно или по команде, но и при выполнении определенных условий.
3.9 Поддержка эффектов, то есть наложенных на какой-то игровой объект изменений, временных или постоянных. Возможные варианты изменения должны создаваться достаточно легко, без переписывания половины движка.
3.9.1 Учитывать, что эффекты могут быть не просто статичными изменениями, а действиями. Например, срабатывать если персонаж кого-то атакует. Пример, аффект, с некоторой вероятностью восстанавливающий хиты персонажу при удачном применении персонажем умения определенного типа.
3.9.2 Возможность многократного наложения одного и того же эффекта, если это разрешено его описанием. Эффект может обновляться, суммироваться или группироваться. Обновление - восстановление таймера, суммирование - складывание положительных или отрицательных эффектов, группировка - неоднократное наложение одного и того же эффекта (например наложение нескольких одинаковых магических щитов, каждый из которых сбивается одной атакой определенного типа). В принципе, можно обойтись только обновлением и группированием, если грамотно реализовать обработку и отображение сгруппированных эффектов.
3.9.3 Эффект может быть применен не только к персонажу, но и к предмету, комнате, группе комнат, зоне, клану, миру.
3.9.4 Поддержка ЭОТ -effect over time. То есть damage over time (DOT), heal over time (HOT) и т.п. эффекты.
3.10 Списки рас и классов монстров, с предопределенными наборами параметров. Они могут совпадать с классами игроков, а могут не совпадать, или совпадать частично.
3.11 Модуль ИИ монстров, предусматривающий возможность дописывания модулей поведения разным расам и классам монстров.
3.12 События, то есть исполнение глобальных скриптов по таймеру или выполнению иных условий, в том числе подключение/отключение других скриптов. Пример - появление праздничных NPC и квестов при праздниках, или атакующих города монстров. Понятно, что внутреннюю логику конкретного события придется реализовывать отдельно, но должен быть глобальный механизм отслеживания условий и запуска/прекращения события по условиям.
3.13 Механика сбора игровой статистики, на основе которой легко строить разные рейтинги, системы званий и т.п.
4. Статистика для администрации. Набрано, потеряно, убито, потрачено и т.п. С возможностью легко расширить или отключить.
5. Поддержка географии мира. То есть, зоны можно объединять в группы, устанавливать тип и иерархию групп. зоны->город|район|дорога. Города+районы+дороги - условно "княжество". Княжества -> королевство. Количество ступеней, названия и соотнесения условны, конечно. Разве что города, как сущности, можно прописать жестко. Слабо себе представляю игровой мир без "городов" в каком-либо виде. Хоть космическая станция, хоть "город дверей".
6. Таймер/календарь. Число часов в сутках, число дней в месяцах, сами месяцы. Настраиваемый, с возможностью иметь несколько параллельных календарей и отображать игроку время по тому или иному календарю, в зависимости от условий. Например - от планеты пребывания.
7. Боевая система. Вот тут я даже не очень уверен, но по-моему система с кулдаунами, по большому счету, тоже раундовая, просто этот факт несколько замаскирован. В одном раунде у нас 2 автоатаки, в другом 3, потому что одна началась еще в предыдущем раунде. В целом же бой должен быть реализован как объект, обрабатывающий последовательность событий. Тогда можно относительно легко добавлять новые события и их обработку.
7.1 Наличие разделения боя по дистанции. Если не нужно - просто отключить все дистанции кроме "ближний бой", как в большинстве циркуль-мадов и есть.
8. Чуть не забыл ж) Модули базовой механики. Как взаимосвязаны параметры? Например опыт и уровень, базовые параметры и количество фитов. Как определяется успех или неуспех применения скилла? Как часто идет автоатака и есть ли она вообще? Какова длительность раунда и "кванта" обработки команд? В общем, то, что в настольных системах называется "core rules". Такие базовые вещи логично вынести в несколько модулей "ядра" игровой системы, относительно легко позволяющих модификацию.
9. Зоны и формат зон, предметов, локаций и монстров.
9.1 Задание шаблоны и тэги в описаниях с обработкой при загрузке или событиях.
9.2 Список монстров и предметов, не являющихся принадлежностью определенной зоны. Как вариант - их можно размещать в специальной служебной зоне, но тогда ограничение на количество предметов и т.п. в зоне должно быть очень большим. Разновидностей свитков или магических напитков, или предметов для крафта может исчисляться сотнями.
9.2 Поддержка механизмов перезагрузки отдельных монстров и комнат, зон целиком и групп зон, с возможностью выбирать тот или иной механизм.
10. Дополнительные фишки-модули - это уже вишенки на торте. Войны и вообще политика кланов, арена и БГ а-ля WoW, поддержка игровых фракций и системы репутации персонажей и кланов, система крафта (с возможностью подключить вместо нее другую), внутриигровой аукцион. Это все отдельные модули, которые можно относительно легко подключат или модицифировать, то есть движок должен предусматривать достаточно легкое подключение плагинов, если те написаны с соблюдением требований.
Как-то так. На таком движке, кмк, можно относительно легко реализовать механику почти любого существующего мада, дописав необходимый функционал по потребности. Да, я знаю, что никто не возьмется такое написать. Тут работы на год-два коллективу кодеров на зарплате. ж)
О чисто технических вещах, типа поддерджки юникода и других кодировок, писать не стал.
Вход
Регистрация
FAQ
Поиск
.