Вторник, 16 Апреля 2024, 16:02

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 1 из 1
  • 1
Форум игроделов » Движки для разработки игр и сложные системы разработки » Unity » А как правильно писать код ?
А как правильно писать код ?
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 строк и понимать, что за что отвечает, и почему один класс обрабатывает всё. :D


Долгожданный анонсик: State of War
berilДата: Понедельник, 24 Апреля 2017, 22:32 | Сообщение # 4
Я не ленивый, я — энергосберегающий
Сейчас нет на сайте
Цитата ArtemS ()
Пол года смотрю и читаю разные уроки по юньке и возник вопрос.. а как правильнее или удобнее писать код для больших проектов ?

IoC и MVC это достаточно для более менее нормальной архитектуры B)

Цитата 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 класс , только разделив его на отдельные логически обоснованные скрипты

Ну я имел в виду ситуацию, когда всё в одном скрипте. Так, конечно, будет более терпимо, но я всё равно не вижу смысла в этих извращениях. Это будет какое-то процедурное программирование. :D


Долгожданный анонсик: State of War
berilДата: Вторник, 25 Апреля 2017, 13:15 | Сообщение # 6
Я не ленивый, я — энергосберегающий
Сейчас нет на сайте
Цитата EchoIT ()
Ну я имел в виду ситуацию, когда всё в одном скрипте. Так, конечно, будет более терпимо, но я всё равно не вижу смысла в этих извращениях. Это будет какое-то процедурное программирование.

Это называется писичная оптимизация ) экономия на вызовах и обработке событий :D




Накодил? Убери за собой!
Инвентарь в 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
Форум игроделов » Движки для разработки игр и сложные системы разработки » Unity » А как правильно писать код ?
  • Страница 1 из 1
  • 1
Поиск:

Все права сохранены. GcUp.ru © 2008-2024 Рейтинг