www.mudconnector.su

Национальный мадконнектор.
Текущее время: Пт мар 29, 2024 1:37 am

Часовой пояс: UTC + 3 часа [ Летнее время ]


Правила форума


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



Начать новую тему Ответить на тему  [ Сообщений: 84 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.
Автор Сообщение
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Пт ноя 28, 2014 8:39 pm 
Не в сети

Зарегистрирован: Пн авг 17, 2009 9:35 am
Сообщений: 26
Попробую сформулировать. Замечу, что я в новых кодовых базах не ковырялся. По идее, многое из того, что я сейчас напишу, тривиально, а значит уже реализовано в той или иной базе, их на сурсфорже хватает. При описании я исхожу из того, что движок более-менее универсален, а не заточен под механику конкретного мада.

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, поддержка игровых фракций и системы репутации персонажей и кланов, система крафта (с возможностью подключить вместо нее другую), внутриигровой аукцион. Это все отдельные модули, которые можно относительно легко подключат или модицифировать, то есть движок должен предусматривать достаточно легкое подключение плагинов, если те написаны с соблюдением требований.

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


Последний раз редактировалось Sventovit Сб ноя 29, 2014 11:48 am, всего редактировалось 6 раз(а).

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Пт ноя 28, 2014 11:43 pm 
Не в сети

Зарегистрирован: Пн май 27, 2013 4:34 pm
Сообщений: 105
Спасибо за информацию. Очень толково описаны требования к движку, давно искал подобные сведения,
т.к. у меня есть желание писать движок, но был занят клиентом. Работы по этому плану действительно дофига. Но как только закончу клиент, попробую что-то подобное сотворить. Результат конечно под вопросом. Помощники не помешали бы конечно. Сейчас я думаю на выбором языка на котором это все пилить.

1. Скриптовый язык - однозначно Lua. Он очень хорош для этого и прост для изучения не программистами. Как никак уже почти 20 лет ему - отточен, отлично работает.
2. Кодировка utf8 без вариантов. Очень легко работать с этой кодировкой.
3. Игровой протокол - скорее всего тоже Lua (на замену telneta). Так как этот язык позволяет создавать песочницы и конфигурировать api как угодно из коробки, то на его базе это получаем готовый и защищенный парсер для игрового протокола. Плюс так еще можно управлять и самим клиентом (окошечки, иконочки и т.д.) ! Клиент сам может уже при этом решать поддерживать то или это, т.е. он не обязан поддерживать весь игровой поток данных на 100%.

4. А вот с основным языком разработки ядра тут нужно думать. Основное требование к ядру - как то научиться работать в многопоточности со скриптами на Lua. Lua поддерживает сопрограммы, но не многопоточность. Многопоточность нужна, чтобы отдельные проблемные зоны кода не влияли на другие (защита от лагов, что важно игрокам).
И тут приходится тщательно выбирать:
С++ (желательно С++11, там есть поддержка многопоточности), но скорость разработки самая низкая из всех языков ИМХО.
C# - тут вопрос поддержки на Linux (соответсвтенно - это Mono). Тут нужно изучить вопрос интеграции с C, т.к. Lua на нем.
Lua/LuaJIT - тут тоже можно использовать Lua как основной язык, но проблема с системой разработки (IDE). Есть плагин для Visual Studio, но тут надо все изучать, так как он поддерживает Lua 5.1, а хотелось бы LuaJIT (для скорости работы).
Go/Erlang - перспективные языки, но очень молодые.
Node.JS - тоже отличная штука, но она заточена на веб и нет многопоточности (только сопрограммы), что ставит выбор на этот язык под сомнение.

Вообщем я в раздумьях и исследованиях - что выбрать.
Склоняюсь в варианту LuaJIT, но пока не приходилось писать большие программы на этом языке.
Хотя рассматриваю и вариант комбинированный - чтото на С++, чтото на С#, чтото на LuaJIT.
Конечно же будет использование базы данных MySQL, для статистики это уже однозначно.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Сб ноя 29, 2014 1:58 am 
Не в сети

Зарегистрирован: Пт сен 04, 2009 10:17 pm
Сообщений: 214
ArtistSpb писал(а):
С++ (желательно С++11, там есть поддержка многопоточности), но скорость разработки самая низкая из всех языков ИМХО.
C# - тут вопрос поддержки на Linux (соответсвтенно - это Mono). Тут нужно изучить вопрос интеграции с C, т.к. Lua на нем.
Lua/LuaJIT - тут тоже можно использовать Lua как основной язык, но проблема с системой разработки (IDE). Есть плагин для Visual Studio, но тут надо все изучать, так как он поддерживает Lua 5.1, а хотелось бы LuaJIT (для скорости работы).
Go/Erlang - перспективные языки, но очень молодые.
Node.JS - тоже отличная штука, но она заточена на веб и нет многопоточности (только сопрограммы), что ставит выбор на этот язык под сомнение.


А, что скажешь про objectscript?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Сб ноя 29, 2014 11:06 am 
Не в сети

Зарегистрирован: Пн авг 17, 2009 9:35 am
Сообщений: 26
ArtistSpb писал(а):
Спасибо за информацию. Очень толково описаны требования к движку, давно искал подобные сведения


Благодарю. Немного дописал про эффекты и события, и поправил опечатки. Писал вчера уже заполночь в состоянии "моск почти умер", благо я все это давным-давно обдумывал.
Насчет языка - а что насчет Java? Разница в скорости исполнения с полностью компилируемыми языками уже давно не актуальна, Java иной раз показывает даже лучшую производительность. Зато кроссплатформенность, что для хостящихся где придется мадов немаловажно. С++, к сожалению, позволяет программисту слишком многое, что тоже значимо, учитывая очень разную квалификацию пользователей движка.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Сб ноя 29, 2014 12:17 pm 
Не в сети

Зарегистрирован: Пн май 27, 2013 4:34 pm
Сообщений: 105
Pacifist писал(а):
А, что скажешь про objectscript?


Данный язык по сути аналог Node.JS и PHP. И судя по объему материала на сайте еще очень молодой.
Я выбрал бы скорее Node.JS нежели objectscript. По крайней мере я не увидел решения главной проблемы -
синхронизация различных параллельных потоков работы в скриптах.
Как вариант решения проблемы - БД. Она в принципе заточена под это. Но подходит ли это решение в нашем случае ?
По сути это хранение текущего состояния мира в БД, соответственно каждое действие игроков - чтение/запись в БД.

Pacifist писал(а):
а что насчет Java?

Основная проблема Java - это эгоизм. Т.е. если вы начали проект на Java, то вы никуда от нее не уйдете. Т.е. вы
не сможете по-простому подключить модули на C++ например. Тут придется изворачиваться и извращаться.
Пример движка на Java уже есть - CoffeeMud. Можно посмотреть. Движок действительно наворочен. Но насколько
он юзабелен стал при этом ?

Основная проблема движка мада - это : Разрешаем ли мы билдерам и все желающим писать скрипты/зоны или нет.
Если нет, то разработка упрощается, но вопрос наполнения игрового мира полностью на вас. Если да, то тут уже
надо защищаться от проблем в скриптах, которые могут сделать билдеры (изза отсутствия опыта).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Сб ноя 29, 2014 12:50 pm 
Не в сети

Зарегистрирован: Пн авг 17, 2009 9:35 am
Сообщений: 26
ArtistSpb писал(а):
Основная проблема движка мада - это : Разрешаем ли мы билдерам и все желающим писать скрипты/зоны или нет.
Если нет, то разработка упрощается, но вопрос наполнения игрового мира полностью на вас. Если да, то тут уже
надо защищаться от проблем в скриптах, которые могут сделать билдеры (изза отсутствия опыта).


Исходя из своего опыта могу сказать, что даже на DG Script сколько-нибудь приемлемые триггера, выходящие за рамки элементарнейших действий, писали лишь те билдеры, которые все равно были программистами, пусть не обязательно профессионалами. Во всех остальных случаях триггера все равно переписывались на 3/4 или писались с нуля. Так что ситуация, когда билдер просто описывает логику квеста и слова персонажей, а скрипты пишет иммортал, вполне нормальна. Теи же билдерпи, которые способны научиться делать это на нормальном уровне, можно и дать доступ к этому в каком-то виде.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Пн дек 01, 2014 12:15 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1416
ArtistSpb писал(а):
4. А вот с основным языком разработки ядра тут нужно думать. Основное требование к ядру - как то научиться работать в многопоточности со скриптами на Lua.


Не очень понимаю как вы будете синхронизацию обеспечивать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Пн дек 01, 2014 12:30 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1416
ЗЫ. Осетра по-хорошему можно урезать на 50% без ухудшения потребительских качеств.
Некогда я тоже думал, что создание каких-то "возможностей изменять таблицы не в коде" реально нужно.
А оно не нужно, абсолютно. Нужен просто код более или менее упорядоченный, чтобы было можно в него
дописывать, фреймворк так сказать. А выталкивание настроек наружу в общем-то ничего не решает
в плане простоты поддержки, надеяться что непрограммисты смогут поддерживать мад очень наивно.

Описанное не кажется чем-то невероятным. Обычный набор. И много человеколет тут не надо,
одного человекогода хватит. Фигня в том, что лично у меня свободного человекогода нету :(.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Ср дек 03, 2014 12:02 pm 
Не в сети
Site Admin

Зарегистрирован: Пт май 16, 2008 4:14 pm
Сообщений: 1416
Отделил (как смог) сюда
topic789.html


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: А что вам надо от движка-то :) ?
СообщениеДобавлено: Сб ноя 07, 2015 3:25 pm 
Не в сети

Зарегистрирован: Пн июн 22, 2009 4:08 pm
Сообщений: 311
Тоже вставлю свои пять копеек.
1) Использование в движке морфологического анализатора (я когда-то использовал pymorphy), чтобы отказаться к примеру от таких вещей, как ручное склонения слов.
2) Мир должен жить без игрока. Например, игрок убил военачальника города => стража разбежалась => в городе наступили беспорядки => из соседнего города пришли стражи и захватили город => в городе снова все спокойно.
Для мобов, к примеру, можно использовать нейронные сети (сейчас куча готовых библиотек для этого)
3) Использование п1 с каким-нибудь анализатором выражений, чтобы можно было отдавать персонажу команды в произвольной форме (команда: "убей человека в красном плаще"), от сокращений слов, в данном случае, придется отказаться


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 84 ]  На страницу Пред.  1 ... 5, 6, 7, 8, 9  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron