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

Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
0
6
9 лет назад
Отредактирован Inflexible
0
А можешь ссылку на скачивание не через дропбокс запилить, а чтоб с ХГМ качало?.. О.О
0
26
9 лет назад
Отредактирован lentinant
0
Inflexible, то есть, скачивание? Это же онлайн-версия, ее качать не надо. Или ты говоришь о самом хостинге? Есть несколько причин, по которым я не заливал сюда, но, если хотите, могу залить, на ваш страх и риск, так как тут можно выбирать разрешение, и я не знаю, как игра будет работать с другими разрешениями.
0
6
9 лет назад
0
lentinant:
Inflexible, то есть, скачивание? Это же онлайн-версия, ее качать не надо. Или ты говоришь о самом хостинге? Есть несколько причин, по которым я не заливал сюда, но, если хотите, могу залить, на ваш страх и риск, так как тут можно выбирать разрешение, и я не знаю, как игра будет работать с другими разрешениями.
У меня на работе просто эта ссылка не открывается :)
Так что я был бы рад, если б тут было...
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.
Тут не рассмотрена ситуация когда один и тот же переход попадает в два пути - тут логика такая, если мы пишем в результирующую матрицу переходов значение, а там уже записано более дешевая стоимость пути, то ничего не пишем, т.к. наш вариант хуже.
Показан только небольшой набор комментариев вокруг указанного. Перейти к актуальным.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.