Спасибо, что снимаешь ролики и делишься своим опытом! Ты вдохновил меня снова сесть за разработку игры. Раньше я постоянно упиралась в графику, так как совершенно не умею рисовать даже пиксель арт, а ты показал обходной путь с символами. Да, это не так красиво, но вполне понятно и рабочая схема. К тому же мне не нравится сидеть за левел дизайном. Я раньше очень боялась лезть в генерацию уровней, но теперь задумалась над тем, чтобы все же разобраться)
Спасибо, да так и есть, рад что помогаю. Графика, музыка, сюжет, програмирование по моему мнению это все косвенно относится к играм, хотя тоже являются важными составляющими. Создание механик, баланс механик, продумывая алгоритмов вот что ценно лично для меня! Графику не делаю так-как сейчас хочу с C# разобраться и не отвлекаться, ну в будущем буду делать пиксель арт и музыку, с помощью нейросеток (тебе также советую если не умеешь рисовать) На счет сложности: вопрос в том, насколько сильно погружаешься в тему, чем глубже тем сложнее, и этот выбор личный. А такая примитивная графика она просто показывает истинный скил геймдизайна, и позволяет расти как геймдизайнер, но в итоге надо делать с графикой иначе проект останется в тенях андеграунда.
Насчёт таймера на уровне, я бы предпочтел полностью избавиться от такой идеии и сделать так чтобы игра была на истощение. Тобиж вместо привычного таймера, будут монстры которые появляются на уровне и с каждым своим новым появлением они будут становиться все сильнее и сильнее, а их будет все больше и больше. Поэтому мы не ставим игрока в ограниченные рамки, но и игрок не может надолго задерживаться на уровне.
Про слои. Вообще, оба варианта валидны. Что в 3 слоя (4), что в один. Вопрос подхода и реализации. Решается и там и там, практически любые хотелки. Слои - каеф, но также ограничивают сложность механик, без дополнительных подпорок. Возможно, стоит слои сделать более абстрактными. Понимаю, может звучать также, но есть поверхность/сюрфейс (пол в данном случае), обстаклы (разрушаемые, не разрушаемые) и в эту логику входят все слои (включая условный aiшник) Ибо как только появится идея сделать много вертикальных уровней, конкретно связанных в реальное псевдо 3д пространство - начнутся проблемы. Можно почитать статьи братьев, авторов Дварф Фортресс, не могу с ходу найти ссылку, но это можно подгуглить. Как и почему и что они делали, когда пришла идея сделать реальные уровни в игре (не просто этаж 1 этаж 2, а именно полноценно связные уровни) И спасибо за поправку про 80% поверхностной базы. Важно это понимать :) А то побухтеть уже захотелось :D
Дополню. Если на этом этапе чуть развязать себе руки - можно будет прикрутить реальные уровни (ось Z условную) которая будет работать и понимать, что если ты убрал пол и под ним нет пола - ты пролетел 2 уровня, а не один. или если ты взорвал потолок (пол верхнего уровня) а там была жидкость - она пролилась. Ну, это сильно сложнее, но мелкие задатки сейчас - победа потом. После нескольких видео, я подозреваю, что механы у вас будут обрастать сложностью ровно с такой же скоростью, как будут лутаться новые знания по предметам, которыми вы заниматесь :)
И еще один ззы. Подсмотрите как сделать простенькие парсеры. Как сделать хороший и простой (пусть за такие штуки и ругают часто) дата класс, чтоб хранить конфиг, для начала и можно было обращаться к этим данным отовсюду из проекта. Смысл в том, что из гугл табличек все циферки будете забирать и не останется никаких магических цифр в коде (кроме конст, которые тоже, по хорошему надо вынсить, но это уже само по себе должно произойти) и убрать хардкодные строки типа "герой". Иначе это ружье бондарчука потом не то что стрельнет, а взорвется.
И ластовый ззы. Никакие видосы не помогут. Книги и даже бот гпт (хотя он кратно ускоряет процесс обучения, если правильно пользоваться и есть программа обучения). Ничего, кроме практики. Пока ты на практике не начнешь это делать и решать эти "проблемы" - теория бесполезна. Этот принцип будет работать всегда. Теории надо знать много, и принципы ООП вы будете еще очень долго осознавать :) Потом минимальные паттерны проектирования, потом будете изобретать свой велосипед (тот же сингл тон) А потом все, снова, перевернется с ног на голову, а потом, возможно, вообще поймете, что дата ориентированный подход сильно круче, ну или в принципе процедурное мышление покажется ближе. И так до бесконечности. Чем больше знаешь - тем меньше знаешь. Но все это ничего не стоит, если бОльшую часть времени вы не практикуете. Это практический навык, с прикладным теоретическим (больше математическим) навыком.
уровни 2d на прохождения, не будет как в дварфах даже близко, игра изначально про 2d и прохождение уровней. Было верно подмечено: слои исключительно для удобства реализации, абстрактные слои:, это скорее слой кристаллов и слой юнитов, А слои блоков они конкретные, для реализации разрушаемого пола и стен под которыми пол и под полом ямы или что-то еще, в видео объяснил.
@@nubowski уххх это жестко) я вот так не буду делать, но классная идея, я хочу больше уйти в генерацию логических цепочек для открытия входа, и генерацию монстров чтобы у них случайно генерировались умения исходя от их принадлежности классу. Ну и проработку ролевой системы. и еще в механики взаимодействия разных блоков чтобы это создавала уникальный геймплей в зависимости от их местоположения, ловушка стреляет ее стрела попадает в взрывчатку та ударной волной убивает врага и отбивает бочку которая активирует рычаг, который активирует ловушку убивая еще врагов)))) а этот враг взрывается, и его ударная волна толкает куб который отражает лазер активирующий кнопку для входа, это как пример возможного рандома для уникальных случайных взаимодействий
Отлично получается! Хотел бы добавить, что ты можешь делиться сложными моментами в программировании или идеями на канале, ведь ты повышаешь планку качества и количества с каждой серией. Важно не перегореть. Что касается ООП и SOLID, не стоит зацикливаться; используй то, что действительно удобно и понятно тебе, ведь эти концепции созданы для работы в команде с обезьянами которые норовят все поломать.
Спасибо от души) учту на счет сложных моментов, они то забываются что там было сложно, попробую записывать. На счет перегореть, такой опыт за плечами из разных сфер жизни, что съел собаку на этом. У меня какой подход, делай пока нравится, а если не нравится, то перестань делать и начни делать по новому чтобы нравилось (это кстати самое сложное), и обычно при таком подходе перегорание не наступает, усталость только. Как я понял, перегорание это сигналл на подсознании что шансы на успех меньше чем затраченные силы... например, я когда делал настолку усложняя механики, у меня наступала полное не желание работать потому что я бесознательно понимало что я иду неверным путем, а в сознание понять этого не мог... Ну есть еще и перетрен умственный, тема интересная, может обсужу ее в видео чуть подробнее.
@@System-Chaos Усталость это тоже один из неприятных моментов по 12 часов работать классно, но после этого нужно много отдыхать. А в целом не могу не согласиться пока в кайф делай.
30:06 Ну, прям категоричный туман войны, думаю, будет подпорчивать стратегический геймплей. Его можно использовать на подробности, типа, есть кристаллы, но какие именно не известно, или на перемещающихся врагов, но про основные точки интереса на уровне знать просто жизненно необходимо.
в таком случае можно сделать туман войны врагам, например подсвечивать их знаками "?" и какие-то подбираемые предметы, до тех пор пока не вошел в их радиус, хотя это тоже может подпорчивать тактику, если учитываем что тактика начинается с первого хода, я об этом подумаю еще. В любом случае умный курсор выдающий подробную информацию о характерстиках объектов будет работать только в радиусе 5-8 клеток от героя.
20:51 Вообще, можно было использовать Math.Min(maxLevel,Math.Max(minLevel, value)). Я не уверен, будет ли ущерб, или прирост к оптимизации, но как минимум, код станет проще.
С интересом наблюдаю как ты делаешь свой проект. Пока всё нравится. Жду освоение работы с файлами и проработку графической части, включающей в себя интерфейс.
Спасибо, я думаю что графика будет уже на unity, и на новом проекте. Но если смогу и на этот проект наложить графику без unity вот тут, будет не плохо, так и сделаю, но я даже не знаю если ли такая возможность, сделать это особо не меняя код.
Момент про проблему об уроне. Я мог бы решить ее путем внедрения запрета о разрушении блока, или сделать штраф в виде отнятия стамины за удар по блоку, но это по факту костыль, А я хочу сделать чтобы в игре были законы в которых игрок выживает и в них нету всяких надстроек, чтобы все было прозрачно, например твердый блок это не блок который нельзя сломать, а это блок 200% защитой, то есть у всего должно быть объяснение на уровне самих механик, а не на уровне разработчик так решил. Отведенное время (шаги) это не костыль, это фундамент, который создает челендж, потому что без времени можно гриндом брать игру. Объясню еще на примере. У нас есть взрывчатка, она должна разрушать твердые блоки у которых много брони и здоровья, но тогда она будет убивать боссов и сильных врагов, костыль это сделать врагам иммунитет к взрывчаткам, или какой-то спец тип защиты от взрывчаток, а вот не костыль, а оформление в рамках законов игры, сделать у взрывчаток большой урон но не гипер большой и добавить высокое пробитие брони, как раз у блоков очень высокий показатель защиты, если правильно подогнать цифры, взрывчатка будет хорошо рушить блоки и не ваншотить всех и вся, а просто наносить достаточно сильный урон.
По поводу критов. Это механика для боёвки. Одна из возможных тактик на выбор игроку. Сам по себе рандомный урон от крита конечно бесполезен. Его надо рассматривать в контексте применения. Должны быть враги которые уязвимы к критам, а другие с сопр. критам. Против первых криты это лучшая тактика, вторым наоборот. Смысл тот же что и с другими боевыми механиками (физ/маг урон/защиты, разные стихии/типы урона и сопр./уязв. им, меткость/уворот, +%урон/%сопр. урону, и т.д.). Ещё могут быть ряд механик условием которых является крит: оглушение при крите, кровотечение, восст. себе части ОЗ от урона (вампирик), вероятность мгновенно убить цель и т.д. Чтобы делать разные комбо и билды. Пока что у тебя не вижу выраженной боёвки, хотя ты упоминал про наличие врагов и боссов.
Смотри, криты это круто, но вопрос в другом. А потянет ли геймдизайнер баланс, если все что дает крит, достигается более простыми методами, где проще балансировать игру. Аналогия вместо крита: шанс оглушения от дробящего урона, кровотечение от режущего. Враги имеют уязвимость к огню или сопротивление к холоду, и в отличии от критов, это балансировать будет намного проще, ибо крит это нет тип урона а модификатор любого урона. Единственное что дает крит, это эффект вау, именно из-за этого хочется его добавить, но если учесть что игра меньше про рандом в боях и больше за тактику, скорее всего в этом проект критов не будет, дабы сэкономить нервы и время. Дак какая боевка, я пока учусь вообще что-либо делать, например чтобы герой ходил по карте, и например не мог идти свкозь стены, хотя я уже это сделал))) В будущих проектах будет большая ролевая система, этот проект пока крайне с упрощенной боевкой будет.
@@System-Chaos проще понять крит можно если рассматривать его именно как тип урона 😃 Например, маги бьют огнём/льдом, колдуны тьмой, ловкачи ближнего боя - критами, стрелки с меткостью - против врагов с уворотом, воин с высокой Силой - против врагов с высокой Защитой (урон = Сила - Защита цели). Суть та же, бывают враги с сопр./уязв. каждому из них. Игрок делает билд с упором на одну из этих возможностей с целью максимизировать боеспособность. Или выбирает более подходящую из нескольких под каждый случай. Может смущать только рандомность урона, но это надо рассматривать статистически. Например есть 25% вероятность крита 2х. Это в среднем равнозначно +25% урона. По врагам с х2 вероятности крита, 50% х2 = +50% урона. По врагам с неуязв. криту ничего не даст. Но опять же, это нужно для боёвки. Тебе пока наверно нет смысла заморачиваться.
@@DobinSergei в моем настолке я крит иначе рассматривал. А это будущая компьютерная игра. Объясню, там нет классов, ты его собираешь из активных навыков и прокачки. Крит есть у всего, у магий и ближнего боя и тд. По моей задумки, крит там был именно как имитация попадания в органы. И там подучается что крит это именно нанесения сильной травмы и там начинался кошмар. Я делал с упором в реализм, и для этого изучал настоящие средневековые бои, биологию и много всего еще. И по факту шанс и урон крита там привязывался к типу урона, а тип урона привязывался исключительно к типу атаки оружия, одно оружие могло бить в зависимости от типа атки, разными уронами. Копье только колоть, а меч и рубить и колоть и резать и тд. Тип урона колющий был сильный шанс крита, но урон от него не самый выский. По мимо крита там был останавливающий эффект и шанс заражения. В теории колющий урон можно было нанести магией, например ледяной стрелой условно. Поэтому в моей игре крит был никак математическая модель, а как имитация нанесения урона по внутренним органам и был привязан ко всем типам уронов и атак.
@@System-Chaos когда крит влияет на любой урон, это же просто ещё один модификатор урона. Тогда он используется в классах или билдах на максимизацию урона. Чем больше множителей, даже небольших, тем больше даёт каждый из них. У меня в игре многое упрощено и условно, пришлось пожертвовать реализмом ради геймплея. Критуют только действия по одной цели, при которых нужно точно целится. Суть та же, это поражение более уязвимых частей. Но если действие бьёт по области даже небольшой (все заклинания), то попадание поражает сразу всю цель, но не так сильно по уязвимым частям как прицельные. Потому не критует. И ледяная стрела применяет именно кровотечение 😃 Каждое заклинание урона применяет какое-то доп. действие помимо урона.
8:57 ну если время ограничено то там заведомо бесполезно долбить один блок 100 ударами. Хотя по механике это возможно, игрок не будет так делать. В чём тогда проблема?
смотри, я вобщем в любом случае сделаю костыль, чтобы стенки бились только ресурсами (бомбы, кирки) Время оно условно, имелось ввиду ходы. Проблема в том, чтобы игрок не гриндил кристаллы с блоков, но при этом чтобы карта могла разрушаться атаками игрока. Но в итоге я прихожу к мысли, чтобы не делать никакого времени, просто сделаю костылем как описал выше, и запрещу карту разрушать игроку с ударом с руки (с оружки)
Можно сделать что углубление это укрытие от дальних атак если углубление равно 3 связанные клетки и меньше, потому что если ямы будут размером 10 на 10, будет нелогично что они работают как укрытие, А вот как можно: яма это укрытие когда герой касается стенки с неукрытием. И выводить статус с боку вы в окопе, +25% уворота от дальних атак, и -25% от ближних атак)
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
Спасибо, что снимаешь ролики и делишься своим опытом! Ты вдохновил меня снова сесть за разработку игры. Раньше я постоянно упиралась в графику, так как совершенно не умею рисовать даже пиксель арт, а ты показал обходной путь с символами. Да, это не так красиво, но вполне понятно и рабочая схема. К тому же мне не нравится сидеть за левел дизайном. Я раньше очень боялась лезть в генерацию уровней, но теперь задумалась над тем, чтобы все же разобраться)
Спасибо, да так и есть, рад что помогаю. Графика, музыка, сюжет, програмирование по моему мнению это все косвенно относится к играм, хотя тоже являются важными составляющими. Создание механик, баланс механик, продумывая алгоритмов вот что ценно лично для меня!
Графику не делаю так-как сейчас хочу с C# разобраться и не отвлекаться, ну в будущем буду делать пиксель арт и музыку, с помощью нейросеток (тебе также советую если не умеешь рисовать)
На счет сложности: вопрос в том, насколько сильно погружаешься в тему, чем глубже тем сложнее, и этот выбор личный.
А такая примитивная графика она просто показывает истинный скил геймдизайна, и позволяет расти как геймдизайнер, но в итоге надо делать с графикой иначе проект останется в тенях андеграунда.
Насчёт таймера на уровне, я бы предпочтел полностью избавиться от такой идеии и сделать так чтобы игра была на истощение. Тобиж вместо привычного таймера, будут монстры которые появляются на уровне и с каждым своим новым появлением они будут становиться все сильнее и сильнее, а их будет все больше и больше. Поэтому мы не ставим игрока в ограниченные рамки, но и игрок не может надолго задерживаться на уровне.
тоже хорошая идея, как вариант, может быть так и сделаю. Назовем это условно уровень проклятия.
Про слои. Вообще, оба варианта валидны. Что в 3 слоя (4), что в один. Вопрос подхода и реализации. Решается и там и там, практически любые хотелки.
Слои - каеф, но также ограничивают сложность механик, без дополнительных подпорок. Возможно, стоит слои сделать более абстрактными. Понимаю, может звучать также, но есть поверхность/сюрфейс (пол в данном случае), обстаклы (разрушаемые, не разрушаемые) и в эту логику входят все слои (включая условный aiшник)
Ибо как только появится идея сделать много вертикальных уровней, конкретно связанных в реальное псевдо 3д пространство - начнутся проблемы. Можно почитать статьи братьев, авторов Дварф Фортресс, не могу с ходу найти ссылку, но это можно подгуглить. Как и почему и что они делали, когда пришла идея сделать реальные уровни в игре (не просто этаж 1 этаж 2, а именно полноценно связные уровни)
И спасибо за поправку про 80% поверхностной базы. Важно это понимать :) А то побухтеть уже захотелось :D
Дополню. Если на этом этапе чуть развязать себе руки - можно будет прикрутить реальные уровни (ось Z условную) которая будет работать и понимать, что если ты убрал пол и под ним нет пола - ты пролетел 2 уровня, а не один. или если ты взорвал потолок (пол верхнего уровня) а там была жидкость - она пролилась. Ну, это сильно сложнее, но мелкие задатки сейчас - победа потом. После нескольких видео, я подозреваю, что механы у вас будут обрастать сложностью ровно с такой же скоростью, как будут лутаться новые знания по предметам, которыми вы заниматесь :)
И еще один ззы. Подсмотрите как сделать простенькие парсеры. Как сделать хороший и простой (пусть за такие штуки и ругают часто) дата класс, чтоб хранить конфиг, для начала и можно было обращаться к этим данным отовсюду из проекта. Смысл в том, что из гугл табличек все циферки будете забирать и не останется никаких магических цифр в коде (кроме конст, которые тоже, по хорошему надо вынсить, но это уже само по себе должно произойти) и убрать хардкодные строки типа "герой". Иначе это ружье бондарчука потом не то что стрельнет, а взорвется.
И ластовый ззы. Никакие видосы не помогут. Книги и даже бот гпт (хотя он кратно ускоряет процесс обучения, если правильно пользоваться и есть программа обучения). Ничего, кроме практики. Пока ты на практике не начнешь это делать и решать эти "проблемы" - теория бесполезна. Этот принцип будет работать всегда. Теории надо знать много, и принципы ООП вы будете еще очень долго осознавать :) Потом минимальные паттерны проектирования, потом будете изобретать свой велосипед (тот же сингл тон) А потом все, снова, перевернется с ног на голову, а потом, возможно, вообще поймете, что дата ориентированный подход сильно круче, ну или в принципе процедурное мышление покажется ближе. И так до бесконечности. Чем больше знаешь - тем меньше знаешь. Но все это ничего не стоит, если бОльшую часть времени вы не практикуете. Это практический навык, с прикладным теоретическим (больше математическим) навыком.
уровни 2d на прохождения, не будет как в дварфах даже близко, игра изначально про 2d и прохождение уровней. Было верно подмечено: слои исключительно для удобства реализации, абстрактные слои:, это скорее слой кристаллов и слой юнитов, А слои блоков они конкретные, для реализации разрушаемого пола и стен под которыми пол и под полом ямы или что-то еще, в видео объяснил.
@@nubowski уххх это жестко) я вот так не буду делать, но классная идея, я хочу больше уйти в генерацию логических цепочек для открытия входа, и генерацию монстров чтобы у них случайно генерировались умения исходя от их принадлежности классу. Ну и проработку ролевой системы. и еще в механики взаимодействия разных блоков чтобы это создавала уникальный геймплей в зависимости от их местоположения, ловушка стреляет ее стрела попадает в взрывчатку та ударной волной убивает врага и отбивает бочку которая активирует рычаг, который активирует ловушку убивая еще врагов)))) а этот враг взрывается, и его ударная волна толкает куб который отражает лазер активирующий кнопку для входа, это как пример возможного рандома для уникальных случайных взаимодействий
Молодчина! Удивительный прогресс за неделю, очень симпатичный код, заметна компактность и код сразу стал понятнее.
Спасибо, стараюсь.
Отлично получается! Хотел бы добавить, что ты можешь делиться сложными моментами в программировании или идеями на канале, ведь ты повышаешь планку качества и количества с каждой серией. Важно не перегореть. Что касается ООП и SOLID, не стоит зацикливаться; используй то, что действительно удобно и понятно тебе, ведь эти концепции созданы для работы в команде с обезьянами которые норовят все поломать.
Спасибо от души) учту на счет сложных моментов, они то забываются что там было сложно, попробую записывать.
На счет перегореть, такой опыт за плечами из разных сфер жизни, что съел собаку на этом. У меня какой подход, делай пока нравится, а если не нравится, то перестань делать и начни делать по новому чтобы нравилось (это кстати самое сложное), и обычно при таком подходе перегорание не наступает, усталость только. Как я понял, перегорание это сигналл на подсознании что шансы на успех меньше чем затраченные силы... например, я когда делал настолку усложняя механики, у меня наступала полное не желание работать потому что я бесознательно понимало что я иду неверным путем, а в сознание понять этого не мог... Ну есть еще и перетрен умственный, тема интересная, может обсужу ее в видео чуть подробнее.
@@System-Chaos Усталость это тоже один из неприятных моментов по 12 часов работать классно, но после этого нужно много отдыхать. А в целом не могу не согласиться пока в кайф делай.
30:06 Ну, прям категоричный туман войны, думаю, будет подпорчивать стратегический геймплей. Его можно использовать на подробности, типа, есть кристаллы, но какие именно не известно, или на перемещающихся врагов, но про основные точки интереса на уровне знать просто жизненно необходимо.
в таком случае можно сделать туман войны врагам, например подсвечивать их знаками "?" и какие-то подбираемые предметы, до тех пор пока не вошел в их радиус, хотя это тоже может подпорчивать тактику, если учитываем что тактика начинается с первого хода, я об этом подумаю еще. В любом случае умный курсор выдающий подробную информацию о характерстиках объектов будет работать только в радиусе 5-8 клеток от героя.
20:51 Вообще, можно было использовать Math.Min(maxLevel,Math.Max(minLevel, value)). Я не уверен, будет ли ущерб, или прирост к оптимизации, но как минимум, код станет проще.
С интересом наблюдаю как ты делаешь свой проект. Пока всё нравится. Жду освоение работы с файлами и проработку графической части, включающей в себя интерфейс.
Спасибо, я думаю что графика будет уже на unity, и на новом проекте. Но если смогу и на этот проект наложить графику без unity вот тут, будет не плохо, так и сделаю, но я даже не знаю если ли такая возможность, сделать это особо не меняя код.
Момент про проблему об уроне.
Я мог бы решить ее путем внедрения запрета о разрушении блока, или сделать штраф в виде отнятия стамины за удар по блоку, но это по факту костыль, А я хочу сделать чтобы в игре были законы в которых игрок выживает и в них нету всяких надстроек, чтобы все было прозрачно, например твердый блок это не блок который нельзя сломать, а это блок 200% защитой, то есть у всего должно быть объяснение на уровне самих механик, а не на уровне разработчик так решил. Отведенное время (шаги) это не костыль, это фундамент, который создает челендж, потому что без времени можно гриндом брать игру.
Объясню еще на примере.
У нас есть взрывчатка, она должна разрушать твердые блоки у которых много брони и здоровья, но тогда она будет убивать боссов и сильных врагов, костыль это сделать врагам иммунитет к взрывчаткам, или какой-то спец тип защиты от взрывчаток, а вот не костыль, а оформление в рамках законов игры, сделать у взрывчаток большой урон но не гипер большой и добавить высокое пробитие брони, как раз у блоков очень высокий показатель защиты, если правильно подогнать цифры, взрывчатка будет хорошо рушить блоки и не ваншотить всех и вся, а просто наносить достаточно сильный урон.
По поводу критов. Это механика для боёвки. Одна из возможных тактик на выбор игроку.
Сам по себе рандомный урон от крита конечно бесполезен. Его надо рассматривать в контексте применения. Должны быть враги которые уязвимы к критам, а другие с сопр. критам. Против первых криты это лучшая тактика, вторым наоборот. Смысл тот же что и с другими боевыми механиками (физ/маг урон/защиты, разные стихии/типы урона и сопр./уязв. им, меткость/уворот, +%урон/%сопр. урону, и т.д.).
Ещё могут быть ряд механик условием которых является крит: оглушение при крите, кровотечение, восст. себе части ОЗ от урона (вампирик), вероятность мгновенно убить цель и т.д. Чтобы делать разные комбо и билды.
Пока что у тебя не вижу выраженной боёвки, хотя ты упоминал про наличие врагов и боссов.
Смотри, криты это круто, но вопрос в другом. А потянет ли геймдизайнер баланс, если все что дает крит, достигается более простыми методами, где проще балансировать игру.
Аналогия вместо крита: шанс оглушения от дробящего урона, кровотечение от режущего. Враги имеют уязвимость к огню или сопротивление к холоду,
и в отличии от критов, это балансировать будет намного проще, ибо крит это нет тип урона а модификатор любого урона.
Единственное что дает крит, это эффект вау, именно из-за этого хочется его добавить, но если учесть что игра меньше про рандом в боях и больше за тактику, скорее всего в этом проект критов не будет, дабы сэкономить нервы и время.
Дак какая боевка, я пока учусь вообще что-либо делать, например чтобы герой ходил по карте, и например не мог идти свкозь стены, хотя я уже это сделал)))
В будущих проектах будет большая ролевая система, этот проект пока крайне с упрощенной боевкой будет.
@@System-Chaos проще понять крит можно если рассматривать его именно как тип урона 😃 Например, маги бьют огнём/льдом, колдуны тьмой, ловкачи ближнего боя - критами, стрелки с меткостью - против врагов с уворотом, воин с высокой Силой - против врагов с высокой Защитой (урон = Сила - Защита цели). Суть та же, бывают враги с сопр./уязв. каждому из них. Игрок делает билд с упором на одну из этих возможностей с целью максимизировать боеспособность. Или выбирает более подходящую из нескольких под каждый случай.
Может смущать только рандомность урона, но это надо рассматривать статистически. Например есть 25% вероятность крита 2х. Это в среднем равнозначно +25% урона. По врагам с х2 вероятности крита, 50% х2 = +50% урона. По врагам с неуязв. криту ничего не даст.
Но опять же, это нужно для боёвки. Тебе пока наверно нет смысла заморачиваться.
@@DobinSergei в моем настолке я крит иначе рассматривал. А это будущая компьютерная игра. Объясню, там нет классов, ты его собираешь из активных навыков и прокачки. Крит есть у всего, у магий и ближнего боя и тд. По моей задумки, крит там был именно как имитация попадания в органы. И там подучается что крит это именно нанесения сильной травмы и там начинался кошмар. Я делал с упором в реализм, и для этого изучал настоящие средневековые бои, биологию и много всего еще. И по факту шанс и урон крита там привязывался к типу урона, а тип урона привязывался исключительно к типу атаки оружия, одно оружие могло бить в зависимости от типа атки, разными уронами. Копье только колоть, а меч и рубить и колоть и резать и тд. Тип урона колющий был сильный шанс крита, но урон от него не самый выский. По мимо крита там был останавливающий эффект и шанс заражения. В теории колющий урон можно было нанести магией, например ледяной стрелой условно. Поэтому в моей игре крит был никак математическая модель, а как имитация нанесения урона по внутренним органам и был привязан ко всем типам уронов и атак.
@@System-Chaos когда крит влияет на любой урон, это же просто ещё один модификатор урона. Тогда он используется в классах или билдах на максимизацию урона. Чем больше множителей, даже небольших, тем больше даёт каждый из них.
У меня в игре многое упрощено и условно, пришлось пожертвовать реализмом ради геймплея. Критуют только действия по одной цели, при которых нужно точно целится. Суть та же, это поражение более уязвимых частей. Но если действие бьёт по области даже небольшой (все заклинания), то попадание поражает сразу всю цель, но не так сильно по уязвимым частям как прицельные. Потому не критует.
И ледяная стрела применяет именно кровотечение 😃 Каждое заклинание урона применяет какое-то доп. действие помимо урона.
Сделай лучше руды через enum. Большое количество сравнений строк делает дольше прогрузку карты
буду иметь ввиду
8:57 ну если время ограничено то там заведомо бесполезно долбить один блок 100 ударами. Хотя по механике это возможно, игрок не будет так делать. В чём тогда проблема?
смотри, я вобщем в любом случае сделаю костыль, чтобы стенки бились только ресурсами (бомбы, кирки) Время оно условно, имелось ввиду ходы.
Проблема в том, чтобы игрок не гриндил кристаллы с блоков, но при этом чтобы карта могла разрушаться атаками игрока. Но в итоге я прихожу к мысли, чтобы не делать никакого времени, просто сделаю костылем как описал выше, и запрещу карту разрушать игроку с ударом с руки (с оружки)
@@System-Chaos ну всё логично, голой рукой шахты не копают 😃
14:48, Ну вообще, было бы логичнее, если бы ямы всё таки можно было использовать для укрытия, а не наоборот. Хотя, тебе виднее
Можно сделать что углубление это укрытие от дальних атак если углубление равно 3 связанные клетки и меньше, потому что если ямы будут размером 10 на 10, будет нелогично что они работают как укрытие, А вот как можно: яма это укрытие когда герой касается стенки с неукрытием. И выводить статус с боку вы в окопе, +25% уворота от дальних атак, и -25% от ближних атак)