>>798375
Для чего-то сложнее нужно разделять всё на разные системы, слои. Тайлы - это статичные элементы карты, даже если они когда-либо меняются (как в Террарии), то делают это редко. Предметы, лут - это отдельные простые сущности, которые лежат поверх сетки тайлов. Какие-нибудь деревья, кусты, которые колышутся на ветру, растут, цветут и могут быть срублены, могут быть особенными сущностями типа мобов, со своей логикой и состояниями. Вряд ли в какой-то игре будут тысячи лутабельных деревьев на одном экране одновременно или тысячи отдельных единиц лута, а вот тысячи тайлов на одном экране при сегодняшних разрешениях экранов - это запросто. Следовательно, тайловую систему нужно оптимизировать отдельно от тех немногочисленных сущностей, которые лежат или живут поверх неё.

Алсо, если необходимо хранить много настроек в каждом тайле, может иметь смысл создать отдельную "палитру тайлов" и хранить в двумерном массиве тайлов только индексы этой палитры. При этом наполнять палитру (определять индексы) можно динамически по мере создания новых комбинаций настроек. Это избавляет от необходимости хранить кучу лишних данных для повторяющихся тайлов, но при этом позволяет иметь удобный доступ к индивидуальным свойствам каждого тайла. Снова имеем двумерный массив байтов/слов, только каждое число - индекс в палитре (одномерном массиве или списке), хранящей сложные структуры (записи/словари) с разными свойствами.

Пример кодом. Вместо этого:

>if tile[x][y].type == GRASS and tile[x][y].walkable and tile[x][y].wetness > 0: ...

Будет примерно такой код:

>if palette[tile[x][y]].type == GRASS and palette[tile[x][y]].walkable and palette[tile[x][y]].wetness > 0: ...

С одной стороны, почти ничего не изменилось в плане читабельности (если обернуть сеттерами и геттерами - внешне код будет совсем одинаковым), а с другой - мы можем иметь тысячи одинаковых тайлов травы с одинаковой влажностью и это будет просто тысяча индексов, указывающих на одну тяжёлую структуру с параметрами. Да, для изменения одного тайла понадобится новая структура (или найти подходящую в палитре), но мы же говорим о тайлах, которые по определению редко меняют своё состояние (в отличие от мобов, лута, снарядов и т.д., которые обрабатываются отдельно).

>мне просто столько фпс не нужно

Фпс лишними не бывают. Особенно если захочешь портировать игру на смартфоны, там неоптимальная архитектура игры в буквальном смысле чувствуется руками, ЕВПОЧЯ.

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

>>796015 (OP)

>Возможность сломать любой предмет, например, прокопать стену киркой.

Стена - не предмет, а часть ландшафта... А ты планируешь делать какие-нибудь головоломки, лабиринты? Если любую стену можно прокопать, смысл головоломок теряется. Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)

>Зелья. Их пока всего два – реген и инвиз. В моем рогалике принято не принимать зелья внутрь, а обливаться ими.

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

>>796120

>многие действия мобов, такие как поиск и подбор предметов с земли оказались довольно требовательными к производительности

В пошаговой-то игре? Странно.

>>796248

>эксель таблица

А как ты экспортируешь из редактора и импортируешь в игру? Сам парсер писал или нашёл готовое решение?

>>796250

>Для того чтобы проектировать комнаты я не придумал ничего лучше чем рисовать их в виде png

Сначала хотел посоветовать сделать внутриигровой редактор, но есть решение намного проще - универсальный бесплатный редактор тайловых карт Tiled, в формате легко разберёшься:
https://github.com/mapeditor/tiled
Вроде бы есть готовые плагины для импорта в Unity.
С другой стороны, внутриигровой редактор был бы удобнее для игроков, желающих разнообразить себе игру самодельными модами. Как в старых стратегиях (Age of Empires), когда можно было сделать собственную карту прямо в игре. Понятия не имею, как такая фича отразится на сути рогалика, но по-моему это круто.

>>796896

>Доделал скрипт который позволяет отцентровывать предмет в руке так чтобы ты брал его не за центр, который может оказаться пустым, а за ближайший к центру непрозрачный пиксель.

Я надеюсь, этот скрипт не для рантайма? В смысле, звучит довольно глупо попиксельно центровать каждый спрайт в рантайме, когда это нужно делать всего один раз на этапе дизайна предметов в игре. Или у тебя можно будет рисовать новые предметы прямо в игре?

>>796905

>добавляй чит, чтобы вызывать его в рантайме

Интересная мысль, тоже думаю сделать консоль.

>>797463

>делать нормали вручную я не буду, это полнейшее безумие

Почему безумие? Если текстуры ты сам вручную рисовал, то и карты нормалей к ним очень легко нарисуешь. На самом деле для вручную нарисованных карт нормалей достаточно всего 9 цветов. Есть специальные картинки-подсказки как с градиентами, так и с резкими границами цвета. Есть туториалы, как их рисовать... Также есть бесплатные утилиты, даже прямо в браузере, позволяющие интерактивно сгенерировать карту нормалей из любой картинки, настроив различные параметры перед экспортом. Попробуй это, я пробовал, вроде неплохо генерирует по пиксель-арт рисункам, правда, я так и не понял, как проверить корректность:
https://cpetry.github.io/NormalMap-Online/

А для совмещения карт нормалей с текстурным атласом, скорее всего, нужно писать свой собственный шейдер. Но лучше, имхо, отказаться от карт нормалей в 2D игре. Выглядят максимально тупо, создавая неестественный объём, да ещё поди и видеокарту грузят как какая-нибудь 3D графика.

>>798047

>Каким образом игрок этих спутников будет встречать я пока не придумал(

Мне больше всего нравится в играх, когда можно любого врага "приручить", "очаровать" или иным образом обратить в союзники, конечно, затратив какие-то ресурсы. Во всяком случае обычного врага, а не босса, хотя вроде бы есть игры, где можно даже боссов обращать в союзники. Но раз ты планируешь города и торговлю, логично было бы нанимать наёмников в этих городах (или покупать рабов у бродячих работорговцев, почему бы и нет).

>>798414
Ух, как много всего)

>Если стены головоломок нельзя разрушить, то изначальное утверждение ложно)

Окей, может быть, я соврал. Если будут головоломки, придется добавлять неразрушаемые стены, это правда.

>Зелья

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

>Тяжелые действия мобов

На самом деле, в той версии почти все было "довольно тебовательно к производительности" .
каждый тик моб обыскивал пол в некотором радиусе вокруг себя и напряженно думал, что бы ему поднять.
Я временно отключил эти функции и сейчас возвращаю их в более оптимизированном виде. В следующем билде будут.

>Эксель

Я использую вот эту штуку: https://github.com/tsubaki/Unity-Excel-Importer-Maker

>Редактор карт

О, спасибо, пойду заценю.
Я думаю, что во внутриигровом редакторе нет особой необходимости. Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты. Хотя, чем черт не шутит.

>Центровка предметов

Нет) Это делается один раз в начале.

>Консоль

Да, это очень удобно.

>Нормали

Ну может и не безумие.. Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.
Видеокарту они грузят несравнимо меньше чем 3д, на то они и нормали, чтобы использовать их там где 3д слишком дорого обходится. А по поводу эстетической составляющей мне пока они тоже не на 100% нравятся.

>Спутники

Мыслительный процесс идет. Мб можно будет и приручать кого-то, но это довольно тяжело забалансить. Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий". С рабами норм тема.

>>798423

>>Редактор карт

>О, спасибо, пойду заценю.

Есть ещё такой: https://github.com/deepnight/ldtk
Но я о нём буквально этой ночью узнал, пока искал ссылки на Tiled, о котором давно знаю и даже немного щупал.

>Если будут головоломки, придется добавлять неразрушаемые стены

В зависимости от типа головоломки, стены можно переключить в разрушаемые после решения головоломки игроком. Либо сделать их очень прочными, чтобы игроку было лень долбить их, но всё-таки оставалась возможность пробиться грубой силой, если мозгов не хватает решить головоломку умом. Либо эти супер прочные стены может пробить только супер оружие с ограниченным боезапасом, и игроку нужно думать, стоит ли тратить заряды. А самое весёлое, если сокровище за стеной хрупкое и испортится, если пробить стену силой или попасться в скрытую за стеной ловушку...

>Это делается один раз в начале.

При запуске игры? Или у разработчика игры? Я просто не понимаю, зачем делать на компе пользователя то, что можно легко рассчитать заранее и хранить только пару чисел, как с хот-спотом курсора:
https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.cursor.hotspot

>Но если я этим и буду заниматься то когда-то потом, когда, общий объем работ будет более определен.

Правильно, геймплей важнее, особенно для рогалика.

>Вообще, я стараюсь отдалиться от концепции "что угодно можно сделать с кем\чем-угодно, какая удивительная свобода действий".

Почему? По-моему, свобода интереснее.

>Так как все и так каждый раз разное, у игрока не будет особой мотивации придумывать кастомные карты.

Я правильно понимаю, что подземелья генерируются рандомно, а редактор карт тебе нужен для дизайна комнат, которые будут примерно одинаковыми, только в разных местах и в разном количестве? Тогда будет в тему одна моя идея, которую я уже несколько лет обдумываю. Идея в том, чтобы игрок имел возможность повлиять на результат генерации игрового мира какими-либо внутриигровыми средствами, т.е. как минимум без модификации игровых файлов сторонними инструментами.

Проще всего объяснить на примере. Вот в Minecraft есть деревни - это случайно генерируемые структуры, в которых форма улиц и число домов полностью случайно, а дома захардкожены разработчиками и имеют всего несколько форм, которые легко запомнить и узнать. То есть даже в одной деревне может быть два совершенно одинаковых дома, но сложно найти две полностью одинаковых деревни. Игрок, при желании, может создать модификацию для игры, которая добавит какие-то новые виды домов или структур в генерацию деревень, и игра будет строить эти новые дома в новых деревнях по мере путешествия игрока по миру. Но делать модификации - сложно, это отдельный от игры набор инструментов, которые нужно где-то достать и потом обучаться им. Что, если бы игрок мог прямо в игре построить домик и каким-то образом зарегистрировать его для генерации в новых деревнях того же мира? С какими-нибудь реками и горами такой трюк не пройдёт, потому что они описываются математически, а вот деревни составляются из готовых кусочков, и на их генерацию было бы легко повлиять игровыми же средствами.

Ну да, согласен, это создаёт проблемы баланса для игры, нацеленной на сложное прохождение, но во многих играх есть упрощённый режим "песочницы", где игрок может творить всё что захочет, и иметь такую фичу в песочнице было бы очень интересно.

Что касается кастомных карт - в таких играх, как Minecraft и Terraria, игроки любят создавать свои собственные карты, нацеленные на решение головоломок, повествование или что-то другое, и делиться этими картами с другими пользователями. И это несмотря на то, что миры в этих играх генерируются рандомно. В тот же Minecraft добавили режим Adventure специально для пользовательских карт, который ограничивает использование инструментов, чтобы игрок не мог случайно сломать карту-головоломку раньше времени. Думаю, в кастомные карты играют в том числе потому, что генератор карт ограничен шаблонами/правилами и не может сгенерировать абсолютно любую карту, т.е. ты не можешь встретить на стандартной карте то, что может сделать на кастомной карте другой игрок. И чем проще и доступнее инструменты редактирования карт, тем больше мотивации у игроков создавать что-то своё и делиться этим с другими игроками, а это расширяет и поддерживает коммьюнити игры даже если разработчик прекратил поддержку игры.

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

>>798424

>А ты тоже что-то пилишь? Есть тред тут?

Треда пока нет. У меня много абстрактных идей (как пример выше) и мало конкретных деталей, чтобы сделать конкретную игру, да и идеи зачастую слишком сложны для меня, чтобы сесть и реализовать за пару дней, а долго работать я не умею - отсутствие результатов вгоняет в депрессию. Были попытки, есть какие-то наброски, но, например, последний месяц я всё забросил и почти ничего не сделал, только играю и сижу в интернете, каждый день думая "завтра точно что-нибудь сделаю". Завидую людям, которые месяцами каждый день работают над своим проектом и получают существенный результат...

>>827917

>Хеш сумма

Почитал про разные хеши, прикольная штука. Но там же все равно на выходе получается что-то вида 2d6e582c3fcfb4b8f3c16650a75dc37b
А как из этого инт извлечь?
Видимо я чего-то недопонял...

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

Сейчас все в принципе и так сделано по второму твоему варианту. Только там ID и название в соседних столбцах таблицы.
Например
Stone Wall | STWL

>Как планируешь квесты делать?

По большому счету, я пока вообще не думал как их технически реализовать.

Представим как может выглядеть средний квест.

Есть НПС.
Он в такой-то локе.
Он хочет предмет.
Предмет в другой локе. Ну, и скажем, не просто на полу, а в брюхе у Владыки Глубин.
НПС получает предмет, отдает награду.

Да, такое вполне можно сделать. Через джсон, да много как... Но будет ли кому-то интересно вручную добавлять такие квесты, располагая таким набором параметров?
Да такие квесты можно генерировать процедурно тысячами. Что, конечно же будет сделано сразу как только я создам класс quest и впишу в него параметры.

А вот представим другой квест.

Есть культ подземных гностиков грибопоклонников.
Они готовы отдать тебе легендарный предмет, Древний Грибной Нож, но если ты выполнить все их испытания.

Далее три испытания
-убить пещерного быка живущего в башне
-собрать 10 жёлтых грибов сгенеренных в рандомных локах
- победить Грибного Патриарха в состязании кто выпьет больше грибного кваса.

И потом ещё оказывается что все это был сон.


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

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

А откуда вообще пошла идея с этими квестами?
В каких-то ещё играх игроки могут добавлять свои квесты?
Я такого вроде нигде не видел.

>>828054

>2d6e582c3fcfb4b8f3c16650a75dc37b

>А как из этого инт извлечь?

Это и есть целое число в шестнадцатеричной системе счисления, в десятичной оно будет выглядеть так:

>60388200822592973995575059968711050107

Это у тебя 128-битный хеш, т.е. 16 байт (максимум 32 цифры в 16-ричной системе счисления). Тип int в языках программирования обычно означает 32- или 64-битное число, следовательно, тебе нужно искать соответствующую хеш-функцию (чтобы давала маленькие числа) или брать только 1/4 или 1/2 от 128-битной хеш-суммы. В любом случае число коллизий увеличится, но насколько это будет критично в конкретном случае можно узнать только на практике.

>Да такие квесты можно генерировать процедурно тысячами.

Процедурно ты скорее всего будешь подставлять случайные предметы случайным НПЦ под шаблонный текст "мне нужен %предмет%", а вручную можно запилить какую-нибудь осмысленную историю, вроде Красной Шапочки, потерявшей свою шапочку, которую игрок найдёт в брюхе минибосса Волк. Здесь от процедурного генератора требуется только разместить НПЦ (Красную Шапочку) и соответствующую цель (Волка с шапочкой) в сгенерированных комнатах подземелья.

>А представь теперь апи который все это будет обеспечивать?

>Чтобы все изложенные выше вещи были формализованы и ничего не надо было кодить.

>Вот я лично не представляю.

https://ru.wikipedia.org/wiki/Декомпозиция
Вкратце, раздели задачу на минимальные части и реализуй эти части по отдельности. Сначала будут простые квесты типа "поиск предмета", потом всё сложнее и сложнее. Если тебя это вообще интересует, конечно.

А вот в Godot не пришлось бы API делать, там можно загружать моды, сделанные на самом Godot.

>В каких-то ещё играх игроки могут добавлять свои квесты?

Да в любой РПГ/рогалике с модами игроки могут создавать свои квесты, обычно в том же формате, в котором их делали разработчики игры. Но не я предложил эту идею, так что не знаю, чем мотивирован тот, кто предложил.

>>827936

>ECS

>Годот никогда такой скорости не получит

Зато на Godot ты можешь быстро разрабатывать игру, а не ковыряться в каком-то ECS, создавая 100500 "систем" только для одного игрового персонажа, состоящего из 100500 независимых "компонентов". ECS нинужна для большинства игр, потому что ускоряет работу только на огромных массивах (сотни тысяч независимых юнитов в какой-нибудь стратегии), которые выгодно хранить в кэше процессора, чтобы он не ждал ответ от RAM. Алсо реализация ECS для Godot есть, но никто в ней разбираться не будет, потому что она нинужна.

>>829158
Про архитектуры я вообще ничего не знаю. Может там и правда все сильно по-другому. Но практика показывает что ецс и на андроиде хорошо заходит, если в игре какое-то серьезное количество сущностей.
Если у нас реально стратегия типо Songs Of Syx, великолепная игра кстати, то там конечно эффект будет сильнее ощущаться, но и с меньшим количеством сущностей он есть.

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

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

В пошаговой игре время идет неравномерно. Да 70% времени игрок разглядывает циферки в 120фпс двигая время на 10 тиков раз в 5 секунд. Тут вообще можно ничего не оптимизировать.
Но вот в оставшихся 30% вычисления должны происходить просто молниеносно.
Представим, что в пещере месится стенка на стенку толпа нейтральных мобов, создавая нехилую нагрузку. А игрок в этом не участвует, а просто проходит мимо. Он должен пройти так же плавно как если бы вокруг ничего не происходило. И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков. И каждый тик это точка синхронизации, к которой должны быть выполнены все-все рассчеты, должны пройти все потоки и так далее.
Вот в чем узкое место.

Есть конечно обходные пути.
Можно заставить игрока после каждого хода смотреть анимацию того как персонаж перепрыгивает с одной клетки на другую. Так сделано у меня, что дает немного дополнительного времени на расчеты. Сейчас это совсем чуть-чуть, если сделать этот промежуток больше, выглядеть будет отвратительно, я вас уверяю.

Можно сделать так, чтобы когда игрок идет быстро мобы переставали драться. Или делали это медленнее.
Но это же полная херня! Это просто нечестно.
Хотя, если фпсов будет не хватать я прибегну и к этому.

Есть вариант для шахматистов. Просчитывать все заранее. пока игрок стоит. Гениально!
Если такое реально где-то реализовано (не в шахматах не в го и не в крестиках-ноликах, а в настоящем рогалике) то я бы поклонился до земли. Хз может где и есть, не берусь утверждать
Количество комбинаций с увеличением глубины просчета растет в такой лютой прогрессии, что я не представляю как это возможно.
Ну хорошо, за секунду стояния на месте просчитал ты все варианты на 5 ходов вперед и что дальше? А игрок не остановился на пятом ходу, пошел дальше и все, 10 фпс.

Чуть более адекватным кажется вариант когда есть какой-то максимальный отрезок времени выделенный на тик. Вот вычисляют все мобы свой ИИ, кто успел за 100 мс, тот ходит в этот тик, а кто не успел тот пропускает ход и дальше считает на отдельном потоке, пока не будет готов. А потом ходит и уходит в меньший кулдаун чем те, кто успел посчитать раньше.
Вот в сторону этого мб есть смысл подумать, но выглядит очень замороченно и без многоядерности, получается, оно вообще не будет работать.

>>829193

>Просчитывать все заранее, пока игрок стоит.

Суммарно нагрузка будет значительно выше, что вызовет более скорый перегрев и разряд аккумулятора мобильного устройства (как смартфона, так и ноутбука). В шахматах брутфорсят ходы, чтобы обыграть слишком умного человека, потому что не хотят учить машину оптимальным шахматным стратегиям, которым обучен человек, которого нужно обыграть. У тебя же вопрос оптимизации хода, а это совсем другое.

>В риалтаймовой игре ты можешь делать вычисления намного более "ленивыми". Когда мобы не сразу реагируют на изменение ситуации это даже выглядит более правдоподобно.

А в чём разница-то? В реалтайм игре моб принимает решения каждые несколько секунд, а в пошаговой тот же моб будет принимать решения каждые несколько шагов. Рогалик - не шахматы, тут твой противник не обязан изменять свои решения каждый ход, не так ли? Тем более если игрок делает несколько "ходов" за один клик мыши - с какой стати мобы должны думать каждый ход, если игрок думает каждые два десятка ходов?

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

Вопрос в том, по какой причине "толпа мобов" создаёт нагрузку, если операции, которые она выполняет, должны быть очень примитивны? Логика моба в толпе: "вижу врага на клетке справа от меня -> могу его ударить -> бью его". Даже если у тебя 100 врагов действуют по этому шаблону, это ничтожно малая нагрузка на процессор. Тем более если моб фиксируется на враге и бьёт его, пока тот не умрёт или пока ему не потребуется отступить. Т.е. перед первым ударом моб сканирует 8 соседних клеток, а все следующие ходы он только проверяет собственное здоровье и состояние врага - не пытается ли он сбежать, что будет быстрее сканирования клеток. Вообще, сканирование должно быть редким, тем более мобы не должны сканировать большую зону вокруг себя. Алсо, не обязательно сканировать пустые клетки, если моба волнуют только враги - он может посмотреть список имеющихся мобов в данной локации, и узнать расстояние до них, не проверяя тысячи пустых клеток.

Другими словами, делай мозги мобов глупее - игроку вовсе не нужна крыса с 5 хп и единицей урона, которая каждый ход сканирует область радиусом 100 клеток и выбирает следующего врага с помощью какой-то сложной формулы. Это пушечное мясо и оно не должно много думать. Вообще, вместо таких мобов может думать общий интеллект, особенно если мобы группируются в стайки - он просто ищет цель для них всех раз в N ходов, а дальше простой а-стар находит им пути до цели, раз в M ходов.

>И в этот момент в течении 5 секунд может проходить не 10 а все 250 тиков.

А что ты там каждый тик считаешь? 250 тиков за 5 секунд - всего лишь 50 тиков в секунду. Физические движки обычно работают на скорости 60 тиков - для примера, движок Bullet начинает тормозить на процессоре 2007 года при попытке симулировать физику примерно при 500+ независимых физических тел на скорости 60 тиков. Неужели ты хочешь сказать, что твоя симуляция пары десятков тупых мобов на клеточной 2D карте значительно сложнее симуляции достаточно правдоподобной физики 500+ независимых тел? Ещё можно было бы понять, если у тебя на одном экране сотни независимых и по определению умных ИИ, а мы вроде как говорим о простых мобах в узких пещерах, где столько народу просто не поместится.

Теперь хочется набросать прототип пошагового 2D рогалика и убедиться самостоятельно, будет ли он лагать на сравнительно большом количестве мобов...

>>829820

>Система проходит только по задамаженым частям тела и добавляет эти модификаторы.

>Потом вторая система суммирует их все и это дает конечное изменение морали за тик.

Хотел прилепить картинку-мем, но не хочу обидеть, т.к. ты всё же адекватный анон. Возможно даже я не прав и твой метод действительно имеет смысл... Но по описанию это всё выглядит так, будто ты абузишь ECS и в хвост и в гриву, рассчитывая, что она магически всё оптимизирует за тебя. Это не так. Если ты делаешь несколько циклов обхода массива подряд, ты в любом случае тратишь дополнительное время, которое можно было бы сэкономить, сделав все дела за один проход. Да, ECS даёт некоторое ускорение в случае работы с большими однородными массивами данных, но это не панацея, архитектура всё равно должна быть продумана. Если лепить системы абы как, можно сделать такую игру на ECS, которая будет медленнее обычного ООП на скриптовом языке. Собственно поэтому я и другие сторонимся ECS, для эффективной реализации этой парадигмы необходимо иметь в голове совсем другой подход к разработке ПО, иначе получится хрень.

>Так или иначе я ее уже починил, теперь эта система занимает что-то вроде 3 мс.

3 мс из 16 мс на кадр, если ты хочешь стабильные 60 квс.

>15 мс рендеринг, что для рендеринга очень много.

А у тебя включена вертикальная синхронизация? По идее, с включённой вертикальной синхронизацией рендеринг кадра всегда должен занимать 16.6 мс на графике. Если же у тебя реально 15 мс на кадр, то я даже не знаю, сколько же у тебя там спрайтов, десять тысяч?

>коллизии 17мс

Что такое "коллизии" в клеточном мире? У тебя там вообще никаких физических объектов быть не должно, откуда взяться коллизиям? Или что ты так называешь?

>смерть существ 16 мс

Добавляй мёртвых существ в очередь и освобождай их ресурсы по мере возможности... или в ECS всё не так просто? Если я правильно понимаю, удаление моба в ECS вызывает удаление всех его компонентов, которые могут быть в середине огромных массивов, которым придётся сместить половину данных на одну позицию в сторону удалённой. Понятия не имею, как можно оптимизировать удаление компонентов в ECS, есть ли какая-то официальная рекомендация Unity по этому вопросу? Для сравнения, в ООП обычно рекомендуют не уничтожать объекты лишний раз и использовать их повторно, чтобы не было лишних операций с кучей (освобождение и поиск нового места), и это, если я правильно помню, в туториалах Unity советовали (т.к. сборщик мусора C# - одна из печально известных проблем всех игр на Unity).

>>829861

>Сделал так что теперь мобы используют не только первую точку построенного пути а первые три. Больше точек не вижу смысла пока ставить.

>Конечно перед тем как сделать ход моб проверяет, не появилось ли у него на пути чего-нибудь.

А почему только три? Представь себе реальный мир. Тебе нужно пройти 10 км через город. Ты знаешь карту города и строишь маршрут по известным тебе дорогам прямо до пункта назначения. Ты не меняешь этот маршрут до тех пор, пока тебе не встретятся непреодолимые препятствия вроде перекопанной поперёк дороги. Но даже так, ты узнаешь об этой проблеме только когда дойдёшь до неё и убедишься в её непреодолимости, только тогда ты запросишь в своих мозгах построение нового маршрута и, возможно, даже пойдёшь сперва назад, т.е. финальный путь будет совсем не таким оптимальным, как хотелось бы.

Т.е. если моб знает наизусть пещеру, в которой он живёт, он проложит маршрут до цели, даже если она скрыта стенами пещеры, и будет идти до неё, пока не дойдёт, прямо перед ним (1-2 клетки маршрута) не появится препятствия или его не отвлекут от движения (урон). И это, я считаю, будет выглядеть достаточно реалистично. Не вижу смысла вычислять новый путь каждые три клетки, особенно если путь достаточно длинный (десятки клеток).

Хотя для 100% реализма каждый моб должен иметь индивидуальные воспоминания о форме карты. То есть если моб находится в комнате А и помнит комнату Б, а в это время в комнате Б произошли радикальные изменения, моб должен построить маршрут до предмета в комнате Б по своим воспоминаниям - устаревшей копии карты в его мозгах, и лишь после того, как он войдёт в комнату Б, он узнает о том, что его маршрут неправильный или предмета там нет, и будет решать, как двигаться дальше или что дальше делать, если пройти теперь нельзя. Но это, как ты понимаешь, совсем другой уровень ИИ и простому рогалику про убийство мобов в подземельях такое просто не нужно.

>>829991
Все значения см которые я привожу замеряются с этой 470-мобной толпой. Точнее две дерущихся толпы по 235 тел
Я использую ее для того чтобы лучше контролировать какой результат моя оптимизация оказывает на системы.
В реальности такой нагрузки даже близко не планируется.
3мс намерено тоже там. В нормальной ситуации это не 3 мс а ноль-точка-че-то-там мс.

Кстати, на счёт фпс, вообще не особо понятно как их мерять, все эти цифры это же пиковая нагрузка.

Что там системе киллов, я не помню, писал ее давно. Во всяком случае это точно не уничтожение сущностей, умерший моб не уничтожается, а просто теряет свой ИИ вместе с парой других компонентов и падает на пол.
Там как минимум в одном месте Debug.log который сообщает кто кого убил и как. Сообщения дебага очень дорогие.
Сто процентов есть способ сделать это в разы дешевле, я просто туда пока не добрался, всему свое время.

Пути по 10 клеток в длину это слишком много. Моб идёт бить игрока в 10 клетках, а игрок взял и телепортировался и теперь он у него за спиной вообще. Если моб пройдет по инерции три клетки то это нормально а 10 уже не очень. Соотношение оптимизация/функционал плохое.
Можно конечно проверять, как далеко ушла цель от конечной точки маршрута, и тогда перестраивать, но мне что-то лень это прописывать, мб потом сделаю.

>Что такое коллизии

Вижу, ты тут не так уж давно.
Физика играет в моем рогалик не последнюю роль, а раньше ее было значительно больше. Объекты могут двигаться и сталкиваться если их бросают или если ими атакуют из рук. При каждом столкновении вычисляется коллизия.

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

Предположим моб атакует топором другого моба.
Вычисляется в какую часть моба попал топор. Это рука.

Вычисляется в какую часть этой руки попал топор. Это щит.
Вычисляется какой частью топор попал по щиту.

К счастью топор имеет только одну часть, это он сам. Как собственно и щит, хотя ничто не мешает ещё углубить эту иерархию.

И так, мы имеем две финальных части, это топор и щит. Щит, как и любая часть прикреплен к своей родительской части соединением.
Вычисляется достаточно ли урона топора + скорости топора, чтобы порвать соединение между рукой и щитом. (Прочность соединения зависит от прочности предмета и характеристик моба)

Если да то после коллизии щит улетает и сталкивается дальше. Если нет то остаётся.
Дальше считается дамаг. Дамаг топора по щиту и щита по топору. Часть дамага топора по щиту проходит через щит в руку которая его держит.

Потом взаимно накладываются эффекты-при-стоклновении, если они были.
Если удар был такой силы что раздербанило и саму руку, то отрывается и рука. Если бы это был не рука а тело или голова то наступает смэрть.

Ещё через всю эту цепочку проходит инфа о том кто ее запустил, так что если мобу снесло голову щитом который выбило из рук другого моба взрывной волной от бомбы, брошенной игроком то все об этом узнают.

Да, я понимаю, местами это переусложненная система. Ты можешь сказать что тут многое из этого нафиг не нужно, и будешь прав. Но мне так прикольно. Я экспериментирую, ищу новые механики. На данный момент эта система норм, хотя и не получила того развития которое я планировал. По факту сейчас частями тела обладают только мобы.

Вообще система уже прошла несколько циклов упрощения, изначально там ещё рикошеты были, масса и ещё всякое разное...
Плюс с оптимизацией я туда пока не зашел.

>>830021

>игрок взял и телепортировался

Лучше уж проверять наличие цели в заданной точке каждый шаг, чем каждый шаг теребонькать а-стар, чтобы он выдал в ответ тот же путь, что и на прошлом шаге (ведь заданная цель не сдвинулась с места). Каким бы методом ты не вычислял новый путь, делать это каждый шаг дороже одного if "цель на том же месте, где и была" then "продолжить путь" else "посчитать новый путь". А твоя оптимизация "всегда идти ровно 3 шага и только потом посчитать новый путь" может оказаться менее верной, особенно если игрок часто телепортируется.

Кстати, что будет делать твой моб, если игрок скроется за углом пещеры? Продолжит преследовать? Или дойдёт до угла и потеряет интерес, если игрока в поле зрения не окажется (успел сбежать)? У мобов вообще есть поле зрения или они сканируют все клетки в радиусе?

>Вижу, ты тут не так уж давно.

>Объекты могут двигаться и сталкиваться

Нет, я тут давно, просто до сих пор не играл в демку и забыл то, что читал несколько месяцев назад. Да, я вспомнил, у тебя там было что-то про броски предметов. Но так ли уж нужно включать в это дело физику, если предметы всё равно должны лечь на клетки? В крайнем случае коллизии здесь уровня Майнкрафта - if "клетка занята" then "произошло столкновение" else "продолжить движение". Тут нет необходимости в полноценных коллизиях.

>Я экспериментирую, ищу новые механики

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

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

>>831179

>рендер занимал 30 мс.

>Теперь 2.8 мс.

Так и знал, что поможет. Везде работает. Впервые узнал об этом приёме, когда bitblt()-ом рисовал.

>Еще до этого при спавне каждого предмета, из пула брался специальный геймобджект с рендерером, которых там лежало 10к. Теперь, получается их требуется на 4096 штук меньше.

Ммм... Если я правильно понял, ты хранишь все игровые объекты в одном массиве, с которым работает и чанковая система, и спавнер предметов, и всё остальное? Разве не было бы лучше разделить их на несколько массивов в соответствии с целью их использования (тайлы; предметы; персонажи; летящие предметы - пули, стрелы и т.п.), чтобы не приходилось далеко бегать по массиву? Заодно можно было бы разложить по разным скриптам: тайлами управляет тайловая карта, персонажами - менеджер персонажей, предметами - менеджер лута, летящими снарядами - менеджер летящих снарядов и т.д. Я бы сделал так хотя бы чтобы самому не запутаться, где что.

>Пол в моей игре это просто спрайт 32х32. А вот стены это другое. Начнем с того что она 32х48 и если ты стоишь перед стеной то твоя голова перекрывает ее нижнюю часть. А если за стеной то уже она тебя перекрывает.

Если я правильно понял, то перекрывает персонажа не вся стена целиком, а кусочек 32x16 пикселей сверху спрайта стены. Под нижними 32x32 пикселями персонаж встать никак не может. Ну вот и нарисуй их прямо поверх пола, или даже вместо пола, если стена целиком перекрывает клетку пола. Кусочки 32x16 можешь либо отдельно рисовать, либо тоже запечь в текстуру, но уже отдельную, которая будет отображаться после всех персонажей. Только учитывай, что эта текстура должна иметь прозрачность, что может повлечь за собой снижение производительности. Замеряй сам, что будет выгоднее.

Разрушаемые стены тоже легко сделать. Принцип тот же, что в майнкрафте. При частичном разрушении рисуешь анимацию разрушения поверх блока, а при полном разрушении один раз отрисовываешь текстуру пола заново, заменяя в ней тайл стены на тайл пола. Или, если такое технически возможно в юнити, можно нарисовать всего один тайл - тайл пола - поверх уже готовой текстуры, в то место, где нарисован тайл стены. В майнкрафте чанки не состоят из независимых кубов и собираются заново при каждом добавлении/удалении куба, а 2D игре можно тупо поверх готовой текстуры новый блок нарисовать (или закрасить прозрачными пикселями удаляемый блок).

>>832902

>Я же хочу чтобы красиво было.

>У него процедурно меняется толщина, прозрачность и так далее.

Разве процедурная толщина, прозрачность и т.д. образуют красоту?
Насколько я знаю, в обычных 2D играх все эти шлейфы стараются рисовать одним спрайтом. Во-первых, так дешевле, во-вторых, этот шлейф всё равно видно будет 1-2 кадра, игрок ничего не разглядит.

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

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

>>832908

>А пул это просто хранилище из кучи одинаковых примитивных объектов, использующихся для рендеринга, которые берутся оттуда по мере надобности, а потом туда-же возвращаются.

Звучит странно, ты имеешь в виду Component в ECS? Так это же не ты сам делаешь, а ECS должна автоматически это делать, абстрагируя тебя от работы с пулами данных.

>делать этажи произвольного размера звучит очень заманчиво

Именно так. Ограничение в 64x64 клетки как-то не очень звучит.

>Делить его на меньшие области я пока не вижу смысла, узкое место производительности сейчас явно не в этом.

Помимо рендеринга, чанки могут использоваться для уменьшения других вычислений. У тебя сейчас боты ходят по всей карте или только в поле зрения игрока? Логично было бы сделать их немного "глупее" вне поля зрения игрока.

>сложно

Согласен. Тем более что выгода не гарантированна. Нужно сначала провести тесты и сравнить производительность, прежде чем вводить в игру такую оптимизацию.

>>832910

>величайший секрет

В чём секрет-то, это же Unity, в ней нет труъ 2D.

>>832913

>Ударил одного крестьянина - дипломатические отношения со всеми жителями деревни портятся на долгие годы.

А что на счёт куриц? Курица будет телепатически сообщать всем жителям об ухудшении отношений в результате пинка ей под зад?

>>832941

>нормальную систему сейвов

JSON или бинарный формат? Сохраняешь все тайлы или только параметры генерации?

>>835801
>>835802
О, ну вот, конструктивная критика.

>С фпс все в порядке

У большинства то да, просто именно что на некоторых компах фпс до очень низких значений падает без видимых на то причин. Собственно в чем трагедия последних 10 постов.

>Интерфейс и управление говно

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

>Прогресса не ощущается.

Ну да, есть такое. У меня есть статы, которые можно поднимать за очки опыта, но это пока не особо много чего дает. Вообще мне хотелось бы сделать игру где прогрессия в плане цифр не так важна, а большее значение имеют исследование и навыки самого играющего. Но это сложно.
Ну есть такие игры, например Exanima какая-нибудь. Где ты в начале, собственно, не особо сильнее чем в конце. Но Exanima это не рогалик, за счет чего там интерес именно в исследовании сделанных вручную лабиринтов. Увы, чтобы тот-же принцип был применим к процедурным мирам они должны быть не менее проработанные чем таковые в Dwarf Fortress, иначе, да, чувствуется однообразие...

>унылая боевка

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

>играешь ли ты в свою игру с точки зрения обычного игрока?

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

Но игрокам конечно виднее весело это или нет. Очевидно что надо что-то менять.

>Вот должно быть весело ещё на стадии прототипа, прежде чем наполнять игру контентом и оптимизировать системы.

Увы, это так.

Вот насчет локализованного урона. Предположим, я сделаю возможность прицельно бить по частям тела.
Тогда это будет подталкивать игрока к тому чтобы каждый удар делать прицельным в голову и для этого нажимать дополнительные кнопки. Примерно такая-же проблема в Dwarf fortress. Там можно прицельно бить по частям тела но никто этого не делает, так как это дополнительные взаимодействия с интерфейсом.
Может сделать эти прицельные удары очень эффективными, но платными, за стамину или типа того...

>Слишком резко

Да не, не резко. Когда меня критикуют это намного полезнее чем когда просто говорят что я молодец, но в игру не играют.

>>835821
Ещё момент по юзабилити и инвентарю. Сделай так, чтобы можно было просмотреть точный список предметов под ногами и выбрать для поднятия один конкретный. Пускай это занимает как и сейчас по одному ходу на предмет (для баланса), но, по крайней мере, не нужно будет собирать целую груду костей в инвентарь, чтобы убедиться, что под ними ничего полезного нет.

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

Можно ли есть мясо из инвентаря я не понял, но если нет, такую фичу нужно сделать. Я поддерживаю быстрое поедание врагов прямо с земли хоткеем, но не бросать же куски мяса на землю, когда нужно поесть?

С камерой хотелось бы не только приближение и отдаление, но и сдвиг камеры в сторону мыши, если мышь близко к краю экрана; когда мышь возвращается к персонажу, камера центруется на персонаже. Это позволило бы иметь широкий обзор при комфортном разрешении тайлов. Все движения камеры должны быть сглаженными.

Мелкие одинаковые предметы типа костей в инвентаре я бы складывал в стопки... Не знаю, что ты планируешь в плане ограничений, но выглядит абсурдно, когда у тебя в рюкзаке маленькая кучка тонких ребёр и из-за этого не помещается кусочек мяса. Да, признаюсь, мне хочется собирать вообще всё, что может быть сколько-нибудь ценным, и я даже надеялся, что у тебя там есть какой-нибудь крафт из костей... Привычка из игр, в которых почти нет бесполезных предметов - всё или почти всё является ингредиентом крафта или может быть продано торговцу (кости хоть сколько-то да должны стоить, это же удобрение, ингредиент для клея или основа оружия; хотя в играх цена обычно обусловлена балансом - доступностью предмета для игрока).

>>835877
Какой развернутый фидбек, шикарно.

>про оптимизацию

Возможно это на самом деле не висюнк а что-то другое, просто профайлер отображает его так. Во всяком случае передо мной то что на первом скрине. А в диспетчере задач то что на втором.
Как видно, гпу загружен под завязку.
Так же 700мб оперативки, это, как мне кажется, тоже абсолютли нот окей. Но тут скорее всего виновата моя база данных с предметами, я примерно понимаю как это починить.

А аудиофайлов в игре нет.

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

>про интерфейс

Мне кажется, он у тебя как-то некорректно отображается. Во всяком случае кнопка версии точно не должна перекрывать арену. Смотри третий скрин.

По поводу подсказок в инвентаре - годная идея, попробую запилить.

Подождать 10 тиков можно если вызвать радиальное меню долгим нажатием правой кнопки на клетке где стоишь.

На счет пиксель-перфект камеры, мне кажется тут тоже что-то с разрешением не то. У меня где-то 4 или 5 разных режимов увеличения, большинством из них вроде вполне можно пользоваться...

>про прогрессию

Вот на счет крыс не согласен)
По-моему прикольно что они тебя избить могут. Просто не нужно самому на них нападать, если их большая пачка, а у тебя оружия нет. Периодически на них коты охотятся, вот тогда можно выждать момент и напасть.
Настоящие проблемы баланса начинаются в районе 5 уровня, когда и из угла выходит негр с молотом и просто двумя точными ударами в незащищенную голову тебя сносит.

>туториальный уровень

Давно хотел его сделать. Типа как отдельную локацию в начле, куда можно зайти а можно мимо пройти.

В фоллауты, увы, ни в один не играл, но этот зеленый экран прицеливания видел. Нужно изучить эту тему.

>>835880
Содержимое клетки можно посмотреть нажав О и листая предметы, но да, это не самый удобный способ.

К сожалению, мясо из инвентаря есть нельзя.
Я бы вообще хотел как-нибудь ограничить механику переноса еды в инвентаре, так как это подталкивает игрока к гринду всего мяса и всех грибов на уровне. Хз как это сделать. Может переносимый вес ввести?
Но для другой еды безусловно хоткей нужен.

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

>>835904
Вот мои скриншоты. Разрешение оригинальное.

Ещё по управлению, не помню уже, писал ли: сделай WASD управление, оно намного привычнее на компьютере, чем тыки мышкой. Тыки с поиском пути - это скорее к мобилкам, чем к ПК. Я знаю, что есть крупные ПК игры с управлением только мышкой, но это не меняет того, что тыки мышкой банально не так удобны, как движение клавишами. Я думаю, что управление тыками мыши характерно для игр с очень сложным GUI, типа MMORPG, MOBA, всевозможные симуляторы и т.д. Для рогаликов всё же характерно управление "только с клавиатуры", потому что во времена первых игр мышей вообще не существовало или они очень редко встречались у пользователей. Понимаю, что у тебя геймплей заточен в том числе на движение по диагонали, но это теоретически возможно осуществить четырьмя кнопками (потребуется минимальная задержка для того чтобы компенсировать разницу во времени нажатия двух клавиш), а в крайнем случае можно перенести управление на нумпад - там как раз вокруг клавиши "5" клавиши сеткой выстроены. Впрочем, в идеале у тебя должны быть настройки раскладки, чтобы игрок мог забиндить всё на свой вкус/под свои возможности. От управления чисто мышью отказываться не нужно, нужна просто альтернатива для расширения аудитории.

>Настоящие проблемы баланса

Пока делал скриншоты, немного побегал по первому уровню, никого не трогая - лестницу вниз не нашёл, зато встретил группу из 3+ скелетов и они меня... окружили (я попытался взорвать бомбу и меня разбросало, а скелетам вообще пофиг). Это не хардкор, это издевательство... впрочем, кто я такой, чтобы судить, я не разбираюсь в особенностях рогаликов - может, в этом и есть фан?

>двумя точными ударами в незащищенную голову тебя сносит

Таки мобы могут прицельно бить, а игрок - нет? Или ты имеешь в виду, что случайные удары так совпали?

>В фоллауты, увы, ни в один не играл

https://fallout.fandom.com/wiki/Aimed_Shot

Нужно понимать важную разницу между первыми фоллаутами и рогаликами вроде твоей игры: в фоллауте тебе дают очки действия на каждый ход, что позволяет тебе осуществить несколько действий за один ход, прежде чем очередь дойдёт до противника; далее каждый враг ходит по очереди, тоже используя свои очки действий. Поэтому в фоллауте можно, например, сделать несколько быстрых ударов и заюзать хилку, а можно сделать только один мощный прицельный удар. Также максимальное количество очков действий зависит от параметров персонажа - прокачки, здоровья и т.п., например, если ничего не путаю, какой-то наркотик позволяет временно повысить число очков действий, но вызывает зависимость и в последствии число очков действий будет меньше обычного, вынуждая принимать наркотик дальше, пока не сдохнешь от передоза/побочек... таки реализм же.

Впрочем, я тут подумал, вроде бы в рогаликах отдалённо похожая система: разные действия занимают разное число тиков, и если игрок делает действие за 5 тиков, а монстру для атаки нужно 10 тиков, то игрок может успеть сделать ещё одно действие, прежде чем монстр атакует... Правильно ведь? Ты что-то такое вроде писал, но я в игре это как-то не разглядел. Так что советую отобразить ней таймер тиков в углу экрана... не знаю, как лучше описать... Вроде бы в CDDA такой таймер видел - в виде круглого прогресс бара, который обозначает какое-то круглое число тиков, наглядно демонстрируя, сколько времени затратило предыдущее действие игрока.

>ограничить механику переноса еды

>гринду всего мяса и всех грибов на уровне

Банально добавь порчу еды со временем. Будет нерационально бегать собирать мясо, потому что пока соберёшь всё, половина по дороге испортится. Также я во многих рогаликах вижу параметр голода, который не позволяет игроку бесцельно блуждать - даже если еда не портится, бегать по уровню нерационально, т.к. пока всё соберёшь, половину придётся съесть. В остальном, балансируй по формулам: нужно составить такую формулу, которая позволяет игроку в среднем вынести с уровня только минимальное количество еды; такие параметры, как размер уровня, количество мобов и растений, дроп еды с каждого растения и моба, скорость порчи/голода, средний расход еды на лечение и т.д. будут неизвестными в этой формуле. Решаешь формулу и получаешь набор параметров для генерации уровня. Эту формулу можно даже использовать во время генерации уровня: если результат формулы говорит о том, что игрок будет голодать, нужно накинуть в уровень бонусной еды и снова проверить формулу; если формула говорит, что еды слишком много, нужно убрать часть мобов/растений или, например, изменить их тип на "токсичный", чтобы игрок их не ел.

>каждый предмет был уникальный

Тут нужно понимать, как это выглядит с точки зрения игрока. Если у тебя 10 кусков мяса, которые весят около 1 кг, но отличаются буквально на считанные граммы друг от друга, то технически все эти куски мяса уникальны, но с точки зрения пользователя разницы между ними нет - это всего лишь расходный материал для лечения, а какие-то мелкие колебания веса значения не имеют. С точки зрения игрока было бы удобнее иметь стопку мяса, чтобы не искать кусок мяса по всему инвентарю. Пускай инвентарь ограничен, но зато нужно меньше движений для использования нужного предмета.

В твоём случае рекомендую сделать так. Пусть любой предмет может быть уникальным, но предметы с одинаковыми параметрами должны образовывать стопки. Незначительные параметры должны быть полностью устранены, т.е. если мясо - то стандартный 1 кг мяса. Предметы с прочностью тоже можно стакать, просто после изменения износа у одного предмета он вылетает из стопки и больше не может быть с ней объединён. Это упростит интерфейс и поиск нужного предмета.

Что касается ограничений, я считаю, что фиксированное число ячеек интерфейса намного сложнее балансировать, чем, например, ограничение по суммарному весу предметов или по числу предметов одного типа. Не знаю, может, это Майнкрафт на геймдев так повлиял, что у многих сейчас инвентарь из фиксированного числа ячеек... Но я не считаю это таким уж хорошим решением, просто к нему привыкли.

Для примера годного инвентаря рекомендую это:
https://play.google.com/store/apps/details?id=com.gm_shaber.dayr
Это тоже пошаговая игра, только игрок большую часть времени один и от его действий зависит течение времени, а не действия противников (противники есть в отдельной боевой системе, которая выглядит как мини-игра). Но не в этом суть. Там инвентарь выглядит как неограниченная сетка с постраничной прокруткой, расширяющаяся по мере необходимости. Можно посмотреть все предметы, а можно выбрать категорию кнопкой-вкладкой сбоку. Есть сортировка по весу, по количеству, по названию, по типу предмета. Есть даже такая крутая фича: каждый расходник имеет уровень износа, но при этом он собирается в стопку с другими расходниками; стопка точно помнит износ всех предметов в ней, но сортирует их степени износа, т.о. при использовании всегда тратится предмет с наибольшим износом. Это избавляет от кучи функционально одинаковых предметов с высоким износом. Есть и уникальные предметы, занимающие одну ячейку - обычно это что-то важное, вроде пистолета. Инвентарь, как ты уже понял, ограничен максимальным переносимым весом, но при этом персонаж способен напихать себе в "карманы" любое количество предметов - просто при превышении лимита он не сможет двигаться по карте. Это тоже очень удобная фича, позволяющая удобнее сортировать предметы в локациях, хотя крафтинг доступен даже если необходимые предметы с точки зрения интерфейса "лежат на земле". Короче, система очень продуманная и удобная для этой игры, хотя я не уверен, насколько хорошо она подойдёт рогалику.

Для сравнения, в Фоллаут тоже ограничение только по весу, а не по числу предметов, только инвентарь там в виде списка, а не сеткой. Сетка по идее лучше работает для большого количества предметов, а список позволяет разместить название и некоторые параметры предмета прямо на строке списка. В общем, нужно смотреть по тому, сколько позиций в инвентаре может быть - если у тебя там только стопки мяса, костей да палок, то сетка из квадратиков вообще ни к чему...

>специальный предмет-мешок

Мне эта фича не понравилась, ибо костыль. Почему в "обычном" рюкзаке одно семечко занимает объём боевого молота? Просто сделай массу и дай бесконечные ячейки, делов-то. Сбалансировать можно что угодно, главное - юзабилити гуя.

>>835906

>Промахнуться нажатием легче, чем скорректировать движение пальца

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

У перетаскивания два косяка.

Во-первых, если предмет ТОЧНО ПОД ПАЛЬЦЕМ, ты со своими сосисками не видишь, куда именно роняешь предмет, т.к. предмет не видишь. На первый взгляд, это возможно пофиксить смещением точки захвата от пальца, но тут возникает вопрос - каким пальцем пользователь ведёт по экрану? Может, правым, может, левым, а может вообще сверху экрана рука висит (если горизонтальная ориентация, такое вполне возможно и иногда удобно). Т.е. эта проблема куда сложнее, чем кажется.

Во-вторых, даже самые лучшие сенсорные дисплеи могут ошибаться, особенно если телефон нагрелся во время игры и руки вспотели. У меня неоднократно бывало в самых разных играх и на разных смартфонах, что я не могу с первой попытки перенести предмет, т.к. он роняется раньше времени или не цепляется вообще. А современные "безрамочные" смартфоны ухудшают проблему - теперь ты можешь неосознанно нажимать на край экрана, вызывая непредсказуемые глюки в игре. Перемещение предметов одиночными кликами ЗНАЧИТЕЛЬНО всё упрощает, потому что у дисплея сейчас 5-10+ точек контакта и каждая из них регистрируется как независимый "клик", позволяя наплевать на многие ошибки. Т.е. у тебя выше шанс правильно переместить предмет кликом, чем если тебя заставляют вести палец через всю твою лопату, ни в коем случае не отрывая от экрана и не прикасаясь вторым пальцем. Видимо, у тебя другой опыт...

>>835911

>при старте комнаты камера спавнится в темном месте и приходится рестартить игру

А ты пробовал подождать? У меня не сразу начинается: сначала чернота и циклоп несколько секунд, только потом появляется локация и правильный персонаж (в смысле, если выбрал не циклопа). Если твой компьютер сильно слабее моего, то тебе ещё дольше ждать нужно.

>Где моё здоровье?

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

>>835912

>DCSS

Глянул порт, на андроид предлагают виртуальную клавиатуру и набирать на ней сочетания клавиш. Ну уж нет, какой бы там геймплей ни был, такие извращения я не люблю ни на компьютере, ни тем более на телефоне. Я считаю, что богатый геймплей можно совместить с простым управлением, не создавая сотни шорткатов на клавиатуру для примитивных действий. Поэтому избегаю "классических" рогаликов, где нужно несколько часов зубрить раскладку клавиатуры и шорткаты.

>>835914

>А что, действительно непонятно что это?

Совершенно непонятно даже то, что это на самом деле кнопки, а не какие-то декоративные спрайты или плейсхолдеры для будущих функций (типа статусные эффекты). У тебя во всей игре кнопки выглядят как коричневые прямоугольники, а тут внезапно цветные иконки даже без рамки. Как я должен понять, что это кнопка? Алсо, раз уж ты занял весь экран инвентарём, мог бы сделать обычные чекбоксы с текстом, а не какие-то огромные иконки.

>То что ты описываешь при старте, это и правда какой-то загадочный баг, я такого не встречал.

Либо у тебя компьютер очень быстрый, либо кэш на диске помогает игре быстрее стартовать. Попробуй удалить кэш или запустить игру на виртуальной машине, особенно на искусственно замедленной, чтобы оценить процесс загрузки на слабом компьютере. Oracle VM VirtualBox бесплатная и её легко настроить.

>>835934

>Вот скрин Бага

>Он при первом же запуске вылез.

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

>>835935 >>836027
Зачем вы ему эту гадость советуете, "x2/x3" - это как те два стула, на одном двойки точёные, на другом тройки дрочёные. У него не пиксель-перфект графика, так что он может спокойно забить болт на пиксели и приближать камеру с минимальным шагом. Чем меньше шаг, тем плавнее и удобнее будет настройка.

>>836095

>И третий, и четвертый

Так в любом случае это быстрее, чем двигать пальцем через весь экран несколько раз подряд без результата.

>искорка закрыта сосисочным пальцем

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

>Пока ты не отпустил

Так я ж говорю, если произошёл сбой сенсора или ты сам случайно палец от экрана оторвал, предмет вернётся на место и придётся повторять операцию. Хуже всего, когда нужно таким образом много предметов переместить. Вот поэтому перемещение нажатием лучше.

А для ПК нужны шорткаты. Только ньюфаг будет мышкой таскать, продвинутые игроки прокликивают нужные предметы с shift/ctrl/alt. Таскание предметов мышкой только в первые часы игры кажется интересным, потом это тупо лишняя рутина.

>>836101

>добавить экран прогрузки

Там есть экран загрузки. Но после экрана загрузки игра по какой-то причине тупит несколько секунд, прежде чем наконец-то отобразит карту и правильную аватарку на индикаторе здоровья. Согласен, что экран загрузки должен висеть до тех пор, пока игра окончательно не прогрузит все ресурсы, и только потом исчезать.

>Потому что это удобно. Управление колесиком не дает поставить нормальное разрешение

Приведу пример: в Terraria можно настроить приближение камеры в сотых долях от x0.6 до x2.0. Графика выглядит нормально на любом значении, нет смысла округлять. А вот в Starbound дали три стула: x2, x3 и x4. Все три стула лично мне не подходят, и это невероятно бесит. Про x4 вообще молчу, x3 слишком близко, а x2 слишком далеко - мне бы хотелось что-то около x2.5, но его нет. Что толку от "пиксель-перфект", если приходится либо всматриваться в мелкие детали, либо терять область обзора?

>скольким людям это не понравилось

Людям не понравилось то, что у него слишком мало подходящих уровней приближения, поэтому так сложно установить комфортное значение. А ты предлагаешь ещё больше ограничить, до двух значений.

>>836113
Рогалики рогаликам рознь, если рогалик выглядит и управляется как таблица в экселе, то это может быть замечательный рогалик, но плохая игра. Если я хочу поиграть в компьютерную игру, я хочу управлять персонажем, а не заниматься рассчётами в таблицах.

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

>>836064

>разрешение

интересно что у многих из вас беда с разрешением, но при этом у всех немного по разному. Ничего, это решаемо.

>Wasd

Такое управление было в более старых версиях, правда не WASD а QWEASDZX. Не знаю... мне было не очень удобно. Мне и в классических рогаликах это никогда не нравилось.
Да, нужно сделать несколько режимов управления, и такой и такой. Это решит проблему.
Тему с задержкой wasd'a я бы не стал пробовать. Я просто представляю как у кого-нибудь после 5 минут обдумывания следующего хода соскальзывает палец и он идет не направо вверх, а просто вверх. А в нашем жанре слишком велика цена любой ошибки. Если бы в DCSS такое было, игроки бы горели знатно.

>Фан

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

>двумя точными ударами

Ну да, я имею в виду случайно.

>таймер

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

>Проча еды

Вот это, кстати, классно ты придумал. Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.

>инвентарь

Наверно мне стоит пока просто сделать его бесконечным, ввести вес и посмотреть как это будет выглядеть.
Потом мб сделать вместо сетки список. Я так понимаю, во всех играх от Бесезды инвентари со списком.
Надо еще подумать над этим.

Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь. Типо как в Dayz или рогалике Stone Shard. Я уверен что есть куча народу кому это категорически не нравится, но мне обычно заходило когда такое встречал.

- Оп

>>836161

>Да пусть у него хоть миллион уровней приближения сделает. Колесиком тупо неудобно этим управлять.

>Колесиком же настроить камеру можно только примерно, да и то, это заставляет поебаться, чтобы даже примерно комфортную величину выставить.

Это раздел разработчиков игр. Здесь не только игроки сидят. Если ты никогда не видел нормального зума в играх, это не значит, что его в принципе невозможно сделать. Вот, сегодня просто сел и накидал сравнительно удобный зум колёсиком, позволяющий установить точные значения с достаточно маленьким шагом (отдельный шаг для >x1 и <x1).

>>836226

>интересно что у многих из вас беда с разрешением

Потому что у всех разные мониторы, а ты захардкодил игру под свой монитор, не задумываясь о зоопарке возможных на сегодняшний день устройств. Кстати, это касается не только разрешений, но и контраста графики - если у тебя IPS/VA/OLED да ещё и яркость подсветки установлена высоко, то у тебя более контрастная картинка, чем на обычных дешёвых LCD (а я ещё яркость снижаю, потому что глаза от яркого света болят). Поэтому у тебя такие грязно-коричневые нечитаемые кнопки, которые тебе, видимо, кажутся нормальными благодаря монитору. Погугли про веб-палитру и почему она появилась - вот с играми, к сожалению, похожая тема.

>но при этом у всех немного по разному.

Разное соотношение сторон. У меня 16:10, у того анона что-то близкое к 16:9, но не совсем. Какое у тебя соотношение сторон, на каком разрешении тестируешь игру? По-моему, ты давно не выкладывал полных скриншотов своей игры со своего монтооа, всё время какие-то обрезки. В юнити так сложно реализовать функцию создания скриншотов? В Godot это в пару строк делается.

>Тему с задержкой wasd'a я бы не стал пробовать

Тогда нумпад. Владельцы обрезков клавиатуры пусть кусают локти и покупают отдельный нумпад))))

>ставить максимальную сложность и пытаться пройти ее без смертей.

Не люблю непрерывное высокое напряжение. Когда встречаешь босса - ок, иногда адреналин приятно получать. Но испытывать напряжение на каждом шагу, перед каждым тривиальным действием - не ок. Должны быть моменты адреналина и моменты расслабления, а "хардкорные" игры - это, как правило, адреналин 100% времени, не дают расслабиться. У меня низкая выносливость и я не могу долго на адреналине играть, а после чувствую себя выжатым лимоном. При этом в условно спокойные игры могу играть много часов подряд, иногда более 12 часов почти без перерывов. Так что внезапная смерть на первом уровне - бред, лучше побродить несколько часов и собрать снаряжение, а затем тактически разобрать босса, чем играть в усложнённую версию русской рулетки. Впрочем, я могу понять людей, которые тратят в день на игру не больше часа и поэтому предпочитают максимально сложные игры, чтобы сразу получить дозу адреналина, без многочасовой подготовки...

>Там есть с песочными часами штучка справа снизу, но сколько каждое конкретное действие занимает не особо видно.

Понятно, я не заметил/не разглядел. Теперь вижу. Важные индикаторы должны быть контрастными, как, собственно, и любые другие важные GUI элементы. А то получается будто бы ты специально прячешь эти элементы.

>На низких хп было полное ощущение того что тебя избивают толпой катая по полу.

>неиграбельно

Ну дык, не доводи героя до минимального здоровья и будет играбельно, лол. Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира. https://youtu.be/6darJMyrAE8

Я думаю, если увеличить ХП в два раза, но при этом ниже 50% будет постепенно увеличиваться штраф на важные параметры - будет нормально. Игрок после нескольких смертей от штрафов смекнёт, что ниже 50% опускать здоровье нельзя, и будет играть аккуратнее. Главное чтобы мобы реже ганкали (gank = gang killing), ну серьёзно, хотя бы новичка (0-1-2 этажи) пожалей.

>>Порча еды

>Вот это, кстати, классно ты придумал.

А разве в рогаликах редко встречается механика голода и/или порчи еды? Я думал, это норма для жанра. Типа прародитель выживалок (Survival) как жанра, только в выживалках обычно бесконечное число жизней.

>Вообще хотелось бы больше каких-то механик связанных со временем, это на самом деле не так часто можно встретить.

Можно добавить спавн мобов со временем. Типа чем дольше игрок задерживается на уровне, тем больше монстров там появляется. Если успел по-быстрому найти выход - тебе повезло, иначе придётся пробиваться с боем. Главное хорошо сбалансировать, чтобы уровень не превращался в непроходимую толпу. И ещё чтобы монстры теряли интерес, если преследуют слишком долго (как если бы у них была энергия/усталость и чувство лени). А ещё можно сделать рост растений и/или "порчи" (Terraria).

>Еще есть система где куча ячеек и предметы разного размера и формы и ты их там крутишь-вертишь.

Да, знаю. Система сложная для реализации, сложная для управления. Да, я уверен, что многим не нравится, т.к. вынуждает ещё больше времени проводить за сортировкой предметов в инвентаре, а не за игрой. Типа, ты зашёл в "3D экшон сурвайвол суть такова", но вместо экшена 90% времени стоишь на месте и сортируешь лут, чтобы впихнуть в рюкзак побольше ценных предметов. Как будто мало игроку разбираться с бардаком в реальности (если бы я хотел сортировать вещи, я бы убрался в комнате или разобрался бы с файлами на диске)...

>>836229

>И там и там они лежат на HDD.

У меня SSD. Дело явно не в скорости диска, поскольку игра очень маленькая по весу файлов. Скорее всего дело в выделении памяти под спрайты или что-то в этом роде. Говорю же, запусти игру на медленной виртуальной машине и замерь через логи время каждого шага - имхо, это полезнее графиков в юнити на быстрой машине.

>А что там за кэш

Ну типа кэш шейдеров. Если у тебя много разных шейдеров, их компиляция может занять существенное время. Это объясняет задержку при первом запуске. Но у меня тормозит каждый раз.

>>836230

>Никогда бы не подумал что механика приближения будет так бросаться в глаза.

Ты правильно заметил, она БРОСАЕТСЯ в глаза. В буквальном смысле, лол.

>Мб неплохой идеей будет вообще привязать камеру не к игроку а к курсору.

Хорошая мысль, но это не отменяет необходимости в адекватном зуме. Зум + сдвиг мышкой (ПКМ). Всё равно у тебя поле обзора персонажа ограничено туманом войны, следовательно, нет причины запрещать игроку максимально свободный обзор одной только мышкой. Тогда и миникарта в принципе не нужна будет.

>>836231

>решил заняться системой прицельного битья

Ясно, расходимся ещё на несколько месяцев?)

Шучу, это должно быть несложно реализовать в техническом плане. Сложно сбалансировать, чтобы не было меты "всегда бить только в голову" или чего-то в этом роде. Этим геймдизайнеры и занимаются, если я правильно понимаю, в своих табличках с формулами баланса.

Специально для ОПа записал летсплей, чтобы продемонстрировать количество багов на квадратный тайл земли в его игре. Первое видео с неправильной частотой кадров, т.к. OBS не хватало чего-то (во втором видео всё нормально), но я решил сохранить его, т.к. там удалось воспроизвести баг с жизнью после смерти - в самом конце уложил 3 скелетов своим трупом и потом скончался при попытке поесть (на undead лечение действует как отрава, всё по канону, спасибо за такое внимание к деталям даже в багах). Во втором видео несколько багов:
1. Игра крашнулась, когда я попытался открыть инвентарь в меню паузы.
2. При попытке БЕЗРУКNМ взять что-либо в "руки" всё управление теряется.
3. Удалось воспроизвести баг того анона со "спавном в тёмном месте". Это оказался независимый от загрузки баг, так что совет "подождать" тут не поможет.
4. Последующий старт котом - непобедимый спидран death% в 0.000 сек, ибо головы нет с самого начала.

Не понимаю, почему у тебя столько возмутительных багов? Понимаю мелкие косяки вроде наезжающей надписи в главном меню, но вот эти краши, ошибки во время загрузки и т.п. просто выводят из себя своей тупостью, будто ты не запускаешь свою игру. Такое ощущение, что ты игру не на самом популярном универсальном игровом движке делаешь, а пишешь с нуля на ассемблере. Не срача ради, но если Юнити настолько непослушная и непредсказуемая конкретно в твоих руках, лучше бы ты делал на Годо. Щас ты доиграешься со своими багами - я не выдержу и сделаю клон твоей игры на Годо быстрее тебя, и все люди будут играть в мою "Скотобазу", а не в твой "Катабазис". Фикси баги. Вот дебаггер, садись фикси. Дебаггером фикси.

>>836270

>зум. Реально бросается. Я не знаю в чем дело

Мне кажется, я нашёл причины проблемы. Вернее, подтвердил свои догадки:
1. Ты проверяешь не щелчок колёсика мыши, а число строк прокрутки, который сообщает игре Windows. У тебя это число скорее всего равно 1, а у меня оно стояло на 3 (раньше и на 5 ставил), из-за чего отдаление камеры происходило в 3 раза быстрее, чем у тебя. Установив это значение на 1 в настройках мыши (см. скриншот), зум стал более послушным на отдаление. Переделай свой код, чтобы он проверял щелчки колёсика, а не прокрутку строк, потому что ты не должен заставлять игрока менять системные настройки. Лучше сделать настройку скорости прокрутки в игре, чем делать её зависимой от настроек ОС.
2. Приближение камеры вообще сломано, т.е. вместо плавного приближения ты просто присваиваешь какое-то конкретное значение, типа "1.0", и уже от него приближаешь, из-за чего возникает эффект, будто камера "бросается" на персонажа. Это должно быть легко пофиксить, скорее всего у тебя где-то "=" вместо "-=" или что-то вроде.

В видео ближе к концу видно, как теперь у меня работает зум, после изменения системной настройки мыши. Но в первую очередь записывал это видео чтобы показать поведение грудной клетки человечка, которого разорвало на части взрывом тестовой /b/омбы. Он продолжает бегать, хотя с точки зрения игрового персонажа это лежащий на земле предмет - его нельзя атаковать, на него можно встать, и его даже можно съесть. Всё просто замечательно, но есть один маленький баг: после обгладывания мяса грудная клетка перестала двигаться, превратившись в груду костей. Срочно пофикси так, чтобы игрок мог создать дружелюбного скелета путём обгладывания трупов врагов или сбора разбросанных костей в кучку. Короче, баг в механике некромантии, делает игру неиграбельной((((

Кстати, благодаря тестовой /b/омбуэ и неудачному расположению v и b рядом, я узнал, что игрок может регенерировать оторванные конечности, если сможет каким-то образом съесть достаточно мяса. Это так и задумано? Сначала удалось восстановить левую руку, а потом и правую. Вот что мясо пещерных крыс животворящее делает!

>Можешь, кстати, пояснить мне немного за автоматическое тестирование?

Почему я? Я безыгорный движкопися-годотер, который все баги ловит с помощью print()...

>Стоит ли мне вкладываться в создание тестов для всего что есть в игре?

Я сомневаюсь, возможно ли покрыть тестами любые игровые ситуации. Игры характерны очень сложным поведением, поэтому автоматические тесты должны будут быть очень сложными... Тут важнее вопрос, достаточно ли независимы у тебя все системы. Если не контролировать архитектуру, любой проект рано или поздно превращается в лапшу, т.е. возникают нежелательные связи, которыми сложно управлять. Поэтому тщательно пересмотри свою архитектуру и сделай системы более независимыми, а после уже сможешь проверять баги в этих отдельных системах. Когда ты убедишься, что в отдельных системах багов нет, ты можешь подняться на абстракцию выше и искать баги в более общих системах. Изменяя какую-то систему, ты будешь искать баги только в ней, т.к. другие системы от неё не зависят и поэтому не могут сломаться, т.е. не придётся тестировать весь проект после изменения одной маленькой системы. Нужно ли писать автоматические тесты на уже протестированные и полностью независимые системы, которые ты больше не будешь изменять?

В частности, непонятно, как ты мог сломать систему меню, если у тебя управление менюшками должно быть в одной очень простой системе наивысшего уровня (Game), которая ставит почти всю игру на паузу, когда игрок открывает меню паузы. Т.е. чтобы сломать это поведение, ты должен был сломать эту простую высшую систему, и возникает вопрос, зачем ты в неё лез? Если же это не так, и поведение менюх разложено между ними, то это значит, что у тебя в коде лапша - неявные взаимосвязи между отдельными менюшками, которые не должны друг о друге знать. Вот распутаешь эту лапшу и никакие тесты будут не нужны (я утрирую, конечно, тесты могут пригодиться, например, при переходе на новую версию движка).

>юнитевских тестов

Вообще ничего о них не знаю.

>кот спавнится живым

У меня он тоже спавнился живым. Тот спавн без частей тела получился из-за какого-то бага, который ломает запуск новой игры. Т.е. после какого-то момента запуск новой игры спавнит персонажа без конечностей - только грудная клетка. Кстати, почему грудная клетка, а не голова? Было бы логичнее сделать голову корневым элементом, в частности если предполагается замена частей кибернетическими или магическими протезами.

>А на годот я не пойду

>Переход на новый движок еще год займет

После событий этого лета многие инди на юнити заинтересовались переходом на альтернативные движки, в частности Годо. Потом часто всплывали посты о том, как им понравился Годо и что они теперь будут делать игру на нём. На самом деле освоить Годо не так сложно после Юнити. Полностью портировать большую игру, наверное, всё-таки сложно, но начать осваивать несложно - концепции в основном те же самые. Тем более 2D, в Годо тебе не придётся мудрить с третьей осью, тут 2D полностью абстрагировано от 3D (как в SDL).

>>836325

>пониженный шанс попадания по небольшим частям с поправкой на подвижность. По голове должно быть сложнее попасть чем по торсу, а по ладони сложнее чем по голове.

Это всё очевидно даже тому, кто в игры никогда не играл и о настолках даже не слышал, лол. Проблема игрового баланса не в очевидных вещах вроде "по маленькой части тела сложнее попасть", а в конкретных числах - т.е. в коэффициентах формул. От этих чисел зависит то, победит игрок или проиграет и понравится ему играть или нет; будет ли победа интересной и будет ли проигрыш обидным. В частности, твоё "ладони сложнее попасть чем по голове" не так-то просто сбалансировать, потому что в ладони может лежать большое оружие и это оружие по логике игрока проще выбить из рук, чем попасть по голове. Но если игрок будет легко выбивать любое оружие, то битвы могут стать слишком простыми. А если попадание по рукам и голове будет слишком сложным, то мотивации целиться в них будет значительно меньше, ведь проткнуть мобу грудную клетку будет означать более быструю победу. Должен быть баланс, но его сложно рассчитать.

>>836339

>Видео не смотрел, из-за кликбейтного превью.

Зря, у Viva La Dirt League всегда очень качественные и очень смешные видео. Если тебя обижает надпись "D&D Logic", тогда рассматривай это видео как описание практически любой видеоигры - это именно в видеоиграх игрок может бегать с 1 хп и совершать очень сложные действия без каких-либо трудностей. В том видео просто описана уязвимость правил, в которых не написано, как нужно отыгрывать низкое здоровье персонажа, но по сути это справедливо для любой игры со шкалой здоровья.

>хитпоинты, поскольку ИРЛ это не так работает

Конечно, ИРЛ это не так работает, но хитпоинты можно приблизить к реализму, если подразумевать, что низкое число хитпоинтов означает высокий износ организма или жизненно важных органов. В твоих примерах случайный чих, вызывающий закупорку главных сосудов и поступления крови в мозг снимает 100 ХП мозгу, из-за чего ведёт к смерти, а в примере перестрелки слишком мелкие пули несмотря на их экспансивность попадали по малозначимым органам и поэтому условно снимали мало ХП, хотя и накладывали дебафф "кровотечение", поэтому позволяли действовать дальше несмотря на ранения. Алсо те люди были под баффом "адреналин", снимающий боль и увеличивающий производительность мышц и мозга несмотря на повреждения органов, логично? Это всё легко вписать в игровой мир, если постараться, просто большинство разработчиков не хотят усложнять баланс и без того сложного дизайна игры.

Однако ОП сам взял на себя ношу балансировать сложную игру, добавив индивидуальный износ разных частей тела. Ему однозначно нужно добавить изменение поведения персонажа при повреждении отдельных частей тела, иначе вся эта возня с индивидуальным износом будет абсолютно бесполезна. Какой смысл отрывать мобу ноги, если он и без них спокойно бегает? Хотя, какие ноги, тут у него одна грудная клетка без головы и конечностей спокойно бегает по карте, ведь ей нечем осознать, что она мертва (мысленно отыгрываю это как то, что строчка кода "func is_dead(): return not head" находится в голове моба, поэтому после отделения головы моб не понимает, что он мёртв, и продолжает вести себя как обычно)...

>хитпониты обозначают не просто раны, а комбинацию здоровья и моральной воли к сражению

Херня система. ИРЛ "моральная воля к сражению" не зависит от уровня здоровья. Может быть здоровый бугай, который трусливо бежит от любого сражения и визжит как девчонка от любого пореза, и может быть смертельно больной герой, закрывающий собой амбразуру, гранату или ещё что-то опасное. В фэнтези огромный голем по логике будет иметь много очков здоровья, но это не значит, что он очень сильно хочет тебя убить - он просто бродит по миру, в основном игнорируя любую живность, потому что создан из камней и собственного мышления не имеет. А у какого-нибудь хомячка-берсерка огромная воля к сражению несмотря на один хитпойнт (давится лапой любого животного крупнее крысы).

>почему у высокоуровневых персонажей намного больше хитпоинтов - они просто игнорируют мелкие порезы и ожоги.

Опять же херня, повышение здоровья очевидно означает укрепление организма какой-то магией, так что нанести урон становится сложнее. Если 1/100 = мелкий порез, то для раскаченного до 1000 ХП персонажа мелкий порез = 10 хп, а не 1 хп. Что он почувствует, зависит не от числа хп, а его болевого порога, а будет ли он игнорировать то, что он почувствует, зависит не от хп и не от болевого порога, а от болевой терпимости. ИРЛ у людей тоже очень разные уровни этих двух параметров - можно иметь низкий болевой порог и высокую терпимость, а можно иметь высокий болевой порог и низкую терпимость, но это всё не имеет отношения ни к здоровью, ни к воле к сражению.

>Например, в обычной гонке, если кто-то оторвался, с этим уже ничего не сделать

Это 100% ложь, ты в гонки вообще не играл? Во-первых, противники могут делать ошибки - если ты делаешь меньше ошибок, чем делают противники, ты постепенно их догоняешь. Во-вторых, если игра не против "призраков", есть возможность развернуть противника на 180 градусов, фактически выведя его из гонки на несколько секунд. Видел даже летсплеи, где игроку удавалось выйти на первое место после неудачного старта, то есть подняться с 16-го места на первое почти к концу гонки - и это без каких-либо бонусов и оружия, против реальных людей. Но если твой уровень игровых навыков значительно ниже противников, то ты, естественно, будешь допускать больше ошибок и постоянно отставать, а не догонять. ИИ противников в гонках настраивают на какой-то уровень игры игрока, и тебе просто не повезло, если этот уровень значительно выше твоего лучшего результата...

>>836403

>Поэтому я эту механику и убрал

Лол, а как же отрывание рук? Игрок без рук не сможет отбиться от противников. Мне уже несколько раз в твоей игре отрывали руки, после этого мобам остаётся только добить остаток игрока. Аналогично с мобами, что они против меня сделают без рук? Покусают?

>чем меньше хп, тем быстрее бегаешь. Но с точки зрения игрового мира это конечно полный абсурд.

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

ОП, сделай тайл спуска на следующий уровень более заметным и чтобы на него не падали предметы и кровь. Сейчас потратил 10 минут на поиск спуска и уже хотел писать отчёт о баге "нет спуска на следующий уровень", но обнаружил, что тайл спрятался за половинкой стены, на нём лежал арбалет и сверху ещё была кровь. Выглядело это как обычная каменная плита с мусором на ней, так что я даже не пытался на неё встать, не говоря уж о нажатии V. Алсо, зачем нажимать клавишу? Сделай спуск автоматическим, как в Pixel Dungeon. А мобам запрети вставать на эту клетку вообще, чтобы ничего на неё не дропали. Главное пофикси длительность загрузки, невыносимо ждать загрузки, в твоей игре не так уж много тайлов чтобы столько грузить.

>>836620

>принес ролик

Я принёс логик нелогичности дизайна игр, когда персонаж, едва цепляющийся за жизнь, действует точно так же, как полностью здоровый. "1 hp" (из 100) = ты не то что в инвалидной коляске, а вообще двигаться не можешь и лежишь под аппаратом жизнеобеспечения. А герои видеоигр спокойно бегают и выполняют любые задачи, только умирают с любого тычка.

>в других играх нужно делать так же

Ты потерял оригинальный контекст:

>Мы просто привыкли гонять с 1/100 ХП как ни в чём не бывало и не осознаём, насколько это нелогично с точки зрения игрового мира.

Я не говорил, что нужно обязательно сделать механику штрафа при низком здоровье, я говорил только что мы привыкли к тому, что персонаж на низком здоровье действует так же как на полном. Привыкли - значит, нам кажется неудобным или даже неиграбельным другое поведение персонажа. Но это не означает, что оно действительно неиграбельно. Ты просто должен действовать аккуратнее и не рисковать лишний раз. ИРЛ ты не будешь скакать как горный баран по скалам, если у тебя серьёзное кротечение, а попытаешься немедленно оказать себе первую помощь и обратиться к тем, кто может тебе помочь. А когда ты играешь, ты вместо оказания первой помощи персонажу продолжаешь сражаться или бегать по уровню, и возмущаешься, если игра своими механиками мешает тебе это делать. Просто нужно изменить отношение к игре и всё встанет на свои места.

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

>игроки тоже бросят игру и пойдут играть к другому мастеру, потому что у этого мастера не днд, а другая игра.

Лол. Если не ошибаюсь, это называется "домашние правила" и выбираются они под вкусы конкретных участников игры. Если им что-то не нравится, они меняют правила, а не мастера, потому что мастер их друг.

В любом случае, правила компьютерной игры сложно изменить под себя, поэтому в случае компьютерной игры игрок действительно просто уйдёт.

>>836538

>мышка

Так вот оно что...

А приближение скачками было из за пиксель-перфект камеры. В ней зум может только определенные значения принимать. Ну да не важно, я ее убрал уже.

>грудная клетка

Ну и жесть. То есть моб не сдох, но при этом все равно упал на пол как дроп. Это ж, блин, в двух соседних строчках происходит, как так...

>регенерировать оторванные конечности

О да! Да!
Наверно не самая очевидная механика, я понимаю.

>Тесты

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

>Как сломал менюинг?

когда радиальную менюху кодил. Сегодня все исправил как раз.

>Почему тело а не голова?

В основном это рудимент с тех времен когда анатомия была вообще у всех предметов. Тело то у всего есть, а голова - не обязательно.
Ну и еще, таким образом получается, что все другие части крепятся к корню через одно соединение. Ну типа глубина иерархии всего 1. Это удобно.

>Годот

А чем годот выигрывает у юнити в плане... сложившейся политической ситуации? Я просто не особо в курсе.
Так или иначе, я потратил уйму времени даже не на изучение самого юнити а на изучение unity DOTS, на котором все и сделано. Теперь чтобы эту игру перенести на что-то другое я даже не знаю сколько времени нужно потратить. Проще уж другой проект начать.
Но так, да, мне нравится в 2д работать. Может когда-нибудь и годо тоже изучу, но уже явно что-то другое буду на нем делать.