Смерть персонажей в консольной игре

Добрый день. Для тренировки пишу консольную action rpg. Встал вопрос, как организовать корректно смерть главного персонажа и врагов что бы потом можно было с них собрать предметы. Нужно подсказать с логикой алгорима.

С со смертью главного персонажа вроде как придумал создать отдельный класс для старта игры и отдельный класс для проверки состояния главного персонажа с методом в потоке, который проверяет жив ли персонаж, если он умер, то метод возвращает занчение false, и метод StratGame()перестает выполняться и игра игра заканчивается.

С врагами сложнее, не могу сообразить как заставить мертвых врагов удалиться после смерти, тоесть по тоей же логике создаю отдельный класс с проверкой на состояние жив ли враг, и при появлении врага запускается поток с проверкой жив/мертв, после чего если он мертв, метод Fight(), перестает работать и запускается екземплярный метод Die(){Console.WriteLine($"{EnemyName} побежден")}; . Но как мне потом убрать персонажа из памяти, а враг в состоянии смерти находиться, и получается чем дольше я играю тем больше плодиться врагов.

Может как то с помощью событий это реализуется, но я не могу никак понять нужный алгоритм. Прошу помочь.

0

Подбираете лут с противника и вызываете для класса Dispose.

1

Aferuga, идеальное решение))

Добавлено через 1 минуту
Aferuga,

Сообщение от Aferuga ....и вызываете для класса Dispose....

для потока в котором создал класс сражение

0

Сообщение от Esso11 для потока в котором создал класс сражение

Можно и там, если скажем лут никак не зависит от класса Enemy, или лут забирается автоматически в том же классе сражения или вообще у мобов нет лута.
Тут все зависит от вашей реализации, если у вас есть список противников вроде List<Enemy> то для элемента можно вызвать Remove или RemoveAt.

Сообщение от Alone11 при появлении врага запускается поток с проверкой жив/мертв, после чего если он мертв

Логичнее проверять по факту, то есть при получении повреждений как-то так:

1

Сообщение от Alone11 С со смертью главного персонажа вроде как придумал создать отдельный класс для старта игры и отдельный класс для проверки состояния главного персонажа с методом в потоке, который проверяет жив ли персонаж, если он умер, то метод возвращает занчение false, и метод StratGame()перестает выполняться и игра игра заканчивается.

Какой к глиняной маме мультипоток? Тама вообще то нужны псевдосинхронно работающие конечные автоматы. Псевдосинхронно означает каждый автомат за один таймфрейм делает строго один шаг. Т.е. система такая - цикл который каждый таймфрейм(он же шаг модели) пробегает всех вражин и вообще все что не статично и вызывает им метод назовем ему условно Update. Тогда можно в методе Die выставить признак мы издохли и количество шагов которые лежать до выноса тела. Каждый вызов Update уменьшать его значение на 1. Когда дотикает до 0 убрать его из списка действующих объектов в список доступных до спавна.
И если что то вообще и параллелить - то только этот цикл. Вплоть до отдельного потока на каждый элемент сцены. И ждать когда все доработают. После этого перерисовка. т.е. главный цикл игры Update - Draw. Между Update и Draw проверять жив ли перс и если совсем не жив выходить из цикла.
Еще вариант - завести таймер -очередь приоритетов и список кого апдейтить. Тогда меньше мертвые тела ждущие выноса дергать надо. Т.е. мертвое тело при умирании убирает себя из списка апдейтов и заносит в очередь таймера. Очередь сортирована по номеру таймфрейма в котором наступает событие. На каждом своем апдейте таймер отправляет со сцены в очередь на спавн всех у кого номер заданного таймфрейма совпал с текущим.
Это чисто технические варианты решения. А можно сделать эстетические аки в Сталкере. Т.е. завести милых песиков которые кроме главных героев питаются невинно убиенными монстрами (в сталкере реально собаки могут мертвые тела прямо с поля боя утаскивать).

3

Fulcrum_013,
Кхм... так-то речь идет о консольной action rpg(см топик), поэтому тут врядли будет какая-то отрисовка.

1

Aferuga, Ну как бы вывод текста это тоже отрисовка. DirectX это просто такая реализация класса Console в графических играх. Ну а пошаговая она или реалтаймовая - разница только в том что пошаговая ждет ввода пользователя перед каждым проходом главного цикла, реалтаймовая не ждет.

0

Fulcrum_013, чувак, кто ты?))) откуда столько знаешь про потоки ?!))) поделись какой то литературой

Добавлено через 34 секунды
Aferuga, Ваш вариант мне более симпатичен

0

Esso11, Да как бы из логики вещей знаю. Параллелить нужно там где не нужно потом плясать с бубном вокруг синхронизации. А там где можно событийным управлением заменить лучшее вообще не параллелить. Когда активных процессов больше чем вычислителей то от параллеленья только лосы на тасксвитчинг вместо профита. А поскольку ядер ну никак не более 12 то их найдется чем загрузить в таких задачах чтобы они без тасксвитчинга молотили. Имеется в виду класс подобных AAA задач - игровая имитация мира со всей его физикой и т.д. Потому что конкретно в этой задачке древнего 8086 чересчур много без всякого параллеленья.

1

Сообщение от Fulcrum_013 Какой к глиняной маме мультипоток? Тама вообще то нужны псевдосинхронно работающие конечные автоматы. Псевдосинхронно означает каждый автомат за один таймфрейм делает строго один шаг. Т.е. система такая - цикл который каждый таймфрейм(он же шаг модели) пробегает всех вражин и вообще все что не статично и вызывает им метод назовем ему условно Update. Тогда можно в методе Die выставить признак мы издохли и количество шагов которые лежать до выноса тела. Каждый вызов Update уменьшать его значение на 1. Когда дотикает до 0 убрать его из списка действующих объектов в список доступных до спавна. И если что то вообще и параллелить - то только этот цикл. Вплоть до отдельного потока на каждый элемент сцены. И ждать когда все доработают. После этого перерисовка. т.е. главный цикл игры Update - Draw. Между Update и Draw проверять жив ли перс и если совсем не жив выходить из цикла. Еще вариант - завести таймер -очередь приоритетов и список кого апдейтить. Тогда меньше мертвые тела ждущие выноса дергать надо. Т.е. мертвое тело при умирании убирает себя из списка апдейтов и заносит в очередь таймера. Очередь сортирована по номеру таймфрейма в котором наступает событие. На каждом своем апдейте таймер отправляет со сцены в очередь на спавн всех у кого номер заданного таймфрейма совпал с текущим. Это чисто технические варианты решения. А можно сделать эстетические аки в Сталкере. Т.е. завести милых песиков которые кроме главных героев питаются невинно убиенными монстрами (в сталкере реально собаки могут мертвые тела прямо с поля боя утаскивать).

Огромное спасибо за наводку. Ваш опыт рубит с плеча. К сожалению я в свое время много пролюбил в универе, и теперь не затащу конечные автоматы с наскока. Ваш совет очень толковый, но боюсь пока сложен для меня, на вскидку переделываю реализацию без потоков, как вы и сказали, и думаю сделать так:Персонаж переходит на новую клетку, в ней проверка есть ли враг, если есть то создаю экземпляр класса битва при столкновении с врагами, передаю в него ссылку на экземпляр героя, в екземпляре класса битва генерирую рандомно врагов от 1 до 3, и веду бой. Как он закончиля запускаю метод собрать лут в него передаю рандомный лут из врагов и ссылку на персонажа, в методе присваиваю
лут в List<Item> персонажа (Это рюкзак его), а потом вызываю Dispose в екземляре битва.Экземпляр битва со всеми врагами удаляется, как я надеюсь. Персонаж двиаегтся к следующей клетке. Как то так. С корректируйте если чего не так.

ps/ Ощущения пока как в том анекдоте про советского разведчика "- Говорили мне в штабе - учи! Учи!"

0

Alone11, не мое конечно дело, но может стоит сделать вначале на том уровне на котором понять легче самому ... и позже модернизировать восполняя знания все новой и новой инфой.

как говорили в одном х/ф ("Бери ношу по себе что бы не падать при ходьбе")

0

Так и делаю, но нужно видеть как делать правильно или придеться топтаться на месте.

0

Alone11, Ну не знаю какие у вас там правила игры. Но не совсем понятно зачем там вообще класс битвы. Насколько понимаю такая штука в архитектуре появилась в результате прикручивания движка "комнатных" битв а-ля БК к какой то из ранних браузерных mmorg ну а дальше копипастится везде.
Вообще лут который в ней лежит должна хранить клетка. Вообще суть разбиения поля на клетки - это двумерный индекс ускоряющий поиск сущностей находящихся вблизи заданной координаты.

0

Fulcrum_013, ох великий бк))) скучаю по нему)

0

Сообщение от Fulcrum_013 Alone11, Ну не знаю какие у вас там правила игры. Но не совсем понятно зачем там вообще класс битвы. Насколько понимаю такая штука в архитектуре появилась в результате прикручивания движка "комнатных" битв а-ля БК к какой то из ранних браузерных mmorg ну а дальше копипастится везде. Вообще лут который в ней лежит должна хранить клетка. Вообще суть разбиения поля на клетки - это двумерный индекс ускоряющий поиск сущностей находящихся вблизи заданной координаты.

Fulcrum_013, действительно, чем то концепт напомнинает БК, так как не играл в нее даже и не думал что примерно что то похожее вырисовывается. Но, я наверное вас немного запутал, я делаю консольную RPG для тренировки, как консольное приложение в VS2015. Цель - тренировка навыков ну и по возможности, как и сказал Esso11, расширить функционал игры тренируя изученные темы, вводя новые элементы, усложняя проект, что даст опыт, может быть какое никакое протфолио, если выйдет что то большое.

Класс для битв создавался мною потому, что, как я понимаю, так должно быть по SOLID (S - принцип единоответственности в часности), отсюда старался разбить каждую сущность или поведение в отдельный класс. Вы, как я понимаю, исходите больше из практического опыта, связанного с реальным опытом разработки на движках, мой скромный опыт использования Unity3D показывает, что там есть свои нюансы, отсюда, пока, у меня нет вообще координат и прочего, Есть только массив Биом, по которым перебором перемещается персонаж, встречает в ней битву или нет, и переходит к следующей.

Скажите, почему для поведения битвы не стоит отводить отдельный класс?
У меня лут находитсья внутри екземпляров врага, которые могут быть в биоме, а могут и не быть.Как я понимаю, если бы у меня было поле по которому игрок перемещался то правильнее класть лут в ячеку поля? Так? Почему?

0

Alone11, Лут должен однообразно хранится и подбираться вне зависимости от его происхождения. А происхождения кроме выпал со врага может быть еще и выброшен игроком и вырос/проспавнился и т.д.

Добавлено через 4 минуты

Сообщение от Alone11 Скажите, почему для поведения битвы не стоит отводить отдельный класс?

А какая в этом классе необходимость? Чем он жизнь облегчит кроме того что усложнит? Он нужен к примеру в танчиках где одна комната боя полностью изолирована от других. А в mmorg где все в одном мире он только мешать будет. Потому как нельзя четко определить кто к какому батлу отношение имеет. Пример - стоишь отстреливаешь песиков. Тут сзади подбирается кровосос... и получает в бошку от снайпера который метрах в 600 сидит, а пока ты это заметил снайпер уже тама с конролером завязался в упор. Вопрос - кого в какой батл пихать и в какой батл какой лут распихивать?

0

Сообщение от Fulcrum_013 А какая в этом классе необходимость? Чем он жизнь облегчит кроме того что усложнит? Он нужен к примеру в танчиках где одна комната боя полностью изолирована от других. А в mmorg где все в одном мире он только мешать будет. Потому как нельзя четко определить кто к какому батлу отношение имеет.

, у меня как раз такой случай, не ММО, что то типо Darkest Dungeon, каждый биом это как комната в Манчкин. Она изолирована, зашел либо враг, либо сокровище, либо ничего.

А если все же добавлю сетевую возможность, как тогда? В чем то логику нужно же описывать битвы? Я кроме как создаение экземаляра битвы в которую будут передаваться персонажи ничего не придумал, на этот счет. Ну тоесть это как если в старых Final Fantasy/Heroes of Might and Magic нарвался на моба - попадаешь на поле битвы, в ней враг либо бот, либо игрок.

0

Alone11, Ну разве что по принципу как в БК. Т.е. когда те кто в битве до конца битвы друг от остальных изолированы. И лут не может просто лежать. Тогда в принципе смысл есть. Опять же если мултиплеер то возникает вопрос - а что делать если кто то еще зашел в туже комнату тогда когда битва уже идет?

0

Сообщение от Fulcrum_013 Alone11, Ну разве что по принципу как в БК. Т.е. когда те кто в битве до конца битвы друг от остальных изолированы. И лут не может просто лежать. Тогда в принципе смысл есть. Опять же если мултиплеер то возникает вопрос - а что делать если кто то еще зашел в туже комнату тогда когда битва уже идет?

Я кажется Вас понял, у меня пошаговая, инстанционая игра, каждая клетка - это как новая комната, попадая туда, соответсвтенно можно либо повоевать либо пройти дальше. Решать такую вещь кроме как созданиме сначала отдельного екземпляра для комнаты с случайной иницилизацией поля bool enemyInside = true/false, а в дальнейшем гинерить экземпляр битвы которая уже помещает в себя персонажа и гинерит врагов, я думаю не возможно, ну или я таких выходов пока не вижу.

Вы же говорите про открытые, в основном, игры, где бои происходят в любой момент и урон идет уже от просчета попаданий (те же Танчики на nes, ну или WOT/BF/CS/DOTA2 ...), то там создавать класс битвы не нужно. Я согласен.

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

0

Alone11, ну в принципе да. никакого мультипотока там не нужно. Мало того его вообще обычно практически не нужно. Потому что даже в реалтайм играх действие обычно идет по таймфрейам. т.е. к примеру таймфрейм 1/64 секунды. Сначала каждый объект должен просчитать что с ним за эти 1/64 секунды произошло, а только потом переходить к счету следующего кадра опять же для каждого. Так получается потому что объекты могут взаимодействовать, а соответсвенно все должны находится в одном и том же моменте времени. Создание по потоку на каждый объект именно эту синхронизацию и затрудняет. Более логичный подход когда каждый поток обрабатывает все объекты модели но разные части их действий. К примеру один поток считает физику/анимацию для следующего кадра, другой отрисовывает то что первый поток насчитал для этого кадра пока он рисовал прошлый. Пошаговые же игры отличаются от реалтаймовых только тем что ждут ввода пользователя перед каждым шагом. т.е. время считается не в реальном масштабе, а в ходах. т.е. тут даже такое разделение между потоками не нужно. 99,9% времени она будет заниматься ожиданием ввода.

Добавлено через 5 минут

Сообщение от Alone11 По существу, исходя из вышеописанной концепции,

Ну тут получается что битва - это типа временное хранилище для расширенной инфы клетки. Обычно фактически все что вы собираетесь запихнуть в битву хранится в каждой клетке и обновляется при изменениях. Типа вражина перешел из a1 в a2 - из списка того что есть в a1 его убрали в список того что есть в a[2] добавили. Вражина помер - труп убрали лут оставили в клетке. Пришел кто то подобрал - лут из списка клетки удалился. Если вражины существуют только во время битвы и лут не может просто лежать то можно и так. Если может просто лежать то логичнее сделать таки расширенную инфу для каждой клетки и возможность подбирать только тогда когда живых вражин в клетке нет.

0