- Amber
- Пользователь
Suslik
Мне всегда был интересен системный подход к самообучению.
Быстрее примерить на себя чужой опыт и определить его недостатки и достоинства, чем бродить вслепую.
Xunter
Почему не поверю? У меня у самого сейчас так, я комментировал "детский сад". До каких-то размеров диаграммы избыточны, либо размеры уже не маленькие, но диаграммы не нужны, потому как все кто надо знают, что происходит в коде. Веселье начинается когда над проектом работает много народу, особенно если кто-то уходит (надо продолжать его работу, для этого для начала надо узнать что он вообще делал) или приходит, или надо ВСЁ срочно поменять (например, надо срочно добавить фичу, о которой 10 раз у гейм дизайнера спросил, возможно ли её появление в будущем и заверил его, что раз невозможно, то и сделано всё так, что это не реально поменять в текущем положении дел, но выяснилось, что издатель говорит, что без этой фичи и игру вообще выпускать не стоит...).
В общем, я ни с кем не спорю. Если человек утверждает что-то, что ему обеспечивает качественно и в срок сделанную работу, а другой утверждает что-то противоположное, но это ему обеспечивает качественно и в срок сделанную работу, то они оба правы, хоть и противоречат друг другу.
the_siv
>я комментировал "детский сад"
я, в общем, тоже.
>Веселье начинается когда над проектом работает много народу, особенно если кто-то уходит (надо продолжать его работу, для этого для начала надо узнать
>что он вообще делал) или приходит, или надо ВСЁ срочно поменять
бывает, да. вот только те диаграммы, которые предлагают чертить перед тем как писать код - они ничем тут не помогут.
если подсистему писал один человек, и он уходит - то тому кто будет на его месте придется вникать в весь тот код.
и код при некоторой культуре бывает вполне читаемый.
докуметацию бывает надо заставлять писать - но это ровно описание интерфейсов(того, что в public) классов, примеры использования в вики иногда.
это всё после имплементации пишется.
Результат голосования разделился примерно поровну.
Итак, есть люди, живущие в самом эпицентре созидания и потому при этом созидании им не нужен вспомогательный объяснительный материал. В пользу этого поведения говорит эволюция Дарвина. Как жизнь пришла к своей теперешней, пусть не идеальной, но вполне дееспособной форме, так и проекты, находясь в постоянном развитии, куда-то идут... и как ни странно доходят. В срок и качественно. Главное успеть удалить перед сдачей все коменты с матами, написанные от избытка эмоций в прокуренной насквозь комнате в четыре ночи в глубокой отладке... Так живут практики.
А еще есть теоретики. Они на вечном пути к совершенствованию и структуризации. Тленная практика для них намного рутиннее свободных изъяснений творческой мысли. Теоретики заняты вечной инкапсуляцией и точностью. И в итоге почти никогда не начинают проектов. Так как для них эти лишние часы продуктивнее потратить на шлифование модели.
Это две крайности. И что самое интересное, никто из них не является неправым. Они даже могут работать в паре.
А где же истина и реальность? А она где-то между.
---------------
Диаграммы действительно бесполезны для думающих о том как и что писать...
Но только диаграммы видят везде те, кто думает на языке написания.
С их помощью невозможно написать игру. Зато можно объяснить уже написанную кому-то постороннему.
А ненаписанную этому кому-то объяснить с их помощью не получится.
Зато получится объяснить ее себе! А не в этом ли их главная задача?
Инкапсулировав включенные системы, проект становится не то что платформенно-независимым, он становится независимой абстракцией сам по себе. И имея диаграмму нужной детализации проработки, можно воспользоваться готовыми (чужими) решениями, вставляя их на определенные места этой диаграммы. Получится быстрый, не без корявостей, но отлаженно работающий результат. А потом, по мере подготовки собственного кода, чужие блоки меняются на отлаженные свои и получается желаемое.
Значит, создав абстрактный результат мыслительного процесса, мы получаем практически мгновенную его практическую реализацию, приложив минимум усилий. И можем ощутить конечный результат еще задолго до
наложения последних штрихов.
--------------------------
Все разработчики лавируют где-то между практиками и теоретиками. И я склонен полагать, что создатель темы решил на время примерить на себя шкуру последних. Так может те, кто и так носит их шкуру, направят мысли в русле основного вопроса?
Может все-таки попробуем разработать теоретическую базу программы, обладающей необходимой модульностью?
Немного не так:)
Скорее уж проектирование нужно и обязательно. Но после получения приемлемого плана надо переходить к разработке. Хотя бы для получения некоей визуализации. А перейдя к ней, не брезговать вновь вернуться к проектированию. И пусть даже начать все сначала. Все сразу и "на ходу" просто не получится.
В данный момент (и еще долгое время после этого) меня интересует именно проектирование. И коль уж речь зашла о нем в этой теме с самого начала, то может попробуем продвинуться сколь-нибудь в данном направлении?
Дописано: в конце-концов можешь глянуть на огрызок моих диаграмм вначале.
Вий
Спасибо вам огромное! Вы очень вовремя это написали, а Я вовремя это нашёл. (Только что начал "проектировать" и писать свою игру и свой движок. ))
У меня лишь один вопрос. Для проектирования систем нужно иметь опыт создания подобных систем или просто систем. Получается, если у меня его нет (я не закончил ни одной сколько-нибудь сложной игры), я не могу браться за проектирование игр? Ведь для придумывания архитектуры игрового движка недостаточно прочитать статью или книгу о том, как кто-то ещё, пусть и очень опытный, делал подобное. Нужно пробовать самому. Как же тогда быть?
P. S.: И в методе улучшения есть один хороший плюс - он удобен для обучения. Шаг первый - я инициализировал DirectX, шаг второй - я нарисовал кубик, шаг третий - я оттекстурировал его... И вот через 15 шагов у меня есть базовые знания о трёхмерной математике, принципах работы с DirectX'ом, и как бонус - простенькая игра, в которой кубик стреляет кубиками в кубики на полянке. Можно показывать друзьям и гордится. А потом учиться подключать шейдеры и делать освещение по Фонгу...
Но то для обучения. Если цель именно создать игру/движок, то тогда ваш подход разумнее. А учиться через улучшение интереснее, чем сначала сделать сотню маленьких примеров из книг по различным API, а потом уже садиться за проектирование всей системы в целом. Это называется кормить себя пряниками. )
Проектирование системы проводится путем упрощения абстрактной модели в мозгу.
Для начала надо разобраться с элементами, входящими в эту систему. Грубо говоря, все, что мы считаем нужным, мы туда пихаем, а что считаем несущественным - отбрасываем. Делим тоже так, как нам привычно\логично\удобно.
Потом надо разобраться со входами и выходами. Отбрасываем "паразитивные" или "несущественные".
Потом..
Весело, по ТАУ нас уже поднатаскали, а вот моделирование систем будет только в следующем семестре.. Эх..
Ну, по идее, теперь от этой диаграммы мы должны прийти к мат.модели (это замена каждого блока какой-то передаточной функцией, то есть диффур записанный в зависимости выходного сигнала от входного), покрутиться там, проверить на устойчивость в различных режимах, а потом вернуться к реальности, Нео :)
Вий
Ошибки проектирования самые дорогие в исправлении. Не каждый себе может позволить посреди проекта менять архитектуру и заниматься проектированием. Тут всегда есть баланс между "поставить затычку" и "переписать весь модуль как надо, убрав все затычки и с расчётом на будущее" с уклоном в первый вариант.
В начале проекта трудно представить себе по полному что будет нужно, иногда требования могут дико поменятся. Можно отталкиваясь от опъта предполагать что будет и делать запас прочности на всякий случай.
Проектирование я думаю есть у всех - прежде чем пишется подсистема, обсуждается ее грубая структура, кто и как ее собирается дергать и юзать, как она сохраняется на диске, апдейт логики и всякое такое. Ето все описъвается в таске, потом уже могут бъть более мелкие и детайльнъе таски.
А про документацию - ето безусловно полезно, но не в том виде, которъй бъл показан тут.
Т.е. мое мнение, что диаграмма кто кому принадлежит - ето какая-то абстрактная штука с околонулевой ценностью - кто кому нужен, тот того и заюзает - очевидно.
Но диаграма въполнения кода - ето полезно, т.е. как системъ взаимодействуют, как и какие потоки даннъх получаются. Ето помогает представить как работает программа, как связанъ подсистемъ логически тоже видно. В отличии от простой стрелочки от текстурного менажера к классу движка...
Ценность такой диаграмъ - документальная и обозрительная, т.е. сам же автор подсистемъ пожет посмотреть и прокинуть примерно ефект размножения етой подсистемъ, смотря на диаграмму въполнения кода.
Чтобъ не бъть голословнъм, вот примерно как въполняется код на самом верхнем уровне в одном из наших движковъх тредов:
Картинка не доделанная, т.е. ее ценность вообще ниская в етом виде, но дает информацию как срабатъвает етот тред и что юзает. Грубо видно зависимость подсистем.
P.S.: Въдрано из документации движка...
Вий
я конечно понимаю, что чукча не читатель, но.
>Собрать требования - это очень важно. Это исходные данные для проектирования. Но когда у Вас есть исходные данные, рано приступать к созданию
>системы.
нет никогда в проекте с нуля четкого и полного описания игры. дизайнеры не проектируют игру сверху до низу - это итеративный процесс, того самого не любимого тобой, улучшения. вначале - "хотим нечто похожее на это и это с такими фичами", потом поток новых фич, отказ от некоторых старых и т.д.
еще новые фичи от художников, и от начальства, и от нвидии.
>А вообще - стоит обратить внимание на обычные скучные не игровые системы. Игры от них, на самом деле, ничем не отличаются.
отличаются, да. геймплей - это продукт проб и ошибок, железо постоянно меняется, требования к играм - тоже.
игрой помимо программистов еще куча народу занимается.
>Нужно систему спроектировать.
никто не спорит, что надо. но это не декомпозиция монолитной системы до элементарных кирпичиков.
есть определенные решения разных подсистем - выбирают из них.
то, про грабли - это фигня, и шаблоны знают, и успешный опыт других изучают.
ты там обобщил нехило - типа бездумно код фигачат - это вот совсем не так. просто человек с опытом знает, что 80% системы это разные нюансы
- выражать их в диаграммах будет намного дольше чем писать код, да еще и восприниматся они будут хуже.
>Неверен подход "Узнали что нужно? Отлично! Давайте улучшим то что есть!" Мы уже сделали, видимо, что-то и думаем дальше, что б такое к ней
>приделать и приделывать ли вообще...
в начале проекта с нуля - да, неправильный. но большая часть создания игры - она такая.
http://software.intel.com/ru-ru/articles/designing-the-framework-… -game-engine/
вот русский вариант статьи от интела и их многохадачный енжин. в ссылк епоменял на ru-ru
Помню тож так же рисовал свою диаграмму классов , чего к чемуу и т.д... ээх ! красивая получилось !! Но потом, когда начал делать , поняв что надо тут переделать .. там.. выкинул диаграмму в топку.
Вопрос всем диаграмщикам на засыпку: Что должны показыватьэти диаграммы (какова цель ) ???
Помимо того , что она является красивой картинкой .
В принципе ничего:)
Это лишь удобное представление наполнения программы. И как бы ни хотелось доказать обратное - не более.
Тоесть они позволяют взглянуть как бы с высоты птичьего полета на разрабатываемую программу.
Свысока - отдельные самые главные блоки.
Чуть ближе - структура блоков
Еще чуть - взаимодействие между ними.
Близко - подробная проработка каждого пункта структуры блока.
Ну а еще ближе уже будет сама программа.
Другой вопрос, куда теперь эту карту программы засунуть... окроме топки.
Например можно попробывать объяснить человеку как программа работает. Показать основные связи, структуры. А потом кусок кода, отвечающий этим структурам. Может от ничего и не поймет, но ощущение что что-то уловил получит.
Или второй вариант - при добавлении/устранении некоего функционала сразу же проследятся последствия этого действия по связям в диаграмме.
Ну и кажись все.
Тобишь основной смысл - вместо написания кусков кода а потом подгонки их друг другу, гоняются прямоугольнички на диаграмме. А потом уже все пишется, с надеждой что все заработает так как надо.
ksacvet777
Ну вот попадешь на работу, тогда поймёшь ;) А если еще вас на проекте будет штук 15 програмистов... :)
Rom
> Ну вот попадешь на работу, тогда поймёшь ;) А если еще вас на проекте будет штук 15 програмистов... :)
диаграммы тут не помогут настолько, насколько могут помочь знания главного программиста о проекте, которые не так легко вылить в диаграммы...
соглашусь с Z, и даже возможно перейду к использованию подобных схем, так как вижу подобные схемы или просто записи порядка выполнения на бумаге у многих коллег...
Тема в архиве.