А как правильно писать код ?
| |
ArtemS | Дата: Понедельник, 24 Апреля 2017, 18:06 | Сообщение # 1 |
почетный гость
Сейчас нет на сайте
| Пол года смотрю и читаю разные уроки по юньке и возник вопрос.. а как правильнее или удобнее писать код для больших проектов ? В разных уроках народ объясняет каждый раз по своему, но игры в этих уроках длятся буквально 1-2 уровня, либо объясняют какой-то определенный аспект какого-либо действия. Сам я нечего крупного пока не написал, так как время хватает лишь посмотреть уроки и повторить за ними, +- какие-то свои моменты протестить, в общем как и у любого новичка..ну я так думаю.
Собственно хочу узнать мнение более опытных людей, скажите ,пожалуйста, как правильнее или грамотнее выстраивать код. Пытаться уложить все в некий GameControllerScript или же каждому объекту и на каждое действие писать свой уникальный скрипт... ну и собственно как это будет влиять на затраты ресурсов компьютера.
Здравый смысл говорит, что общий код - очень просто запутаться, не знаю но может и обработка будет расти..так как каждый кадр в главном скрипте будет проходить тело всего прооекта.. хренова куча скриптов - как минимум больше памяти будет занимать, но подозреваю, что увеличится работоспособность, да и если грамотно реализовать структуру, то и не запутаешься..
А вы что скажите ?
хуяк, хуяк и в продакшн
|
|
| |
roma3fon | Дата: Понедельник, 24 Апреля 2017, 19:12 | Сообщение # 2 |
участник
Сейчас нет на сайте
| ArtemS, Это тема не простая, но вот несколько основных аспектов: 1: Самая большая нагрузка ложиться на дельтафункции, поэтому очень важно оптимизировать логику выполняемого кода именно в них, пусть даже это приведет к овер-энженирингу в остальном коде, обычно это решается большим набором булевских операторов. 2: Классы с предполагаемо большим количеством экземпляров, тут пытаемся избавиться от лишних методов, и свести к минимуму локальные переменные, так же важно следить за логикой построения деревьев классов, так что бы эти классы не создавали в себе экземпляры больших классов. 3: Не стоит транжирить память на создание клонов объектов без надобности (юзаем ref и out) 4: Для математических операций используем юньковский класс Mathf а не шарповый Math, он заточен именно на работу с геометрией и хорошо работает с остальными решениями юнити. 5: Оптимизация алгоритмов, тут советы дать сложно, но не стесняемся пилить велосипеды (1: костыль под конкретную задачу будет работать быстрее, чем обширное решение; 2: улучшите навыки) 6: Высокий уровень абстракций зачастую помогает в восприятии кода, так что коль проект большой пилите, Шура, пилите. Вот несколько полезных ссылок: https://docs.unity3d.com/ru/current/Manual/ExecutionOrder.html https://docs.unity3d.com/410/Documentation/ScriptReference/index.Performance_Optimization.html https://docs.unity3d.com/ru/current/Manual/UnderstandingAutomaticMemoryManagement.html
Сообщение отредактировал roma3fon - Понедельник, 24 Апреля 2017, 19:14 |
|
| |
EchoIT | Дата: Понедельник, 24 Апреля 2017, 20:56 | Сообщение # 3 |
старожил
Сейчас нет на сайте
| ArtemS, не писать его вообще. /thread
Цитата 3: Не стоит транжирить память на создание клонов объектов без надобности (юзаем ref и out) Юзеры IBM PC подъехали, все в мезозой!
Но в целом предыдущий ответ наиболее полный, а в плане оптимизации всегда можно посмотреть в профайлер, и то, что много жрёт - переписать по-другому. Загуглить, понять в чём проблема, заодно и научиться избегать подобных ситуаций в будущем. И да, не засовывайте всю логику в один скрипт, потом офигенно весело читать 3 000 строк и понимать, что за что отвечает, и почему один класс обрабатывает всё.
Долгожданный анонсик: State of War
|
|
| |
beril | Дата: Понедельник, 24 Апреля 2017, 22:32 | Сообщение # 4 |
Я не ленивый, я — энергосберегающий
Сейчас нет на сайте
| Цитата ArtemS ( ) Пол года смотрю и читаю разные уроки по юньке и возник вопрос.. а как правильнее или удобнее писать код для больших проектов ? IoC и MVC это достаточно для более менее нормальной архитектуры
Цитата roma3fon ( ) 1: Самая большая нагрузка ложиться на дельтафункции, поэтому очень важно оптимизировать логику выполняемого кода именно в них, пусть даже это приведет к овер-энженирингу в остальном коде, обычно это решается большим набором булевских операторов. 2: Классы с предполагаемо большим количеством экземпляров, тут пытаемся избавиться от лишних методов, и свести к минимуму локальные переменные, так же важно следить за логикой построения деревьев классов, так что бы эти классы не создавали в себе экземпляры больших классов. 3: Не стоит транжирить память на создание клонов объектов без надобности (юзаем ref и out) 4: Для математических операций используем юньковский класс Mathf а не шарповый Math, он заточен именно на работу с геометрией и хорошо работает с остальными решениями юнити. 5: Оптимизация алгоритмов, тут советы дать сложно, но не стесняемся пилить велосипеды (1: костыль под конкретную задачу будет работать быстрее, чем обширное решение; 2: улучшите навыки) 6: Высокий уровень абстракций зачастую помогает в восприятии кода, так что коль проект большой пилите, Шура, пилите. Это больше в оптимизацию, а не в архитектуру
Добавлю еще это
Код Vector3 * float * float - делает две дорогостоящих операции с вектором, Vector3 * (float * float) - одну Кеширование transform на старте, чтобы вызывать их как переменные, а не через стандартные юнити-процедуры реалтайм localPosition вместо position везде где это возможно (очень большая оптимизация при сложных иерархиях) вместо transform.localPosition = (lastPos+x*y)*z выполнять эти операции в кешированном значении и потом присваивать позицию (иначе она меняется каждую операцию и вызывает физический движок и юнитивские сервисы) Вместо Vector3*float выполнять отдельные вычисления по Vector3.x, y z, в идеале вообще не использовать операции по векторам (возможно в последних версиях юнити уже исправлено) Time.deltaTime тоже лучше закешировать в статик переменную очередное напоминание не юзать foreach Array вместо List не дают существенной разницы на unity 5.4+ (как и наличие или отсутствие геттеров и сеттеров) Можно вычислить значения синусов/косинусов для разных значений, и занести их в Array на старте, чтобы потом получать их быстрее, чем через стандартные функции (работает быстрее в редакторе, пк-билдах, не всегда на консолях (зависит от размера массива))
Общие советы делать все, чтоб не было GC Allocation не вызывать Instantiate в рантайме (только на старте) все новые структуры данных имеют свои недостатки. “пишите код, как будто вы в 1979” (List уже исправлен, Dictionary вызывают просадки при первом обращении, подписки на события тоже) использовать класс StringBuilder для работы со строками (но лучше с ними не работать вообще) избегать использования Update и FixedUpdate. Использование кастомного апдейт-менеджера, который просто вызывал кастомный апдейт во всех скриптах сэкономило 1-2мс на каждом кадре в Inside на консолях
Цитата EchoIT ( ) не засовывайте всю логику в один скрипт, потом офигенно весело читать 3 000 строк и понимать, что за что отвечает, и почему один класс обрабатывает всё. отчего же, если игра небольшая, а и для нее хватит 3000строк, то все можно впихнуть в один partial класс , только разделив его на отдельные логически обоснованные скрипты.
А так вообще полно книг на тему архитектуры и оптимизации в Unity
Так же смотри видео с Unite, там разрабы игр делятся своими секретами
Накодил? Убери за собой! Инвентарь в Unity(UI) Инвентарь в Unity(GUI)
|
|
| |
EchoIT | Дата: Вторник, 25 Апреля 2017, 01:35 | Сообщение # 5 |
старожил
Сейчас нет на сайте
| Цитата отчего же, если игра небольшая, а и для нее хватит 3000строк, то все можно впихнуть в один partial класс , только разделив его на отдельные логически обоснованные скрипты Ну я имел в виду ситуацию, когда всё в одном скрипте. Так, конечно, будет более терпимо, но я всё равно не вижу смысла в этих извращениях. Это будет какое-то процедурное программирование.
Долгожданный анонсик: State of War
|
|
| |
beril | Дата: Вторник, 25 Апреля 2017, 13:15 | Сообщение # 6 |
Я не ленивый, я — энергосберегающий
Сейчас нет на сайте
| Цитата EchoIT ( ) Ну я имел в виду ситуацию, когда всё в одном скрипте. Так, конечно, будет более терпимо, но я всё равно не вижу смысла в этих извращениях. Это будет какое-то процедурное программирование. Это называется писичная оптимизация ) экономия на вызовах и обработке событий
Накодил? Убери за собой! Инвентарь в Unity(UI) Инвентарь в Unity(GUI)
|
|
| |
Storm54 | Дата: Среда, 26 Апреля 2017, 13:29 | Сообщение # 7 |
постоянный участник
Сейчас нет на сайте
| Цитата beril ( ) очередное напоминание не юзать foreach Не всегда foreach приведет к снижению производительности, т.к. компилятор подобные моменты неплохо оптимизирует.
Цитата ArtemS ( ) общий код - очень просто запутаться, не знаю но может и обработка будет расти..так как каждый кадр в главном скрипте будет проходить тело всего прооекта.. Думаю, здесь нужно пояснить, что размер программы прямо не связан с производительностью. Все скрипты, лежащие в проекте юнити и так компилируются в одну сборку и загружаются целиком в память при старте приложения. Так что не важно, в одном классе все описано или же в разных. При разработке архитектуры в первую очередь учитывается ее расширяемость, простота поддержки уже написанного кода.
Цитата ArtemS ( ) хренова куча скриптов - как минимум больше памяти будет занимать, но подозреваю, что увеличится работоспособность, да и если грамотно реализовать структуру, то и не запутаешься.. Память, отведенная под код, будет занимать примерно столько же. Если же рассматривать каждый класс, как наследник от MonoBehavior, который вешается на GameObject в Unity, то это увеличит общее время апдейта, т.к. движок делает несколько проходов по всем объектам и вызывает соответствующие методы (Update, FixedUpdate и т.д.). Если писать свой менеджер, который будет делать тоже самое, то можно выиграть в плане производительности, опуская многие проверки, проводимые движком.
А вообще, судя по вопросам, я бы посоветовал прочитать про базовые вещи: как именно выполняется программа на более низком уровне, какие варианты организации памяти бывают, как загружается программный код. Все это не относится напрямую к Unity, но смогло бы дать ответ на подобные вопросы.
Сообщение отредактировал Storm54 - Среда, 26 Апреля 2017, 13:33 |
|
| |
|