![]() |
Здравствуйте, гость ( Вход | Регистрация )
![]() |
![]()
Сообщение
#1
|
|||||
Level 9 ![]() Класс: Волшебник Характер: Chaotic Good Раса: Дракон NWN: Скриптинг [PW] ![]() |
\\попытаюсь написать что-то вроде статьи. Баланс. Начнем с начала. Что такое баланс с точки зрения разработчиков? Попытка уровнять шансы различных классов и направить развитие по задуманной клее. Т.е. определить примерное время развития, исключить возможность «прыжков» через уровни и прочее. Т.е. по сути сделать ограничения, чтобы начинающим было одно, тем кто поиграл поболее и только хай-левелам остальное. Нужно это или нет - время показывает что нужно. Попытаюсь рассказать как построить сбалансированный мир опираясь на опыт 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. Следующим пунктом идут правила. До этого пункта мы (предположительно) описали группы однотипных предметов, теперь нам нужно задать правила сопоставления. Скорее всего в скрипт будет передаваться информация об «убитом» мобе, открытом сундуке и т.п. Из нее мы берем всю нужную нам информацию (основая – тег, но может быть что угодно, включая локацию (может кто захочет жестко в тулсете прописать предпочтительные уровни в переменных зоны)) На основе правил ищем что выпадет. пример (полностью абстрактный, просто чтобы представить)
8. Далее идет обработка нашего шаблона в nwn или sql скрипт. Не считая стадии описания это самая ответственная часть J Собственно сложного тут ничего нет, но поработать надо. В результате работы может получится примерно следующий скрипт: (все _очень_ примерно)
В случае подгрупп идет рекурсивный вызов той же функции. С правилами чуть посложнее, но не на много. Что требуется и что получаем: Требуется все это реализовать. Я займусь, если кого то такая система серьезно заинтересует. Еще лучше если кто-то еще из скриптеров заинтересуется, одному писать и тестить скучно. Еще лучще если это будет кто-то, знающий xml По сути мы получим свой мини скриптовый язык для описания системы лута (которая учитывала бы любые уникальные теги, их просто нужно будет описать. В идеале все будет понятно не скриптеру. Сам скрипт предпологается писать на чем-то кроссплатформенном, скорее всего на перле. Если на шарде используется крафт - _очень_ просто все касаемое выпадения\добывания лута вставить сюда. Теперь чуть подробнее на деталях. В папке с модулем лежит файл itempalcus.itp, который отлично открывается NWN Explorer’ом. Это описание плюс ресреф всех кастомных вещей модуля. Есть подобные же стандартный файл, itempalstd.itp в одном из паков с игрой. Если создавать простейший конструктор, то не придется вспоминать теги. (для примера – посмотрите тут http://kaa.mhost.ru/cgi-bin/items.cgi . Это скрипт на js для нашего крафта на Миде. Данные в правом поле берутся из файла, полученного в результате экпорта itempalcus.itp с помощью NWN Explorer’а.) |
||||
![]() |
![]()
Сообщение
#2
|
|
Level 9 ![]() Класс: Волшебник Характер: Chaotic Good Раса: Дракон NWN: Скриптинг [PW] ![]() |
Система пермаментной смерти
Да,да. Оно самое :) Кажется все когда-то хотели реализовать идею пермаментной смерти, но отпугивать игроков никто не хочет. В то же время по игре часто нужно убить "совсем". Предлагается следующее: Два вида смерти. Первая - "не настоящая". Нужна в основном для начальных уровней, когда покусали злые мобы и прочее. Реализуется как стандартная НВН-смерть (или лежит на месте пока не вылечит кто). Ничего необычного, сойдет та смерть что реализована уже. Вторая - "пермаментная". Некоторые виды мобов и игроки в некоторых случаях могут убить "совсем". Чар баниться на уровне игры, ставиться хитрая метка и раз в сутки (раз в час, т.д. - не важно) ОС удаляет все файлы с входжением "хитрой" строки (т.е. удаляет файлы с убитым чаром с ваулта). Для этого аккаунта запоминается количество экпы, что было у убитого чара. При создании следующего чара он начинает игру не 1 уровнем, а ему выдается какая-то часть опыта убитого (может и часть денег из "наследства", какие-то начальные вещи). Все, что было на убитом чаре - понятное дело теряются. Детали уже зависят от шарда, но идею надеюсь понятно объяснил. Какие плюсы это дает: * Игрок "стирается" из мира. Если его съел крокодил - значит съел совсем, наутро он не очнется и не пойдет гулять. * Можно реализовать "убийства". Т.е. у вездеприсутствующей гильдии воров\убийц появится настоящая работа. А то кому интересно заказывать убийство, если через несколько минут тот-же персонаж снова живой. * Самые "дорогие" мобы получают возможность "сожрать" игрока совсем. Награда хорошая, но и риск большой. * Игроки даже если были "убиты" - не начинают совсем с начала, а имеют начальный опыт и какое-то наследство. По желанию на шардах с разными условиями для разных классов можно добавить условие, что опыт выдается только аналогичному классу с убитым чаром. |
![]() ![]() |
Текстовая версия | Сейчас: 26th April 2025 - 22:25 |