DeadStar — готовлю билд для теста боёвки, пока что упирается в создание сносных противников. Параллельно распиливаю игру на комнаты. И сегодня маленькая победа (для моего личного геймдева в целом) — сделал комнаты как в тру-метроидваниях — разного размера и пересчёт переходов между ними. Дальше миникарта и сохранение состояния объектов. Отдельный гемор — езда на Звезде, буду делать позже.
- 15 июля 2019, 22:16
- 08
делай несносных противников.
Вот тебе идеи:
- противники очень похожие на декорации, пока не зашевелятся
- телепортирующийся по экрану противник
- очень быстро бегающие мелкие твари, которые не нападают, но при столкновении ранят
- противник, к-му надо стрелять в бошку, к-й он бьет (стрелять надо туда только во время собственной атаки)
- противник, к-й перемещается с постоянно меняющейся скоростью
- просто 2-3 вида животных, к-е просто передвигаются по уровню, но их нельзя убить или как-то с ними взаимодействовать
- вылезающие из под земли самонаводящиеся жуки (в случайные моменты когда рядом игрок), убиваются 1-м выстрелом, сами умирают при камикадзе
Идеи неплохие, да и у меня тоже довольно много есть.
Однако, хочу классифицировать противников, причём заранее. Есть несколько когорт: Андроиды(как ГГ), Роботы, Насекомые, Люди, Рефлекты. Пока что мне нужно сделать противников-Роботов. Их будет большинство, и скорее всего они будут разделены ещё на подклассы.
Если в игре нужно будет качаться и каждый (даже самый первый) враг будет головной болью (ну хотя бы на максимальной сложности), то я уже фанат игры) Я просто люблю игры, где начинаешь с самых низов, когда статы или силы минимальные и сначала даже один слабый враг доставляет проблемы, так намного приятнее раскачиваться и чувствовать прогресс, чем если бы изначально всё было средне. Не будет чувства, что наконец-то начал побеждать опасных врагов, а когда враги все опасные, то это вообще шик :3
PS Специально себе в Skyrim (например) снижаю статы с помощью модов до 1, и убираю все заклинания, и еще урон увеличиваю (как со своей стороны, так и вражеской), по другому если играть, то возникает чувство, что кто-то до тебя этим персонажем играл, и уже нехило вкачался, узнал где-то важные заклинания, и враги мало доставляют проблем даже на легендарной сложности. И так во многих играх, где тебе сразу накидывают кучу ништяков, а лучше бы их своим потом и кровью добывать, тогда ценность этих ништяков автоматически бы повысилась.
Что ты подразумеваешь под прокачкой?
Я планирую несколько аспектов для прогресса игрока:
1) Количество ХП и энергии увеличивается ТОЛЬКО если нашёл/купил спецайтем. Там максимум до 26 будет докачать, остальное можно будет забустить пассивками
2) Оружие(три слота в правом нижнем углу) можно будет находить или покупать. Примерно 10-20 разновидностей, но тут я хочу сделать упор не на урон, а на эффективность. Т.е. комбинации этих оружий не будут тебя прям усиливать, а скорее толкать применять новые стратегии. Можно вспомнить CRYPTARK как референс.
4) Чертежи (слот и лента сверху справа) - их будет довольно много, 50 и более. Это бафы. Очень похоже на импланты из SURGE, но только без пассивок. Их игрок будет находить или покупать.
5) Основы - это жизни игрока (те три штуки в левом нижнем углу, когда кончаются - gameover), но они не будут одинаковыми. Будут разные основы, которые как раз будут давать пассивный буст. Скорость побольше, урона побольше, двойная энергия, щит поверх ХП, выделение токсинов. В общем что-то типа амулетов из Пустого Рыцаря. Но т.к. Основу можно потерять в бою - будет выбор на какой гонять в какое время. Их будет 20-30 разновидностей.
Прокачки в привычном понимании не будет. Т.е. это не будет методичный дроч статов. Это будет подбор более удобного эквипа. При том что сложность противников будет увеличиваться. В основном урон и паттерны. И даже первый, слабый противник сможет доставить немало геморроя (как в Salt&Sanctuary или The Surge)
Будет ли игра лёгкой в начале я пока не решил. Хочется делать что-то более демократичное типа Hollow Knight, но усложнённые режимы игры я скорее всего введу, как раз для задротов =)
да не так выразился, хоть я люблю дроч статов, но и не обязательно чтобы это вообще было,
но главное чтобы был любой уровень прогресса своей силы, вполне норм метод метроидвании
Желательно чтобы усложнённые режимы были доступны сразу)
Я помню какой азарт был проходить Dynasty Warriors: Orochi 2
если плавно качаться и плавно сложность подымать, то нет такого чувства,
когда гордишься, что смог убить 2-5 солдат за бой. Хотя там обычно за сессию 400-700 нормальный показатель.
Или допустим, когда ставишь моды на Морровинд или Скайрим. Те вещи которые ты раньше выкидывал,
в модах с уложнённым режимом бережно собираешь и вообще их ценность становится заоблачной,
а в оиригнальном TES, обычно многие вещи берёшь просто потому-что влезает в сумку.
В сложном TES с модами Любое открытие сундука - похоже на открытие сокровища) В обычном TES, я обычно даже игнорировал сундуки, там весь лут кажется одинаковым и ненужным, когда игра не сложная.
ну конечно в идеале, для расширения аудитории уровень сложности пусть лучше будет лёгким по умолчанию,
с возможностью менять до супер сложного режима
Расскажешь, как ты это сделал?
Всегда было интересно, как в метроидваниях это делают. Мне в голову приходит только один способ, который не требует порталов и кучи кастомных скриптов на каждую комнату:
делаешь рельсы для камеры
размечаешь их индексами комнат
притягиваешь камеру к ближайшим рельсам
(заодно получаешь плавное движение камеры внутри длинных комнат)
получаешь номер комнаты
используешь ресурсы этой комнаты
профит
Скажем, простое разбиение на прямоугольные комнаты получится, если расставить рельсы, состоящие из одной точки, в центрах комнат. Но у тебя точно должно быть что-то другое, у тебя ведь камера к игроку привязана.
Нет, у меня всё не так. Если бы у меня весь уровень был на одной карте я бы не делал рельс, а использовал бы границы комнаты для ограничения камеры, и когда игрок переходит в другую комнату, камере назначаются новые границы.
Однако, я как раз раздробил большой уровень на множество маленьких. Во-первых, это снимает множество вопросов производительности. Во-вторых, есть в этом некий кайф - исследование по комнатам, карта из прямоугольничков на которой помечено где ты был, где чекпоинт, где секреты и т.д.
Но тогда и возникает одна большая проблема: "Как позиционировать игрока в новой комнате?
Как понять в какую дверь игрок вышел и в какую вошёл?"
Возможно, есть какой-то очень простой способ в иной архитектуре движка с собственным редактором уровней. Но я мыслю терминами того инструмента который у меня есть. И не нужно восклицать "ВОТ ОНО! ТО САМОЕ МЕСТО КОГДА ОГРАНИЧЕНИЕ ДВИЖКА НЕ ПОЗВОЛЯЮТ....", у вашего движка тоже довольно много ограничений, а жизнь моя коротка, чтобы писать каждый раз движок под свои нужды или делать полгода то что я сделал за месяц... мне проще придумать алгоритм, который работает с тем инструментом, который я хорошо знаю. В данном случае со статической структурой пререндерённых комнат.
Я, пожалуй, напишу про это отдельный пост в ближайшие дни, ибо не достойна такая тема покрыться пылью в комментариях. Но это всё если тема действительно интересна местной аудитории. Как проявить интерес к этой теме, надеюсь аудитория догадается =)
А, то есть тебе нужно, чтобы сам движок воспринимал комнаты как отдельные, поэтому в любом случае нужно описывать связки между ними. Понял. Но ты ведь это делаешь каким-то готовым хитрым методом, а не вручную для каждого перехода? Отдельный пост будет интересно почитать.
Ну и да, у тебя за счёт такой модели будет возможность делать всякие аномальные структуры комнат (например, для секретных мест, не отмеченных на карте).
Ну я вижу два подхода:
1) Движок имеет готовые пререндоённые комнаты как ассеты или сцены. В них уже всё расставлено и игра просто переключается между ними
2) Движок имеет комнаты в виде набора объектов/тайлов/итд, которые можно подгружать в одну сцену (а ненужные удалять) - но тогда нужно ловко менеджить контент, а это непростая задача даже на самопальных движках.
В GameMakerStudio2 можно делать и так и так. Но в первом варианте для редактора комнат можно использовать очень даже неплохой встроенный редактор (на написание подобного у меня бы ушла пара месяцев). А во втором придётся писать свой редактор, да ещё и менеджить ресурсы.
Я пошёл по первому пути. Есть набор комнат, есть двумерный массив, в котором проставлены ID этих комнат. Если комната занимает несколько клеток массива - то во всех этих клетках проставлен один и тот же ID.
Про переходы пока думаю. На данный момент переходы считаются по факту выхода игрока за пределы комнаты с последующим перерасчётом координат используя лишь положение игрока внутри текущей комнаты и информацию из массива. Но для отображения на миникарте придётся делать ещё какое-то место хранения, пока не придумал какое. В идеале бы иметь граф, и в каком-нибудь hollow knight-е скорее всего так и есть. У меня скорее всего будет массив рёбер просто, которые будут обозначать переходы между двумя клетками. А т.к. массив статический, то можно обойтись без координат, а просто пронумеровать все ячейки по какому-нибудь нехиторому правилу, например подряд.
А зачем защищаться от аргумента, который даже если кто и применит, то он абсолютно не имеет смысла? У тебя игра делается за месяц-два-три, а этот подход сразу подразумевает тратить порядка полугода на все эти упаковки битов в байты и наоборот. Нету у Гамака никаких препятствий реализовать всё что есть во всех Метроидах, от и до. Пост тоже жду, пиши.
Несколько раз читал тред - так и не понял в чем сущность описываемой проблемы с отдельными комнатами и "пересчётом переходов между ними". То есть суть задачи вообще.
Задача примерно такая: "как сделать хождение по комнатам как в метроиде/кастлвании с учётом что комнаты разного размера."
В моём случае есть гамак, у него есть комнаты с объектами. Хочу сделать комнаты и карту как в метроидвании, чтобы это было более менее гибко и малой кровью.
Хм. Видимо я совсем не улавливаю в чем тут может быть подвох. В ГМС же в редакторе комнат собраны эти самые комнаты? Совсем не понимаю в чем проблема загружать следующую комнату при выходе из текущей.
У комнаты несколько проходов. Вот ты загрузил следующую комнату. В каком проходе должен появиться игрок? Как ты это узнаешь? Нужно считать. А как считать? Сходу не очень понятно. Учитывая, что проход в теории может быть шириной/высотой во всю комнату.
Допустим у нас есть менеджер сцен, который отвечает за загрузку комнат. В нем есть переменная, которой можно назначить число при столкновении с объектом-триггером, который инициирует перемещение в другую комнату. Если значение равно 0, то перемещаем игрока к объекту waypoint0, если равно 1 - к объекту waypoint1. Вроде не очень сложно.
Это подразумевается в моём подходе, только там учитываются ещё и разные размеры переходов.
Это как и зачем? Что подразумевается под переходом? Я думал есть отдельные комнаты-сцены только
Они и есть, под переходами я понимаю объекты-порталы у граней комнаты, из которых выходит игрок, перейдя в комнату из предыдущей. Они разного размера в том смысле что некоторые входы в комнаты больше чем другие.
У тебя проход размер с полстены. Где ты будешь спавнить игрока? В центре waypoint?
Ты захотел поменять местами сцены. Что ты будешь делать? В каждой сцене переписать у триггеров это число?
А если ты накосячил в триггерах и они начинают вести не туда?
Видимо, ты из тех тру-хардкор-программистов, которые не ценят своё время и готов писать расстановку объектов на сцене прямо в коде инициализации сцены. Извини, но этот метод имеет очень много недостатков и мне не подходит.
Не понял проблемы.
Не понял проблемы. У тебя есть сцена. В ней есть триггер, переносящий игрока в другую сцену. Если ты хочешь поменять сцены местами, ты просто в триггерах меняешь загружаемую сцену. Где-то же надо показывать игре какую сцену загружать следующий? Допустим, был переход в сцену A со значением 0 (а это - левый срединный вейпоинт, например), а захотел сделать переход там в другую сцену, пишешь что переходим в сцену B со значением 1 (а это, например, верхний срединный вейпоинт)
Ну, как бы, как ты без триггеров планируешь игре говорить, какую сцену загрузить? Придется явно указывать, что загружать, и там тоже можно накосячить.
Я расставляю все нужные объекты в редакторе и мне не нужно ничего писать.
Надо, но делать это внутри самих комнат = bad smell
Почему? Комната разве не одна из основных верхних нод в игре? Удобно когда комнаты в отдельных файлах, и ты можешь легко загрузить новую комнату, редактировать ее, расставлять объекты и т.п.
Я и так могу всё это делать. Только зачем мне решая задачу перестановки комнат лезть в более нзкоуровневый конеткст - контент комнаты? Если я работаю с комнатами как с более высокоуровневыми сущностями?
Это всё равно что прописывать дамаг получаемый врагами от пуль внутри каждого врага индивидуально, а не задавать у пули общий урон.
Я за то, чтобы как можно больше параметров выносить в конфиги.
Справедливости ради, это могла бы быть такая специфическая игровая механика. Но в данном контексте речи о таком не идёт, да.
Хейз, ты серьёзно? Каждый проход надо обозначать инстансом объекта-маркера портала, растягиваемым в рум эдиторе. Может это только мне сходу понятно, но почему тебе это не пришло в голову, удивляюсь.
Блядь на словах это всё просто звучит. А ты вот попытайся реализацию продумать и ответь на такие вопросы:
1) Тебе нужно считать оффсеты при переходах, ведь если твой перс перешёл в комнату через верх, то в следующей комнате он должен появиться сверху
2) Тебе нужно внутри комнат прописывать для каждого инстанса В какую комнату он ведёт. Иначе ведь никак.
А разве нельзя запоминать координату гг в момент выхода, чтобы потом в момент входа в новую комнату разместить его на соответствующем уровне?
Это само собой, но координаты нужно пересчитать. Если игрок выходит через центр старой комнаты, а заходит сверху новой - то ведь координаты уже не будут совпадать - нужно считать сдвиги.
У меня прям слов нет. Ты решил эту задачу ещё 9 лет назад, на Гамаке версии 8.0, в своей игре.
Ты скажешь - так комнаты же разной формы. Да, но четыре стены комнаты везде являются такими же самыми стенами. Надо взять базовый размер 1x1 комнаты и от него построить суб-координаты переходов автоматически. Ну, конечно придётся писать инстансам индексы комнат и индексы входов в них. Хотя я не знаю зачем ты решил распиливать игру на комнаты; в комментах уже упоминали что можно просто поставить камеру на рельсы и сменять эти рельсы в зависимости от комнаты, т. е. попадаешь ли в такой-то прямоугольник.
Пришла в голову идея - можно задавать переход в следующую комнату как пару значений - индекс (название) комнаты и УГОЛ входа в комнату. Потому что очевидно что координаты входа будут находиться на одном из 4 отрезков границ комнаты. И если тебе нужно зайти слева, то можно просто задать угол 180 и вот оно твоё лево. При этом ты можешь масштабировать целевую комнату по обоим осям как угодно, это всегда будет слева посередине. А если угол 135, то всегда слева наверху. И так далее. Но это так, побочные мысли, задачу можно решить и без этого.
Я так понял, ты имел в виду появиться снизу новой комнаты, если перешёл через верх старой. Либо сверху новой, если перешёл через низ старой.
Всё верно, но и триггеры тогда никакие нахер не нужны. Нужно правильно рассчитать координаты. Но не так просто на практике как звучит в теории.
Карта может быть большая, а это - проблемы производительности уже.
У тебя в послужном списке куча игр с большими картами. Деактивация, деактивация, и ещё раз деактивация. Но если твой подход с отдельными комнатами будет эффективней, то конечно ты прав.
А. В этом смысле. Ну, я не знаю как там что у тебя делается, так что с предложениями не лезу)
В WBNR я писал глобальные координаты комнат в самом их названии, но комнаты были одного размера, здесь такой способ не подойдет. Можно создать простенький глабалмап эдитор, который бы пробегался по размерам всех комнат и выдавал соразмерные прямоугольники. Далее ты компонуешь эти прямоугольники в глобальную карту и на выходе получаешь файл с расположением комнат.
Редактор я ещё буду делать для сбора цельных локаций, да. В идеале бы автоматом считать наличие переходов в комнате для полного автоматизма, но боюсь, что в рантайме я такую инфу собрать не смогу о комнатах, только размеры.
Могу дать на тест фреймворк интерфейса (кнопочки, ползунки, окна). Он пока сырой и не заточен под юзерфрендли, но базовые вещи на нем сделать можно.
Не, я буду своё говнокодить под свои форматы данных =)
Светило Гамака боится перед игрой пройтись по всем комнатам персистентным контроллером который делает with o_exit { global.exit[other.i]=id; other.i++; } ?! Что стало с миром?! :yak:
Сложно это всё, но где наша не пропадала?
Наша нигде не пропадала!
Гамак - лучший гамак в мире!
Слава гамаку!
Пффффф, вот жеж говно
https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/rooms/general/index.html
То есть функции взятия камеры и виды у них видите ли есть, а получить ширину и высоту комнаты - хуй. Ширину и высоту слоя тоже не получиться...
Притом что есть функция которая берёт слой из любой комнаты:
https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/rooms/layers/layer_get_target_room.html
А толку то?
https://docs2.yoyogames.com/source/_build/3_scripting/4_gml_reference/rooms/layers/index.html
Была бы хоть одна функция чтоб прочекать объект в позиции, но нет же.
Видимо, реально придётся обход всех комнат делать. Это, конечно лёгкий пиздец, ну да ладно, придумаю чё-нить.
А кстати в ГМ8.1 это всё было (ну, кроме чека объекта в позиции без перехода в комнату). Проклятая Студия мне никогда не нравилась. Йойо будет как всегда отмазываться кросс-платформенностью, и что поделать, они правы. Прогиб под требования индустрии.
Вроде и в первой студии подобные функции были.
Судя по мануалу, уже и там не было.
Храни список переходов. В каждом переходе храни 2 комнаты, к-е он соединяет в координаты любой точки перехода в обоих комнатах.
И как предполагается задавать переход при проектировании уровня? Писать цифрами в коде? Хейз уже отвечал что это костыли, и он прав.
Объектами. Или чем-то вроде глобальных переменных. Или какими-нибудь кастомыми свойствами комнаты. Вы сами делаете на Гамакере, вам лучше знать.
Но блин, кто в разработке игры главный - движок или разраб?
Писать цифрами в коде - единственный вариант решить любую проблему, если ваш движок сам этого не умеет.
В движке есть редактор уровней, в котором можно расставлять экземпляры (или по-буржуйски инстансы) объектов, это и будет установкой их координат, а также размера. Хранение списка переходов, которое ты предлагаешь, отнимает управление переходами из конкретных координат редактора уровня, перенося его в некий глобальный список, в котором левел-дизайнеру потребуется осуществлять навигацию, или, проще говоря, каким-то образом понимать в какой строчке вообще какой переход находится.
Это чревато заведением названий для каждого перехода, хотя в подходе на который нацеливается Хейзер, и я, и сам Гамак с этой целью продуман, названия назначать каждому переходу не нужно. Это всё симптомы старого программирования методом перфокарт и такой-то матери, когда всё надо подписывать, везде ещё 10-этажные комментарии писать, и работа таким способом затягивается на тысячи лет, эффективно распиливая гос-и-не-только-бюджеты на...
В общем, у нас задача стоит не так. Задача стоит - сделать игру.
Пусть тогда делает удобный редактор, если не хочет прописывать что-то вручную, а движок по дефолту этого не умеет. Вы опять упираетесь в ограничения своего движка.
Либо делаешь удобный инструмент, которым ты можешь быстро выточить себе 50 дверных ручек, либо не делаешь, но зато каждый раз в ручную вытачиваешь эту дверную ручку.
Еще раз - в вашем случае самый простой вариант - создать в комнате триггер перехода, и уже в свойствах этого триггера хранить название/номер комнаты, в которую он ведет и координаты, куда телепортирует. Все!
Зачем вам еще какие-то глобальные списки переходов, уникальные имена - мне не понятно. Если вам надо отредактировать какой-то переход - открываете комнату, где он хранится и редактируете.
Я, видимо, из-за того, что не пользуюсь ГеймМекером, не понимаю возникающей перед вами проблемы.
Но редактор уже есть. Я вообще не знаю в чём у Хейзера проблема. Как он выше отписал, а ни в чём, только в том что надо внимательно всё сделать. Так что не надо ничего нового писать, и граф переходов по твоему предложению тоже организовывать не требуется.
Поясню повторно - глобальный список переходов предложил ты, во всяком случае так я тебя понял. Если ты предложил список на каждую комнату отдельно, то это тогда совпадает с тем что Хейзер и так сделал, под что Гамак прекрасно приспособлен безо всяких допиливаний.
А уникальные имена были бы нужны в глобальном списке для того чтобы по ним быстро находить какие координаты требуется отредактировать в конкретный момент. Ну представь себе таблицу чисел, где например 100 переходов. Неудобно же. Для того и названия бы каждому надо было присвоить. По типу комната12_переход_влево_наверх.
Мне не понятно в чем сложность. Как-то же разработчики других игр делают переходы между уровнями? Почитай как и сделай так же.
В конце-концов всегда можно построить граф.
Вершины - это комнаты. Ребра - это переходы между комнатами.
В комнатах хранишь триггеры-переходы. В каждом триггере - номер/название другой комнаты, куда телепортируется персонаж и координаты исх. точки, где он в ней окажется. Подсчитав смещение персонажа в триггере относительно левого верхнего угла - прибавляешь его к координатам этой исх. точки и телепортируешь туда персонажа игрока.
Переходы между комнатами всегда должны быть однонаправленными, потому что:
1) Так легче гарантировать что персонаж при входе в комнату не попадет в ее переход и не вернется обратно. Просто переносишь персонажа чуть-чуть вперед перед переходом, который ведет обратно. Я так в Tri0 делал.
2) Можно сделать односторонние переходы когда из 1 в 2 попасть можно, а обратно - нет.
3) Можно сделать несколько переходов из 1 в 2 и один переход из 2 в 1.
4) Можно сделать так что из 1 ты попадешь в 1, но в другое место.
5) Закрывать проходы, создавать новые, менять их прямо во время игры.
... и вообще кучу других интересных штук типа комнаты-лабиринты-головоломки, которые вообще игроку не будет понятно как соединены.
В любом случае чем универсальнее вещь, которую ты делаешь - тем больше с ней будет возни и тем дольше ты ее будешь добавлять на уровень. Хочешь сделать быстро - делай, но эта твоя вещь будет уметь только что-то одно.
Как-то же разработчики других игр делают переходы между уровнями? Почитай как и сделай так же.
"best guide ever 2k19"
Я всегда так делаю когда сталкиваюсь для себя с чем-то новым и непонятным в геймдеве.
В конце концов всегда можно вписать правильные нолики и единички. Не так ли?
Чем этот способ проще чем просто взять и отключить переход до тех пор пока не выйдешь из его координат? Как это и делается по-нормальному.
Это можно сделать отдельным запирающим флагом, не обязательно для этого делать переходы однонаправленными. Что ты пытаешься сэкономить? Если память, то исходить нужно из того, каких переходов в игре больше - двунаправленных или однонаправленных. В метроидваниях, жанре в котором Хейзер делает игру, всегда больше двунаправленных переходов, а это значит что предложенных тобой однонаправленных переходов потребуется создать в два раза больше, так как 1->2, а потом 2->1. И в чём преимущество?
Это свойство не уникальное для однонаправленных переходов, его прекрасно можно сделать и с двунаправленными. Ты перепутал с правилом, что нельзя назначать конечные точки одинаковые разным переходам.
Тем что если игрок захочет вернуться обратно, то он не сможет этого сделать пока полностью не выйдет из триггера (потому что он отключен). А потом будет удивляться "почему я уперся в невидимую стену, а меня не переносит в другую комнату?".
Во всех играх так делают и пока еще никто не жаловался.
Можно хоть все сделать по-разному. Перед тем как что-то сделать - нужно подумать как оно будет работать, и представить как ты им будешь пользоваться.
В случае с переходами - гораздо лучше и надежнее запрограммировать один универсальный переход, который можно использовать разными способами и имеющим множество назначений. Чем придумывать кучу оригинальных решений для всех возможных случаев.
А однонаправленный переходам - это универсальный портал. Это может быть и телепорт внутри одной локации, и переход в другую локацию. Который можно отключить, оставив включенным переход в обратную сторону.
Кто тебе сказал что в графах ребро из вершины не может вести в себя?
Ну так триггер надо делать очень маленьким, чтоб с него сразу сойти. Либо располагать его вообще за экраном, и это снова никак не соотносится с тем что переходы по твоему мнению должны быть односторонними. Или как?
Сразу видно, диванный аналитик. В Метроидах (а это с десяток игр), о которых идёт речь, все переходы двусторонние, а не односторонние, как ты предлагаешь. Как тебе такой аргумент?
Так чем же подход с двусторонними переходами менее универсальный чем с односторонними? Это вопрос точки зрения, а не единственной непреложной истины. Это ведь очевидно, что ты выходишь в дверь, и пространство двери работает в обе стороны одинаково? Хочешь односторонний переход? Делаешь дверь.Закрыть() до поры до времени, и всё прекрасно работает.
Эти вещи Хейзер программировал тоже 10 лет назад, и с ними у него никаких проблем не было. Рассматривается совсем другая задача, конкретно соединение малых комнат разного размера в общем, что называется, лэйауте (layout). То, что ты хочешь предложить универсальный инструмент, заканчивается тем, что ты подстраиваешь задачи под инструмент, вместо чтобы отдельно выточить вилку и отдельно выточить ложку.
Как-то так.
Повторю главное - в Метроидваниях ВСЕГДА двусторонних переходов больше, чем односторонних. Это канон жанра, если хочешь. Если его нарушать, нарушается сам дух эксплорейшона, и уменьшается собственно подобие Метроиду и Кастлвании, давших начало жанру.
Я понимаю почему математически односторонний переход более универсален, это действительно так. В рамках того что Хейзер решает вот здесь и сейчас, того что надо решить, а не размышлять туда и сюда, односторонние переходы это исключение из общего правила, что все они изначально двусторонние.
Пример из головы. Для хранения данных используются величины электрического напряжения внутри ячеек памяти. Нули записываются как высокий вольтаж, а единицы как низкий. Почему? Потому что единицы это значимая информация, которой должно быть много, а чем больше единиц - тем больше требуется вольт, а значит больше изнашивается ячейка памяти, пропуская через себя больший поток электронов. По этой же причине устройства хранения данных инициализируются единицами, а не нулями. На электроэнергии это тоже экономит где-то там, но основной смысл в том чтобы лишний раз не напрягать. Так вот у тебя это получается не особо. Вопрос был - как сделать игру, а ты отвечаешь как сделать часть движка. Благородно, но мимо кассы.
Кто тебе сказал что я такое говорил? Перечитай внимательно то что я написал. Писал я не о том что граф слишком ограниченный (ибо это не так), а о том что для ведения в одну и ту же комнату не обязательно делать переходы односторонними, как это ты попытался представить в том не очень логичном списке из трёх пунктов.
Мне тоже было непонятно в чём сложность. Пока я не взялся за задачу всерьёз. И там проблемы начали сыпаться одна за другой. Довольно много проблем я уже решил и продолжаю решать, оптимизируя свой метод.
Впрочем, рассуждать о сферических конях снисходительно поплёвывая со своих колоколен всегда проще =)
Словестно алгоритм выглядит правильно и круто, но технически его реализация может сильно спотыкаться о подводные камни. И не надо думать, что это только с гамаком такие проблемы. С другими языками таких проблем скорее всего ещё больше.
Помнится я что-то писал на яве и хотел упростить себе жизнь, перегрузив обычный итератор. Как же я плевался когда узнал что у настолько разрекламированного языка нет вещей, которые давно есть во всех уважающих себя ООП-языках. Эхххх.
Расскажи в чем именно сложности, в чем подводные камни, может я тоже с таким сталкивался. Я ведь тоже пытался делать метроидванию.
Пока расскажешь в чём все сложности, можно их уже одолеть. Особенно на Гамаке, в такой частной задаче, под ряд которых он затачивался годами.
Я уже описал в своём посте - это и были сложности. Сперва такой думаешь что вот ты будешь делать карту как в метроидвании и вот у тебя будут разные комнаты и ты такой будешь делать двери чтобы объект переходил из комнаты в комнату и всё будет заебок. Чего сложного то?
Допустим я это сделаю, а как я буду карту открывать по клеточкам? Значит нужно вводить какую-то сеточную структуру - матрицу. Значит нужно уметь транслировать комнаты в эти матрицы. И переходы тогда лучше так же считать по матрице без триггеров. А значит, нужно будет вычислять координаты игрока при переходах - это разработка алгоритма трансляции координат между глобальными и локальными и отладка этого алгоритма. Ещё есть туман войны, есть положение игрока на карте, есть положение на карте других объектов. Хранить их внутри отдельных ячеек или в виде списков? И всё это требует постоянного осмысления - понимания что можно решать как отдельные задачи, а что решается в комплексе. А значит пытаться спроектировать заранее наиболее оптимальную структуру для моей задачи. Отрисовка миникарты - как её отрисовать? Делать полный обход матрицы каждый кадр? Или отренедрить всю миникарту в текстуру и выводить по частям? Но ведь это равносильно обходу матрицы! Тогда ренедерить карту в текстуру целиком но только при изменении состояния карты?
Вот я сижу и каждый день отвечаю на эти вопросы, нахожу методы решения тех или иных проблем, анализирую их сильные и слабые стороны.
А потом ты идёшь всё на практике делать, и оказывается что при пересчёте координат игрока в координаты экрана ты не учёл что координаты игрока могут быть за переделами комнаты и нужны коррективы, или что у тебя формула работает не так как ты задумывал или ещё чего обнаруживаешь что идёт вразрез с твоими планами.
У тебя рандомногенерируемый мир? Если нет, то почему нельзя жестко все прописать?
При первом попадании в комнату считать ее открытой и рисовать на миникарте как открытую.
Все объекты, находящиеся в одной локации - хранить в этой локации. При переходе объекта в другую локацию - переносить объект из списка одной локации в список другой.
Если переносится персонаж, то все его дочерние объекты переносить вместе с ним (надеюсь Гейммекер так умеет).
Отрисовывать только те клетки, которые попадают в кадр (в область где рисуется миникарта).
Отрендерить в текстуру (или если у тебя связи между комнатами не генерируются случайно - нарисовать картинку самому) и рисовать только ту часть текстуры, которая соответствует области вокруг персонажа.
При изменении состояния комнаты - перерисываешь эту комнату в этой текстуре.
Для рисования все карты где-нибудь в меню или в паузе - просто рисуешь всю эту текстуру целиком.
Делай глобальную систему координат, для каждой комнаты записывай координаты ее левого верхнего угла в этой системе. А внутри комнаты для всех объектов используй локальную систему координат этой комнаты.
Будет и так и так. Не понимаю что значит жёстко. Я уже не одну игру сделал "жёстко" - с большим миром в единой сцене. Стоит ли рассказывать насколько сложно вносить в такой мир изменния? Это сложно как с точки зрения встраивания нового контента, так и технически(подтормаживание редактора на больших картах).
Если комната большая, та так не пойдёт. По классике большие комнаты открываются по частям.
Это вопрос реализации. Можно все таскаемые айтемы создавть динамически. В Гамаке можно так седелать. Но я буду создавать айтемы прямо в комнатах. Сделаю список этих айтемов с уникальным ID - комната и координаты и параметрами в какой комнате и координате он находится в данный момент. При старте комнаты я буду проверять этот список и создавть нужные объекты в нужных местах. А для тех объектов что изначально присутствуют в списках на старте комнаты буду проверять есть ли они в этом списке, и удалять их если есть.
Но это в теории. Практика выявит подводные камни и здесь.
Руками умеет. Но это и не нужно. Мне нужно переносить только то что у игрока в руках. А это вопрос одной переменной.
Этого я не понял. Разумеется у буду кадрировать. Но миникарту я харню текстурой, так что я буду просто рисовать часть текстуры.
Это не то. Мне нужно рисовать все разведанные части. Я уже сказал что рендерю карту в текстуру при каждом изменнии состояния карты.
Что в этом плохого? Сделать вещь, которая может делать то что мне нужно прямо сейчас а не то что мне может не понадобиться никогда в жизни?
Ну и сложности как оказалось особой нет, толко внимательность нужна. Вообще я просто поделился что сделал карту как в метроиде, чего я до сих пор никогда в своей практике не делал =)