Ответ: _Epic
 

Имхо лучше сразу забить на "скрипты на объектах" и делать нормально, главным скриптом. Им создавать, им обрабатывать и им удалять все и вся. Визуальную часть редактора юнити оставить для формирования сцен, расстановки триггеров и прочего, что сделать кодом "на глаз" тяжело

Ответ: _Epic
 

Забить на модульность и гибкость разработки. Конечно у каждого свой подход, но зачем пренебрегать возможностями, которые дает редактор и не упростить код?

Ответ: _Epic
 

Навскидку не вижу преимуществ у "главного скрипта" перед "каждый объект сам себя контроллирует"-парадигмой. Подискутируем?

Ответ: _Epic
 

Имхо, за счет правильного использования модульности можно сделать нехилый такой реюзабельный код. Если префабы полностью автономны, то не возникает проблем с перекидыванием их из одних проектов в другие. Даже если они (проекты) вообще разных жанров и основаны на разном фреймворке.

Попробуй-ка поддерживать такую гибкость, используя один главный скрипт, который и удаляет, и создает, и управляет...

Ответ: Один главный скрипт или модульность?
 

Вынес обсуждение в отдельный тред

Ответ: _Epic
 

Несмотря на то, что я не верю в реюзабельный код
(

)
, таки подтверждаю, что таскать запчасти меж проектами очень удобно.

Но всё равно интересно, какие бенефиты приносит схема "всё в одном".

Ответ: Один главный скрипт или модульность?
 

очевидно - остутствие необохдимости менять парадигму разработки (человеку, привыкшему работать с похожими на блиц системами).

Ответ: Один главный скрипт или модульность?
 

Сомнительное преимущество... по началу можно так поступать, но только пока изучаешь систему

Ответ: Один главный скрипт или модульность?
 

это даже скорее не приемущество - а причина, заставляющая людей так поступать.

я вообще щитаю инструмент надо использовать на 100%. - можно декомпозирвоать скрипты - надо это сделать.

Ответ: Один главный скрипт или модульность?
 

мне поначалу очень сложно было принять, что единой точки старта нету как во всех нормальных программах.

впрочем все равно какие-то главные скрипты должны быть, которые должны как-то контролировать игру. например отвечать за остановку игры во время паузы или проверять не закончена ли игра по причине пгбеды или проигрыша и наверно еще куча примеров в игре найдется. или я все же не правильно понимаю?

Ответ: Один главный скрипт или модульность?
 

Обхожусь одним-единственным скриптом с несколькими статичными переменными. А дальше уже микро-скрипты хавают значения состояний и действуют в соответствии с ними.

Ответ: Один главный скрипт или модульность?
 

Не могу ориентироваться нормально в файле с кодом где 2000+ строк, ну нафиг. Для небольших игр это вполне приемлемо, в остальных случаях нет.

Ответ: Один главный скрипт или модульность?
 

вот какой скрипт должен отслеживать состаяние игры(есть ли рядом враги, зив или нет игрок) и включать нужные графический и звуковые эффекты? или при достижении определенного тригера отключать все управлениг камеру и включать кат сцену?
как такое делается?

Ответ: Один главный скрипт или модульность?
 

За каждую часть игры/уровня может отвечать отдельный скрипт, остальные могут быть выключены. При достижении чекпоинта управляющий скрипт может смениться на другой с другим управлением и т.д. Есть много вариантов решения такой задачи. Я не думаю что километровые свитчи состояний это нормальный выход.

Ответ: Один главный скрипт или модульность?
 

А кто говорил что нельзя разбить на инклуды?

Ответ: Один главный скрипт или модульность?
 

В C# нет инклудов. Есть только partial.

Ответ: Один главный скрипт или модульность?
 

А как же using?

Ответ: Один главный скрипт или модульность?
 

using namespace? пространство имен и инклуды абсолютно разные вещи.
юсин лишь позволяет не писать путь к пространству имен в коде.
п.с. импорты в джаве лучше ибо они автоматически ставятся. в шарпе я еще ниразу не видел чтобы кто-то писал свое пространство имен. да и в одно пространство имен обычно столько классов засовывают, что список из сотни абсолютно разных классов получатся. и я так понимаю я свой класс вполне могу засунуть в чужое пространство имен, что не гуд. да и весь код в фигурные скобки брать - мне не нравится.

Ответ: Один главный скрипт или модульность?
 

просто using.

хотя да. это просто неймспейсы.

в любом случае можно писать классы в разных cs файлах и пользоваться общими функциями даже без using ( по крайней мере в MSVS, не знаю как на юнити)

Ответ: Один главный скрипт или модульность?
 

С точки зрения игрока не важно, как написана игра, поэтому, я считаю, нужно делать так, как удобно, даже если сам инструмент настроен именно на работу с отдельными скриптами, объектами и префабами.

Ответ: Один главный скрипт или модульность?
 

Эм... Посоны. Можно подробней про юзанье одного главного скрипта и контроль объектов* из него? Просто хочу понять как работать с этим.
* - в смысле, какой самый шустрый вариант.

Ответ: Один главный скрипт или модульность?
 

По скорости работы скриптов варианты одинаковые, по организации кода и модульности разработки главный скрипт проигрывает по всем пунктам. Никакого конструктора игр одним главным скриптом из Unity не сделать, а ведь конструктор - это ее достоинство.