Ответ: I.D.S. MONSTERS
Цитата:
|
Ответ: I.D.S. MONSTERS
Цитата:
> Теперь монстры имеют радиус обзора, реализованный через триггер, который отслеживает слой игрока Тебе так сильно нужны эти триггеры в 2д-игре? Радиус — корень суммы квадратов разности по X и Y, не? |
Ответ: I.D.S. MONSTERS
Цитата:
Давай по подробнее для двоечников, ок? ) Цитата:
Я счёл, что триггеры будут идеальным вариантом. Тем более, что на юнити почти все так и делают. |
Ответ: I.D.S. MONSTERS
Цитата:
"Все так делают" — нифакт, профессиональные разрабы не ссутся как в старые-добрые писать свой функционал там, где это целесообразно. Блоггеры на Ютубе в видосах "Своя игра на Юнити за 5 миллисек" юзают триггеры (и им подобные решения) потому что это понятнее для школьной аудитории и не надо знать никакой математики. |
Ответ: I.D.S. MONSTERS
Цитата:
только для 2Д мира, для 3Д будет сложнее, делать там проверку по дополнительной оси. Я ещё не знаю, будет открытый мир плоским, или кривым террайном, может у зданий даже будут этажи разновысотные, хз. Мне сейчас мой вариант выгоднее, и проще. Да ещё и мне не нужно постоянно проверять, загружен ли префаб персонажа в сцену, триггер тип персонажа мониторит. Так же я размер триггера могу прям в сцене регулировать, и видеть его, это удобно. Ещё важно то, что у триггера есть три готовые проверки состояния (в нас вошли, в нас стоят, из нас вышли), это многое упрощает, и ускоряет процесс разработки. |
Ответ: I.D.S. MONSTERS
Цитата:
https://docs.unity3d.com/ru/current/....Distance.html PHP код:
это многое упрощает, и ускоряет процесс разработки. Ну раз упрощает так упрощает. |
Ответ: I.D.S. MONSTERS
Цитата:
Код:
//Определяем дистанцию между персонажем и навигатором Ну представь у нас 200 монстров, и чё они все будут дистанцию до персонажа мерить? Это был отличный способ поставить блитц на колени, в юнити я таких экспериментов проводить не хочу. Так им ещё и проверять постоянно, находится ли в сцене префаб игрока, прежде чем проверку на дистанцию запускать. А с триггерами тупо на физ движке, пересеклись коллайдеры, хуяк событие. Я могу быть не прав конечно, я хз как там в юнити реализовали просчёт пересечения коллайдеров, но что-то мне подсказывает, что это дешевле, чем спамить Vector3.Distance с множественных объектов. Конечно всё ясно будет по результатам тестирования, когда я заспавню лес монстров с триггерами, нужно фпс смотреть. Если будет лютая просадка, то попробую способ с постоянным замером дистанции. |
Ответ: I.D.S. MONSTERS
Кристал на 10 дней превратился в геймера, и задротил в Minion Masters,
но Кристал излечился, и сегодня вернулся к геймдеву. Реализованы точки респавна монстров, в определённом радиусе от которых монстры респавнятся в рандомной позиции. Реализованы порталы аля фильм терминатор (надувающийся пузырь). Пузырь надулся, в нём появился монстр, пузырь исчез. Запускается таймер жизни монстра, после окончания отсчёта дезбринга отправляем обратно в ад нафиг, создавая пузырь вокруг него, и сдувая пузырь. Код порталов и жизни монстра: Код:
//Портал появления Код:
public GameObject MonsterPortal_z1; |
Ответ: I.D.S. MONSTERS
Итак, мне нужны тестеры. будем проводить первый стресс тест.
На карте находится 5 точек респауна монстров, они создают каждая по 20 монстров, далее каждую секунду будет удаляться по одному монстру, и каждой точкой создаваться по одному. Все монстры с триггерами-глазами. Цель теста - проверка оптимизации, выявление багов. Если у вас игра тормозит, сообщите конфигурацию своего ПК. Если нашли баги - сообщайте подробно описав ситуацию. Заранее благодарен. Билда: ТЫК |
Ответ: I.D.S. MONSTERS
Для тех кто прошёл удачно первый стресс тест, получайте второй.
Здесь каждую секунду создаётся 10 монстров, за 100 секунд будет создано 1000 монстров, и после каждую секунду будет создаваться 10 монстров, и 10 удаляться. Вы поймёте что уже набралась тысяча, когда шары начнут сдуваться. Пробегите кубиком наверх аккуратно, и побегайте там. Можете по выманивать монстров, но не дайте приблизиться, иначе перекинет на другую сцену. Меня интересует, гладко ли у вас всё, нет ли подёргиваний? На моём ПК всё как по маслу, никаких лагов. Билда: ТЫГ P.s. 1000 монстров это 2000 триггеров. P.p.s. В данный момент есть не оптимизированная штука, все 1000 монстров следят за камерой, и поворачиваются в её сторону, они проводят 1000 расчётов положения камеры, когда можно делать один в отдельном скрипте. Данная срань оптимизироваться не будет, т.к. фича нужна лишь для плоских монстров созданных из квадов, которые являются временным решением, пока отсутствуют 3D модели. |
Ответ: I.D.S. MONSTERS
Вложений: 2
Изменения на сегодня:
Теперь у монстра случайное время жизни в установленном диапазоне. Теперь точки респа создают монстра через случайный промежуток времени в установленном диапазоне. Теперь в окне сцены визуализирована область респа монстров вокруг точки респа прозрачным шейдером, что удобно для выбора расположения точки, чтобы монстры не появлялись где не надо (например за пределами игрового поля). Визуализация действует только в сцене, и убирается в игре. Помимо точек респа теперь можно сразу по умолчанию накидать в определённые места монстров, которые тоже будут помечены в сцене цилиндрами. (Все эти визуализации в скрине ниже). Поработал с космосом. Теперь он не выглядит как граффити на асфальте вокруг игрового поля, а передаёт всю глубину своих глубин на столько, на сколько позволяет текстура. Космос теперь отдалён от игрового поля, и движется за камерой, чтобы визуально создавать эффект отдалённости и гигантности, так же космос вращается в противоположную сторону от камеры, при поворотах камеры. Короче проще посмотреть в билде, может показаться, что космос гигантский и статичен, но это я так вас обманываю, на самом деле он маленький, и динамичен. Побегайте камерой, по отдаляйте, по приближайте, по крутите. (При статичном космосе визуально была бы картина другая, в нашем же случае камера это эксцентирк вращающийся вокруг своей ноги, и космос следует именно за эксцентричной частью, при этом поворачивается в противоположную сторону от угла поворота камеры. Результат: обман зрения, вы видите якобы далёкий и огромный статичный (как в реальной жизни) космос, в глубинах которого на краю вселенной болтается наш игровой уровень). Космос теперь трёхслойный с прозрачностью, чтобы сгладить текстуру, и передать глубину глубин глубины глубокого космоса. БИЛД |
Ответ: I.D.S. MONSTERS
Учу общаться скрипты между собой.
Теперь расчёт размера сетки в сцене боя ведётся исходя из уровня угрозы монстра. Уровень угрозы закреплён в переменной внутри скрипта привязанного к монстру. Там целая сеть прогонов через несколько скриптов, узнав уровень угрозы, выбираем размер сетки: Код:
//Уровень угрозы Но создаём пока не его. Всё пока сыро, но работает. В данный момент чтобы реализовать данную задачу двумя параметрами (MonsterNumber, ThreatLevel) обмениваются пять скриптов: скрипт отвечающий за характеристики монстра, скрипт работающий с его триггером, статичный глобальный скрипт получающий информацию с кем сталкиваемся, скрипт создающий сетку, скрипт создающий монстров на сетке. |
Ответ: I.D.S. MONSTERS
Теперь скрипт создающий монстра в сцене боя знает кого конкретно создавать.
Теперь этот скрипт знает какого размера сетка игрового поля получится, высчитывает правый край, находит его середину, и помещает монстра туда. Теперь скрипт сетки выделяющей монстра знает какого размера получилась сетка игрового поля, и верно подгоняет положение сетки выделяющей монстра. Заменён шейдер сетки игрового поля, теперь она симпатичнее, этот шейдер решил проблему отрисовки, ранее очень большая сетка на расстоянии переставала отрисовываться. Теперь монстр увидевший игрока рычит, это маленькое дополнение изменило восприятие проекта. Теперь появилось ощущение, что мы играем в игру. Звук рыка в режиме 3D, откуда рычат, от туда и слышим. БИЛДО |
Ответ: I.D.S. MONSTERS
Цитата:
|
Ответ: I.D.S. MONSTERS
Взрослая жизнь задолбала! Да что такое! Опять сегодня мало времени на кодинг было!
Однакож нужно выговориться. Я продолжаю работать над конструированием сцены боя, и создавать то, о чём понаобещал ранее. Так вот, игровой уровень строился исходя из учёта уровня угрозы нападающего монстра, а теперь мы имеем некий импровизированный инвентарь персонажа с пятью ячейками для хранения походных монстров, в котором записываются порядковый номер и уровень угрозы монстра. Порядковый номер нужен будет на днях, для написания скрипта по созданию в сцене монстра из инвентаря игрока, а вот уровень угрозы его уже нужен для конструирования сетки уровня. Как я заявлял ранее, мы будем выбирать самого опасного монстра игрока, и сравнивать его с уровнем опасности нападающего монстра, а после выбирать кто из них круче, и в соответствии с полученными данными выбирать размер уровня. Так-как логично, что более крутые монстры будут тупо крупнее, и часто резво перемещаться на большие расстояния, и в маленький уровень не влезут, а создавать уровни размером 100 на 100 для всех подряд включая самых мелких монстров это было бы мегатупо, так-как основную часть геймплея займёт время доковыливания до врага. Я думаю вы согласитесь, что такая система расчётов была нужна, она готова, и применена почти в одинаковом виде к трём скриптам, пример: Код:
public int ThreatLevel; //Уровень угрозы Монстра Код:
public static class PlayerKarman Так-как в нём будет проходить основная часть геймплея, на его разработку будет потрачено огромное количество времени. Мне нужно будет и массив проходимости клеток создавать, и рандомный расставляльщик всяких деревьев и прочей хрени мешающей нам перемещаться. Во всяком случае сложность конструирования уровня уже даёт за обе щеки покемонам, так-как в серии тех игр нет вообще возможности перемещаться по полю боя, а у меня будет, так-как это даёт массу возможностей в выстраивании тактики боя. Уже даже герои меча и магии начинают сосать, так-как там по моему весь бой происходит на одинаковой сцене, с сеткой одного размера, там только задники меняются, есть там правда и вторая сцена "замок". А у меня 7 размеров уровней генерирующихся автоматически в одной единственной сцене, чем не повод для гордости? )) Масштаб задумки огромный, чтобы всё рассказать придётся писать огромный диздок, в котором нет смысла для студии из одного человека ) --- Окей, что дальше делаем? Далее создам скрипт, запихивающий игрока в сцену боя, при этом у нас будет 2 варианта на выбор, либо мы присутствуем в стороне как в HoMM3 например, либо идём и самим персонажем в бой как в HoMM4. Разница будет в том, что стоя в сторонке и отдавая приказы монстру, мы будем в безопасности, и сможем убежать, а при выходе на поле боя лично, мы сможем там сразу опиздюлиться, а смерть юзера это будет стопроцентный молниеносный гамовер. Зачем же нам выползать на поле боя самому? Ну во первых, в моей игре задницу игроку никто нализывать не будет, и никакой профессор "ОАК" нам с ходу не вручит имбового пикачу, нам дадут дубинку, и скажут, хочешь жить, умей вертеться. И с этой херновиной мы пойдём врукопаш на монстров, чтобы кого-нибудь поймать, или сдохнуть. При этом если у нас нет походных монстров, значит бой стопроцентно начнётся с игроком на поле боя. Далее, в скрипте создания монстра на поле боя будет реализована рандомная случайность, что монстр который на нас напал, моментально призовёт на помощь от 0 до 2 монстров на подмогу. А если вы помните, мы призываем монстров с помощью перчатки-контроллера, которая может контролировать только одного монстра, собственно только одного и призывать, и раз монстров противников может оказаться более одного, значит игроку придётся самому часто выползать на поле боя в виде подмоги. Но я уже ранее писал, что будет возможность призвать больше монстров. Первая это используя скилл особого монстра, вторая это дополнительный предмет, о котором я не расскажу. Уже жду не дождусь когда наконец смогу перейти к разработке механики боя, однако ещё много что нужно реализовать перед этим. |
Часовой пояс GMT +4, время: 09:44. |
vBulletin® Version 3.6.5.
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Перевод: zCarot