|
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
реализация статус-эффектов
Други! Поделитесь опытом, плиз. Раздумываю над реализацией статус-эффектов персонажей. Все кто играл в RPG или стратегии, знают, что имеется в виду: кровотечение, благословение и т.п. В моём представлении, статус-эффект - это сущность, используемая в Модели персонажа. Имеет следующие свойства: ID, режим отмены (только явный или через время), время действия. Явно напрашивается отдельный класс StatusEffect.
Вопрос в том, как лучше его "прикрутить". У меня в голове пока такой рабочий вариант. Сделать в Модели персонажа вектор объектов типа StatusEffect, зашвыривать туда все статусы и обрабатывать каждый ход. Меня он привлекает универсальностью - можно любым персонажам присваивать любые статусы или их комбинации. Но смущает ряд моментов в части управления подобным хозяйством. Главный вопрос, нормально ли это - постоянно перебирать статусы в векторе, проверяя каждый раз, нет ли в векторе статуса, влияющего на производимый в данный момент расчёт? Это буквально на каждый чих, начиная от доступности игровых действия и заканчивая бонусами/штрафами к самым различным параметрам. В общем, если есть мысли о том, как подобные вещи организовать, буду признателен. Спасибо.
__________________
Не сломано - не чини! |
|
|||||
Опять же, вместо вектора можно использовать хэш-таблицу Dictionary
__________________
while(live()) { hope(); } |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
ZergMaster, о, точняк. Хорошая идея. Даже наверное не просто Dictionary, а какую-то свою оболочку, чтобы Модель вообще не парилась с этими статусами, а просто спрашивала: "Есть такой?", и получала ответ. А уже всю возню отдать данному классу.
А можно ли перебрать все элементы Dictionary?
__________________
Не сломано - не чини! Последний раз редактировалось Appleman; 16.05.2018 в 16:13. |
|
|||||
Сущности:
1. Персонаж. Каждый имеет уникальные, динамические характеристики, которые могут зависеть от разных факторов. 2. Действующий эффект. Имеет оставшееся время. 3. Данные эффекта. Статические, все возможные эффекты заданы заранее и не меняются. 4. Список действующих эффектов. // Персонаж class Character { var agility:Number; var strength:Number; var effects:EffectList; var needUpdateStats:Boolean; } // Действующий эффект class Effect { var id:Uint; var remaining:Number; } // Данные эффекта class EffectData { var id:Uint; var name:String; var bonusAgility:Number; var bonusStrength:Number; } // Список действующих эффектов class EffectList { // Просто список с Effect, диспетчерезирующий события добавления/удаления. } Персонаж подписан на свой список эффектов, при изменений в нём устанавливает флаг needUpdateStats в true. Когда необходимо получить актуальные значения параметров персонажа, например, через геттер, проверяется этот флаг и в случае true - выполняется перерасчёт. (lazy update) Это примерный рецепт. Конкретная реализация зависит от проекта, сущностей, связей и т.д.
__________________
Дети не должны знать о своих родителях |
|
|||||
Регистрация: Dec 2014
Адрес: Санкт-Петербург
Сообщений: 479
|
Tails, большое спасибо! Я как раз и рассчитывал что-то подобное увидеть.
Похвастаюсь, что сам уже реализовал практически то же самое, только до класса EffectData пока не дошёл. И EffectList у меня скорее получился менеджером, который помимо поиска/добавления/удаления эффектов, управляет ими внутри себя. В частности, после каждой итерации перебирает эффекты, проверяет, не закончился ли срок их действия и т.п. Да, получается, что постоянный и отчаянный перебор эффектов в таком варианте никуда не делся. Если нам, например, нужно взять актуальную силу, то по-любому придётся ломиться в EffectList, перебирать все ID-шники действующих эффектов, а затем по каждому соваться в EffectData и смотреть, нет ли там влияния на силушку.
__________________
Не сломано - не чини! |
|
|||||
Цитата:
Цитата:
По сути разница только в том, что первый сразу получает объект и записывает ссылку на него в переменную, а второй получает ключ, по которому можно получить объект Цитата:
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Цитата:
Что-то вроде: EffectData надо хранить в хеш таблице с ключом по id (Int), тогда обращение будет выполняться за O(1).
__________________
Дети не должны знать о своих родителях |
|
|||||
Цитата:
Мне интересно другое, а как ты узнаешь, что эффект должен обновиться? То есть по сути эффект тоже должен каждый кадр проверяться на наличие изменений. Их в любому случае надо как-то перебирать и проверять
__________________
Ко мне можно и нужно обращаться на ты) |
|
|||||
Задача слишком абстрактна, т.е. реализация зависит от множества факторов, теоретизировать можно бесконечно... например, одни эффекты дают негативное влияние, другие позитивное, и то и то постоянно. часть эффектов отрабатывает через интервал, например раз в N минут, секунд, и т.д.. эффекты могут исключать друг друга. Я могу до бесконечности придумывать, но не вижу в этом смысла. Я думаю, будет лучше, если автор распишет конкретную идею, с точным описанием, а вот потом, хоть всем вместе придумывать реализацию.
__________________
местонахождение |
|
|||||
Регистрация: Jul 2014
Сообщений: 42
|
Интересно узнать, как формируются запросы на взаимодействие с персонажем. Если рассматривается ограниченная группа взаимодействий, то персонаж может иметь функции, которые, присущи всем персонажам и каждый вид мобов их переопределяет для себя.
Например 1. die - моб умирает, включается эффект смерти - какой-нибудь андроид или паук взорвётся, а слизняк превратится в пятно, вызывается super.die(), где восстанавливается изначальный вид и HP, и он добавляется пул (какой-нибудь стек) мобов, чтобы потом быть извлечённым при необходимости. Но если это будет моб-зомби, то он может снова оказаться воскрешённым и тогда super.die() вызывать нет смысла в первый раз. 2. rise - моб появляется на указанном месте, но каждый вид мобов сам решает, сразу ему становиться видимым, сопровождать это каким-то эффектом, сопутствующим этому виду и прочее 3. setLife - устанавливается число жизни. Опять же, кто-то может начать истекать кровью, если value<N, кто-то - чернеть или зеленеть 4. contact - если моб получает ссылку на другого моба или строение, с которым он контактирует, то для каждого вида мобов может быть индивидуальная реакция на контакт - кто-то начинает стрелять, кто-то уползает подальше, кто-то двигается по траектории относительно объекта контакта или вызывается диалоговое окно итд Возможно, все подобные функции стоит держать не в родительском классе мобов, а в API-классах, которые будут устанавливаться для каждого вида мобов в конструкторе или даже динамически. В таком случае моб становится абстрактным пультом как у телевизора и не знает, что за функции будут привязаны к нему. Зато может реализовывать интерфейс ICommandExecutor и IAPIProvider. Моб будет иметь функцию exe(cmd:ICommandObject) и getAPI(group:String):IAPI. По данным из команды выбирается подходящая API - например, ♪ изменение жизни(здоровья, силы, маны, интеллекта), ♪ диалог, ♪ сборка новых предметов, ♪ функции автономного поведения(разведка, охрана, следование) и уже в API отправляется команда и ссылка на моба. API добавлять и удалять через register/unregisterAPI(group:String, api:IAPI) и получать через getAPI(group:String):IAPI. |
Часовой пояс GMT +4, время: 17:52. |
|
« Предыдущая тема | Следующая тема » |
|
|