lorenze
> Чем больше объём работ и членов команды
тем более важным становится документирование и управление проектом и командой, приходится постоянно контролировать что делает каждый, чтобы получалась одна игра, а не много игр у каждого своя.
kvakvs
> тем более важным становится документирование и управление проектом и командой,
> приходится постоянно контролировать что делает каждый, чтобы получалась одна
> игра, а не много игр у каждого своя.
естественно, даже тупо каждому сказать одно и тоже порой просто не возможно =) проще 1 раз написать и довести до всеобщего сведения.
>>Диз док/Тз это живые документы, написать сразу всё и до мм точно, могут лишь те у кого огромный практический опыт.
Дык об чем и речь. :)
По такому детальному документу даже полный идиот от программирования справится. Поэтому его цена и выше чем собственно код.
Ужасная "статья", просто нагромождение слов. Верстка ужасная, нет четкой структуры. Нет фактов, одни эмоции. Будь я новичком, я бы подумал, что автор неадекватен, поэтому для него все так сложно, и мое ЧСВ взлетело бы еще выше. В мусорник.
@!!ex
> По такому детальному документу даже полный идиот от программирования справится.
ну хорошо, я вот такой идиот от программирования и есть : )
откуда гейм-дизайнер может знать все нюансы программирования, чтобы идиоту осталось ток закодить? : ))
обычно геймдизы как чёрт от ладана бегут от программирования и даже скриптования, и прально делают, между прочим : )))
стало быть геймдизйнер может лишь описать некие тенденции, которые он желает видеть, или некоторый набор сценариев, что в каком случае происходит, так вот это можно описать качественно... или передать на словах программисту
если это будет передано на словах, то программист либо истерзает постановщика задачи вопросами, что правильно, либо часть задач решит самостоятельно, что менее правильно, но тоже имеет право на жизнь
иотого 2 пункта:
1. без этих вопросов геймдиз даже вобразить себе не может, что они есть
2. программист не задаёт вопросов пока он реально не начал что-то делать
стало быть какой бы ни был монументальный диздок, это всё можно смело бросать в мусорную корзину, если отдельные его части не подкреплены кодом и компилятор не дал добро : )))
Sh.Tac.
Диз док/Тз не геймдиз пишет:) А человек руководящий разработкой(он же по совместительству может быть и геймдиз), а следовательно имеющий понятие о алгоритмизации и особенностях программирования. И если руководитель проекта имеет огромный практический опыт, то он может написать очень точную/детальную проектную документацию, по которой можно делать фактически закрытыми глазами. Согласен с @!!ex, что подобный документ стоит дороже кода. Это так же как в бизнесе франчайз стоит дороже самой точки реализации услуг/товаров, так как франчайз подразумевает точнейший бизнес план, отработанный годами на практике.
Вспомнился хороший анекдот на эту тему:
Ехал как то "новый русский" на своём навороченном мерседесе по глубинке и тут он у него тупо заглох.
Естественно он в нём не в зуб ногой, и тут мимо проезжает трактор. Он останавливает и спрашивает у тракториста "эй мужик, сможешь починить ?"
Тракторист заглядывает под капот и посмотрев пару минут, бъёт своим молотком куда по двигателю, "ну что пробуй завести" .
Новый русский с первого раза заводит свой мерс.
НВ - "Сколько с меня за ремонт?"
Тракторист "100$"
НВ "а чо так дорого за один удар молотком?, слух, а ты ради прикола выпишы мне чек, я своей братве похвалюсь деревенским сервисом"
Тракторист передаёт бумажку на которой написано:
"Удар молотком = 0.01$"
"Знать куда и как ударить молотком = 99.99$"
lorenze
> Диз док/Тз не геймдиз пишет
диздок пишет, именно что, геймдизайнер % )
техническую часть пишет лид-программер/аркитект
как он её напишет, в "ворде" или в виде базовых классов/интерфейсов/инвариантов, я считаю, это его дело : ))
lorenze
> если руководитель проекта имеет огромный практический опыт, то он может
> написать очень точную/детальную проектную документацию, по которой можно делать
> фактически закрытыми глазами
очень сильное допущение, а если не имеет? ; )
хорошо, допустим имеет, и нафига ему писать "очень точную/детальную проектную документацию", если у него есть, к примеру, готовая самописная инструментальная библиотека/каркас, проверенные в "боевых" условиях? : )
а если у него нету собственной кодобазы, то какой у него к чертям "огромный практический опыт"? : ))))))))
Sh.Tac.
Прошу прощения, конечно, но сейчас несешь откровенную чушь. Взгляни на название сайта вверху страницы, а потом подумай, дизайн документ для разработки игры должен подробно описывать алгоритмы и способы решения задач для программиста? Или же он должен четко формулировать задачи для всей команды с учетом четко выбранного направления деятельности? Если кратко, диздок нужен не для того, чтобы объяснять моделлеру как работать в максе и какие модификаторы применять, но должен четко формулировать, каких персонажей/локации/пропсы нужно смоделить, какие должны быть для них анимации и как это будет использоваться в конечном продукте. Почему каждый так стремится превознести собственную значимость, забывая о том, что без слаженной работы и четкого представления о проекте далеко не уедешь? Неужели вы думаете, что код движка намного ценнее например, полного набора контента для игры? Или описаний боевой или магической системы? Или баланса юнитов? Или всем этим тоже программист занимается?
Правка Если лень читать много букафф, то в кратце:
откуда взялось понятие о том, что конечный продукт в геймдеве реализуют исключительно программисты? А если не только они, то почему проектная документация (в частности диздок) должна содержать подробную информацию только для них?
Sh.Tac.
> диздок пишет, именно что, геймдизайнер % )
Не всегда и не везде.
Sh.Tac.
> очень сильное допущение, а если не имеет? ; )
То будет меньше точности и верности.
Sh.Tac.
> хорошо, допустим имеет, и нафига ему писать "очень точную/детальную проектную
> документацию", если у него есть, к примеру, готовая самописная инструментальная
> библиотека/каркас, проверенные в "боевых" условиях? : )
Разработка игры командная работа, а в команде далеко не только программисты.
lorenze
> Разработка игры командная работа, а в команде далеко не только программисты.
это и коню ясно : ))
тока как я уже отмечал, если "руководитель" ны смыслит ни черта в программировании, то он не может напрямую писать ТЗ кодерам
он может общаться лишь со старшими программистами, которые и напишут ТЗ, либо сделают сами, чаще всего второе предпочтительнее по скорости и качеству разработки
З.Ы.
Dan Diamond
>откуда взялось понятие о том, что конечный продукт в геймдеве реализуют исключительно программисты?
потому как игра это в конечном счёте программа : ))
З.Ы.Ы.
за чушь спасибо : )))
>Неужели вы думаете, что код движка намного ценнее например, полного набора контента для игры?
код движка ничего не стоит
именно поэтому id так легко выкладывает сорцы
Sh.Tac.
> это и коню ясно : ))
>
> тока как я уже отмечал, если "руководитель" ны смыслит ни черта в
> программировании, то он не может напрямую писать ТЗ кодерам
>
> он может общаться лишь со старшими программистами, которые и напишут ТЗ, либо
> сделают сами, чаще всего второе предпочтительнее по скорости и качеству
> разработки
Руководитель производства(операционный руководитель) должен смыслить в этом иначе он ничем руководить не сможет =)
Sh.Tac.
> потому как игра это в конечном счёте программа : ))
Да только программа которая без контента никому даром не нужна :) И это не стоит забывать.
ММОГ или Игра есть коллективная работа разных специалистов и работа одних без работы других не имеет никакого смысла.
Sh.Tac.
Дизайн-документ пишет геймдизайнер. Даже по названиям похоже, не правда ли? =) То, что он не может грамотно поставить т.з. программисту - верно, но в его задачи входит общее руководство, представление о проекте и видение конечного продукта. Т.е геймдиз выполняет обязанности режиссер. Ведь чтобы организовать в фильме качественные спецэффекты, режиссеру не надо быть специалистом в этой области, верно? Естественно, что бы не было недопонимания и произвола, существуют всяческие лиды отделов. Лид программер занимается руководством и раздачей т.з. рядовым программистам (о чем ты и говоришь ;) ), лид артист руководит отделом моделлеров и художников. Но тем не менее, связью всех отделов в единую команду тоже должен кто-то заниматься. Лид геймдизайнер, например =)
Само собой, рядовой геймдиз занимается более мелкими задачами, типы шлифовки баланса или придумыванием комбо для файтинга.
Поясню на примере: геймдиз приходит к программистам и говорит о том, что для данной рпг необходимо сделать разделение на 5 локаций, связанных в определенных местах переходами с заставочными экранами в виде картинок, которые в данный момент рисуют художники. Никто не указывает программистам, как должны быть реализованы порталы, это их работа, разработать алгоритм, сделать так чтобы все работало так, как попросил геймдиз. Но если программисты сами для себя пишут документации, сами их выполняют, то кто будет следить за разработкой в целом?
>потому как игра это в конечном счёте программа : ))
Да нет же =) Привязываясь к вышеприведенному примеру, если игра это в конечной инстанции просто программа, то вместо порталов могут быть реализованы подгрузки местности например =) А что, так ведь удобнее для игрока ;) Пример, конечно утрированный, но все же =) И куда потом девать нарисованные загрузочные скрины? )))))
А если нечто, реализованное программистами будет влиять на игровую механику? Или, что хуже нереализованное?
lorenze
> Руководитель производства должен смыслить
тут мы возвращаемя к посту 22 за авторством @!!alex
>Именно поэтому, годам к 30-35 программисты уходят на другие должности - проектирование и управление.
у программиста есть 2 пути:
1. стать руководителем, не программировать самому, тупо пинать других
2. стать аркитектом, программировать самому, смотреть чужой код и "слегка журить"
мне кажется, что если программист к указанному возрасту так и не разобрался, что же он такое делал всё это время, ему надо однозначно идти в руководство, там компетентность не является залогом дальнейшего продвижения по карьерной лестнице, зачастую даже очень наоборот : ))
>только программа которая без контента никому даром не нужна
думаю в качестве прототипа и опоры дизайн-документу в самый раз подойдёт : )
>ММОГ есть коллективная работа разных специалистов и работа одних без работы других не имеет никакого смысла.
MMO слишком большая конструкция
там есть специалисты которые напрямую вообще никак не взаимодействуют друг с другом
и это ИМХО есть хорошо, т.к. низкая связность приветствуется даже в коде, чего уж говорить о человеческих взаимоотношениях : )))
З.Ы.
Dan Diamond
не вижу противоречий и предмета для споров по приведённому посту : )
>А если нечто, реализованное программистами будет влиять на игровую механику? Или, что хуже нереализованное?
именно поэтому конечный программист важнее любого самого именитого геймдизайнера : ))))))
Sh.Tac.
> думаю в качестве прототипа и опоры дизайн-документу в самый раз подойдёт :)
Я о другом) для конечного пользователя программа без контента даром не сдалась )
Sh.Tac.
> MMO слишком большая конструкция
> там есть специалисты которые напрямую вообще никак не взаимодействуют друг с
> другом
>
> и это ИМХО есть хорошо, т.к. низкая связность приветствуется даже в коде, чего
> уж говорить о человеческих взаимоотношениях : )))
Да аналог нейронной сети - оптимален :) Порой даже имеет смысл разделять специалистов одного направления.
Dan Diamond
Есть 2 типа руководителей)
1) геймдиз/режисёр-руководитель - хорошие примеры Дж. Лукас и П. Мулинье
2) программист-руководитель - хорошие примеры Б. Гейтс и Дж. Кармак
Независимо от специальности навыки руководства общие для всех.
Sh.Tac.
lorenze
Дык, весь спор-то о том, кто должен составлять проектную документацию, т.е. дизайн документ =)
Sh.Tac. утверждает, что программист или лид программист, я утверждаю что геймдиз, точнее лид геймдиз )))) Тем не менее, это должен быть лид, т.е. руководитель. А должен ли он отлично разбираться в программировании или геймдизайне? Мне кажется, что в геймдизайне - обязательно, а вот в программировании- опционально.
Берем ммог: нам требуется внедрить систему караванов и их грабежа игроками. Для этого нам нужны неделимые локации без системы порталов, т.е. без подгрузок между разными локациями. Как это будет реализовано - дело программистов, т.к. они работают с движком и это их специальность.
Но ведь документации должно быть указано что мы хотим получить на выходе - систему, когда игрок собирает караван, движется из точки а в точку б, а на этом пути его грабят другие игроки. Механика грабежа тоже должна отображаться в документации, т.е. в деревеньке грабить нельзя, а в лесу можно. А грабеж происходит путем набирания очков в миниигре match3 на отдельном экране. Я как геймдиз не буду описывать алгоритмы, с помощью которых Match3 реализуется в коде, но я опишу саму механику миниигры, примеры уже реализованных подобных игр и отличия от уже существующих аналогов.
Так вот, все что написано выше начиная со слов "...в документации должно быть указано..." - задача геймдизайнера (лид геймдизайнера).
Если все согласны с этим, то вопрос снят и спор разрешен =)
Тема в архиве.