Ответ: Сравнените Юнити и другие системы
 

Дарова :)
Помню как тебя с DarkBasic на Blitz3D перетаскивал :)

Ответ: Сравнените Юнити и другие системы
 

Было дело :rolleyes: Вот теперь на Юнити.

Ответ: Сравнените Юнити и другие системы
 

импер вошёл в чат
привет. йа тоже помню blitzgames.vov.ru

Ответ: Сравнените Юнити и другие системы
 

И я Сефирота помню, правда не уверен, что это взаимно) Тогда был у меня страшный ник - "gamer" :D

Эксплуатирую юнити месяцев 5-6, отвечу с позиции своих не очень обширных знаний:
Конструкторы игр а-ля GameMaker, 3D Game Studio. Отношение к конструкторам в среде программистов в целом пренебрежительное, и этот отпечаток иногда ложится на юнити. На мой взгляд - не конструктор.
В блитце шейдеров не было О_о По крайней мере в чистом b3d...
Можно и без шейдеров жить, чего уж там... А можно с ними... На мой взгляд, с ними красивее)
Это на тот случай, если ты захочешь делать игру с модифицируемой извне структурой. А-ля Half Life, WarCraft... То есть поставлять её с редактором. Тогда и ресурсы желательно вынести их датапаков, в которые юнити их по умолчанию загоняет при билде (речь о ПК билдах, про прочие не знаю)
Именно так. Иногда это приобретает извращенную форму - одна сцена, один объект, один скрипт, который стартует другие скрипты, и дальше всё почти как в блитце... Но это крайность, редактор юнити позволяет существенно сократить время на выполнение задачи.

Ответ: Сравнените Юнити и другие системы
 

gamer-а помню )
Вот и я про тоже примерно. На юнити без программирования я не представляю игр - какой конструктор? Шейдеры я использую те что есть и далеко не все, другие мне лично пока совершенно не нужны. Редактор выполняет пока все потребности.
Про код... можно и как в ББ кодить, но думаю это сильно не правильно )) Внутри скрипта на одном объекте в юнити может весеть куча написанных классов которые ни на каком объекте не весят, но задают определённое поведение.

Ответ: Сравнените Юнити и другие системы
 

Если в проекте работают двое человек, один из которых программист, а второй занимается созданием уровней, то для второго Unity - конструктор, т.к. он пользуется написанными программистом компонентами для настройки поведения объектов с помощью Drag And Drop.

Вот это жутко неудобно при навигации по проекту. Предпочитаю каждый класс хранить в отдельном файле в своей директории проекта.

PS: Вам отдельную тему сделать для беседы?

Ответ: Сравнените Юнити и другие системы
 

Ну в принципе так и надо. Ну я имел ввиду немного другое... например у меня несколько разных персонажей: противники и герои, их обоих объединяет возможность ходить. Это отдельный класс Move который содержит логику и особенности передвижения по особо собранному уровню. Этот класс не надо наследовать от MonoBehaviour и следовательно не надо кидать ни на какой объект в сцене, а просто подключить к классу противника или героя, которые разом получат одинаковую логику движения, которую можно дополнить другими классами.
Недавно прочитал что такое наследование - это паттерн Декоратор :rolleyes:

На какую тему? Я уже вроде всё :)

Ответ: Сравнените Юнити и другие системы
 

Не нашел тут причины держать много классов в одном файле. Либо я чего-то не понимаю... Т.е. дублировать классы Move в разных MonoBehaviour? Зачем?

Ответ: Сравнените Юнити и другие системы
 

Нет, достаточно в void Start персонажа создать экземпляр Move, а в Update через объект move получить выполнение этого класса. То есть класс объекта в сцене это меньшая часть программирования и он заключает в себе только запуск других классов. Что обеспечивает разные варианты поведения объекта комбинируя классами в скрипте персонажа.
А каждый класс в принципе и положено держать в разных файлах.

Ответ: Сравнените Юнити и другие системы
 

Кажется мне что ты изобрел монобехи в монобехах ;) Компоненты на основе MonoBehaviour и предназначены для выполнения определенных функций. В результате, чтобы сделать объект уникальным, достаточно добавить ему нужные компоненты (поведение), например компонент Move и настроить их поведение открытыми полями.

Ответ: Сравнените Юнити и другие системы
 

Ну тогда например есть ещё один, а может даже много разных но подобных, Классов - AI... они управляют твоим персонажем, то есть работает с классом Move, который содержит в себе все методы передвижения. Эти два класса ни на каком объекте в сцене не висят, а просто создаются экземпляры в классе объекта который в сцене и с монобехом. И в класс AI передаётся ссылка на объект Move, после чего AI сразу получает возможность управлять объектом через методы управления Move и без всяких монобехов и скриптов в сцене. И это уже по-моему какая-то инкапсуляция и какое-то мизерное наследование что и является частью принципов ООП, практически о отсутствии которого в Юнити здесь говорили :) На большее в сторону ООП у меня просто не хватает опыта и знаний, но в этом виноват не "конструктор" Юнити в котором кодить можно по-разному.

Ответ: Сравнените Юнити и другие системы
 

Теперь понятно. Ну если будут вопросы как организовать что-то в проекте, то задавай вопросы, подумаем вместе. Слава богу о ООП и использовании его в Unity у меня опыт есть.

Ответ: Сравнените Юнити и другие системы
 

Тема немного почищена.