| |
CrashBoom
Пользователь
Откуда: Москва
Регистрация: Авг. 2004
Всего: 39 сообщений
|
Привет. Мое имя - Джош Сойер. Я - разработчик игры, прежде Black Isle Studios, в настоящее время работающих для Midway San Diego. Я - не эксперт по процессу развития игры, но я работал с довольно многими производителями и имел возможность видеть много различных стилей руководства проектом и неумелого руководства. Я вижу, что много честолюбивых людей намеревается делать Моды, 90 % +, из которого никогда не заканчиваются. Я не думаю, что это - потому что идеи не являются нормальными или потому что вовлеченные люди - связка идиотов. Я думаю, что это - потому что проекты - a), плохо спланированы б), плохо намеченный и c), плохо управляемый вообще.
Это не обычно для проектов быть успешными несмотря на неумелое руководство. Вы можете конечно развить игру или мод без напряженного управления, но Вы могли бы также желать, щелкать вашими пятками вместе, и надеяться, что вещи объединятся. Управление занимает время и ни забава, ни очаровательное, но это имеет жизненное значение к успеху усилия команды. Я хотел бы предложить процесс и некоторые общие подсказки о том, как организовать ультрасовременный проект. Эти предложения - не обязательно лучшее в мире. Вы можете даже думать, что они - плохие идеи, но они, кажется, работают от моей перспективы. Эти предложения предполагают, что Вы, инициатор делающего модинг процесса, являетесь руководителем группы/продюсер/бог император. Не станьте слишком догнанным на правах; только умственно отсталые легкой походки эго действительно дают проклятый так или иначе. Если Вы - те, координирующие вещи и получающие вращение шара, этот пост для Вас.
Прежде, чем я начинаю с поломки стадии, я хотел бы предложить некоторый общий материал:
Установите форум сети, IRC канал, список адресатов, база данных ошибки и FTP сайт для вашего мода. Есть много свободных форумов сети. http://www.ezboard.com/ - приличный. Находить IRC сервера принимать гостей за вашим случайным каналом - не обязательно, что трудный, но может занять время и требовать скачка через обручи. Однако, обсуждение в реальном времени по еженедельному основанию довольно важно для связи команды, духа товарищества, и общего единства. Списки адресатов - хороший способ уколоть уши людей, которые не могут читать правления каждый день или кто был эффективно помещен в очередь к соединению ультрасовременной команды. Только не злоупотребите этим. http://www.bugzilla.org/ - симпатичная проклятая хорошая открытая ошибка лицензии, отслеживающая пакет программ. FTP сайт может быть трудно качаться для некоторых людей, но это действительно полезно для того, чтобы организовать активы. Только дайте uploading привилегированным людям, организуйте структуру папки, как Вы считаете целесообразным, и это будет делать вещи намного более легкими для каждого.
Не позвольте людям (или полной команде) дрейф. Держите людей, сосредоточился на задачах под рукой. Много людей, которые предлагают для мода только, хочет сделать материал забавы высокого уровня. Много материала в развитии игры - не забава. Однако, если Вы можете держать людей, сосредоточенных на задачах вехи (даже не забавы), веха строят, должен показать достаточный прогресс, чтобы действительно качать людей. Задачи не забавы полезны, когда вознаграждение превышает тяжелую работу.
Если возможно, использование кое-что подобно http://www.wikimedia.org для ваших документов мастера. Всегда держите backups исходных файлов, но лучшее, если полная команда имеет доступ к одной версии документов. Это помогает предотвращать беспорядок, когда изменения сделаны. Конечно, всегда сообщите вашим членам команды, когда документы изменили, и позволяют им знать то, что изменилось и где они могут видеть то, что изменилось.
СТАДИЯ ВИДЕНИЯ (лидерство команды)
Установите то, чего Вы пробуете достигнуть с вашим модом. Вы просто пробуете создать набор новых уровней? Вы собираетесь изменять HUD? Вы собираетесь добавлять новое оружие? Вы собираетесь добавлять новые модели характера к игре с новыми мультипликациями? Широта покрытия и глубина. Сколько новых уровней? Сколько новых монстров?
Оправдайте, почему любой должен дать **** о том, что Вы делаете. Почему - эта забава? Если Вы хотите делать мод, потому что Вы лично думаете, что это - забава, несмотря на ее узкое привлекательность, это прекрасно. Однако, более легко получить людей (включая потенциальных членов команды) возбужденное о том, что Вы делаете, когда Вы можете быстро и ясно сказать им, почему, что Вы делаете, собирается быть забавой и возбуждением.
Когда Вы определили то, что Вы хотите сделать и почему это будет забава, записывать это в ясных, кратких сроках для распространения людям, которые могут хотеть воздействовать на вашего мод. Вы действительно не хотите принести людям на борт только, чтобы сделать так, чтобы они уехали на полпути через проект, потому что они неправильно истолковали то, чего команда/Вы пробовала достигнуть. Держите каждого сосредоточенного на ваших целях с начала, и напомните себе о них через проект.
Учитывая возможности вашего мода, делайте грубую оценку того, в каком количестве членов команды Вы будете нуждаться. В этой стадии, Вы предполагаете, потому что Вы не будете иметь хорошей идеи относительно того, что вовлечено с каждой задачей. Однако, Вы должны быть способны оценить некоторые вещи. Например, если ваша цель состоит в том, чтобы делать новые уровни и использование существующими инструментами, чтобы изменить вещи, Вы вероятно не будете касаться кодекса и не будете нуждаться в программистах. Однако, Вы будете нуждаться в проектировщиках уровня, чтобы вынуть карты и 2D художников, чтобы создать структуры. Сломайте ваши потребности в четыре дисциплины подкоманды: проект, искусство, программирование, и аудио.
Для каждой дисциплины Вы будете укомплектование персоналом, пробовать найти тот действительно хорошим членом команды. Не пробуйте укомплектовывать полную команду немедленно. Как проектный директор, Вы имеете хорошую идею относительно видения, но Вы можете быть плачевны при анализе деталей осуществления того видения. Прежде, чем Вы бросаете 4-8 "художников" в мод, Вы нуждаетесь в уравновешенном, информированном анализе ваших художественных потребностей. Найдите одного хорошего художника сначала. Найдите одного хорошего программиста, если Вы нуждаетесь в том. И эй, если - все, Вы нуждаетесь, это является большим. Если наводнение добровольца людей, благодарите их за их подчинение, но говорите им, что это будет короткое время прежде, чем Вы полностью укомплектовываете. Держите в контакте с ними в течение пре-производства, так что они не уйдут далеко. PROTIP: Вы можете найти людей, которые хотели бы помочь Вам, - bitchin высшего качества ’, но только не имеют времени. Рассмотрите вежливо спрашивающим у них для их помощи в анализе других претендентов, особенно если Вы не знаете достаточно о дисциплине, чтобы отделить пшеницу от мякины. Теперь, когда Вы имеете основную команду, это - время для пре-производства.
ПРЕДПРОИЗВОДСТВО (команда ведет и основная команда)
Как только Вы установили вашу основную команду, распространяете ваш документ видения для анализа. Цель - для основной команды, чтобы серьезно анализировать возможности проекта и разломать это вниз на реалистические списки задач. УЧРЕЖДЕНИЕ СПИСКА ЗАДАЧИ ИМЕЕТ ЖИЗНЕННОЕ ЗНАЧЕНИЕ К УСПЕШНОМУ УПРАВЛЕНИЮ ВАШЕГО ПРОЕКТА. Помните, для всего, что Вы хотите достигнуть, кто - то должен заставить это случиться. Вещи волшебно не становятся сделанными. Даже наименьшие задачи должны быть внесены в список (в пределах разумного конечно - только пробуют быть полным). Сопровождение списков задачи должно быть списками актива. Актив - любой объект (обычно художественный объект, но возможно файл таблицы или другой бит данных), который должен быть создан для использования в игре. Например: Одна из задач - создание Монстра X. Неявный в создании Монстра X - создание Монстра данные Xа (в кодексе или через редактора), его модель, его структуры, ее скелет, и ее мультипликации. Когда Вы намечаете эти задачи, Вы можете группировать их в списке задачи для простоты (то есть: Монстр мультипликации Xа), но убеждается, что фактически внес в список все те активы в доступном для команды списке где-нибудь. Если Вы не вносите в список это, Вы могли бы также предположить, что это не собирается быть созданным.
Создайте документы мастера для каждой дисциплины. Эти документы эффективно будут проектами и руководящими принципами для того, как ваш мод закончен. На них будет ссылаться другие члены основной команды и большей командой в течение стадии производства. Документы мастера должны объяснить, как каждый набор задач будет закончен и должен внести в список спецификации для активов и процессов где необходимо. Если программисты будут нуждаться в некотором компиляторе или наборе библиотек, делайте это совершенно ясным. Если структуры для геометрии уровня все были властью двух размеров, 4 битов, не больший чем 512x512.tga формат, и входить под 2 megs на одном грузе, было бы мудро внести в список это. Организация этих документов может быть обсуждена основной командой, но формат должен быть решен руководителем группы.
Организуйте ваш список задачи. Удалите избыточные вхождения. Продвиньте связь между членами команды, чтобы признать зависимости и риски. Вы можете найти, что некоторые из основных членов команды осуждают элемент видения как невозможный или чрезвычайно высокий риск. Если команда прибывает в согласие на этом, серьезно рассмотрите пересмотр видения и возможностей проекта. Что – ни будь, что является "опасным" - кое-что, что должно быть осуществлено и проверено как можно раньше. Это особенно важно, если это - элемент пьесы игры, которая могла бы пан или пропал проект. Если Вы имеете странного нового механика или оружие, которое может решительно изменить пьесу игры, осуществлять это рано и проверять это. Если целый проект опирается на ту “новую вещь”, и это сосет, нет никакого смысла к продолжению вперед с видением как написано. Зависимости между задачами (например, Вы нуждаетесь в этой поддержке редактора прежде, чем Вы можете делать эту работу особенности), должен быть ясно отмечен за более позднюю интеграцию в график. Все зависимости должны быть закончены до задач, которые нуждаются в них. Я знаю, что это кажется логичным, но Вы были бы удивлены, сколько людей “не получает это”.
Оцените время, требуемое для каждой задачи. Да, каждая единственная проклятая задача. Наименьшей единицей времени должен быть приблизительно час. Они не должны быть гиперточными оценками, но они должны быть реалистическими. Если Вы являетесь неуверенными на наборе задач, дополняете их немного. Почти всегда лучше оценить, что задача возьмет больше времени чем меньше времени. Если задача входит под оценкой, горячий проклятый, Вы - на мгновение раньше срока.
Суммируйте часовые работой общие количества для каждой дисциплины, возможно организованной разделом науки (мультипликация или моделирование, например). Это даст Вам хорошую идею относительно ваших потребностей укомплектования персоналом. Если Вы имеете 38 часов программирования задач, один программист, работающий 5 часов в неделю в течение 8 недель должен поразить цель. Если Вы имеете 180 часов художественных задач, один художник, работающий 3 часа в неделю не собирается быть сделанным в том же самом году как программист, так, чтобы мог бросить рывок в ваши планы в течение трех месяцев dev цикл.
Держа зависимости в памяти, начните организовывать список задачи в график. Дайте акцент пунктам высокого риска, и координируйте их к дате вехи пре-производства. Также, если Вы имеете многошаговый трубопровод/процесс для того, чтобы получить активы в игру, проверьте их. Замысловатый трубопровод может записать бедствие для проекта. Эта веха пре-производства будет служить доказательством концепции и способностей команды. Если Вы можете успешно закончить самые опасные элементы проекта своевременным способом, заканчивая другие элементы должен быть более легок, даже с большим (более трудным справиться) команда. Поскольку Вы намечаете эти вещи, получаете реалистические оценки от членов команды на том, сколько часов они могут вставить в неделю. Действительно, пожалуйста, имейте в виду, что Вы воздействуете на мод, и что люди могут иметь реальные жизни и реальные рабочие места, чтобы проявить внимание. Закончите стадию выполнения вашей вехи о рабочей неделе перед фактической датой вехи. Отпуск на прошлой неделе для щипания и установки ошибки. Будьте устойчивы об этом. Не позвольте особенностям осуществляться после вашего однонедельного сокращения. Устойчивый, играемый строят, должна быть цель. Качество, не количество.
Если падения графика, короткие в одной дисциплине (например, будет требоваться две недели, чтобы сделать все в пре-производстве, но мультипликации, которая возьмет восемь недель), или штат или переместит дату вехи пре-производства кое во что более реалистическое. Поймите, что это займет время, чтобы найти новых членов команды и получить их до скорости, так наметьте "их" задачи соответственно; не наметьте несуществующего члена команды с задачами день, что Вы понимаете, что Вы приезжаете короткими.
Координируйте новых членов команды с ядром так, чтобы группа роста была все еще все на той же самой странице. Сделайте так, чтобы они прочитали документы мастера и взяли их обратную связь, когда соответствующее.
Начните работу над вехой пре-производства. Имейте всех членов команды, сообщают ежедневно относительно их прогресса. Если член команды не сообщает, предполагает, что они не достигали ничего. Продвижение курса реалистично. Если Вы видите, что люди надевают даты, обсуждают проблемы с ними и пробуют приспособить ваш график соответственно. Не ждите до конца вехи, чтобы принять меры. К тому времени, это должно слишком поздно установить проблему. ЗАКРАДЫВАНИЕ В РАЗВИТИЕ ИГРЫ ПРОИСХОДИТ, ПОТОМУ ЧТО ЛЮДИ НЕ ПОНИМАЮТ ИЛИ НЕ ПРИНИМАЮТ МЕРЫ КОГДА НАМЕЧЕННЫЙ ПРОМАХ ЗАДАЧ. Если необходимо, переназначите задачи от члена команды "скольжения" члену команды, который является раньше срока (или желающий сделать больше работы), или заменять члена команды. Ультрасовременные рабочие печально известны за быть всем разговором, никаким действием. Они не будут оштрафованы за быть не в состоянии сделать их работу добровольца. Не беспокоите попытку класть поездку вины на них; если они не являются достаточно восторженными, чтобы делать время для этого, получать их от команды. Это столь же просто как это.
Непрерывно держите полную информированную команду (пассивно в форме сети и активно в модернизации еженедельной электронной почты) прогресса каждого члена на вехе. Мало того, что прохиндеи помогают мотивировать других членов команды (“Эй, мы фактически сделали кое-что! ”), но команда будет остро знать, скользит ли любая из их зависимостей. Только не внесите в список даты, проценты от завершения, и названий задачи. Напишите краткий обзор того, что было сделано, что не сделало, и что это означает, полный.
Около конца вехи, в преднамеренной дате, имеют анализ команды того, где веха стоит и какой потребности быть сделанной, чтобы заставить это случиться “for reals”. Некоторые задачи не могут быть достижимы. Обратите внимание, что и обсуждают это в посмертном пре-производстве. Для всего остального, делайте реалистические и соответствующие модификации к графику. Если одна мультипликация будет отсутствовать, возможно убеждая, что аниматор работать немного дополнительный на прошлой неделе не неблагоразумен. Сам хруст не плох. Никакой график не совершенен. Хруст плох, когда непрерывно, потому что нет никакого реалистического, проверенного графика.
Создайте строящийся с активами вехи пре-производства (кодекс, искусство, диалоги, и т.д.). Рассмотрите это и распространите это членам команды. С ними, выполните посмертный, чтобы анализировать то, что пошло не так, как надо, что пошло право, и что это означает для наступающих вех и задач. Активно вытяните мнения из членов команды на том, что они чувствовали, пошел право и неправильно. Некоторые люди не предлагают мнения, даже если они имеют жизненное значение.
Если вашей вехой пре-производства не был плачевный отказ, идти дальше к производству.
ПРОИЗВОДСТВО (полная команда)
Переоцените списки задачи, и разломайте их вниз на вехи, подобные вехе пре-производства. Каждая веха должна иметь кое-что, чтобы показать. Для любительских модов, не обязательно имеет значение, если вехи две недели длиной, один месяц длиной, или три месяца длиной. Что является важным - то, что существенный объем полной работы достигнут, что берет веху, строят к значительно более высокому уровню чем предыдущая веха.
Обратитесь к любым рискам, которые возникли в течение пре-производства. Измените возможности проекта, начните искать новых членов команды, и т.д. графики и документы мастера не вырезаны в камне. Они живут документы, и нужно рассмотреть также.
Поскольку новые члены команды продвигаются, приносят им до скорости, помогают им чувствовать себя подобно, они - часть сообщества, и работы, работы, работа того графика. Обратите внимание на это. Изменение это. Принесите уменьшение к вниманию членов команды и акта на этом быстро.
Закончите вехи, куклу. Трудная часть, уже о которой позаботятся. Я не забочусь, хотите ли Вы дать эльфу синие глаза или серые глаза, или если пусковая установка ракеты сделала 50 или 100 пунктов ущерба на прямом ударе. Вы и команда можете понять это самостоятельно. Но если Вы не имеете организованного, намеченного подхода к вашему проекту, маловероятно, что любая из тех деталей действительно собирается иметь значение.
|
Отправлено: 10:51 - 31 Авг., 2004
|
|
Raven
Пользователь
Откуда: Владик
Регистрация: Февр. 2004
Всего: 408 сообщений
|
Машинный перевод? Нехорошо :-( Попробую "причесать" на досуге.
|
Отправлено: 15:36 - 31 Авг., 2004
|
|
CrashBoom
Пользователь
Откуда: Москва
Регистрация: Авг. 2004
Всего: 39 сообщений
|
Я и говорю что плахой перевод. Я его читал, но это лучше чем ничего ведь так.
|
Отправлено: 17:51 - 31 Авг., 2004
|
|
olegmmm
Пользователь
Откуда: Ульяновск
Регистрация: Июль 2004
Всего: 36 сообщений
|
Можно создать топик с таториалом
Джош Сойерс: Воздействие радиации на цвет глаз у эльфов или жил ли Мастер на горе Ородруин.
:))
(Отредактировал(а) olegmmm - 1:04 - 1 Сент., 2004)
-----
Ты остаешься,
Я ухожу - две разные
Осени для нас
|
Отправлено: 0:59 - 1 Сент., 2004
|
|
Arnx
Пользователь
Откуда: Nsk/berdsk
Регистрация: Янв. 2003
Всего: 41 сообщение
|
Старые прописные истины. Максимально уплотните взаимодействие между участниками проекта. Максимально документируйте проект(с целью оценки и правильно поставленых срокой и ключевых точек(mail stones,way points etc)), для чего на первых этапах привлекайте минимум народа, но высокой квалификации. Организуйте "правильный" документооборот (хотя бы CMM1). Подходите к этому как к работе, а не забаве. Не допускайте потери контроля, разброда среди лидеров и тп... Этого материала везде хватает, только почему то народ его читать ленится. Причем понять этот материал еще не значит суметь ему следовать.
Народ, бошльше читайте, начиная от классики - Гради Буча и кончая экстремальным программированием.
|
Отправлено: 12:43 - 1 Сент., 2004
|
|
Silver
Member
Откуда: Moscow
Регистрация: Февр. 2005
Всего: 23 сообщения
|
Все проекты, в которых я принимал участие имели такую схему
Я тут недавно, но уже нашёл 2 мажорные проблемы
1. - это хостинг файлов. С этим могу помочь, есть секрваки с хорошей скоростью.
2. - это отсутствие общего IRC сервера для участников проекта. Там весь контенгент мог бы общаться онлайн и обсуждать детали все вместе. Тоже могу помочь. Есть возможность сделать вам приватный сервер, тобишь, никаких оффтопик.
Думайте, комарады, решать вам!
-----
Let me cut your ugly pinky finger, mr. president of United States of America!
|
Отправлено: 18:21 - 3 Марта, 2005
|
|
| |
|