Increaser
Я никогда не писал, что в Unity нет никаких багов.
И как понять твоё сообщение ?
Storm54
Никаких нет. Он вообще не шарит в Unity. Просто любитель велосипедов, обиженный на весь мир.
Increaser
Критика понятна. Как мне кажется, упираемся в строго типизированность языка.
Предложения по решению сложившейся проблемы будут? Желательно в рамках инфраструктуры Unity3D.
ronniko
> Никаких нет. Он вообще не шарит в Unity. Просто любитель велосипедов, обиженный на весь мир.
дак в этом сообщении нет ничего про баги. с чего ты взял что нет багов а не чего-то другого?
Dan398
Предложения по решению сложившейся проблемы будут? Желательно в рамках инфраструктуры Unity3D.
Решения от Increaser-а ?
шутишь :)
kkolyan откуда ты знаешь что он имел в веду написав "Никаких нет." и "не шарит в Юнити"?
Ты его мысли умеешь читать , что-ли ? :)
Он же потому так мутно и пишет, что бы съехать в удобный момент.
Он же мутный тип. Уже не раз замечал как он юлит и уводит в разные темы.
ronniko
> откуда ты знаешь что он имел в веду написав "Никаких нет."
свою логику я уже объяснял выше в этом треде. а сейчас хочу подебажить твою. скажи, как ты понял что он именно про баги?
ronniko
> И как понять твоё сообщение ?
Потрудись перечитать пост того, кому оно было адресованно
Ты даже лично мне не ответил, всё увиливал. Боялся признать проблемы Юнити.
А адресовал Storm54.
А самое главное написал "он не шарит в ЮНИТИ" типа какие там проблемы могут быть.
Dan398
> Предложения по решению сложившейся проблемы будут? Желательно в рамках инфраструктуры Unity3D.
Свои предложения я Unity излагал пару раз. Зачем их излагать тут? Их кто-то увидит? Или что?
Для начала можно посмотреть, как с аналогичной проблемой справляется автор Node Canvas.
ronniko
> Ты даже лично мне не ответил, всё увиливал. А одресовал Storm54.
Окей, прогресс. А теперь почитай что сказал Storm54
ronniko
> А самое главное написал "он не шарит в ЮНИТИ" типа какие там проблемы могут быть.
Одно никак не следует из другого. У тебя проблемы с логикой. Ты не шаришь в куче вещей, но это никак не связано с их проблемностью или беспроблемностью.
Increaser
Ты не шаришь в куче вещей, но это никак не связано с их проблемностью или беспроблемностью.
Вот это ты зря начал.
Ты коня в вакууме абстрактного не рисуй. ты конкретно пиши . Ты тоже много чего не знаешь.
Потому как обычно твой пост не пойми о чем и зачем.
Свои предложения я Unity излагал пару раз.
ты же умный сильно и еще можешь же брать лицензию с сорсами и фиксить сам.
https://gamedev.ru/unity/forum/?id=292904&page=4&m=6118213#m45
Ты опять пытаешься увиливать.
Как обычно.
То, что ты не шаришь в чем-то, никак не указывает на проблемность вещи
ты о Юнити говоришь или о каких-то событиях и объектах вселенной ?
По моему тут все о Юнити говорят.
Причем здесь "не шаришь в чем-то, никак не указывает на проблемность вещи" ?
ronniko
> Ты же умный, советовал брать сорцы Юнити и фиксить баги или своё дописать.
ronniko
> Ну и чё не можешь по этой теме ТС помочь ?
1. Как это связано?
2. Я сказал ТС что я думаю по этому поводу и как это работает. Но ты читать не умеешь, я понимаю.
Рили я понял почему ты в ассемблере застрял. Ты просто уже в том возрасте, когда что-то новое не выучить, понимаю.
Increaser
Ты просто уже в том возрасте, когда что-то новое не выучить
зачем мне учить всякий шлак типа Юнити ?
Я лучше выучу TTS синтез голоса. Чтобы диалоги классными сделать в своей игре и с интонацией.
Что касается движка Unity – он имеет большие проблемы с микшированием музыки и звуков. Проблема осложнена фактом того, что движок Unity является закрытым, то есть его исходный программный код закрыт от просмотра, и у пользователей нет даже малейшей возможности понять причину происходящих проблем. Если вы встретили игру, в которой присутствует случайное искажение звуков, такое как, например, потрескивание, похрустывание, щелчки, пропуски, обрывы и иные искажения звуков, то с большой вероятностью эта игра была также сделана на движке Unity.
Я даже не знаю с чего начать :)
Обычно люди рассказывающие как надо делать и что они очень шарят в Юнити, могут показать как надо делать.
И вот возникает резонный вопрос, а ты шаришь в Юнити или только трындеть умеешь и сказки рассказывать, о том как ты яко бы шаришь ?
Второе ты пишешь
Свои предложения я Unity излагал пару раз. Зачем их излагать тут?
Ну понятно, что такое ты тут излагать не будешь :)
Dan398
О, среди священной битвы есть ответ по теме! Dan398
> Архитектурные подходы изобретают в основном для решения каких-либо проблем развития проекта. И я просто не увидел явной декларации самой проблемы; что значит handlers - я не понял.
Идея в том, чтобы сформировать префабную модульность алгоритмов. То есть это скорее не решение проблемы, а увеличение комфорта. Под handlers в рамках идеи я понимаю
1) прежде всего: экземпляр SO - по сути какой-то public API без данных. Например, IStatsCalc public Stats CalcStats(Stats s, Factor[] factors) - чёт такое. Некая обезличенная в API сущность, которая содержит реализации в интерфейсном фантике.
2) Параметры расчётов - опционально. Чаще всего - 1 скрипт - 1 экземпляр без параметров.
Dan398
> - Проблемы с сериализацией. SO в базовых классах несёт дополнительные поля, которые плохо (или вообще не) конвертируются в JSON. Писать отдельные (де)сериализаторы - можно, но ленно.
В рамках предложенного usecase - и не особо-то и нужно бороться. Может я чего не понимаю.
Dan398
> - Нет доступа к конструктору. Используя конструктор объекта, можно инъектировать зависимости, которые строго необходимы для работы объекта. Обходное решение - проверка на валидность и ручная инициализация.
Чтобы инъектировать зависимости - есть много фишек. Можно вообще через lazy искать, как-то resolve. Но то, что это yaml, который всё это записывает, хранит инфу о полях - да, неприятно. Загрязняет идею. НО! А что если перестроить идеологию SO instance = empty handler. Да, тогда надо делать большую сигнатуру метода и кидать туда всё нужное. Зато, тогда SO - просто кирпичик-обработчик без привязки к хранению какой-то data.
Dan398
> - SO - всё ещё файлик. А хранить его где? Будь эффект сугубо кодовым решением, то он бы хранился в кодовой базе и создавался для общих сущностей. А указанный "OutOfBoundsDeathHandlerSO", как я понял, привязывается ко всем двигающимся умираемым сущностям, не привязан к конкретной. Как итог - разрастание мусора в проекте.
Не пон, в чём проблема. Есть folder с экземплярами возможных обработчиков. Что-типа систем из ECS, но проще и банальнее. Есть GameEntity. У нее есть Data. Есть ISOHandler[]; Мы их компонует в инспекторе...
Dan398
Хороший пример, хорошая альтернатива. Тем не менее, пока я не нашёл принципиальных недостатков в моей идее. Хотя и не пробовал.
> Альтернатива подходу банальна до безобразия - интерфейсы к нативным C# классам. Но тут проблема с тем, что нужно подружить интерфейсы с редактором. Вот здесь есть демонстрация наращивания эффектов урона, с доступом к полям класса через инспектор. Правда, при добавлении эффектов в инспекторе создаётся класс через конструктор без аргументов, но тут уже нужно бороться отдельно.
Dan398
> А вообще - Model-Controller всему голова. Моделька сериализуется и хранит только данные, описывающие состояние. Контроллер кэширует игровые сущности и обрабатывает модель. Красота.
Ну это база. По мне так любой ключевой monobeh сущности не должен хранить данные, а иметь ссылку на Data. Data - реактивщина, ее слушают всякие и кто-то в json тудысюды могёт
Dan398
> SerializeReference - прежде всего ИНСТРУМЕНТ, с помощью которого решаются проблемы, а именно отрисовка инспектора разных по типу объектов в одном поле класса.
А меня немного напрягает. Рефлексия + сериализация путей... Достаточно хрупкая тема. SO тоже могут слететь, да. Но этот механизм по кр мере не предполагает дополнительного кода. Всунул вынул и пошёл.
По поводу битвы про юнити.
Что мне нравится в юнити:
1) самое большое комьюнити - тут крыть нечем. У всех есть плагины, расширения, поддержка, гайды
2) тотальный простор архитектурного самовыражения и построения проекта и точек входа.
Что мне НЕ нравится:
1) идеология ориентирована на main thread. и inatantiate и rp и все моменты игрового цикла. Всякие unitask частично вытаскивают, но такое...
2) тотальный простор архитектурного самовыражения и построения проекта и точек входа. Это и большой минус. Хотелось бы видеть унифицированный подход для отделения data от динамических сущностей, оптимизацию работы с потоками и многое другое.
3) плохо проработанная физика. Многие проблемы не решены. Приходится многое решать вручную.
ИТОГ: попрорукие - делают лажу. Но это закономерно и нормально. А unity норм для своих задач. просто не надо aaa делать, даже DOTS не спасёт.