Я всё еще издеваюсь над БТ, пытаясь получить приемлемый результат. Пока дошел до концепта, похожего на оригинальную игру, но с изменениями, о которых я писал немного раньше.
По просьбам желающих, залил на ХГМ. Правда, может шалить разрешение (размер шрифтов, местоположение и всё такое), и я могу забыть залить новую версию. Во всяком случае, выбирайте разрешение 640 на 480.
Игрок всё так же управляет и комнатами, и героем. Враги также ходят и вращают комнаты. От системы "накопительного хода" отказался, теперь у вас три действия на ход (в будущем улучшаемая характеристика), после которого ходит один враг. Атака в любом случае завершает ход.
За убийства врагов игрок получает золото, которое можно тратить на лечение (красный алтарь с сердечком) либо на прокачку характеристик (синий алтарь с молнией). Характеристики врагов определяются характеристиками персонажа (коэффициентами).
В любой момент можно перейти на следующий уровень (временный спрайт лестницы - стрелочка вверх).
Пока есть только основная механика, и один тип врага - скелеты (с чего и название поста). В будущем на более высоких этажах будут более опасные враги (с более высокими коэффициентами), и дополнительные элементы типа сундуков и ловушек. Также собираюсь добавить навыки (в том числе, и врагам), правда, всё еще думаю над тем, как выдавать их игроку.
`
ОЖИДАНИЕ РЕКЛАМЫ...

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
14
9 лет назад
0
lentinant:
поиск пути я пытался сделать, для монстров
Они не могут целенаправленно искать игрока? о_О Повышение сложности через преследование и агрессию игрока - это более мягкий и интересный путь, чем тупо накручивать врагам хелсы.
По идее, поиск пути не должен отличаться от обычного. Тут небольшая матрица ячеек, возможность перехода из ячейки к соседям фиксирована, цена зависит от её положения. Перед каждым расчетом нужно строить граф уровня, цена перехода из узла в узел рассчитывается как количество поворотов, требуемых для перехода. А дальше классический поиск в ширину, никаких наворотов типа A* не нужно, размер матрицы крошечный.
Если что - могу поделиться кодом поиска пути на C++.
0
26
9 лет назад
0
овышение сложности через преследование и агрессию игрока - это более мягкий и интересный путь, чем тупо накручивать врагам хелсы.
Дело еще и в том, что пространство маленькое, и если все враги подряд будут просто преследовать игрока, то рано или поздно его тупо окружат. Рандомное же блуждание обеспечивает хотя бы какую-то видимость патрулирования монстрами уровня, и дает игроку причины обходить монстров в случае необходимости.
0
14
9 лет назад
0
lentinant, конечно не должны все враги ломиться на игрока. Только самые злобные и агрессивные. Это фишка, когда все враги простые и рандомные, а некоторые, особо опасные, агрессивно ищут игрока. Враги в виде яблонь, которые хочешь обстучал, а хочешь мимо пошел не делают вызова, разве что плотной толпой встанут на пути.
1
24
9 лет назад
1
Дело еще и в том, что пространство маленькое, и если все враги подряд будут просто преследовать игрока, то рано или поздно его тупо окружат.
Решал когда-то эту проблему внесением хаотичности в движение противников, но с сохранением общего направления на игрока. Например так - один шаг гарантированно к игроку на три случайных. Так, конечно, тоже окружают со временем, но не так быстро и эффективно. Плюс здорово оживляет картину происходящего, когда кол-во случайных движений меняется в зависимости от расстояния до игрока - например, 2 шага до игрока это гарантированное преследование, а больше - начинает появляться случайность в движении, нарастающая с расстоянием. Плюс от типа противника можно варьировать эти граничные значения.
0
26
9 лет назад
0
По идее, поиск пути не должен отличаться от обычного. Тут небольшая матрица ячеек, возможность перехода из ячейки к соседям фиксирована, цена зависит от её положения. Перед каждым расчетом нужно строить граф уровня, цена перехода из узла в узел рассчитывается как количество поворотов, требуемых для перехода. А дальше классический поиск в ширину, никаких наворотов типа A* не нужно, размер матрицы крошечный.
Я подумал над этим. Припустим, мы посчитаем стоимость перехода из каждой ячейки в соседние, и на основе этой инфы будем искать путь. Но ведь, в процессе первого же перехода мы меняем параметры комнат, а значит, меняем вес некоторых ребер нашего графа. Обычные алгоритмы поиска пути тут не подходят. Можно при переходе к каждой вершине строить для нее заново граф, с новым весом, но, опять таки, нагрузка будет больше во столько раз, сколько вершин у нас в графе.
0
14
9 лет назад
0
Но ведь, в процессе первого же перехода мы меняем параметры комнат, а значит, меняем вес некоторых ребер нашего графа. Обычные алгоритмы поиска пути тут не подходят.
Именно обычные и подходят. Поиск в ширину с учётом веса рёбер. Классическая задача.
0
26
9 лет назад
Отредактирован lentinant
0
Именно обычные и подходят. Поиск в ширину с учётом веса рёбер. Классическая задача.
Может, я слишком глупый, и чего-то недопонимаю, но вот в чем фишка. Есть такая ситуация.
Надо попасть из A в C. Текущие стоимости переходов (повороты комнат только по часовой стрелке): из А в В - 2 (один поворот, одно передвижение), из В в С - 1 (одно передвижение), из А в D - 2 (один поворот, одно передвижение), из D в С - 3 (два поворота, одно передвижение). Итого, имеем два пути - A-B-C стоимостью 3, и A-D-C стоимостью 5. Во всяком случае, так посчитает алгоритм Дейкстры. Очевидно, что лучше брать первый путь.
Но смотрим, как пойдет наш персонаж. Он вращает комнату B, чтобы попасть в нее из А, переходит, и... ОП! Передвижение из В в С внезапно стало требовать кроме передвижения еще и три поворота! То есть, реальная стоимость всего пути - не 3, а 6.
С другой стороны, после перехода с А в D, что потребовало 2 действия, нам достаточно еще раз повернуть D, чтобы перейти в C. То есть, реальная стоимость всего пути - не 5, а 4.
Так что меня одолевают сомнения насчет того, что стандартные алгоритмы применимы для графов с переменным весом ребер. Разве что рекурсивный подход - для каждой вершины строим новый граф, с соответственными весами ребер, в нем для каждой не пройденной вершины снова строим граф, и так пока не соберем все вершины. 36 вершин, по графу на каждый, в каждом из этих графов для 35 вершин надо будет построить снова граф, в котором для каждой из 34 вершин надо будет построить граф, и т.д..
Загруженные файлы
0
14
9 лет назад
Отредактирован Kozinaka
0
lentinant, ага, понял тебя. Действительно, стоимость переходов зависит от ранее пройденного пути. Но это всего лишь означает, что стоимость переходов из текущей точки в четыре соседних нужно просто будет рассчитывать заново, а не брать из заранее просчитанного массива. Не нужно вселенную параллельных графов делать, всё равно веса нужны только для расчета перехода из текущей точки в соседние. Достаточно для каждой точки волны хранить состояние максимум четырёх соседей.
Попробую на примере:
  1. Пускаем первую волну, игрок стоит в точке А. Волна состоит из двух соседних точек. Путь в точку B стоит 1 поворот + 1 переход. Путь в точку D тоже стоит один поворот + 1 переход. Пишем в результирующую матрицу переходов: AB - 2, AD - 2. При этом для каждой из конечных точек запоминаем состояние всех соседних клеток (максимум 4, целый граф не нужен, т.к. альтернативные пути не должны и не влияют друг на друга - они все будут менять исходное состояние карты).
  1. Теперь из каждой точки первой волны запускаем по новой волне.
  1. Волна из точки B имеет всего одну незадействованную ранее точку - C. Стоимость перехода из уже повёрнутой к игроку B в С теперь 3 поворота + 1 переход (стоимость считали исходя из сохранённого ранее положения соседей точки B). Пишем в результирующую матрицу: BС - 8 (стоимость пути до B + стоимость перехода).
  1. Волна из точки D также имеет одну незадействованную точку - С. Стоимость перехода из уже повёрнутой D в С теперь 1 поворот + 1 переход. Пишем в результирующую матрицу: DC - 4 (стоимость пути до B + стоимость перехода).
  1. Волны пришли в конечную точку, поиск окончен. Теперь собираем оптимальный путь идя от C в обратную сторону и выбирая переходы с наименьшими весами: CD (4) - DA (2). Итого, самый дешевый путь: ADC.
Тут не рассмотрена ситуация когда один и тот же переход попадает в два пути - тут логика такая, если мы пишем в результирующую матрицу переходов значение, а там уже записано более дешевая стоимость пути, то ничего не пишем, т.к. наш вариант хуже.
1
26
9 лет назад
1
Kozinaka, вообще, я думаю, я поступлю гораздо проще, и при выборе одной из соседних комнат буду просто выбирать ту, которая ближе к герою. Да, количество поворотов может быть хуже, но это будет, скажем, заменой элемента случайности, о котором говорил prog.
0
24
9 лет назад
0
lentinant, тогда лучше случайную, а не оптимальную из всех возможных ячеек, ведущих к герою по мнению алгоритма поиска пути - получается AI целенаправленно идет к герою, но может произвольно петлять на неоптимальные маршруты.
Суть в том, что матрицу путей перестраивать всеравно придется довольно часто - после ходов игрока, как минимум, а в идеале после ходов каждого существа. Потому имеет смысл делать алгоритм построения матрицы максимально простым и учитывать постоянный пересчет в оценках работоспособности алгоритма. Особенно в условиях, когда идеальный поиск пути не требуется.
0
14
9 лет назад
0
lentinant:
при выборе одной из соседних комнат буду просто выбирать ту, которая ближе к герою.
Вот я тоже такие штуки люблю. Дешево и сердито. Думаю, этого вполне хватит.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.