Там еще контрольная группа была, которая жила в таких же условиях, но думала о чем-то другом. Вчера забыл про это.
В любом случае без подробной информации об улучшениях, сложно делать выводы. Возможно они чувствовали себе более счастливыми, вырабатывалось больше эндорфинов или чего-то подобного, что приводило к незначительному улучшению состояния.
Из вики (Эндорфины):
О том, что раны победителей заживают быстрее, чем раны побеждённых, было известно ещё в Древнем Риме.
А на сколько улучшилось зрение?
Мне кажется состояние людей могло улучшиться по другим причинам. Например: черно белый телевизор меньше влияет на зрение или лучше отдыхали, что могло улучшить память.
А как обстоят дела с модульностью в анриале?
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
При использование Composition Root, все связи видны как на ладоне. Как минимум это должно упростить жизнь новым программистам на проекте.
Я сейчас читаю книгу «Dependency Injection in .NET». Там об этом написано. Хотя там написано про инициализацию зависимостей, но думаю к сигналам и командам это тоже относится.
Я в игре могу подвесится прям на команды как на события. И тоже строготипизированно. Выглядит как-то так:
В StrangeIoC есть два вида событий: старые событий и новые сигналы. Я это имел ввиду.
Чем упрощают? Что для вас «асинхронные» в данном контексте?)
Команда выполняется в течении нескольких кадров. Проще вызвать другую команду в конце асинхронной команды. Иначе нужен будет или callback или promise.
Чтобы просто не создавать классы размером в 1000 строк, можно использовать шаблон стратегия. Хотя я часто пишу статические классы — утилиты или хелперы.
Суть команд, мне кажется, больше, чем просто декомпозиция большого класса.
commandBinder.Bind(GameEvent.HIT).To<DestroyEnemyCommand>().To<UpdateScoreCommand>();
commandBinder.Bind(GameEvent.HIT).InSequence()
.To<CheckLevelClearedCommand>()
.To<EndLevelCommand>()
.To<GameOverCommand>();
injectionBinder.Bind<ICommandBinder>().To<SignalCommandBinder>().ToSingleton(); // сигналы - новые, строго типизированные события.
https://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Это должно проделываться в Composition Root. Вызов одной команды из другой это явно плохая практика.
Кстати, в StrangeIOC команды могут быть асинхронными, в этом случае они конечно упрощают жизнь. Хотя я для этого использовал Promise, которые очень популярные в JS.
файле на тысячи строк
Я не говорил, что надо вообще все в один файл писать. Но создавать файл для каждой функции, еще и в 1-5 строк… это странно для меня. Хотя конечно можно в одном файле написать несколько классов.
Но остается проблема с GC. У вас некоторые команды создавались в каждом update, рано или поздно это может внести свою лепту в понижение fps.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.
В чем удобность команд?
Читал про StrangeIOC, там можно создавать цепочки из сигналов и команд. Но у вас такого не видел.
Еще, возможно, когда в команде много программистов, то удобнее, когда каждая операция в своем файле (проще мерж, лучше видно историю изменений).
Но не нравится мне, что надо создавать класс/файл на каждый чих.
В последний версиях C# появился оператор nameof, который был бы очень полезным в нашем случае.
Unity обещают скоро обновить компилятор, может скоро сможем его заюзать.
Вообще мне кажется сериализация и редактор никак не связаны. FormerlySerializedAs должен работать вполне независимо от, использую ли я в редакторе SerializedObject или нет.
Я не пойму, а что хорошего в том, что изменения просто игнорируются? С несколькими сценами еще не работал, поэтому тоже не пойму, как эта фича повлияла на SetDirty.
В каких случаях Event.current.GetTypeForControl(controlId) и Event.current.type могут иметь разные значения?
Всегда использовал просто Event.current.type и работало.
Вы понимаете как работает данный код?
HandleUtility.AddDefaultControl( GUIUtility.GetControlID( FocusType.Passive ) );
Давно использую этот код, чтобы отключить переключение кликом мыши на другой объект, но как это работает так и не понял.
За такое как SerializedObject надо бы по рукам бить, ибо имя переменной указывается строкой и легко допустить ошибку.
Не понимаю зачем они отказались от EditorUtility.SetDirty. Это удар ниже пояса.
Сами юнити, кстати, во всю используют SerializedObject т.к. это единственный способ получить доступ к приватному полю.
В любом случае без подробной информации об улучшениях, сложно делать выводы. Возможно они чувствовали себе более счастливыми, вырабатывалось больше эндорфинов или чего-то подобного, что приводило к незначительному улучшению состояния.
Из вики (Эндорфины):
Мне кажется состояние людей могло улучшиться по другим причинам. Например: черно белый телевизор меньше влияет на зрение или лучше отдыхали, что могло улучшить память.
В Unity есть лишь Plugins/Standard Assets, Editor и все остальное. Т.е. код в этих папках компилируется в разные сборки. И игровая сборка ничего не знает о других, что предотвращает некоторые ошибки. Но хотелось бы больше возможностей.
При использование Composition Root, все связи видны как на ладоне. Как минимум это должно упростить жизнь новым программистам на проекте.
Я сейчас читаю книгу «Dependency Injection in .NET». Там об этом написано. Хотя там написано про инициализацию зависимостей, но думаю к сигналам и командам это тоже относится.
В StrangeIoC есть два вида событий: старые событий и новые сигналы. Я это имел ввиду.
Команда выполняется в течении нескольких кадров. Проще вызвать другую команду в конце асинхронной команды. Иначе нужен будет или callback или promise.
Чтобы просто не создавать классы размером в 1000 строк, можно использовать шаблон стратегия. Хотя я часто пишу статические классы — утилиты или хелперы.
Суть команд, мне кажется, больше, чем просто декомпозиция большого класса.
https://strangeioc.github.io/strangeioc/TheBigStrangeHowTo.html
Это должно проделываться в Composition Root. Вызов одной команды из другой это явно плохая практика.
Кстати, в StrangeIOC команды могут быть асинхронными, в этом случае они конечно упрощают жизнь. Хотя я для этого использовал Promise, которые очень популярные в JS.
Я не говорил, что надо вообще все в один файл писать. Но создавать файл для каждой функции, еще и в 1-5 строк… это странно для меня. Хотя конечно можно в одном файле написать несколько классов.
Но остается проблема с GC. У вас некоторые команды создавались в каждом update, рано или поздно это может внести свою лепту в понижение fps.
Я не представляю как выглядел мой проект, если бы каждый метод я выносил бы в отдельный класс. Где-то должна быть эта грань.
Читал про StrangeIOC, там можно создавать цепочки из сигналов и команд. Но у вас такого не видел.
Еще, возможно, когда в команде много программистов, то удобнее, когда каждая операция в своем файле (проще мерж, лучше видно историю изменений).
Но не нравится мне, что надо создавать класс/файл на каждый чих.
Unity обещают скоро обновить компилятор, может скоро сможем его заюзать.
Вообще мне кажется сериализация и редактор никак не связаны. FormerlySerializedAs должен работать вполне независимо от, использую ли я в редакторе SerializedObject или нет.
Я не пойму, а что хорошего в том, что изменения просто игнорируются? С несколькими сценами еще не работал, поэтому тоже не пойму, как эта фича повлияла на SetDirty.
Всегда использовал просто Event.current.type и работало.
Вы понимаете как работает данный код?
HandleUtility.AddDefaultControl( GUIUtility.GetControlID( FocusType.Passive ) );
Давно использую этот код, чтобы отключить переключение кликом мыши на другой объект, но как это работает так и не понял.
Не понимаю зачем они отказались от EditorUtility.SetDirty. Это удар ниже пояса.
Сами юнити, кстати, во всю используют SerializedObject т.к. это единственный способ получить доступ к приватному полю.