Привет, тут я выкладываю разговорные видео по геймдизайну в основном инди рогаликов, с упором на разбор механик. А так потихоньку делаю игру и делюсь наработками и мыслями. В геймдеве с 2019, начинал с настолок, в видео геймдеве, то есть в программировании с 3 апреля 2024. В играх ценю: потенциал на генерацию бесконечного количества уникальных ситуаций, творение собственных билдов, случайную генерацию окружения, субъектов, предметов и сюжета, шахматное решение задач, возможность изменения каждого тайла или пикселя, крафт в перемешку с генерацией для создания уникальных предметов, пошаговые бои или платформинг, сложность, атмосферность, большой лор. Игры вдохновение: что именно: генерация 1 мира, 1* предметов, 2 боевка, мувмент, 3 песочность, 4 система билдов, 5 крафт, 6 атмосфера, 7 оформление. Worms 1,2,3, spelunky 1,2,3, 7, terraria 2,3. Poe 1*,4, 5, 6, 7, OriginalSin: 1*, 2, NwN2(D&D): 4,6,7, battle brathers: 1, 1*, 2, 7, portal: 2, 6, 7, sacred: 6, 7, rf online: 2, 5, 6, 7
Ты молодец с кодом все супер. Подключи систему контроля версий, в студии это делается прям на коленке, защищаешься на случае утраты кода, сохраняя на удаленном репозитории, новые задачи ставишь там же, отщипываешь ветки, мержишь с мастером, откатываешься в случае непонравившегося кода. Мега удобно.
Что если при подборе предмета до его удаления создавать строку лога в виде текста? Тогда можно взять данные из самого объекта. Хранить и выводить готовые строки.
Я так и сделал. Но это данная многосоставная, то есть информация о фоне, и цвете текста в разных его частях. И раньше чтобы не заморачиваться я прост копировал ее напрямую с объекта, но как объект исчезал, лог переставал работать, поэтому я сделал, что лог генерирует этот текст на основе тип лога и сохраняет всю информацию в себе.
@@System-Chaos если хранить в виде текста, то он не должен перестать работать. Один раз создаётся строка тип string, и можно её выводить сколько хочешь без объектов. Данные с объекта нужны только в момент создания строки, это можно сделать до уничтожения объекта.
Я думаю стоит почитать еще про анбоксинги, боксинги. Очереди, кстати, что выше предложили, тоже. Ну и базовые алгоритмы. Конечно, в коде, без фундаменталки, их не придумать. Но, можно немного времени потратить на блок схемы, булевую алгебру и алгоритмику, самую простую. Это глобально поможет во всем. И чуть позже - научиться, на глаз, определять, что по сложности алгоритма. Это, правда, довольно важно. Раз уж пришел к решению все самостоятельно познавать, не использовать движки, готовые решения и тд. Вообще, можно просто в документации открыть и почитать про стринги, билдеры, массивы, дин. массивы, коллекции все, что есть итд. В целом, там все написано (прям провалиться в метод и посмотреть, как он написан) *я не советую упороться в книжку ) просто ты столкнулся с некоторым ноледж-волом, и его стоит проломать чуток
Спасибо за напутствие, гляну про то что ты написал. Я планирую использовать движку, и готовые решения по максимому, но пока вот так вот решил идти, чтобы прокачать скил писания алгоритмов.
@@System-Chaos "грокаем алкоритмы" + какие супер начальные посмотреть можно на просторах. Оч простым языком описаны некоторые подходы в книжке, не заумная, осилить можно успер быстро первую часть, а вторую по мере стокновения с задачами. Вообще - любые книжки/статьи/видосы - хороши только когда тебе это нужно и ты с этим на практике стокнулся. Иначе - в 80% - просто потеря времени )
Вместо массива для хранения логов можно использовать Queue (очередь). Это удобнее, потому что: * Есть метод Dequeue(), чтобы убрать предмет из конца очереди * Есть метод Enqueue(), чтобы добавить предмет в её начало. Это проще, чем пересоздавать массив с новой ёмкостью, переставлять все элементы сразу, или делать второй массив, описывающий порядок чтения
у меня один массив логов. у меня массив объектов класса. Я не пересоздаю массив, самый новый лог записывается поверх самого старого если массив переполнен
Dequeue удаляет из начала очереди, Enqueue добавляет в конец очереди. Этот контейнер не подходит, так как автор перезаписывает самый старый лог новым. Он же отображается на самом верху. Идеальный вариант либо массив либо List, любую текущую ячейку для записи можно определять как current % maxLogCount, переменная current всегда показывает текущий ид лога. Промотка немного посложнее, нужно анализировать границы массива/листа. В массиве доступ за O(1), никаких удалений автор не использует просто перетирание памяти.
Я бы рекомендовал использовать *ncurses* или иные кросплатформеные решения для отрисовки *TUI*. Обычные вызовы IO слишком медленные, особенно для цветной отрисовки. Хотя проект особо не позицинируется как что-то в Real-Time.
Зря тратишь время на "мучения" с консольным приложением. Переходи на UNITY. На графоний там тоже можно забить, сделать примитивную тайловую систему и заниматься сутью игрового процесса, но всё же с картинками.
для большей читабельности кода не надо команды в одну строку писать. одна команда - одна строка. то же самое к ифам относиться если тело условия содержит больше одной команды - блок лучше писать на новой строке. и если одна команда под условием - тоже на новой строке. Для 2 месяцев обучения очень хороший прогресс. но над стилистикой надо поработать. Есть рекомендации по оформлению кода для разных языков. Стандарта как такового не существует, но рекомендации есть. Большинство их придерживается в той или иной мере, в зависимости от требований команды. Но в любом случае код должен быть максимально читабельным. это упростит дальнейшую работу.
я знаю, но я решил сделать так, чтобы игроки могли глазами просчитывать дистанцию) То есть шахматный геймплей. Если игра была как в оридижнал син, то там бы пришлось именно так)
@@System-Chaos Более точный вариант, возвращающий double: Math.Sqrt(double number). Более простой и быстрый, работающий только с целыми числами: A ^ 0.5f
Прочность стен не интуитивно понятна, думаю, можно сделать её проще к пониманию такими методами: Вариант 1: Сделать разные материалы горной породы и сделать блокам свойство соотношения видов, после чего генерировать породы как свободный градиент. Плюсы: При визуализации пород можно сильно улучшить графику. К породам можно привязать особенности генерации. Минусы: Может замедлить генерацию карты Вариант 2: Прочность зависит от окружения камня. Типа, +3 к прочности за каждую прилегающую стену, +5 к прочности за каждый кристалл в прилегающей стене и т.п. Плюсы: Игрок получает способ управления характеристиками и может заранее их определять. Систему можно использовать для разных врагов или препятствий, которые также воздействуют на камни. Минусы: менее рандомно
нравится подход) прикольно да, но у меня бетон))) и он будет один) из-за лора)я его даже назвал "поверхностная материя" и "твердая материя" так-как этот мир это абстракция... условно сон в которым ты спишь а во круг сплошные голые стены) Но твоя идея реальна крутая, возможно такие сложные взаимодействия я сделаю в следующем проекте, а пока вот хочу сделать попростому, но твоя система реально интересная, особенно влияние прочности в зависимости соседних блоков. В теории в моей игре, я больше склонюсь к такому геймплею... есть какой-то предмет интерактивный, который дарует в радиусе блоком +100 к броне, но чтобы разрушить этот предмет надо ударить опр типом урона или использовать стоящие много стамины умение. Но я думаю, что да, блоки влияющие на другие блоки это будет прям база в этой игре)
9:56 ну, делать Move через string - это глупо. В System.Numerics есть структура Vector2. По сути, это просто две координаты а одной упаковке, но как упрощает процессы! Векторы можно слогать и вычитать сразу. Если пугает тип координат float, то можно создать собственную структуру вектора. Для того, чтобы с ней можно было проводить математические операции без методов, можно использовать explicit operator. В общем, главное, чтобы не через string, потому что для каждый уникальный сценарий придётся прописать отдельно
через неделю, 2 месяца как начал изучать код. Этот выпуск как-то затянут, но это потому что дофига всего, сделано было, или я просто подустал и не смог более компактно все объяснять, вообщем как есть, так есть.
Посмотрел описание канала. Могу посоветовать для ознакомления следующие игры: 1) Nethack. Один из наиболее известных рогаликов. Примечателен большим разнообразием механик, в сочетании с процедурной генерацией, что как следствие даёт огромное разнообразие игровых случаев и поворотов (часто забавных), возможность тактически-творческого (шахматного) подхода к решению, и почти бесконечную реиграбельность. 2) Amayui Castle Master. Если не воротит от аниме. И там есть необязательный 18+ который можно пропускать. Примечателен тактической (шахматной) пошаговой боёвкой, есть крафт и градостроительство. Мне нравится как ты рассказываешь. Я кстати тоже увлекаюсь подобным (рогалики, песочницы, процедурная генерация, взаимодействие с окружением, тактика, билды). Изучаю всё что с этим связано. Делаю на C++, правда начал раньше чем ты. И больше в направлении RPG и выживание, ближе к классическим рогаликам. Особенно доставляет эстетическое удовольствие вид подземелий моего самопального генератора! Не знаю стОит ли снимать об этом видео, я не такой хороший рассказчик. Если интересно, могу где-нибудь поделиться скринами.
По поводу критов. Это механика для боёвки. Одна из возможных тактик на выбор игроку. Сам по себе рандомный урон от крита конечно бесполезен. Его надо рассматривать в контексте применения. Должны быть враги которые уязвимы к критам, а другие с сопр. критам. Против первых криты это лучшая тактика, вторым наоборот. Смысл тот же что и с другими боевыми механиками (физ/маг урон/защиты, разные стихии/типы урона и сопр./уязв. им, меткость/уворот, +%урон/%сопр. урону, и т.д.). Ещё могут быть ряд механик условием которых является крит: оглушение при крите, кровотечение, восст. себе части ОЗ от урона (вампирик), вероятность мгновенно убить цель и т.д. Чтобы делать разные комбо и билды. Пока что у тебя не вижу выраженной боёвки, хотя ты упоминал про наличие врагов и боссов.
Смотри, криты это круто, но вопрос в другом. А потянет ли геймдизайнер баланс, если все что дает крит, достигается более простыми методами, где проще балансировать игру. Аналогия вместо крита: шанс оглушения от дробящего урона, кровотечение от режущего. Враги имеют уязвимость к огню или сопротивление к холоду, и в отличии от критов, это балансировать будет намного проще, ибо крит это нет тип урона а модификатор любого урона. Единственное что дает крит, это эффект вау, именно из-за этого хочется его добавить, но если учесть что игра меньше про рандом в боях и больше за тактику, скорее всего в этом проект критов не будет, дабы сэкономить нервы и время. Дак какая боевка, я пока учусь вообще что-либо делать, например чтобы герой ходил по карте, и например не мог идти свкозь стены, хотя я уже это сделал))) В будущих проектах будет большая ролевая система, этот проект пока крайне с упрощенной боевкой будет.
@@System-Chaos проще понять крит можно если рассматривать его именно как тип урона 😃 Например, маги бьют огнём/льдом, колдуны тьмой, ловкачи ближнего боя - критами, стрелки с меткостью - против врагов с уворотом, воин с высокой Силой - против врагов с высокой Защитой (урон = Сила - Защита цели). Суть та же, бывают враги с сопр./уязв. каждому из них. Игрок делает билд с упором на одну из этих возможностей с целью максимизировать боеспособность. Или выбирает более подходящую из нескольких под каждый случай. Может смущать только рандомность урона, но это надо рассматривать статистически. Например есть 25% вероятность крита 2х. Это в среднем равнозначно +25% урона. По врагам с х2 вероятности крита, 50% х2 = +50% урона. По врагам с неуязв. криту ничего не даст. Но опять же, это нужно для боёвки. Тебе пока наверно нет смысла заморачиваться.
@@DobinSergei в моем настолке я крит иначе рассматривал. А это будущая компьютерная игра. Объясню, там нет классов, ты его собираешь из активных навыков и прокачки. Крит есть у всего, у магий и ближнего боя и тд. По моей задумки, крит там был именно как имитация попадания в органы. И там подучается что крит это именно нанесения сильной травмы и там начинался кошмар. Я делал с упором в реализм, и для этого изучал настоящие средневековые бои, биологию и много всего еще. И по факту шанс и урон крита там привязывался к типу урона, а тип урона привязывался исключительно к типу атаки оружия, одно оружие могло бить в зависимости от типа атки, разными уронами. Копье только колоть, а меч и рубить и колоть и резать и тд. Тип урона колющий был сильный шанс крита, но урон от него не самый выский. По мимо крита там был останавливающий эффект и шанс заражения. В теории колющий урон можно было нанести магией, например ледяной стрелой условно. Поэтому в моей игре крит был никак математическая модель, а как имитация нанесения урона по внутренним органам и был привязан ко всем типам уронов и атак.
@@System-Chaos когда крит влияет на любой урон, это же просто ещё один модификатор урона. Тогда он используется в классах или билдах на максимизацию урона. Чем больше множителей, даже небольших, тем больше даёт каждый из них. У меня в игре многое упрощено и условно, пришлось пожертвовать реализмом ради геймплея. Критуют только действия по одной цели, при которых нужно точно целится. Суть та же, это поражение более уязвимых частей. Но если действие бьёт по области даже небольшой (все заклинания), то попадание поражает сразу всю цель, но не так сильно по уязвимым частям как прицельные. Потому не критует. И ледяная стрела применяет именно кровотечение 😃 Каждое заклинание урона применяет какое-то доп. действие помимо урона.
10:05 - спорное утверждение. В данном случае наоборот, довольно просто. Самые сложные процедурные генерации в рогаликах Dwarf Fortress и Caves of Qud. Советую ознакомиться, может заинтересует. И да, согласен что Айзик - не рогалик. Рогалик это Rogue-like, означает подобная игре Rogue. Это очень своеобразный геймплей. Если посмотреть на обе эти игры, между ними ничего общего кроме 2d графики с видом сверху.
имелось ввиду про роглайты, а не рогалики. Ибо щас в роглайтах пошла тенденция уже как лет 10, просто комнаты местами перебирать и это называется случайной генерацией. А спеланки это именно что раглайт с процедуркой по тайлам а не просто местами комнаты перебирает, и он выделяется на фоне масс. Я это хотел сказать, понятное дело что дварфы и рогалики классические там жесть с точки зрения механик, генерации и тд) Я и не спорю)
@@System-Chaos а ещё некоторые знатоки рогаликов замечают что есть тенденция многие инди-2d называть рогаликами. Комнаты случайно перебирать это конечно не процедурная генерация. Эта механика ещё пошла из Зельды. Но видимо она работает нормально для своей задачи, хоть и простая. Это просто декорация, фон для основного геймплея. А генерация сложных карт это для игр которые больше на исследование мира и собирательство.
@@DobinSergei генерация, это для создания бесконечного количества уникальных ситуаций вне зависимости от жанра(мое мнение). Если правильно делать генерацию змейка и тетрис может стать супер интересной игрой, но увы никто не заморачивается над глубиной генерации, а только поверхностно. Не спорю, в играх на исследования генерация играет ключевую роль. Но лично на мой вкус, генерация играет ключевую роль в любом синглплеере, где я хочу не просто пройти а играть в игру на долгосрок. Я в детсве фанател по вормсу исключительно изза генерации_)
8:57 ну если время ограничено то там заведомо бесполезно долбить один блок 100 ударами. Хотя по механике это возможно, игрок не будет так делать. В чём тогда проблема?
смотри, я вобщем в любом случае сделаю костыль, чтобы стенки бились только ресурсами (бомбы, кирки) Время оно условно, имелось ввиду ходы. Проблема в том, чтобы игрок не гриндил кристаллы с блоков, но при этом чтобы карта могла разрушаться атаками игрока. Но в итоге я прихожу к мысли, чтобы не делать никакого времени, просто сделаю костылем как описал выше, и запрещу карту разрушать игроку с ударом с руки (с оружки)
Спасибо, что снимаешь ролики и делишься своим опытом! Ты вдохновил меня снова сесть за разработку игры. Раньше я постоянно упиралась в графику, так как совершенно не умею рисовать даже пиксель арт, а ты показал обходной путь с символами. Да, это не так красиво, но вполне понятно и рабочая схема. К тому же мне не нравится сидеть за левел дизайном. Я раньше очень боялась лезть в генерацию уровней, но теперь задумалась над тем, чтобы все же разобраться)
Спасибо, да так и есть, рад что помогаю. Графика, музыка, сюжет, програмирование по моему мнению это все косвенно относится к играм, хотя тоже являются важными составляющими. Создание механик, баланс механик, продумывая алгоритмов вот что ценно лично для меня! Графику не делаю так-как сейчас хочу с C# разобраться и не отвлекаться, ну в будущем буду делать пиксель арт и музыку, с помощью нейросеток (тебе также советую если не умеешь рисовать) На счет сложности: вопрос в том, насколько сильно погружаешься в тему, чем глубже тем сложнее, и этот выбор личный. А такая примитивная графика она просто показывает истинный скил геймдизайна, и позволяет расти как геймдизайнер, но в итоге надо делать с графикой иначе проект останется в тенях андеграунда.
С интересом наблюдаю как ты делаешь свой проект. Пока всё нравится. Жду освоение работы с файлами и проработку графической части, включающей в себя интерфейс.
Спасибо, я думаю что графика будет уже на unity, и на новом проекте. Но если смогу и на этот проект наложить графику без unity вот тут, будет не плохо, так и сделаю, но я даже не знаю если ли такая возможность, сделать это особо не меняя код.
Насчёт таймера на уровне, я бы предпочтел полностью избавиться от такой идеии и сделать так чтобы игра была на истощение. Тобиж вместо привычного таймера, будут монстры которые появляются на уровне и с каждым своим новым появлением они будут становиться все сильнее и сильнее, а их будет все больше и больше. Поэтому мы не ставим игрока в ограниченные рамки, но и игрок не может надолго задерживаться на уровне.
Про слои. Вообще, оба варианта валидны. Что в 3 слоя (4), что в один. Вопрос подхода и реализации. Решается и там и там, практически любые хотелки. Слои - каеф, но также ограничивают сложность механик, без дополнительных подпорок. Возможно, стоит слои сделать более абстрактными. Понимаю, может звучать также, но есть поверхность/сюрфейс (пол в данном случае), обстаклы (разрушаемые, не разрушаемые) и в эту логику входят все слои (включая условный aiшник) Ибо как только появится идея сделать много вертикальных уровней, конкретно связанных в реальное псевдо 3д пространство - начнутся проблемы. Можно почитать статьи братьев, авторов Дварф Фортресс, не могу с ходу найти ссылку, но это можно подгуглить. Как и почему и что они делали, когда пришла идея сделать реальные уровни в игре (не просто этаж 1 этаж 2, а именно полноценно связные уровни) И спасибо за поправку про 80% поверхностной базы. Важно это понимать :) А то побухтеть уже захотелось :D
Дополню. Если на этом этапе чуть развязать себе руки - можно будет прикрутить реальные уровни (ось Z условную) которая будет работать и понимать, что если ты убрал пол и под ним нет пола - ты пролетел 2 уровня, а не один. или если ты взорвал потолок (пол верхнего уровня) а там была жидкость - она пролилась. Ну, это сильно сложнее, но мелкие задатки сейчас - победа потом. После нескольких видео, я подозреваю, что механы у вас будут обрастать сложностью ровно с такой же скоростью, как будут лутаться новые знания по предметам, которыми вы заниматесь :)
И еще один ззы. Подсмотрите как сделать простенькие парсеры. Как сделать хороший и простой (пусть за такие штуки и ругают часто) дата класс, чтоб хранить конфиг, для начала и можно было обращаться к этим данным отовсюду из проекта. Смысл в том, что из гугл табличек все циферки будете забирать и не останется никаких магических цифр в коде (кроме конст, которые тоже, по хорошему надо вынсить, но это уже само по себе должно произойти) и убрать хардкодные строки типа "герой". Иначе это ружье бондарчука потом не то что стрельнет, а взорвется.
И ластовый ззы. Никакие видосы не помогут. Книги и даже бот гпт (хотя он кратно ускоряет процесс обучения, если правильно пользоваться и есть программа обучения). Ничего, кроме практики. Пока ты на практике не начнешь это делать и решать эти "проблемы" - теория бесполезна. Этот принцип будет работать всегда. Теории надо знать много, и принципы ООП вы будете еще очень долго осознавать :) Потом минимальные паттерны проектирования, потом будете изобретать свой велосипед (тот же сингл тон) А потом все, снова, перевернется с ног на голову, а потом, возможно, вообще поймете, что дата ориентированный подход сильно круче, ну или в принципе процедурное мышление покажется ближе. И так до бесконечности. Чем больше знаешь - тем меньше знаешь. Но все это ничего не стоит, если бОльшую часть времени вы не практикуете. Это практический навык, с прикладным теоретическим (больше математическим) навыком.
уровни 2d на прохождения, не будет как в дварфах даже близко, игра изначально про 2d и прохождение уровней. Было верно подмечено: слои исключительно для удобства реализации, абстрактные слои:, это скорее слой кристаллов и слой юнитов, А слои блоков они конкретные, для реализации разрушаемого пола и стен под которыми пол и под полом ямы или что-то еще, в видео объяснил.
@@nubowski уххх это жестко) я вот так не буду делать, но классная идея, я хочу больше уйти в генерацию логических цепочек для открытия входа, и генерацию монстров чтобы у них случайно генерировались умения исходя от их принадлежности классу. Ну и проработку ролевой системы. и еще в механики взаимодействия разных блоков чтобы это создавала уникальный геймплей в зависимости от их местоположения, ловушка стреляет ее стрела попадает в взрывчатку та ударной волной убивает врага и отбивает бочку которая активирует рычаг, который активирует ловушку убивая еще врагов)))) а этот враг взрывается, и его ударная волна толкает куб который отражает лазер активирующий кнопку для входа, это как пример возможного рандома для уникальных случайных взаимодействий
Отлично получается! Хотел бы добавить, что ты можешь делиться сложными моментами в программировании или идеями на канале, ведь ты повышаешь планку качества и количества с каждой серией. Важно не перегореть. Что касается ООП и SOLID, не стоит зацикливаться; используй то, что действительно удобно и понятно тебе, ведь эти концепции созданы для работы в команде с обезьянами которые норовят все поломать.
Спасибо от души) учту на счет сложных моментов, они то забываются что там было сложно, попробую записывать. На счет перегореть, такой опыт за плечами из разных сфер жизни, что съел собаку на этом. У меня какой подход, делай пока нравится, а если не нравится, то перестань делать и начни делать по новому чтобы нравилось (это кстати самое сложное), и обычно при таком подходе перегорание не наступает, усталость только. Как я понял, перегорание это сигналл на подсознании что шансы на успех меньше чем затраченные силы... например, я когда делал настолку усложняя механики, у меня наступала полное не желание работать потому что я бесознательно понимало что я иду неверным путем, а в сознание понять этого не мог... Ну есть еще и перетрен умственный, тема интересная, может обсужу ее в видео чуть подробнее.
@@System-Chaos Усталость это тоже один из неприятных моментов по 12 часов работать классно, но после этого нужно много отдыхать. А в целом не могу не согласиться пока в кайф делай.
Надо срочно, уже сейчас, уходить от строковых названий типа "большой алмаз" в коде и переставать сравнивать строки. Надо создавать dictionary или enum или что там в си шарпе для этого и все кодить юзая только подсказки редактора и в итоге это будет что-то в духе GEMS.Almaz == block.currentType. В дальнейшем это сбережет тебе дни, потому что ошибаться в строках ты будешь постоянно, это нормально. А заменив на словари и подобное ide будет тебе давать на выбор только то, что есть. Второе, что надо иметь ввиду, это то что всякие списки типа шансов выпадения и прочие данные типа табличных - лучше хранить в файликах типа json или csv и потом считывать их прямо в коде. Это избавит код от излишнего мусора, плюс в том же excel с данными этими работать проще, да и менять баланс можно, не заходя в код.
Enum удобнее, что-то я сразу не докатило до этого, я не ошибаюсь, потому что я не пишу слова а копирую их. С файловой системой пока до этого еще не дошел буду иметь ввиду, спасибо)
30:06 Ну, прям категоричный туман войны, думаю, будет подпорчивать стратегический геймплей. Его можно использовать на подробности, типа, есть кристаллы, но какие именно не известно, или на перемещающихся врагов, но про основные точки интереса на уровне знать просто жизненно необходимо.
в таком случае можно сделать туман войны врагам, например подсвечивать их знаками "?" и какие-то подбираемые предметы, до тех пор пока не вошел в их радиус, хотя это тоже может подпорчивать тактику, если учитываем что тактика начинается с первого хода, я об этом подумаю еще. В любом случае умный курсор выдающий подробную информацию о характерстиках объектов будет работать только в радиусе 5-8 клеток от героя.
20:51 Вообще, можно было использовать Math.Min(maxLevel,Math.Max(minLevel, value)). Я не уверен, будет ли ущерб, или прирост к оптимизации, но как минимум, код станет проще.
Можно сделать что углубление это укрытие от дальних атак если углубление равно 3 связанные клетки и меньше, потому что если ямы будут размером 10 на 10, будет нелогично что они работают как укрытие, А вот как можно: яма это укрытие когда герой касается стенки с неукрытием. И выводить статус с боку вы в окопе, +25% уворота от дальних атак, и -25% от ближних атак)
Момент про проблему об уроне. Я мог бы решить ее путем внедрения запрета о разрушении блока, или сделать штраф в виде отнятия стамины за удар по блоку, но это по факту костыль, А я хочу сделать чтобы в игре были законы в которых игрок выживает и в них нету всяких надстроек, чтобы все было прозрачно, например твердый блок это не блок который нельзя сломать, а это блок 200% защитой, то есть у всего должно быть объяснение на уровне самих механик, а не на уровне разработчик так решил. Отведенное время (шаги) это не костыль, это фундамент, который создает челендж, потому что без времени можно гриндом брать игру. Объясню еще на примере. У нас есть взрывчатка, она должна разрушать твердые блоки у которых много брони и здоровья, но тогда она будет убивать боссов и сильных врагов, костыль это сделать врагам иммунитет к взрывчаткам, или какой-то спец тип защиты от взрывчаток, а вот не костыль, а оформление в рамках законов игры, сделать у взрывчаток большой урон но не гипер большой и добавить высокое пробитие брони, как раз у блоков очень высокий показатель защиты, если правильно подогнать цифры, взрывчатка будет хорошо рушить блоки и не ваншотить всех и вся, а просто наносить достаточно сильный урон.
Залипать на самом деле нечего. Карта совершенно рандомная мешанина пикселей. Спасает (частично) только очень мелкий масштаб. Это структурно не напоминает ни один возможный биом (лес, пещеры, искусственные сооружения), и не имеет ни какой внутренней логики. Для пещер леса и прочей природы можно использовать алгоритмы на основе клеточных автоматов. Для сооружений можно генерировать сразу комнаты случайного размера, добавляя новые к одной из существующих со случайной стороны и соединяя их проходами. Так все комнаты будут естественно соединены, не будет полностью изолированных и недоступных. И будет выглядеть так как будто осмысленно построенное подземелье. А если использовать бинарные древа, то будут получаться очень правдоподобно выглядящие подземелья с симметричными частями.
Тут еще дело в геймплее, и как ты подметил в минилистичности карты, и мне как раз нужна была мешанина причем для этого биома особенно, его название "непонятие". То есть как генерировать логические пещеры я знаю, уже смотрел алгоритмы, но я хотел сделать ближе к полному хаосу и не хотел делать как обычно это в рогаликах, это будет потом, возможно в другом биоме
Есть ещё распространенный метод генерации чего угодно, который обобщенно называют L-System. Метод основан на правилах. Можно найти разные онлайн генераторы по данным правилам. На основе этой идеи можно придумать не только детерменированные, но и хаотичные генераторы. Плюс в том, что можно сделать некие правила генерации и удобно их записывать, а алгоритм генерации будет работать на основании удобно и просто записанных правил, при этом правила можно будет легко менять и усложнять, не меняя обрабатывающий алгоритм. Есть понятный ролик по этой теме "Unity Procedural Town Tutorial Ep3 T theory of L-System"
Посоветовал бы все числа поместить в константы. Потому что пока только начинаешь и погружён в код, все числа вроде бы понятны. Но через неделю, месяц, полгода уже просто магические числа. Константы как имена переменных и функций будут помогать ориентироваться
@System-Chaos у нас на работе договорённость использовать без констант только 0 и 1. А ещё деление на два, так как это означает половина. И запись типа DOT_SIZE / 2 будет очень читаемо, что это именно половина размера точки. Вот если делить на любое другое число, там уже нужна константа, чтобы было понятно что за число такое. И ещё обратил внимание текст так же используется везде зардкодом. Его хорошо бы сразу либо в ресурсы, ну либо в те же константы. Вот например слово пространство много раз повторяется 7:40, если потом вдруг захочешь поменять это слово, то придётся во всех местах менять. В общем базовые принципы) А так очень круто получается! Мне даже самому захотелось что-нибудь подобное написать на досуге сначала на андроид, а потом расширить на мултиплатформу
я от того видео ушел вперед на 20 часов изучение) Поэтому это уже переписалось частично и будет переписываться ближайшее время дальше, я там писал код понятия не имея что такое классы. По факту я там просто тестил свои полученные знания.
Немного забегая вперед, поскольку генератор уже достаточно крутой имеет смысл держать всю информацию в удобной форме. Идеально это двумерный массив классов Cell, класс Cell может быть абстрактным или интерфейсным, то есть грубо говоря мы определяем просто класс, но не говорим, а какого вида это ячейка проходимая или нет, это будет зависить от генератора, который создаст нужный new конкретного конструктора и тогда уже в дело будет вступать полиморфизм в зависимости от класса например метод Draw отрисует ячейку по своему, это тема ООП. Про enum-ы тут уже сказали, добавлю, что это очень удобная штука, выступает как идентификатор - по которому можно переходить как по индексу массива, так и можешь извлечь прямо строку как назвал ее в самом enum написав так myEnum.Value.ToString(), где myEnum тип Enum-а, Value содержимое. Value может быть назван по русски, тогда при вызове метода ToString() получишь ее строковое представление, экономия данных + полезные идентификаторы.
Прикольно, удивительный прогресс за месяц )) Рекомендую познакомиться со структурой данной стек, если на этапе генерации ты хочешь вернуться к тому месту где например на карте развилка, прорисовал комнату - возвращаешься к запомненной развилке x,y координаты двемерного массива и погнал дальше рандомить ))
Спасибо, на самом деле, прогресс медленный, потому что я очень мало изучал, и много писал при минимум знаний, сейчас погружен в изучение, пока структуры, системы, энамы не пройду, то есть ооп, продолжать не буду, и да я уже изучил out ref in это как раз к той теме что ты пишешь про стэки и кучи. Кстати спасибо за идею, что да, таким образом можно делать более вдумчивые развилки. Но для моей игры и такой генератор тоже не плохо делает вещи, но я буду пробовать твою идею в будущем. Причем генератор будет для каждого биома свой. На видео про кристаллы есть прикрепленный диздок, там есть небольшие наброски про генерацию биомов.
Молодчина, подписался на тебя. Тоже люблю геймдев и рогалики со случайной генерацией. Тоже дам напутствие... Не начинай с очень сложного - случайная генерация тяжелая задача, луче подкачайся на реализации простых механик игры. Работаешь в геймдеве - подтягивай математику и геометрию очень нужна штука, алгоритмы A*-поиск кратчайших путей. Если очень хочется случайная генерация рекомендую углубиться в структуры данных типа графов - поиск в ширину, глубину, можешь посмотреть в сторону книг на английском - Maze generation for programmers. По C#, изучаешь методы - сосредоточься на простом, простая передача параметром, в большинстве случаев этого достаточно, перегрузки и шаблонность это все потом. Рекомендую изучить Linq, который будет перебирать для тебя то что ты попросишь, а ты параллельно будешь обрабатывать то что linq для тебя нашел ;) Первая непростая задача для тебя - а точнее классика для рогаликов! Реализация тумана войны, с продвижением игрока, карта будет ревеалиться. Можно усложнить, если входишь в темные места радиус открытых тайлов уменьшается, если есть рядом источник света наоборот.
