Прошлый тред: >>835726 (OP)
Официальный сайт: https://unity3d.com/ru
Документация: https://docs.unity3d.com/ru/current/Manual/index.html
Уроки: https://unity3d.com/ru/learn/tutorials
Форум: https://forum.unity3d.com/
Магазин ассетов: https://unity3d.com/ru/asset-store
UnityWiki: http://wiki.unity3d.com/index.php/Main_Page
На Unity сделано много замечательных игр - Valheim, Genshin Impact, Subnautica, Albion Online, Endless Space, Beat Saber, Boneworks, Rust, Блицкриг 3, Pillars of Eternity, Tyranny, Kerbal Space Program и многие другие. Главным преимуществом Unity перед другими движками является его простота для одиночной разработки. Не нужно иметь целую компанию девелоперов, чтобы сделать хорошую игру. Если ты один или имеешь небольшую команду и хочешь сделать хорошую игру без претензий на ААА, то Unity станет лучшим выбором. Тем не менее, даже крупные корпорации зачастую выбирают для своих игр именно Unity.
FAQ
- Какие у Unity сильные стороны?
- Простота разработки, удобный инструментарий, кроссплатформенность, богатая документация, огромное сообщество.
- Какие у Unity слабые стороны?
- Сложность в создании фотореалистичной графики. Для графики "как в Crysis" рекомендуется взять другой движок. Хотя Unity вполне способен выдавать не уступающую любым другим движкам картинку, это требует определённого навыка от разработчика.
- На каких языках я могу писать скрипты для Unity?
- На выбор два языка - C# и UnityScript. UnityScript - это что-то среднее между JavaScript и ActionScript. Выбирай язык по своему вкусу, они оба вполне удобны, но помни, что большинство примеров написано на C#.
- Для каких жанров подходит Unity?
- Для абсолютно любых! Жанр ограничивается лишь фантазией разработчика (и его умением писать скрипты, разумеется). Можно создавать и РПГ, и стратегии, и слэшеры. Можно делать VR-проекты или Minecraft-подобные песочницы.
- На каких платформах работают созданные с помощью Unity игры?
- Windows, Linux, MacOS, SteamOS, Android, iOS, Windows Phone, PlayStation4, Xbox One, WebGL, Oculus Rift и многие другие. Полный список можно найти на официальном сайте. Таким образом, игры Unity работают на десктопах, на смартфонах, планшетах, приставках, в браузерах, VR-очках и некоторых других системах.
- Часто вижу скриншоты с красивой природой на Unity. Как такое создать?
- Очень просто! В Unity встроены удобные инструменты для создания террейна и SpeedTree для создания деревьев и готовая реализация ветра - не нужно ничего писать или скачивать и подключать плагины - ландшафт в Unity создаётся в пару кликов.
- Что такое стартер киты?
- Starter Kit - это набор скриптов и префабов, а зачастую и графических элементов для игры. Они призваны облегчить разработку игры определённого жанра и как правило разбиты по жанрам (Action-RPG Starter Kit, RTS Starter Kit, 3D Shooter Starter Kit, Space Game Starter Kit, VR Starter Kit и так далее). Также бывают стартер киты различных игровых элементов, не связанных с геймплеем (Nature Starter Kit с дополнительными природными объектами, Medieval Starter Kit со средневековыми объектами и так далее). По сути, стартер киты выполняют в разработке игры ту же роль, что и фреймворки в программировании. Однако стоит отметить, что использование геймплейного стартер кита принуждает разработчика изучать большое количество чужого кода и чужой структуры для внесения своих изменений и полноценного использования. В связи с этим большинство разработчиков предпочитает писать почти всё с нуля, получая полное понимание работы своей игры. Новичкам крайне не рекомендуется начинать знакомство с Unity со стартер китов.
- Что нужно уметь делать для создания полноценной игры, кроме Unity-разработки?
- Кроме непосредственной разработки игры на Unity, требуется также уметь создавать 3D модели (3ds Max, Blender, ZBrush), 2D рисунки (GraphicsGale, Aseprite, Piskel), текстуры (Substance Designer, NeoTextureEdit), музыку (FruityLoops, Ableton). Не обязательно учить это всё - например, в 2D играх не нужны 3D модели, а музыка необходима далеко не всегда. Также вы можете скачивать элементы для ваших игр на бесплатных сайтах. Если у вас есть деньги, то все необходимые элементы можно заказать у фрилансеров на https://www.fl.ru/ (русскоязычный) или https://www.upwork.com/ (англоязычный).
- Бесплатен ли Unity?
- Можно свободно скачивать, использовать и продавать готовые игры на Unity с лицензией Personal - это абсолютно бесплатно! Но на бесплатной версии при запуске игры будет появляться короткий стартовый ролик "Made with Unity", а также ваши доходы ограничены 100 000 долларов в год. Для снятия этих ограничений нужно приобретать платные версии лицензий Unity. В конечном итоге, платные варианты используются лишь крупными компаниями с огромными доходами, тогда как обычные разработчики в большинстве своём используют бесплатную Personal лицензию.
Обучение по книгам
Обучение языку C# книги на русском языке:
1. Head First. Изучаем C# 4е издание Авторы: Эндрю Стиллмен, Дженнифер Грин
2. Программирование на C# для начинающих 2е части Автор: Алексей Васильев
3. C# для чайников Автор книги – Джон Пол Мюллер
4. Unity и C#. Геймдев от идеи до реализации Автор: Джереми Гибсон Бонд
5. Язык программирования C# 7 и платформы .NET и .NET Core Авторы: Филипп Джепикс, Эндрю Троелсен
Для людей абсолютно не знакомых с движком есть 3и основные книги на русском языке:
1. Разработка игр на Unity 2018 за 24 часа Майка Гейга
(Знакомство с движком, изучение редактора, создание 4х простых игр практически без кода, отличное пособие для полных новичков).
2. Изучаем C# через разработку игр на Unity. 5-е издание Харрисон Ферроне
(Пошаговое освоение всех базовых знаний по программированию на языке С# в редакторе юнити, создание одной игры стрелялки от первого лица, написание искусственного интеллекта врага, книга переведена не совсем корректно и порой встречаются не просто опечатки, а серьёзные неточности перевода.)
3. Unity в действии. Мультиплатформенная разработка на C#. 3-е межд. издание Хокинг Джозеф
(Правильное построение архитектуры кода для сложных проектов, углублённое изучение программированию на C#, создание 4х полноценных игр на движке, обязательно нужно скачать код проектов, так как в книге он местами уже устарел.)
Вижу шапку поправил но не до конца.
>Сложность в создании фотореалистичной графики. Для графики "как в Crysis" рекомендуется взять другой движок. Хотя Unity вполне способен выдавать не уступающую любым другим движкам картинку, это требует определённого навыка от разработчика.
Уже можно любую hdrp завезли. Хоть как в анриле.
>На выбор два языка - C# и UnityScript. UnityScript - это что-то среднее между JavaScript и ActionScript. Выбирай язык по своему вкусу, они оба вполне удобны, но помни, что большинство примеров написано на C#.
В юнити всего один язык и это C#.
>Очень просто! В Unity встроены удобные инструменты для создания террейна и SpeedTree для создания деревьев и готовая реализация ветра - не нужно ничего писать или скачивать и подключать плагины - ландшафт в Unity создаётся в пару кликов.
Не актуальный старый кал. Либо юзаешь ассеты или пишешь шейдеры.
>1. Разработка игр на Unity 2018 за 24 часа Майка Гейга
>2. Изучаем C# через разработку игр на Unity. 5-е издание Харрисон Ферроне
>3. Unity в действии. Мультиплатформенная разработка на C#. 3-е межд. издание Хокинг Джозеф
Старый ебучий кал. Добавить туда надо смотрите обучалки на ютубчике или шерстите оф документацию с примерами. Или сам курс от юников пройти уже на сайте.
хватит это терпеть.
Чел, пустой проект весит около 100 мб в исходнике и 30мб сбилдженый. Открывается 3-10 сек.
О чем разговор?
>обсуждение редактора юнити
>не по теме
ну как хочешь. иди позови котла, чтобы мой пост удалили лол
сидите в своем дохлом треде с 1 постом в день дальше, нытики
Тут есть те, кто зарабатывает на assets store?
Да вон прочитал там с соседнем треде, один поднял, другие завидуют ))
>>843548
https://www.youtube.com/watch?v=oGib_NNPw9k
Полно кто из РФ зарабатывают на Assets store.
Тут вопрос в другом, котов ли ты год/полтора делать ассет, где ещё не сразу могут принять (а проверяют его две~три недели)
Ну потому что я увидел два сообщения, подумал, что флешмоб и поддержал.
Вопрос, насколько хорошо в Unity 3d использовать PBR материалы (К примеру атлас с 4096x4096) для mobile?
Или это слишком жирно и android/ios устройство такого не вывезут?
>баги двача
>>843555
>баги двача
Ньюфаги, если вы нажали один раз кнопку "отправить", но ЧТО-ТО СЛОМАЛОСЬ и сообщение не исчезло из формы, не нажимайте эту кнопку повторно - подождите минуту-две и нажмите "обновить" внизу страницы. Иногда так получается, что сервер принимает сообщение и добавляет в тред, но клиент форму не очищает и страницу не обновляет. ПОВТОРНО НАЖИМАТЬ НЕ НУЖНО, ваши повторные нажатия кнопки и создают эти дубликаты сообщений. Особенно это касается капчующих с мобилок, у которых жирные колбаски вместо пальцев делают двойной тап, не осознавая этого.
У меня такое было пару раз несколько лет назад. Быстро понял, в чём проблема, и больше на это не попадался. Если вы не ньюфаги - не завидую вашим играм...
Не хочу обижать, но я надеюсь, что графику ты всё же поменяешь. Максимально унылая картинка, ни о чём просто. Если я хочу поиграть в tower defense, я выберу себе игру с привлекательной графикой, потому что игромеханически все эти игры плюс-минус равны - "строй башни, улучшай башни, жди завершения уровня, повторяй всё это на следующем". Но даже если ты выдумал какой-то очень крутой новый геймплей (вряд ли), без привлекательной картинки его у тебя никто не увидит и искать не будет. Чем менее привлекательна игра внешне - тем больше сил и средств нужно вложить в маркетинг...
Есть такое. Но максимум на что я могу пойти - найти тайлсет для террейна повеселее.
У тебя ассеты все в разных стилях, сделай всё единообразно.
Насколько я понимаю эта хуйня из под коня и называется связанностью и мне как минимумм нужно модификаторы атаки инкапсулировать в отдельный класс и в ApplyDamage передавать его, вместо целого набора параметров???
Хотел тебе помочь, но в этом треде вахтер пердит вонюче, сорри
Я хочу перекатиться на другой движок, в котором проекты не открываются по 5 минут. Это большой блок для меня.
Да и вообще наверное поведение башни стоит полностью отделить от статов? и типо можно тогда в башне заменять модели поведения или например делать их несколько. Добавить спавнер допустим, или автокас каст заклинаний через какой-то промежуток времени в довесок к автоаттаке!? чи да чи ни? А сама башня будет просто хранилищем и инициализатором компонентов.
Выглядит как пижня, у меня на HDD создаётся минуту дай бог
Ты на unity 5 до сих пор сидишь что-ли?
Скачай последнюю версию и создай URP проект
В итоге получаем, что башне глубоко поебать на задания и возможность их исполнения, что вроде как заебись.
Так же вынес статы башни в отдельный класс. Если рожу глобальные апгрейды башен, то смогу в теории через декоратора крутить вертеть статами как хочу, опять же добавлять таски.
Даст кто-нибудь письку ебать за такой код или хуй пососу как всегда?
>Даст кто-нибудь письку ебать за такой код
Да, за такой код тебе дадут пизды, но в более традиционном смысле.
>Update()
>Смотрит какая играется анимация чтоб понять доступна ли башня для действий
Ты совсем далбаеб? Может лучше анимация будет зависеть от того что делает объект, а не наоборот?
Пусть пишет. Одним конкурентом меньше. Я бы ему еще посоветовал записаться на курсы сакутина, чтобы добить наверняка
Отличные курсы. Всяко полезнее чем выпуки безыгорных говнокодеров с двача с завышенным самомнением, которые в штаны дристанули, когда узнали, что кто-то 900к поднял за месяц
Пацаны пацаны кажется новая идея проклевывается!!!!! Карочи Так с виду у всех тасков один и тот же набор методов с разным исполнением. Попахивает шаблонным методом, который будет запускать мелкие подзадачи инкапсулированные в отдельные классы, под чьей абстракцией будут сидеть конкретные варианты исполнения, типа как в стратегии. Тогда в теории, можно без преписывания кода для каждого нового таска полность, накодить различные варианты исполнения задач низкого уровня и комбинировать такси уже из них.
Идея это хорошо, но твоя реализация этой идеи как всегда будет куском говна, так что на твоем месте я бы не радовался.
Другалечек, ты че такой злой и категоричный? Ассетов на ассетфлип не нашел или клон вампиров не продался? Зачилься.
1) Кто то покупал через пайпал ассеты? По идее можно же закинуть на палку через обменник с бестчейнджа или с киви?
2) У меня иногда такое бывает: если загружаю модель с анимацией, то всё ок и другие анимации ЭТОЙ ЖЕ МОДЕЛИ на ней работают (выдёргиваю анимации путём Ctrl+D).
А иногда бывает так, что я не могу запустить анимации, если применяю их на отдельно взятой модели, даже если она полностью заригана, аниме тайп generic, аватар генерил с этой модели и пробовал брать из другой, анимированной модели , на которой такой-же скелет и анимации работают (естественно там тот же скелет как и в анимации).
Причем ни в игоре, ни в редакторе, когда в окно превью анимации драгндропаю эту модель, тоже ничего не проигрывается. Ситуация странная и даже объяснить толком сложно, надеюсь кто то с таким сталкивался и решил.
Ебаный рот этого аниматора.
Что с ним не так? Почему через стейтмашин анимация проигрывается с задержкой?
Потому что виндовс не активирован ты скрыл справа полезную панельку в которой настраивается в том числе задержка при переходе с одного стейта на другой.
Только скажи и я покажу тебе все
Вообще у меня там все по нулям. Для эксперемента убрал переходы между стейт машиной и базовым уровнем-одно и то же
Если делать атаку не через стейтмашин а через обычный стейт, то все работает корректно
И тут у меня закралась мысль. А чем башня, как сущность отличается врагов? Не двигается же просто и все. А враги по сути выполняют те же таски. И че епты, получается надо вводить общее понятие сущности, от которого уже распедаливать?!?!
Меня смущает прокладка в виде entry между эни стейтом и твоими атаками, плюс не совсем понятно использование анистейта для всего, ты уверен что тебе нужна стейт машина?
>entry
Оно так по дефолта создаётся. Ее можно выкинуть?
>Надо ли ?
Мне стейтмашина нужна что бы сгруппировать анимации по различным вариантам ходьбы и атаки
>>843994
>>843997
>>844005
Заебало. Одарю косариком того кто свяжется со мной в телеге и объяснит как работает этот аниматор ебаный , стейтмашины и что я сделал не так именно в этом случае.
@ReiselReise
Рассказываю бесплатно и изи.
Делаешь Пустышку и в неё заходит энтри.
Остальные атаки вызываешь только во время действия. ИЗИ.
Пытался и так сделать. Но хуй там плавал
https://blog.unity.com/technology/wait-ive-changed-my-mind-state-machine-transition-interruptions
где-то тут в ордерах кароче у тебя проблема
Почему нельзя как в вебе, где используя html css Js (а ещё лучше какое-нибудь react или Vue) можно сделать фактически любой дизаен, с анимацией в том числе.
Почему я должен перетаскивать кучу кнопок и каждую из них индивидуально настраивать по стилям, вместо того чтобы хранить стили для каждой кнопки где нибудь в файле, и править только там, а не тыкать каждую кнопку,когда захочу что-то поменять
Чтобы мне не приходилось через скрипты скрывать какую-то панель, что показать другую, чтобы это происходило само собой:
<panel v-show="selectedPanel == panel.settings" >
<slider v-model="userdata.volume" min="MIN_VOLUME" max="MAX_VOLUME" >
</slider>
Этот код шаблона сам отслеживает, если выбрана панель настроек, то ее и показываем. Не надо вручную ее скрывать и показывать через код, правило уже прописано в шаблоне. Так же там в слайдере автоматически берется значение из userdata и сразу же его перезаписывает напрямую, как только пользователь двигает слайдер
Извини, брат, я за свои 5000 с яндекс игр трясусь, конкурента растить не буду.
Сап, юнитач
Не нравится visual studio, хочу что-нибудь более легковесное с поддержкой юнити. Rider от JB пойдойдет?
Да, райдер официально поддерживается юнитей. Несколько лет на нем сижу и проблем нет.
- Встроили ECS. Пишут, что уже можно в проде пользоваться.
- NetCode for GameObjects.
- UI Toolkit прокачали, теперь для написания инструментов для редактора лучше его использовать.
- По графонию: Decal Layers, Forward+ для источников света, новые системы для воды облаков, Shader Graph Full Screen Master Node для эффектов и многое другое.
- DirectX 12 вышел из экспериментального состояния.
>Встроили ECS. Пишут, что уже можно в проде пользоваться.
Я так и не понял что это и нахуя надо. Посоветуйте чё почитать, посмотреть чтобы дошло наконец.
>Я так и не понял что это и нахуя надо.
Для обычного игродела не нужно, если не собираешься моделировать поведение десятков тысяч объектов в риалтайме.
А че это чисто оптимизаторская хуита? Каких-то других пруфитов типа читаемости или легкости в создании архитектуры нет?
>пруфитов типа читаемости или легкости
Если где то прибыло, значит где то убыло. Производительность получается за счет отсутствия читаемости и легкости.
Перевел проект с 2020 на 2022 и получил критикал еррор. Теперь он тупо крашится при загрузке. Ахуена, спасибо)))
>менять движки посреди разработки
Причем тут юнити, ты сам долбоеб.
> Перевел проект с 2020 на 2022 и получил критикал еррор
так это база базовая
Че за папка Temp, ты уверен что она не юзается юнитей для функционирования?
В общем схема работы выглядит так. Сама башня знает, что есть таски и может попытаться их запустить. Таск содержит в себе информацию о радиусе активации, кулдауне и объекте, который содержит в себе визуал таска - условно снаряд. Если в радиусе есть цель и кулдаун откатил, таск активирует этот объект и передает в него трансформ цели.
В этом объекте есть филды абстрактного типа - провайдер координат - его цель предоставить координаты из трансформа цели - либо реальные, либо если атака по земле - в момент начала атаки. соответственно через наследование можно варьировать.
И абстрактный тип отвечающий за движение - линейное, параболическое, инста перемещение в точку.
когда объект достигает нужных координат, происходит некое абстрактное дейтсвие.
Получается, что могу собирать задания, комбинирую различные модули. Причем я сначала думал сделать абстракцию заданий, а потом через наследование делать отдельно автоатака, каст, призыв и т.д. Но походу это вообще не нужно, и я просто автоатаку соберу как модульную конструкцию из нужных компонентов.
Ну че, как выглядит в плане концепции - нормально чи нI?
Хуярить таски циклом в апдейте выглядит неоптимизонно, чому бы их не реализовать через подписку?
Это просто затычка. их вообще так нельзя будет делать, потому что аниматор охуеет. Поэтому я буду там какую-то систему связей прикручивать через эвенты или просто делигады.
Такс не должен быть монобехом. Таск это задача со статусом, а не дата-класс. Либо меняй название.
Execute() охуенный, конечно
Сделай поиск цели отдельным компонентом и собачь его на башню
В классе всегда указывается от чего наследует. В обычном случае от Monobehavior
А его наследников как найти? Вот я в своем проекте допустим пока еще знаю, что есть, потому что скриптов пара десятков. А допустим их больше и программист другой.
Искать в проекте, по идее если проект не даунами деланый, то всё через эксплорер находится изи.
>Искать в проекте
)) чувствую себя гестаповцем на допросе лол. А принцип поиска какой? Т.е. я как ебло пока придумал только один способ. Допустим делаю абстрактный класс Move, например. Все производные от этого класса я называю по принципу Move + особенность наследника, типа MoveLikeDrunk. И задался вопросом, а как надо?
Хз, я соло индюк называю как мне удобно. В компаниях обычно есть стайлгайды, можешь погуглить unity styleguide или как-то так.
Сделать абстрактный геттер с возвращаемым типом. Вроде
protected abstract Type OwnType {get}
И перегружать OwnType => typeof(MyChild)
Для наследников можешь делать дженерик-классы
Если там такая же залупа как с аниматором, то беги нахуй оттуда.
делай страницу игры в магазине лучше и не отражающей реальность
и это база
я привык к решерперу. показывает много чего удобного
в самой вс вроде была где-то иерархия классов но никогда не пользовался
из минусов - он пиздец какой тяжелый стал в последнее время.
в нагрузку очень сильно ебет мозги сменой парадигмы программирования.
Нужно. У меня ВИЗУАЛЬНАЯ НОВЕЛЛА.
Блендшейпы не для всех выражений подходят, потому что челюсть отдельным мешем- но она заригана, и движение челюсти отдельно ещё больше искажают меш головы.
>Нужно.
Тогда вертись кабанчиком, изучай, мониторь все что можно
Я чёт даже не видел ВН с анимированными ебальниками. Обычно же тупо заготовленные картинки юзают, не?
Единственный способ скуфу почувствовать себя чэдом.
>>844622
Heavy Rain, Life is Strange, Last of Us, Walking Dead - это не ВН по-твоему? Даже если нет, то в анимешном стиле тоже есть новеллы с модельками.
>Heavy Rain, Life is Strange, Last of Us, Walking Dead - это не ВН по-твоему?
По-моему это буквально называется интерактивное кино
Есть бюджет - полагаемся на арт, мокап, озвучку и виз. эффекты = кино.
Нет бюджета - полагаемся на готовые модельки и текст = ВН.
Но технически суть одна.
В большинстве современных игр используется костная анимация ебала.
В общем, я решил комбинировать бленд шейпы с ригом для челюсти и глаз.
лично я пищу рогалик-идлер на экс! лицевые анимации не нужны
сука, мама роди меня обратно. ну что за херня со стандартными класами. есть DynamicBuffer<LinkedEntityGroup> который вроде бы как отвечает за связи. если убить родителя - должны убиться связанные объекты. ок настроил. настроил заодно отдельно иерархию в инспекторе(в экс все отдельно. это основной принцип. можешь разбить любую логику на отдельные шаги и сущности - РАЗБИВАЙ). убиваются все кроме первого в списке. он есть в списке. но не убивается. вот что за хуйня. хорошо что логика отдельных компонентов полностью самостоятельна и отвечает за одно конкретное действие. ну т.е. архетектура подразумевает что никак не связана и она таки да. выкинул нахер LinkedEntityGroup. захуярил свою parent-child связку. все работает все удаляется.... ready to production блядь
Есть Live2D с интеграцией с Unity, свежая версия с кряком есть на рутрекере. Именно ей и делают живые лица в новеллах
Не шаришь, это базированный подход, использовать аниматор чтобы в редакторе визуально стейт машину настраивать для поведения чего-то
В синемашине так сделано например тоже.
Дибилыч?
>>843883
База. Но не совсем. Открыто должно быть только то, что должно быть открыто, обычно то что в
>>844015
> Почему нельзя как в вебе, где используя html css Js (а ещё лучше какое-нибудь react или Vue) можно сделать фактически любой дизаен, с анимацией в том числе.
Можно. UI Toolkit.
хочу сделать красивый шедевральный(арт, геймлей, история) 2д-квест.
с чего начать? так много уроков на рус/англ, там много книг - глаза разбегаются. С чего начать?
(пока хочу сделать каркас, а потом за будущую долю от прибыли найму хорошего художника)
(в одиночку всё, друзей нема)
и еще потом хочу сделать 2.5д изометричекий квести по мотивам сериала топи
ну русские болота, деревни, мистика, все такое %)
Есть ведь такая штука, которая облегчает создание пет проектов для соло разрабов?
я конечно сейчас пойду загуглю, но интересно ваше мнение на счет таких штук
Допустим в соответствии с паттерном разбиваю код на 3 основных части.
Модель - туда уходят только данные касающиеся непосредственно характеристик - хп, скорость, баунти, резисты хуисты и ттому подобное, переменные касающиеся навигации туда не уходят. Она не моно и данные наверное надо в нее подгружать из скриптабл обжекта. СО передается через конструктор.
Вью это моно и будет префабом, в коде содержатся данные только о визуале, анимация, спрайт рендерер, звук, хпбар.
Соответственно, видимо класс спавнер, как связующее звено между фабрикой и данными о префабах должен создавать контроллер и выглядеть это должно приблизительно так new EnemyController(EnemyVeiw - созданный фабрикой префаб, new enemy(enemySO)) и в класс контроллер уходит вся требуха о передвижении, обработке урона, эффектов и так далее. А тот же вью, будет только обрабатывать команды от контроллера типо View.playAttackAnimation();
Вроде +- понятно. Единственно я не уверен насчет кода о передвижении. Т.е. вроде кажется логично, что передвижения обрабатываются в контроллере, а потом вью просто получает команду сместиться в координаты, но так ли это должно быть? И допустим , если взять ХипПоинты. Контроллер модели передает команду - ты получил изменение хипоинтов на такую-то величину, Логика обсчета этого изменения инкапсулируется внутри модели же и контроллер про такую хуйню вообще ничего знать не должен?
Взаимодействие с другими суцьностями идет через вью получается чтоли? рейкасты в колайдеры и так далее. Получается эти данные надо через вью передавать в контролер эвентами чтоли? Я же напрямую к контроллеру то обратиться не могу.
>А тот же вью, будет только обрабатывать команды от контроллера типо View.playAttackAnimation();
Представление (View) отвечает за отображение данных модели пользователю, реагируя на изменения модели[1].
однако здравствуйте. получается нихуя не так, если идти строго по догме, то контроллер только прокидывает эвент.
А вся логика сидит в модели. хмм.
А потом заходишь на метанит, а там пишут, что вся вычислительная логика не в модели нихуя, а в контроллере лол)))))))) и ебись как хочешь.
>>844800
>>844783
>>844774
Модель, подходящую для создания интерфейсов, неоправданно использовать в более сложных объектах. Тем более в юнити, где один объект состоит из множества компонентов.
Для начала, вью у тебя УЖЕ отделён на архитектурном уровне - это компоненты Sprite renderer, Mesh renderer и так далее.
Моделью могут быть статы в Scriptable object, если под моделью подразумевать чистые данные.
А вот всё остальное придётся назвать "контроллером", что не очень помогает. И вообще, в контексте игр, контроллер - это объект, который принимает ввод с устройства ввода.
А насчет скриптабле обжекта. Допустим я вынесу базовые статы в отдельный СО, там есть характеристики типа скорость, которые могут изменяться в течение жизни отдельной сущности, например эффектом замедления. Если я поменяю скорость напрямую в обьекте, она изменится во всех. Это неправильно. Если я скопирую все данные из СО в другой обьект, чтобы уже там их крутить вертеть, получается тупо и дублирование вроде как. Я так понимаю, чтобы было по уму, придется мутить декоратор?
Обычно там хранят неизменяемые данные.
Вот хороший пример https://habr.com/ru/post/421523/
А изменение скорости отдельного юнита лучше прописывать в отдельном скрипте "Модификторы", например.
Мне такой подход не нравится, че толку с этой изоляции данных? По сути если делать модель только для данных, то логику получается просто в контроллер придется скинуть, и там же будет логика которая прокидывает все это к вью. Фу. Ниче и не меняется по сути по сравнению с тем, чтобы ну просто открыть скрипт и просто там все в куче написать.
Я обычно делаю мвп
Модель - скрипт отвечющий за логику и данные. Он и коллизии обрабатывает, и хранит параметры, и какие-то ивенты там запускает, и в апдейте что-то крутит. Но абсолютно никак не касается графики. Иногда добавляю какие-нибудь дополнительные ивенты или еще что, чтобы к ним можно было проще презентер прицепить.
Презентер - скрипт который зависит от модели, и обновляет всю графику от ее состояния.
Получается, вся логика и графика разделены, и если нужно для одной модели можно сделать несколько разных презентеров, чтобы и графику тоже разделить на части - один там аниацию персонажа обновляет, другой партиклы пыли спавнит под ногами.
Да, ецс у меня некст по плану изучать. Посмотрим че там юнитеки намутили на релизе!
Модель в юнити, как правило, состоит из многих компонентов. Много разных данных, много скриптов.
Да, само собой, по необходимости модель стоит дробить. Очевидный пример - какой-нибудь компонент для хп(типа модель), и презентер который отображает это хп.
без учета юнитеков - разделяй и властвуй. могешь разделить любое действие на элементарные - РАЗДЕЛЯЙ. может на этот момент когда ты это делаешь выглядит избыточным, но завтра, когда понадобится новая фича, ты скажешь спасибо
можно перевести на русский что он сказал? слова воопшем-то знакомые но смысл ускользает. при чем тут парадоксы? при чем тут клон парадоксодрочильни? при чем тут тера инвикта? при чем тут моды? при чем тут моно?
Он сказал: кто-то недавно спрашивал, как сделать клон парадоксоигры - вот смотрите, я наткнулся на игру сделанную в одиночку.
Блин, стремно что я понимаю местных шизов. Я еще понимаю нормисный язык, но надолго ли.
дык она не в соло сделана, а командой (небольшой да) которая лонг вар моды на икском пилила
Немного подправил. Уже вроде попизже получается.
Инкапсулировал работу с аниматором, теперь энеми похуй что в аниматоре происходит. Грит мне анимацию такую дай, как будешь делать не ебет вообще.
Вынес статы в отдельный класс разделил игровую смерть и удаление. Теперь статы сообщают наверх, что объект умер, управляющий срипт делает с этим что хочет, потом когда посчитает нужным запускает свой эвент на фабрику, что пора бы удалиться.
Раньше спавнер использовал напрямую метод SetPath в энеми, что хуйня вроде как, теперь спавнер просто передает нужные данные в энеми через инициализирующий метод.
Осталость только инкапсулировать в отдельный класс выделенное красным и снаебнуть скорее всего стратегию, чтобы енеми мог менять поведение с похода по вейпоинтам до базы игрока на режим подраться в рукопашку с защитником из башни. Но это я наверное не быстро нахуярю.
Вот такие дела, маслятки.
> UI Toolkit.
странное. не ну юзабельно и местами удобно. стили опять же.
НО
кустом контролы это нечто слишком херово сделано. они создаются только кодом. т.е. возьмем стандартный прогрессбар. самое базовое - бекграунд - филлер - текст. я должен в коде прописать создание этих саб элементов и в коде же задать все параметры включая стили. ок я понимаю биндинги к данным или поведение задать только кодом, но почему нельзя скормить ему готовый юидокумент как шаблон?
вместо простенького
<ui:VisualElement class:"progress-bar__background">
<ui:VisualElement class:"progress-bar__filler" />
<ui:Label class:"progress-bar__text" />
</ui:VisualElement>
попутно настроив все нужные стили в визуальном редакторе
я должен делать
var back = new VisualElement();
back.AddToClassList("progress-bar__background")
Add(back)
var filler = new VisualElement()
filler.AddToClassList("progress-bar__filler")
back.Add(filler)
var label = new Label()
label.AddToClassList("progress-bar__text")
back.Add(label)
после чего компилировать, кидать на форму и уже там настраивать дефолтные стили(банально расположение компонентов относительно друг друга)
а если нужно что-то добавить или поменять структуру - повторить. я сначала думал что я что-то упускаю и есть какой метод типа LoadDocument() которому можно скормить uxml, но нет. в чем великая сермяжная суть делать вот такой uxml-based интерфейс и заставлять собирать его кодом?
далее стили для этих вложенных элементов в редакторе менять нельзя. только ручками прописывать стиль на основе стандартного. а там жопа вроде .unity-progress-bar__background-container которое не только скопировать нельзя оно еще не помещается в поле редактора и обрезается посему его надо гуглить отдельно. отдельно доставляет что в гайдлайнах не рекомендуют использовать длинные имена. и сами используют
Вот хочу просто персонажем по локациям побегать, под каркасом понимаю это. Без миссий, триггеров, квестов.
Как начать?
>>844994
вот буквально ECS чар котнтроллер ассетс. тупо контроллер чара и сампл сцена по которой можно побегать. пример как делать это в екс
Не надо делать ECS, если у тебя только не тысячи юнитов с ИИ в риалтайме пиздиться будут на одном экране.
Чета заебало последнее время, как убрать?
Не по теме, но добавлю что перекатился с 2022 на 2019, по причине багов и заторможенности.
По твоему кейсу чекай авто замену в настройках, там где интелектуальна.
Да, мне тож не очень зашло, но вроде бы они недавно его обновили
Надо как-то исключить детей из системы отслеживания клика. Чтобы клик на ребенка считался не кликом на него конкретно, а кликом на весь родительский объект.
Все, сам нагуглил. Надо было Picking mode установить в ignore у этих элементов.
Суть: звуки шагов. Я их реализовал как инстанс префабами (метод инстанса дергается через анимацию). Они по рандому проигрывают аудиосоурс из массива и самоуничтожаются.
Проблема: то что хорошо выглядит в траве или на деревянной поверхности плохо выглядит на твердой поверхности(на каменном полу где хочется однообразного "туп-топ-туп-топ").
Как это можно реализовать? У меня в голове пока только вариант перехватывать одним инстансенным объектом предыдущий пока тот не уничтожился и считывать из него флажок. Но это видится нерациональным
Ну бля оберни все в какой-то класс, который сохраняет звук из последнего инстанса.
Например, анимация в нужном месте запускает анимационный эвент. Эвент обращается к классу, который содержит в себе возможные звуки шагов и последний сыгранный и говорит ему - играй сука. Тот обращается классу, который детектит поверхность, а тот отвечает - пещера, ебать. Тут класс, который содержит в себе звуки создает через интерфейс new PesherniyRejim(lastSound,audiosorse). Послдений начинает кормить аудиосорсу одинаковые звуки. Для остальнх соотвественно звуки бы выбирались отличные от предыдущего. Я бы делал как-то так наверное
В обучалке юнити была эта тема, 6 пункт посмотри
https://learn.unity.com/tutorial/create-dynamic-sound-effects?pathwayId=61a65568edbc2a00206076dd&missionId=61a615eaedbc2a03fbc84c03#
> плохо выглядит на твердой поверхности(на каменном полу где хочется однообразного "туп-топ-туп-топ").
Ну так подбери однообразные звуки. Открой любую классическую игру типа халвы и там даже на твердой поверхности есть рандом шагов.
Не понял вопроса. У тебя все звуки хранятся в одном массиве? ну так сделай ты несколько массивов по типам поверхности. А тип поверхности получай от коллайдера, когда вступаешь на новый тип поверхности.
Нормально делать слишком тяжеловесно для обзора.
А так, скорее всего суть в том, что интерфейс был IDamageable ил что-то подобное. Ну еще нужен менеджер мира какой-то например если мы хотим AoE урон, но для простой игры это не нужно. Так что тут фишка в том что ты не связываешь свой мяч обязанностью знать устройство игрока, а можешь наносить урон любому с таким интерфейсом. Например не игроку, а животному, ящику и т.п.
Нет, смысл был не в гибкости, а стояла конкретная задача, прокинуть связь до мяча. Он на мяч передал игрока как интерфейс через цепочку классов. Типо класс контроллер начинает игру, создает класс игрока, потом создает игровую доску и передает ей класс игрока, та создает спавнер шаров и передает ему класс игрока, тоо передает игрока шарам и они его запоминают. Только он интерфейсом его передал. Типо шар не должен знать об игроке, но может иметь ссылку на его интерфейс.
Т.е. получается, что упаковка метода убавления хп у игрока в интерфейс является по своему смыслу колбеком, который передается по цепочке куда-то на дно.
Смысл всегда в гибкости, а именно, в возможности потом делать легкие изменения. Если ты напрямую связан с классом игрока, а класс игрока еще с чем то, а там еще, то хрен ты потом этот лапшекод изменишь когда захочешь добавить новые сущности.
Интерфейс на то и является ИНТЕРФЕЙСОМ, что через него взаимодействуют, а не с функциями или переменными игрока напрямую.
Бля. Лол. Чувак говорит, нельзя передавать класс игрока в шар, потому что шар низкоуровневый класс и по ооп не имеет права знать об игроке. На вопрос, а как? Он накидывает на игрока интерфейс и передает его. Интерфейс ни для какой не гибкости, а конкретно для передачи одного метода от игрока до мяча. Снабжая это комментариями о том, что мяч не должен иметь доступ к игроку и его функциям, которые мячу не нужны, а вот эту конкретную ему послать можно. Ты просто к слову интерфейс докопался, не понимая, что это реализация колбека просто такая
Ну вот ты пересказываешь то, что я и говорю. Все верно. Шару нельзя знать класс игрок, ему можно знать интерфейс с одной функцией "получить урон". Хз че тебя не устраивает.
Почему это гибкость в будущем, я тебе уже тоже два раза объяснил.
Как минимум чтобы у тебя не было портянки
if (obj is Player) (Player)obj.damage(val)
else
if (obj is Breakable) (Breakable)obj.do_wall_damage(val)
и тд
Будет прсто
damage(IDamageable obj)
obj.damage(val)
возможно у тебя вызывает неприятие что он передает тот же самый объект плеер.
но это так и работает, потому что за интерфейсом всегда находится какой-то конкретный объект.
Просто тебе с этой стороны интерфейса неважно. Если ты подключаешь кабель IDE, тебе неважно что там - жесткий диск, дисковод, ссд. Но реальный объект там все равно есть и он как-то будет передан. А если подключаться без интерфейса, это как если бы ты провода прямо в контроллер жд впаивал.
Но в реальности схема может быть сложнее, там может быть менеджер мира или сервис локатор, который подберет подходящий объект и т.д.
>>845147
>Там вопрос абстракции вообще не стоял и не поднимался.
> частой ошибкой там было, что начинающие девелоперы передавали ссылку на класс игрока,
и вопрос чего это по твоему, как не абстракций?
iplayerdamagehandler это жесткий диск, хдд или сидиром? Сколько уровней абстракции в этом интерфейсе можно почувствовать?
В общем, дружище, я тебе благодарен, что ты откликнулся на вопрос о помощи. Но, если честно, вопрос был вообще в другом.
Хотя пизжу, ответ был. Ебну синьки сегодня в честь праздника и займусь рефакторингом))))))))
Ты уже научился создавать скрипты, глядишь через пару месяцев дойдешь до создания куба на сцене.
Для игры типа шариков это вообще не нужно. А для более сложной игры, ссылки на все IDamageable нужно будет хранить в одном компоненте, а потом передавать ему сообщения вида "персонаж X нанёc персонажу Y ущерба на Z хитпойнов", дёргая методы либо через делегаты.
>>845140
Не знаю, зачем так делать, особенно для простых игр. Unity-подход для внедрения зависимостей - это как раз выставление объектов в инспекторе, а не создание через код.
>Unity-подход для внедрения зависимостей - это как раз выставление объектов в инспекторе, а не создание через код.
Есть мнение, что на юнити подходе дальше игр про падающие шарики будет тяжело уехать.
> Не знаю, зачем так делать, особенно для простых игр. Unity-подход для внедрения зависимостей - это как раз выставление объектов в инспекторе, а не создание через код.
Для простых игр базовички вешают зенжект, катаются еблом по клаве и просто смеются юнити в инспектор.
А там в эксплорере можно убрать отображение мета файлов? Чтобы только скрипты были видны чi не? И типо чтобы в вс код создать новый скрипт я так понимаю надо создавать новый файл в формате имя.cs?
>Не знаю, зачем так делать, особенно для простых игр
Ну чел, который это делал, учил не создавать игру про шарики оптимальным образом, он на основе разбора игры про шарики показывает подходы и знакомит зрителей с основными правилами ооп.
> Но пока думал, как сделать удобнее работу с Ide дошел до одной очевидной вещи, что не надо табаться в юнити и там создавать скрипты, а их можно прям в иде создавать лол. Это кстати реально бесило.
Всм? В вижуал студии тоже.
Ну типо когда ты смотришь видео и курсы, в тебя один шаблон действий закладывают, что ты все делаешь через юнити едитор. И я допустим просто не думал о том, что можно работу со скриптами в полном объеме делать в вижуал студии. А потом как понял, переместил вкладку солюшен как мне удобно, раскрыл скрипты и все стало в миллион раз удобнее.
Еще можно отключить автокомпиляцию скриптов, чтобы юнити не пытался каждый раз когда ты с иде переходишь в него переподгрузить скрипты, а только горячей клавишей.
Запомнить что при переходе на другую версию проекты могут ломаться, и впредь не переходить на другую версию во время разработки.
И что всю жизнь сидеть на говне мамонта? Когда в каждой версии что-то фиксится и добавляется?
> Когда в каждой версии что-то фиксится
Минорные релизы(цифра после f) апи не меняют, на них можешь переходить.
у папочек в солющене еще можно отключить флажок "namespace provider" тогда не будет назначать.
воопше там есть где поигратся с опциями. хз решерпер это делает или сама вс но если у тебя в папке файлы в одном неймспейсе, то она проставляет этот неймспейс а не путь
дык я не страдаю, наоборот люблю все красиво по неймспейсам раскидать
особенно в гребанном экс, где на каждый пук 10 компонентов 20 систем и пара тагов.
<link> атрибут у текста. в примерах текстмешпро LinkSample показывает как с ними работать.
fbx. блендер его спойно экпортирует а юнити нативно хавает. собственно юнити хавает и свой формат блендера но самостоятельно конвертит в фбх используя блендер
По анимациям косяков не будет? В годоте это была боль требующая дополнительных шагов.
Первый раз во время экспорта чекни повороты по Y,и размеры в настройках импорта. Если все ок, то можеш забыть о траблах навсегда. Также есть разные тонкости экспорта анимаций, но это уже потом когда начнешь их делать.
Че по схеме. Класс buildingUI будет содержать в себе метод инициации Init, который на основе информации из класса building должен спавнить кнопки с иконками башен. К нему напрямую может обратиться только UIHandler. В самом UIhandler будет метод, который будет инкапсулировать в себя BuildingUI.Init(), и метод этот будет выделен в отдельный интерфейс. Соответственно Game при запуске игры, имея доступ к UIhandler, будет передавать этот интерфейс через Gameboard по цепочке до класса, который контролирует процесс постройки.
Балдеж же вроде?
И В итоге получается типо MVC вроде как. Я только тут не понимаю один момент, как правильно соединять эвент из Building с методом инициализации Building UI. TowerBuildHadler должен просто подписать переданный интерфейс на евент класса building, а все нужные параметры building передает через параметры эвента, правильно?
И еще вопрос, если мне нужно будет достать эвент из класса ниже чем BuildingUI? у меня все равно должна сохраниться иерархическая цепочка, где Game не лезет ниже чем UIHandler?
Братишка, попробуй написать скрипты, а не скрипт.
Мимо автор говносхемы снизу.
Это норма, и это правильный подход если не знаешь что будет в игре дальше и придумываешь на ходу.
Не бойся рефакторить и переписывать скрипты. Удобнее даже их разделять на несколько и строить по схеме модульности, что если меняешь один, другие не сыпятся следом.
Сам building выгядит вот так. Насколько я понимаю, если я в таком виде отправлю информацию через эвент в UI, который занимается спавном кнопок, то это не правильно. Потому что этому UI по факту придется препарировать полученный класс, а он типо не сильно должен вообще о таком знать, он просто должен получить число кнопок, картинки к ним и цифру денег, так?
С другой стороны, в старой версии у меня был вот такой подход. Связующий класс через эвент получал доступ к building, из билдинга доставал массив ангрейдов и прогоняя его через for давал команду BuildUI на активацию каждой кнопки по отдельности через метод ActivateButton , где соответственно индексы кнопок совпадают с индексами апгрейдов. Т.е. класс обозначенный на схеме как TowerBildHandler берет на себя всю обработку информации, а не подписывает тупо методы на эвенты.
С моего дна, вроде как кажется, что так правильнее делать.
Есть эксперты по архитектуре? солидам-хуелидам.
Бля без обид, но ты делаешь явно какуюто хуйню.
Палю идеально, и просто решение одновременно.
Создаешь 1 скрипт - Кнопка менджер. В нем при старте создаешь кнопки.
Он принимает только команду - включить/выключить кнопку(С кастомными настройками по типу картинки/текста).
Из 2 скрипта логики игры ты тупо посылаешь команды - Сделать видмыми какие кнопки, и при нужности меняшешь картинки/текст на них.
Это тупо занимает пару строк, при этом никакой дрочи с тем что утебя на скринах.
А если допустим я напишу отдельный скрипт для кнопок в BuildUI и сделаю там метод инициализации тоже? И получится такая цепочка, что в BuildUI через эвент присылается массив upgrades. А BuildUI через for циклит этот массив и передает Building из него непосредственно в кнопки через button.Init(Building), а кнопки этот билдинг самостоятельно препарируют? можно так?
Ты буквально описал то, как у меня работало до этого, просто у меня связи были с нарушениями, на втором скрине ссылка на контроллер, который был самым топовым классом, например. А принцип такой и был, что класс обрабатывающий всю хуйню давал команду на включение, конкретных кнопок.
>>845457
Спасибо посоны, я в принципе стараюсь модульно писать, и внутри скрипта всё разбивать на аккуратненькие функции с одной задачей у каждой, но сами понимаете во время эксперимента просто хотел получить пруф оф концепт и не заметил как наебенил говна. Но пруф оф концепт получил.
Ну балдеж же?
Запомни - Упрощение логики залог успеха. А то что ты нагородил это усложнение читаемости и количества на ровном месте. Убирай эту хуету и делай по нормальному.
Интерфейс не правильно сделал. Он должен не метод инициализации делегировать, а сам buildUI прокинуть и тогда можно на обратные эвенты подписаться. Даже из названия это следует. Как же реально упрощает жизнь отдельный скрипт для каждой залупы, для каждой сраной кнопочки.
>>845475
Да бля возьми ты уже зенжект, на это же больно смотреть. Ты ж облысеешь эту лапшу писать дальше.
Не задумки так то твои логику имеют, но сколько же тут чисто механически дроча на ровном месте просто потому что ты решил делать классическую ооп архитектуру в стиле 90х а она тут не нужна.
та хто такой этнот ваш хрюнжект и почему я пишут в требования к РАБоте
https://www.youtube.com/watch?v=hsK3h49VIvc
а сделай мне игру что бы эльфы в лесу и домики деревянные набегают и злой в замке.
>классическую ооп архитектуру в стиле 90х
буду в резюме так писать
Тогда понятно, почему тут сидят люди, которые никогда в жизни ничего не выпустят
Блять, зачем вы это распространяете? Гиперверие лишь всё усугубит.
>>845507
Ну, то и я не сделаю. А ИИ в скором времени сможет.
>>845508
Не гугла. Это убийца форумов и чатов
зы. а если серьезно - это же название параметра а не тип.
Это сделано для таких ситуаций когда у тебя функция
foo(int, int)
И тебе подсказывает
Variable1 = 13
Variable2 = 27
foo(залупа: Variable1, говно: Variable2)
Чтобы ты не написал случайно
foo(залупа: Variable2, говно: Variable1)
Дженерики делались в том числе для того чтобы в коробчку инты не класть. Над загуглить.
https://forum.unity.com/threads/in-c-how-to-avoid-boxing-unboxing-of-the-value-types-in-generic-methods.1135822/
я там следующим постом написал что это имя параметра а не тип же.
>>845576
>>845578
Всем поебать на этот боксинг раз в 10 секунд, вы лучше рендер тред оптимизируйте.
Судя по тому что даже в оф документации пишут отвязывать руками, видимо всё правильно делаешь.
Ты про стандартные события Си-шарпа? Если да, то надо отвязывать обязательно. Это такое негласное правило. Более того, если ты подписан на событие какого-нибудь долгоживущего объекта или синглтона, то подписанный объект будет долго жить.
Конечно. Лайфтайм подписок полностью на тебе.
А вот юнитиивенты автоматом отвязываются.
Вообще ивенты лучше не юзать, у них не удобный синтаксис, юзай юнирх.
>>845597
>Ты про стандартные события Си-шарпа?
Про те, которые из юнити, из нового интерфейса, которые вешаются на VisualElement через RegisterCallback. Но, думается мне, это однохуйственно.
Алсо да, пилю свое поделие на UI Toolkit, зависимость уже появляется. Без документации конечно тяжеловато, но все необходимые моменты уже прохавал.
>Вообще ивенты лучше не юзать, у них не удобный синтаксис
Ты дебс? Что там неудобного?
а у меня появляется зависимость от экс
только по этому треду. пожалуй таки большая часть упоминаний его здесь от меня(прошу извинить - меня таки торкнуло). в других тредах(включая прошый юнити тред) не срал
Документацию по нему то завезли уже? А то я не ебать какой уверенный кодер.
весьма и весьма базовую. приходится страдать на ютуб видео 2.5 человек(буквально. первый начал в древности, но с тех пор апи сильно поменялось а он воопшем-то подзабил. второй начала тогда же и старается освещать изменения - приходится понимать как оно работало тогда, работало в промежутке и работает сейчас. третий таки вроде начал новое почти с нуля, но пока дошел только до самой базы - все остальное безбожно устарело и/или туториалы уровня "как нарисовать сову" или совсем пространные рассуждения "экс - крута" без конкретики) остается копать на форуме и автодоках с херовым описанием
хы. CodeMonkey, Turbo Makes Games, WAYN Games соответвенно
Понятно, в общем как я и боялся. Собсно апгрейдиться я и не собирался, максимум сделаю проект тупо поиграться, но сперва игру допилю до релиза в стиме.
оно странное. но все сводится к чистому "взять один набор данных. посчитать. сохранить результат" и порядок этого. приходится ломать привычки и учится программировать заново. с другой стороны оно логично перетекает в максимальную изоляцию элементов и многопоточность
>>845620
ессно что-то хотя бы частично готовое переносить смысла нет.
Ну надо сначала писать
Zalupa += hueta
Потом в другом месте
Zalupa -= hueta
А если где-то забыл? И не надо говорить, что не забудешь.
Причем сразу лямбду ты не можешь туда запихнуть, обязан еще одну функцию писать, даже если там дел в одну строку.
А вот с юнирх все просто
Zalupa.Subscribe(_ => {....}).AddTo(this);
И все, все само отпишется когда геймобдект уничтожишь. Или можно это вообще в любой класс вешать в композит диспосабл, не обязательно в монобех.
>>845625
Ааа, так это их обновленный екс?
А ты прям все на екс пишешь, или смешиваешь с другим подходом? Мне кажется ui на екс делать с ума можно будет сойти.
я пока тупо эксперементирую и разбираюсь
ессно смешиваю. гуя на экс нет в принципе. но тут есть нюанс - ты считаешь все в экс а результаты уже ложишь в гуй(или любые другие "стандартные" объекты юнити, которые не имеют прямого отображения в экс) через классы прокладки(вот ButtonDebugRef - это как раз такой) вот например всякие прогресбары - хп там или прогресс какого процесса. создаешь соответвующий гуй элемент стандартно. и делаешь 2 компонента
public class PBRef : IComponentData { public ProgressBar value; }
public class LabelRef : IComponentData { public Label value; }
public struct CurMax : IComponentData { public float Cur; public float Max; }
которые вешаешь на новую энтити. все зачем она нужна по сути - передавать данные из экс. ну и системы которая будет это делать
CopyDataToProgressBarSystem:
foreach(var (bar, cmax) in SystemAPI.Query<PBRef, RefRO<CurMax>>)
{ bar.value.Max = cmax.ValueRO.Max; bar.value.Value = cmax.ValueRO.Cur; }
CopyDataToLabelSystem:
foreach(var (label, cmax) in SystemAPI.Query<LabelRef , RefRO<CurMax>>)
{ label.value.text = $"{cmax.ValueRO.Cur}/{cmax.ValueRO.Max}"; }
максимально просто. за "кадром" эти системы создают зарос на два компонента, и итерируют по ним. так как она работает с классом это "гибридный" экс - логика его но никаких профитов в производительности нет. его имеет смысл положить в фикседапдейт или еще куда более медленное. а вот то что будет писать данные в CurMax - "чистое" экс. добавляем парочку компонентов (все унаследовано от IComponentData, но опущу для простоты)
public struct TagGetProgressFromHP {}
public struct ProgressTarget { public Entity Target }
public struct HPData { public int Hp; public int MaxHP }
первый не содержат собственно данных и является тегом - по сути меткой какую систему гонять. вешаем прогресстаргет и тег на ту же энтити. в прогресстаргет ложим энтити с хп
CopyDataFromHPSystem:
foreach(var (cmax, target) in SystemAPI.Query<RefRW<CurMax>, RefRO<ProgressTarget>>.WithAll<TagGetProgressFromHP>()) {
var hp = SystemAPI.GetComponent<HPData>(target.ValueRO.Target);
cmax.ValueRW.Cur = hp.Hp;
cmax.ValueRW.Max = hp.MaxHP; }
опять все сводится к элементарным действиям. на первый взгляд громоздко(особенно учитывая что я опустил описания систем, оставив только код) - 3 системы и 6 компонентов для отображения текста и хпбара. но в этом суть. мы реализуем ОДНО изолированное действие за раз. получаем цепочку действий которые взаимодействуют через общие компоненты данных. можно легко заменять источник и получатель и связанную логику, вставляя и пропуская шаги или делая альтернативные ветки - например вместо стандартного прогрессбара использовать какой свой типа радиального или воопше повесить логику которая будет обновлять модельку в зависимости от прогресса строительства. а вместо хп использовать любые данные что ложатся в формат прогрессбара - заполненность инвентаря, кулдаун скила, прогресс строительства и т.п.
и вот это понимание, что все надо дробить дробить и еще раз дробить на максимально элементарные куски да еще разделяя данные и код как раз и ломает шаблон при переходе с ооп.
Прикольно. Скоро думаю тоже буду его ковырять и вести экс пропаганду.
С одной стороны - стили и воопше гибкие настройки самого гуя
С другой стороны - не удобно работать с кодом(за пределами "стандартных" действий - кастом компоненты например) и нельзя нормально в ворлдспейс
Строка: Test1:
Что за символ стоит после двоеточия? Не "", Не " ", Не string.Empty. Что за? Как узнать?
Причем на других позициях нормально считывается, а это строка должна разделяться в массив, но происходит вот эта ошибка при чтении.
Ага, при посте сообщения этот символ удалился, значит это пробел так понимаю или что макаба стирает?
Самый главный плюс - flex. В старых гуях ты ебанешься при попытке сделать что-то сложнее полоски хп или статичной менюшки с кнопками. Любые динамически заполняемые элементы интерфейса - практически невывозимая задача для непрофессионального разработчика. К примеру список выровненных элементов, каждый из которых содержит список выровненных элементов. На новых гуях это задача тривиальная.
Минус, как сказал этот анон >>845667 в том, что непривычно работать с этим интерфейсом в коде. Как в вебе через жабаскрипт, так и тут придется сначала найти нужный элемент по его id, и только потом работать с ним. Т.е. нельзя до рантайма в инспекторе скрипта на префабе рассовать по местам все ссылки. В результате кода может получиться больше, чем раньше за счет ручной инициализации. Но во всем остальном проблем никаких не наблюдаю.
Спокойно работаю с интерфейсом в обычном ui, какие там могут быть сложности?
А ты не знаешь, они сделали в новом УИ виртуальные списки? Помню мне пришлось самому это писать на старом УИ, это такой Ад был.
Виртуальные списки - когда в памяти существуют только элементы, которые видны в данный момент на экране. Даже если в списке 10 тысяч элементов разных размеров и с разными характеристиками, то всё будет идеально работать.
Ну давай заценим твои работы.
>>845680
Очень сомневаюсь. На настоящий момент состояние - "вроде работает". Я сам лично наткнулся на то, что до сих пор не работает событие GeometryChange, причем на форумах об этом писали еще в 2020 году. Так что использовать можно лишь на свой страх и риск. Я просто устал ждать релиза и жру что дают.
ну например в процессе разработки ты накидал временный гуй без нормального скина - сильно заморачиваться смысла нет, оно все равно будет менятся и воопше ты погромист а не дизайнер. к моменту завершения разаботки наконец подъехал цельный, специально сделанный скин от художника и тебе надо его применить. для каждого окошка. для каждой кнопочки. для каждой надписи отдельно. а потом окзалось что вот тот зеленый не такой зеленый как было надо и все повторять... ну опять же вот этот флекс мне сильно знаком по WPF и он очень удобен, хоть и требует привыкания после стандартного формошлепства
>>845680
где-то отдельно упоминалась оптимизация списков в таком ключе. когда модили баттлтех пришлось пилить самим - то еще развлечение, но без этого никак. создание списка эквипа в мечлабе когда перевалили за пару сотен предметов занимало от 10 минут на нормальном компе и обновление фильтров минуты.
> К примеру список выровненных элементов, каждый из которых содержит список выровненных элементов
Layout group + AspectRatioFilter?
Сначала может показаться, что все просто. Но когда у элементов списка есть свои layout group, а у них тоже есть вложенные элементы и т.д., то старый гуй жидко пукает и умирает.
>>845671
Нашел проблему. Она не гуглится и весьма специфична. Для тех кто столкнется - При сохранении класса в файл, юнька по какой то причине в некоторых местах заместо строки сохраняет пустой аски символ. Этот символ не считается за пустоту или за любой другой. Пофиксил это тем что пересобрал класс под другим именем и другой формой записи.
>>845673
Да еслиб это было так просто, то мои 5 дебаг проверок это бы сразу выявили.
И в чем проблема? Какой именно символ, какой у него ascii код? В hex editor что пишет? Почему он туда попал, из html копировал? Что именно его туда сохраняет?
>И в чем проблема
При чтении строки крашится игра ссылаясь на null референс, будто строки или файлы сохранения не существует, остальные же строки читаются нормально.
>Какой именно символ, какой у него ascii код
Не знаю как узнать. Видится как обычный пробел " ", но при этом не детектится в проверках как пробел, пустота, или что еще.
>В hex editor что пишет
У меня такого нету.
>Почему он туда попал, из html копировал? Что именно его туда сохраняет?
Обычная строка с данными, коих пару десятков в сэйве(Сохраняется прогресс игры). Сохраняю и загружаю через бинари.
>Сохраняю и загружаю через бинари.
> пересобрал класс под другим именем и другой формой записи.
Какая связь вообще?
Если ты делаешь сейв игры, очевидно ты пишешь туда мусор, либо нулевой символ, либо какой-то другой непечатный.
Чем ты читаешь? Проблема была только с одной строкой, от этого и мистика. Поменяв название класс аи чередность строк проблема решилась. Это из разряда - Юнька что-то сломала, но потом сама и починила.
У меня тоже раз была проблема с невидимым символом в конце строки >>838272 →
> Но когда у элементов списка есть свои layout group, а у них тоже есть вложенные элементы и т.д
Ваще не проблема же, если ты все скалирование настроил у каждого отдельного элемента.
Но да, я не отрицаю, что это несколько заебно в некоторых ситуация и может быть придется что-то упростить, но если совсем уж с ума не сходить и не делать редактор уровней так то все изи делается обычно.
>>845476
Крутил, вертел, чувствую не то нихуя. В итоге двое суток ушло на то, чтобы догадаться, что соединять надо не Building и BuildingUI, а BuildingUI и класс обрабатывающий запросы на постройку и пиздец все шоколадно стало. Но могли бы и подсказать ебанарот.
У меня тут на втором и третьем скрине есть эвенты, которые выполняют одну и туже функцию - просто пробрасывают один и тот же инт с днища наверх. Допустимо их в таком случае называть одинаково или лучше попердеть над названиями?
Написано же что файл используется. Попробуй перезагрузить компьютер и удалить. Если уж не в терпешь то скачай анлокер файлов, такая маленькая тулза, она позволяет удалять любые файлы когда угодно.
Да делаю я, делаю. Просто вдруг какой-то более успешный чем я разраб желает попиздеть, то я не против послушать.
>более успешный чем я разраб
А тут успешные в принципе есть?
Кстати юнитеки даже туториал сделал по тому как свой говнопроект на гитхаб залить, через Github desktop всё в пару щелчков делается
Вопрос нериторический. У меня при инициализации UI запускается цепочка инициализаций, на каждом отдельном уровне которой происходит подписание на эвенты. При закрытии UI происходит по сути полная деинициализация с обратным эффектом. Тут у меня два стула.
Стул-первый, подписание/отписание эвентов - затратная операция. Т.е. каждый раз когда я врубаю/вырубаю UI оно жрет какую-то лишнюю капельку.
Стул второй, я могу вынести инициализацию в отдельный класс. При запуске игры, будет запущена цепочка инициализаций, весь UI подпишется друг на друга туда сюда. Вызов отдельных элементов ГШ соответственно вынести в отдельные методы вызова. Проблема в том, что в таком случае UI будет перманентно откликаться на все события в игре и даже в выключенном состоянии что-то перезаписывать и как-то реагировать.
Как бы вы сделали ммммМ?
А нет нихуя не два стула, второй надо делать. Вопрос отпал.
>Стул-первый, подписание/отписание эвентов - затратная операция.
а ты это профилировал? это не должно быть особо затратной операцией, у тебя там сотни тысяч этого все что ли?
Да это не затратные операции. То, что их дохуя, создает иллюзию сложности. В реальности они все по затратности как отрисовка куба какого нибудь или сферы.
> Стул-первый, подписание/отписание эвентов - затратная операция.
Пизда затратная, штук 10, да пусть хоть 1000, элементов в список обсерверов добавить.
Ты давай лучше с профайлером прогони и посмотри что реально производительность жрет.
> и даже в выключенном состоянии что-то перезаписывать и как-то реагировать.
Что конкретно? Тут как бы от твоей архитектуры и нужной тебе логики зависит, скорее всего можно вообще забить хуй и пусть оно "реагирует".
Нет, ты по идее делаешь коммиты каждый раз когда добавляешь новую фичу, или даже функцию, или вообще строчку, как тебе нравится, но как правило чем чаще тем лучше. И комменты пиши нормальные, чтобы самому потом понятно было.
>Что конкретно? Тут как бы от твоей архитектуры и нужной тебе логики зависит, скорее всего можно вообще забить хуй и пусть оно "реагирует".
А ничего на самом деле, я поспешил с вопросом, потом подумал, и придумал как логику разделить и там все заебись вообще. Т.е. если выделить логику инициализации как создание связей между элементами УИ, а запросы на активацию уже этих отдельных элементов и скакрмливание туда внешней информации вынести в отдельные методы, то все шикарно просто будет и читаемость возрастет и производительность даже лучше станет.
>а ты это профилировал? это не должно быть особо затратной операцией, у тебя там сотни тысяч этого все что ли?
Нет, у меня объемы небольшие, будет незаметно на самом деле. Но код как оказалось неудачный, переделывать больше по этому буду.
Ебаться с анимациями чтобы голова стабильной оставалась или синмашина поможет решить вопрос?
Нахуй она костью головы двигается, пусть следует за позицией персонажа с оффсетом.
А башка не будет влазить в камеру во время движения? Надо попробовать.
Ну ты бошку лучше удали вообще, оставь до шеи поставь лимиты вращения камеры чтобы внутрь шеи не смотреть
Берешь ассет паки с офф сайты, их них вырезаешь нужные модели. Также отдельно с разных помоек можешь качать. Вариант для особо изысканных эстетов качать ассеты на других движках и также вырывать нужное от туда.
В 99% это быстрее и проще чем пилить самому. Для простого юзай блендер, мелочевку мелкополигональную самому быстрее сделать и натянуть текстуру. Пару видосов по блендеру и все получится.
Не можу, я планирую мультиплеер сделать, башку будут видеть все кроме тебя кек.
Я чё долбоёб еще в моделлинг влезать, учить блендер, кости настраивать. Да пошло оно всё нахуй, куплю в ассетсторе или закажу у моделлера.
Материал это по сути шейдор, копай в этом направление. Но не забывай что там же еще как сделан этот материал в блендере, и через что рендерится. Там куча всего может быть.
>с материалами?
с любыми материалами - нет.
если же ты самоограничишся PBR - то тогда можно настроить одинаково (по одинаковым картам)
есть еще всякие https://armorpaint.org/ которые могут облегчить страдания
>>846096
По факту любой материал лишь графический редактор шейдера, который в конечном итоге конвертируется в код на соответствующем софту языке шейдеров.
Но я надеялся что может есть какой-то конвертер или сопоставление нодов блендера и материалов юньки. Но видимо в блендере на материалы вообще время тратить не стоит.
Под эту схему и башни мои заебись переделываются. балдеж, завтра накидаю.
Я нет, но из-за зп, для меня низковата, но если ты джун, то пиши смело, потому что:
1. Текст могла писать тупая хрюша
2. Знаю много крутых прогеров у которых проблема с грамматикой и даже читают чуть ли не по слогам, хз почему так
> GTAP Game Ireland Limited,
> 500 долларов в месяц
Пусть своих ирландцев за такие деньги нанимают.
>но если ты джун
а уровень джуна это вообще сколько? знание базы редактора и основ шарпа? Или солид + паттерны - необходимый минимум?
Если тебе надо объяснять как выполнять задачу - то ты джун
Если в тебя можно кинуть задачу и ты без вопросов справляешься - ты миддл
Если ты можешь составить план по разработке игры, раскидывать задачи мидлам и обучать джунов - ты помидор
>Если ты можешь составить план по разработке игры
Могу, но не хочу.
> Текст могла писать тупая хрюша
Там 10 человек, какая хрюша
>>846111
А в целом да, можешь писать. Может чел русский плохо знает потому что это не его нативный язык.
Но подозрительно, что за 35 проектов у них команда 10 человек все еще.
> знание базы редактора и основ шарпа?
Смотря что ты подразумеваешь под базой и основами.
> Или солид + паттерны - необходимый минимум?
Паттерны не особо(ну ток синглтон и обсервер=юнити ивенты и си шарп ивенты). Солид скорее да чем нет.
В целом, главное требование для джуна - у него должна быть своя игра сделана. Пусть она будет и простая, но это сразу индикатор, что ты физику можешь натсроить, анимации, юай сверстать и даже как-то кодом все это связать. Это прям самое главное на что смотрят, без этого вряд ли твою кандидатуру будут рассматривать.
>а уровень джуна это вообще сколько
Умение скачать ассет и кинуть его на сцену.
Пошел бы, но это тупой наеб джунов. Им откликнется на вакансию человек 100+, из них либо выберут тех кто готов быть рабом за еду, или будут кидать на тестовом.
А ты хорош, я же действительно могу камеру настроить чтобы она не видела некоторые слои, и засунуть туда башку. Спасибо.
не завидуй додик
>FadeAnimation
Спроси свою нейронку знает ли она про DOTween
Видишь, анон всегда будет знать больше чем говнонейронка. Та будет высирать тебе неоптимальную копипасту из туторов, подходящую только для хелоу ворда, а не реального проекта.
Блядь, я тут подумал, что мне проще самому написать, чем пытаться этой хуйне ради рофла объяснить че от нее требуется лол пахпха
Я уже 3 часа пытаюсь от неё получить вменяемый скрипт для 2д топдаун машинки, она выдаёт какую-то чушь. И хотя у меня есть такие скрипты разного уровня сложности, от простого вращения и изменения велосити, до симуляции колёс - она ничего даже близко похожего до сих пор не смогла выдать, кроме самого примитивного варианта.
Просишь её чуть-чуть усложнить, и начинает выдавать какой-то бред, который не имеет смысла.
Да, прогеров не скоро заменит. Она может в целом делать, то что нужно, но в деталях, например обсираться, пальцы кривые все дела. На картинке сразу видно, так мозг устроен, можно взять картинку и пальцы пофиксить. А с кодом, ну скажешь ты ей мини игру накодить, ну за секунду выдаст тебе 10к строчек, запуск ошибка. Там может не так много фиксануть надо будет, но ты же не сможешь быстро разгрести, что она там наплела. Скорее гугл разорится, она уже хороша в этих небольших подсказках, через три года красота будет. Эта нейронка как конфетка
Мне кажется она норм только когда ты впервые юзаешь какой-то язык и стек и особо не знаешь как там делать даже банальные вещи.
По сути такой своеобразный аналог гугла, с той лишь разницей, что тебе прям сразу код выдается, но его работсоспособность оценить не выйдет.
Так посоны. По ходу пьессы решил инкапсулировать звук и спрайт в отдельный класс. И тут понял, что придется делать такую булдыгу чтоли ебаный икебастос? Или можно по кайфу на один презентер с анимацией все повесить?
Программирование уже должно на еще более высокий и легкий уровень выйти, будешь просто проговаривать алгоритм, а оно пусть само там подбирает. Ну вот, например, в блендере в скелете нужно у выделенной кости выделить всех ее детей и к именам добавить 001, 002... Весь день проебешь, гугля как это делается, а так сразу хуяк тебе кодик, там уже примерно понятно будет как, что называется и легко допилить
>будешь просто проговаривать алгоритм, а оно пусть само там подбирает
Разбудите когда кнопка "сделать пиздато" будет.
А гуй - это зачастую и правда самое сложное в проекте, лол.
>>846260
А хуле вы хотели, это дело спеца совсем другого профиля. Гуй, сделанный погромистом - это всегда пиздец.
За себя говори, у меня гуй нормальный. Благо несколько лет отпахал на фронтенде с реактивными фреймворками.
>на фронтенде с реактивными фреймворками
на реактивной тяге бгг ебучий React
>ебучий React
Удобно же. Разметку сделал. Стилей накидал. Собрал одной кнопкой. Заместо пердолинга с созданием и размещением компонентов кодом.
Он не поймёт если не отработает на подобном фреймворке пару лет. Я долго вертел нос от фреймворков, не желая отказываться от жейквери, пушо ничего сложнее визитосов не делал, для интернет-магазов юзали платформу. А потом вкатился в Vue, React и уже для самой тривиальной хуйни разворачиваю бойлерплейт ибо одной командой, удобно и уже знакомо.
> я думал они нас рабсеян порешали
Порешали в том плане, что игроки из России и Белоруссии не могут совершать покупки, то есть никаких донатов. И нет дохода с рекламы. Но ты можешь продолжать зарабатывать в других странах и выводить деньги в России.
Ведь для каждой модели должен свой вью-презенетр быть, так?
НУ точно второй вариант. у каждого скила свой вью презентер, а хендлер контролирует запуск скилов, чтобы не было нахлеста анимаций.
>Я уже подзаебался переосмысливать как работает мвп, если честно.
ну еще поебешься малех и поймешь что кушать суп ножом и тащить в юнити MV* не нужно
Альтернатива какая? в редакторе компоненты по публичным филдам перетаскивать?
Не уверен но помойму ты хуйнёй занят. Если твоя цель просто кодить ради кодинга то ок, но зачем тогда ты так сильно напрягаешься? Ты вообще игру делаешь или что?
Модератор, почему оп пик с пропагандой лгбт? Это уголовка уже.
Это можно и нужно делать безотносительно использования MVC/MPV в юнити.
> что кушать суп ножом и тащить в юнити MV* не нужно
Нужно, но не так
>>846336
> Альтернатива какая? в редакторе компоненты по публичным филдам перетаскивать?
Перетаскивать компоненты или нет - это не вопрос к мвп или мвц.
Чтобы передавать зависимости, ты можешь использовать сервис локатор(нет), ди, или фабрики.
>>846320
Я хз что ты там изобретаешь, но почему бы не сделать пикрил?
Tower - скрипт который вешаешь на геймобжект.
TargetLocator - нечто что дает цель. Будет ли это какой-то внешний сервис, или компонент - зависит от того, что тебе нужно.
Tower также полностью контролирует некий Gun, это может быть либо СО с прописанной логикой для метода Fire, или целый префаб
Gun это то, что стреляет по цели. Важно: это НЕ реальная пушка, это всего лишь нечто, что отвечает за запуск некоторой атаки. Tower передаст ему точку откуда стрелять и в кого.
TowerView подписывается на ивенты тавера, при необходимости мониторит даже в апдейте что-то. Это может быть как монолитный компонент, который управлет и анимациями и звуками, так и раздообленный на несколько, по сути как ты у себя нарисовал.
Дурак что ли. Это коммунистический плакат!
>Это можно и нужно делать безотносительно использования MVC/MPV в юнити.
В чем плюсы относительно MVP/MVC?
>>846339
Ты какать когда ходишь у тебя цель кишку почистить или штаны снимать? почему ты снимаешь штаны, когда какаешь? Или это другое?
В юнити уже реализован MVC, в самом движке. Модель - это, например, данные Transform. View/Presenter - это компоненты спрайтов, мешей и моделей, которые рендерятся там, где они находятся. Тебе не надо писать движок поверх движка, чтобы делать игры. А перетаскивание компонентов в формы - это всего лишь способ управления зависимостями. Хуячь всё в одном скрипте, не ошибёшься.
Чел я без негатива пишу. Не занимайся хуитой. Ты движок взял чтобы игру сделать, а не написать свою лапшу поверх движка.
Если была цель насрать кучу кода чтобы показать на гите и взяли как джуна то ок, но зачем тогда срать в треде об этом?
>Я хз что ты там изобретаешь, но почему бы не сделать пикрил?
У меня башня потенциально может иметь несколько вариантов действий, кроме автоатаки. То что на твоем рисунке по сути отображает класс Skill на моей схеме. За исключением того, что я пока думаю, как к нему прокинуть View составляющую. Не, ну в целом, я могу просто к каждому скилу конечно прикрутить отдельный аниматор и не ебаться вообще. Но
>>846353
база нах, либо ты дебил ебаный зарабатываешь деньги, либо ты хуй сосёшь со своими инцельскими архитектурами
> У меня башня потенциально может иметь несколько вариантов действий, кроме автоатаки.
Значит даешь ей весь TargetLocator, и из него пусть берет че надо.
> За исключением того, что я пока думаю, как к нему прокинуть View составляющую.
Зачем? Что конкретно view будет отображать из скилла?
Вот есть башня да, стоит такая коробка и на ней сверху оружие - это все вью башни. А у скилла че отображать тебе надо?
> Не, ну в целом, я могу просто к каждому скилу конечно прикрутить отдельный аниматор и не ебаться вообще.
Ну, когда "скилл" стреляет например пулей - пусть просто спаунит эту пулю, вью тут никакой не нужен.
Или ты хочешь чтобы там огонь как от выстрела появлялся? Так это ж ответственность вью башни, и ей пох чем там она стреляет.
>>846353
если честно мне нахуй не надо с вами спорить. Хотите через компоненты работать, пожалуйста. Подход имеет все права на жизнь.
Так дело не в споре. Ты пытаешься реализовать велосипед поверх готового решения. В этом 0 смысла во всех смыслах.
Помимо того что ты на пустом месте усложняешь архитектуру и читаемость (А это один из столпов геймдева и программирования в целом) ты еще и городишь жуткие костыли ухудшая производительность.
Бросай это дело, ну или залей на гит и показывай всем что ты сделал, но не применяй на реальных задачах.
>Что конкретно view будет отображать из скилла?
Ну стоит башня с магом. У него анимация автоатаки- просто поднимает посох. Добавляю ему с прокачкой возможнсть кастовать ледяной дождь, он начинает этим посохом 2 секунды баландать в воздухе типа призывать стихию.
>Значит даешь ей весь TargetLocator, и из него пусть берет че надо.
может быть. я уже внутрянку не помню че там с ним.
Вообще полный цикл выглядит так Башня проверяет готовы ли скилы - запускает первый готовый - запускается анимация - анимация содежит эвент который сообщает, когда включать "пулю"- дальше в анимации есть эвент, сообщающий о конце анимации скила, это означает, что аниматор свободен и можно использовать следующий доступный скилл. Пуля там куда-то летит сама по своим делам уже несколько кадров.
и?
>>846372
>Помимо того что ты на пустом месте усложняешь архитектуру и читаемость
По слоям от большего к меньшему - сложно. Кинул макаронину от кор класса в самый анальный уголок игры - архитектура. Все понятно. лайк.
Ну смотри, можно так сделать:
Tower - содержит CurrentSpell и поднимает ивенты типа начал кастовать, закончил кастовать, текущий спелл сменился.
Вью - маг - ловит эти ивенты и выбирает анимацию в зависимости от спелла(и ее длительность подстраивает под каст тайм). Т.е. надо сделать чтобы ты ему в паметрах мог задавать пары: спелл-анимация.
Т.е. словил он старт каст - начал играть анимацию заданную, и никаких проблем.
> Так дело не в споре. Ты пытаешься реализовать велосипед поверх готового решения. В этом 0 смысла во всех смыслах.
Он все правильно делает, организовывает код по логике, с опытом будет щелкать такие задачи и ебошить готовый прототип за то время, пока кирилл спрайт двигаться заставит.
Можно попробовать. Помозгую попозже, а то из-за утечки газа разволновался, голова не работает лол
https://github.com/Delt06/di-framework
https://github.com/gustavopsantos/Reflex
https://github.com/PereViader/ManualDi.Main
https://github.com/apkd/Medicine
Например, на пике, пускаю луч, все что зеленым должно стригерится, все что за стеной должно игнорится. Как такое запилить?
Зеленый круг за стеной тоже красным должен быть, сфейлил что-то
Бля, как только спросил походу понял как сделать через маски для рейкаста. Спасибо, посоны.
Я так и работаю, у меня на старом 4:3 мониторе вкладка Game, а на стандартном 16:9 всё остальное
Так намного удобнее? Какая диагональ у мониторов? Ещё видел некоторые размещают второй монитор вертикально для отображения большего количества года, но хз насколько это пригодится на самом деле.
Сорян, немного напиздел, не 4:3, а 5:4.
>Так намного удобнее?
Да
>Какая диагональ у мониторов?
16:9 - 27 дюймов
5:4 - 19 дюймов
>второй монитор вертикально
Хочу попробовать эту тему, но некоторые аноны что шея затекает и неудобно. Хотя мне в принципе пох и я всё равно буду брать вертикальный монитор. Если не зайдет, то будет просто третий моник.
У меня три моника, но так как основной это 2К/27 дюймов то два других используются только для демонстрации ютабчика и аниме-картинок, так как крутить ебалом становится неудобно. Еще пробовал ставить один над другим - хуита. Два 22-дюймовых рядом да, реально юзать.
И как работать? Вертеть головой, как конь, от кормушки к поилке? Гораздо легче альт-табнуться, да и научные исследования подтверждают, что наличие второго монитора УМЕНЬШАЕТ эффективность работы. За редким исключением, типа слежения за камерами наблюдения или биржевыми графиками.
>альттабаться легче чем не альттабаться
Пиздец. он даже научные исследования прочитал какие-то лол)))))))))))))))))))))))))))))))))))))))))))))))))
Понятное дело, что у вас книжки читать - цэ наследие москальской оккупации. Но ты можешь не переживать, я ничего не читал.
Шею свою куриную подкачай дрочила, если тебе альтаб проще нажать, чем голову сместить на полградуса.
>научные исследования подтверждают, что наличие второго монитора УМЕНЬШАЕТ эффективность работы
Не верю.
У меня 1 большой моник и я постоянно вынужден то открывать Picture in Picture, то изъебисто разделять экран на 2 части.
У тянки два монитора, на одном у нее открыт реф, на втором рисует. Альт табаться тут вообще не вариант.
Твое исследование явно не про разработчиков игр. Может быть, про каких то офисных операторов или водителей трамваев, которым второй монитор мешает, потому что они на нем сериалы смотрят, и они звонки пропускают.
>думает есть ли смысл брать второй
>мне не хватает уже моих троих
не лезь оно тебя сожрет
> научные исследования подтверждают, что наличие второго монитора УМЕНЬШАЕТ эффективность работы
Научные исследование на ком, чьих задач, и почему меня это должно ебать?
Я ща с одним монитором, и это жутко не удобно по сравнению с двумя в некоторых ситуациях, которые занимают процентов 15 времени, но это как бы тоже существенно. Если ты делаешь что-то посложнее чем движущийся куб, то в какой-то момент придется настраивать сцену и смотреть на нее с разных ракурсов, да еще и открывать сразу несколько инспекторов и подкручивать в них значения, на одиг монитор это не влезет. Также документацию на втором мониторе можно открыть. При профайлинге нужно порой сразу несколько окон открывать.
>>846453
> Чтобы разделить юнити и студию например
Полная хуета.
> Полезнее было бы разделить вкладки Scene и Game
Да, хотя бы так.
мимо
У меня противоположный опыт. Есть два монитора, и я не нашёл ничего, что можно было бы разместить на втором, в контексте работы с юнити. Пытался игровое окно - для тестирования игры приходится перекладывать в его сторону мышь, клавиатуру и поворачиваться в его сторону, а потом опять убирать, либо косоёбится всем телом и перекручивать позвоночник. Потому что главный монитор находится прямо перед глазами, а побочный - в стороне. Либо можно поставить два монитора так, чтобы они находились равноудалённо от клавиатуры, но тогда неудобно смотреть ни на один из них. В итоге я вывел на второй монитор окно консоли, чтоб не занимало место в основном окне. Польза сомительная.
>Также документацию на втором мониторе можно открыть. При профайлинге нужно порой сразу несколько окон открывать.
Это всё работает, если мониторы квадратные (см. пик). Но один широкоформатный монитор заменяет два квадратных. А на два широкоформатных не хватит ресурса шеи или позвоночника, потому что перед глазами их не разместить, а значит, придётся крутиться и перекручивать позвонки, что травмоопасно. Ну или есть ещё вариант, что у вас пиздатое 100% зрение, тогда 2 широкоформатных монитора можно поставить перед собой на расстоянии 1.5-2 метра.
>и я не нашёл ничего, что можно было бы разместить на втором, в контексте работы с юнити
Я профессиональный юнитидебил, когда надо было переносить дизайн интерфейса от хуйдожников из фигмы в юнити то второй моник сильно помогал.
По делу есть что сказать или ты просто кукарекнуть зашел?
Конечно. Найди какого-нибудь обзорщика на ютубе, чтобы он тебе обзор сделал как тебе надо чтобы у тебя было.
подключаешь его как второй монитор
и уже смотришь удобнее стало или нет. если да, берешь нормальный монитор. если нет, то ничего не потерял.
зумер не догадывается, что телевизор нужно на стол с пекарней поставить. подскажите, не справляется малой.
Анончики! Свершилось! Возрадуемся!
https://www.youtube.com/watch?v=Pec_2qXTQKs
И че как там курс? четкий молодежный или залупа глубиной до создания классов?
Только нахуй он нужен, когда полно нормальных книжек? Берёшь книжки и практикуешься. Все эти курсы-хуюрсы приводят только к прокрастинации.
У тебя что-то там перекрывает пайплайн, удали его и поставь заного.
Да просто удали пакет и установи заного, можешь еще подчистить системные папки юньки на всякий, она все перекочает.
Посмотрел сразу конец. карочи это в лучшем случае глава 3 метанита по с#. В общем по факту 30 минут самостоятельного изучения вложили в 10 часов видео.
аудиты небось проводят как автостол
не парься тебе это не грозит
Если ты не знаешь, у них эдитор вообще то отправляет кучу инфы о твоей игре, где аи всё анализирует. Но как сказали выше, с шансом 0.00001% что заинтересуются.
>а откуда Юнити узнает, сколько денег заработали мои игры?
Дураку понятно что твоя игра ничего не заработает, ведь чтоб заработать на игре надо ее сначала сделать.
Дурачок или шарит?
>При разработке надо писать классы без монобеха до тех пор, пока без него возможно обходиться.
Все правильно. Это же логично. Создавай пустой класс, остальное дописывай по мере необходимости.
А я пришел с пикрилом 😶
Последнее время задумался достаточно серьезно о том, чтобы залететь на работку, потому что не хочу топтаться на месте и уподобляться местным лепилам, и бля чет реально работы то нихуя нет. пхех.
по сравнению с просто шарпоклассом действительно кучу багажа за собой тащит но все это нужно, а там где не нужно то и монобех не нужен
Еще и это дурацкое окно появляется что бла-бла ограничьте права для запуска эдитора, а я ебу как и зачем вообще это надо.
Очень странная формулировка. У монобехов есть своя задача, там где они не нужны - их юзать и не будут, там где нужны - там будут. А юзать их в любом случае надо, потому что а как ты иначе на сцене что-то покажешь?
Ну тут вот есть отряд девелоперов, который не может в архитектуру, поэтому все в игре делает монобехами, чтобы протаскивать через них связи. Аргументируя это тем, что юнити сделали монобехи, значит лучше всего работать именно с ними.
Всё ок, но монобеха тащит с собой апдейты, старты и прочее-прочее для взаимодействия с двиглом. Ты что там собрался делать такое что тебе монобеха не нужна?
АХАХАХАХА ЧЕ ЗА ХУЙНЯ
И вот этим он так хайповал!? Не ну для начинающих пойдет, но стоило назвать "первые шаги в C#"
Мне она тоже нужна, только я ее не пихаю везде потому что могу.
Когда код без нее можно написать лол))) Ну типо по сути монобеха это точка входа/взаимодействия со сценой. я ее сделал в объекте и раскидываю дальше от нее что надо вниз по архитектуре. Больше она мне не нужна обычно. Ну есть специфические методы, типо инстантиейта или корутины, тут приходится да.
>в каких случаях она не нужна?
>в случаях когда она не нужна
ясн))))))))
public class ScoreManager
{
public IReactiveProperty<int> Score => ...
public void AddScore(int score){...}
}
public class WinConditionChecker
{
public IObservable<Unit> OnVictory =>...
public WinConditionChecker(IEnemyManager enemyManager)
{...
}
}
Если ты в коде создаешь создаешь какой-то класс, который не имеет отношения к сцене, то нах тебе его делать монобехом? Чтобв потом заморачиваться с его удалением?
>В чем минус юзать монобехи?
Я просто не знаю, как это, типа чисто математику вычислять? Что там такого надо напридумывать, чтобы специально выводить и вычислять, блокчейн считать что-ли? Примерно что-то уровня параллельных вычислений?
>>846724
Что это означает?
> Я просто не знаю, как это, типа чисто математику вычислять? Что там такого надо напридумывать, чтобы специально выводить и вычислять, блокчейн считать что-ли? Примерно что-то уровня параллельных вычислений?
Вот >>846710
Зачем счетчику счета, или какому-нибудь классу, который проверяет пройден ли уровень, быть монобехом?
Пока один ИТТ не может сообразить, как его башенки разделить на model и presenter, другой не заморачиваясь кидает компоненты на объекты и выпускает игру. Мы тут почти все любим программировать, но если нет разницы, зачем тратить время и силы?
Двачую частично. Может быть в этом и есть смысл сделать свою архитектуру поверх юнити, но если цель создать игру, эту идею лучше отложить и воспользоваться решениями от самого движка, и уже исходя из них реализовывать планы.
Поэтому не соглашусь что дополнительные время и силы потрачены напрасно. Вспомнить только одних пчеликов которые на 3д движках годами кодят сценки, и им по кайфу. Вроде были их треды на этой доске даже. Приятно было смотреть на интересные штуки у них.
Игры разные бывают. По факту усилия должны соответствовать задаче. Но в общем и целом, в том чистом коде написано как надо и для чего это надо. Просто челы работают в одиночку и лепят, игры объемом с змейку. Ну до пенсии ты эту хуету то не будешь делать. Надо куда-то двигаться вперед.
>>846739
ну так ты когда какать ходишь, штаны зачем снимаешь, если результат один и тот же? Или если для тебя в данном случае результатом являются чистые штаны, тогда не какай просто и все. Зачем какать, если можно не какать, а результат то тот же.
>ну так ты когда какать ходишь
>>846350
>Ты какать когда ходишь
У тебя плохо с аналогиями. Вероятно, тебе сначала стоит вылечить проблемы с испражнением, а потом делать игры. Видно, что проблема тебе мешает.
> Пока один ИТТ не может сообразить, как его башенки разделить на model и presenter
Ну так он разберется, научится, и дальше будет быстрее делать. Это ж не так что ты можешь просто впервые про что-то услышать и сразу начать ебошить.
> другой не заморачиваясь кидает компоненты на объекты и выпускает игру
Наоборот. Не заморачиваысь с архитектурой проект станет невозможно развивать, попробуй сам скачать зенжект и накидывать классы по солиду, уже через месяц ты с него ни за что не слезешь.
Но к вопросу это кста отношения не имеет - делаешь ты мвп или нет, в любом случае у тебя так или иначе будут классы не монобехи в каких-то ситуациях.
ожидаемо, типикал двачер хотел повыебываться ложнологическими приемами, был обоссан своим же оружием и ушел в режим постановки диагнозов. У тебя вышка то хоть есть? Знаешься ли философию преподают буквально везде.
Тебе нужен специалист с медицинской вышкой - у меня её нет. Нельзя обсуждать предметно вопрос, если собеседника что-то отвлекает (позывы в туалет, как в твоём случае).
Нет. Сразу столкнешься с неудобствами, например в HDRP опять переделан постпроцессинг, пускай минимально по сравнению с постпроцессинг стек, но все равно придется переписывать скрипты. Также у меня в хдрп не работает всинк в редакторе, вообще охуеть.
ты сейчас в какой стадии находишься? прокрастинация или прохождение очередных курсов о том же самом другими словами?
Бля что за бред ты пишешь животное? Если челик за место игры дрочится с той хуитой что написана выше он никогда ни вчем не преуспеет, и просто будет тыкаться дальше. Хватит травить эти влажные мечты.
Камушек в стиральной машинке, спок. Всем понятно каким бытием наполняется твое сознание.
Иди нахуй фантазер безигорный. Пиздуй делать архитектуры поверх архитектур до конца жизни. Без задачная хуита
От тебя прям такой самобытный запах двоща. Все эти темы о том как выебать писечку, как вкатиться в айти, почему у меня ничего нет и ничего не могу ведь я очинь умный. умнее всех других. Все это ты. А жизнь тем временем идет вперед.
Это просто маркер стажера и ниже. Джуном не возьмут, если он везде лепит монобехи.
Это не влажные мечты, это я тебе говорю, что понял, после того как начал работать в геймдеве, где надо быстро результат получать, да еще и есть риск что проект норм зайдет и придется много че расширять. Ты думаешь это все просто так придумали, потому что заняться нечем?