Планирование шарда, самая сложная часть Опции

[_kaa_]

\\попытаюсь написать что-то вроде статьи.

Баланс.

Начнем с начала. Что такое баланс с точки зрения разработчиков? Попытка уровнять шансы различных классов и направить развитие по задуманной клее. Т.е. определить примерное время развития, исключить возможность «прыжков» через уровни и прочее. Т.е. по сути сделать ограничения, чтобы начинающим было одно, тем кто поиграл поболее и только хай-левелам остальное. Нужно это или нет - время показывает что нужно.

Попытаюсь рассказать как построить сбалансированный мир опираясь на опыт blizzard’ов (в основном на World of Warcraft) и на свой J

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

1. Разделение мира на зоны. Нубам – нубово (с) J
При разработки локаций четко заранее должно быть продуманно на какой диапазон уровней игрока расчитана зона. Чуть ниже будет подробнее.
2. Разделение лута по уровням, особенно если присутствует крафт. Опять же, продуманно заранее. Если из моба должны выпадать вещи, используемые в крафте,– они должны соответствовать уровню в крафте, допустимого на этом уровне игрока. Стандартная система лута для этого подходит мало, чуть ниже вернемся к этому пункту.
3. Должны быть продуманны ограничея для «самых умных». Например: за моба много выше по уровню давать не очень много опыта. (Близзард поступил совсем жестко – игрок ниже моба на 4-6 уровней имеет большие проблемы с попаданием в такого противника. Подобное в принципи можно сделать и для НВН). Некоторые ограничения (например радиус stealth для rogue зависит от разницы уровней моба\игрока) сложно реализовать в НВН, но не нужно забывать поставить мобам соответствующий скилл. Ибо нефиг.
4. Если используются разного вида скрытые двери, квесты основанные на каком-то скилле и т.п. – все должно подчиняться тому же правилу.

Список можно продолжать и дальше, но основа должна быть понятна. Что подводит нас к непопулярному в россии пунтку – планирование J Сколько вы знаете полностью распланированных еще до создания шардов? :P Очень мало.

\\если кому захочется обсудить - просьба не здесь, создайте тему.
Добавлено в [mergetime]1118613425[/mergetime]
Система лута:

Немного вернемся к системе лута. Стандартная система до жути страшна и неудобна. Учить\править что-то чужое, буржуйское – тоже не всегда удобно. В идеале – составить ТЗ и реализовать удобную систему силами того же форума.

Попытаемся описать такую систему, которая нас бы устраивала:

1. Шарды бывают разные. Кто-то использует SQL, кто-то нет. Неплохо бы заранее об этом подумать и сделать универсальную систему.
2. Выпадающий лут обязан зависить от тега\расы\уровня\класса и т.п и т.д. моба. Т.е. хорошо бы иметь возможность задать в правилах зависимость от любой информации, что можно получить с моба.
3. Иногда нужна зависимость от уровня\класса игрока. (для наград например).
4. Нужна возможность группировать похожие предметы. Скажем если должно выпадать плохенькое оружие – это не обязан быть всегда топор. Хотелось бы сделать группу «плохенькое оружие» и в ней перечислить теги плохенького меча, топора, кинжала и т.п. Возможно даже с указанием шанса выпадания конкретного предмета.
5. Разрешить «вложение» групп. (Если в пред. Примере мы создали группу «плохенькое оружие», то в группе «оружие» мы можем перечислить уже не теги конкретных вещей, а указатели на группы «плохенькое оружие», «среднее», «хорошее» и т.п. Опять же, возможно с указанием шанса выпадения вещи из конкретной группы или же просто рандомно один предмет из группы.)
6. Сам текст групп и правил должен быть читабелен. Т.е. скорее всего это должен быть не готовый скрипт, а своего рода шаблон\файл описания. В этом случае мы можем по правилам (лучше всего конструктором) создать шаблон и его превратить в скрипт (для SQL версии и обычной. Но это вариант максимум )
7. Следующим пунктом идут правила. До этого пункта мы (предположительно) описали группы однотипных предметов, теперь нам нужно задать правила сопоставления. Скорее всего в скрипт будет передаваться информация об «убитом» мобе, открытом сундуке и т.п. Из нее мы берем всю нужную нам информацию (основая – тег, но может быть что угодно, включая локацию (может кто захочет жестко в тулсете прописать предпочтительные уровни в переменных зоны)) На основе правил ищем что выпадет.
пример (полностью абстрактный, просто чтобы представить)