Октябрь 2008

«.. .looking на практике открытым исходным кодом компьютерной игры сообщества [...] Мы видим нечто иное, чем то, что выступает в принципах программной инженерии.»

Уолт Скакки

Практика развития бесплатно/Libre Open Source программное обеспечение (F/убытки) набирает обороты в компьютерной игровой индустрии. Традиционно проприетарные отрасли становится все более заинтересованы в F/потеря парадигмы для разработки сложных программных проектов. Руководители и разработчики должны понимать потенциал, включающий F/потери практики в их собственные производства цикл предложения.

Как правило собственностью и процессы разработки программного обеспечения F/потери сравниваются с точки зрения имущественных прав, распределение доходов и мощности в сети актеров. Координации и контроля практики, примирительного артефакты и средства разработки и взаимодействия между различными субъектами, участвующими в развитии часто пренебрегают. Собственности и развития F/потери различаются с точки зрения обмена знаниями между соответствующими субъектами и различные стратегии для преодоления информационной асимметрии. Признавая, что это различие является важным шагом для оценки как собственности, могут воспользоваться закрытым исходным кодом программного обеспечения дома путем интеграции различных F/потери практики в их повестки дня в области развития.

Компьютерных игр и сообщество F/потери

Взаимодействие между F/потери и компьютерных игр, развитие идет минимум десять лет назад и может быть связано с двух различных, хотя и переплелись тенденции: i) усилия некоторых крупных промышленных игроков использовать потенциал базы пользователей в развитие собственных компьютерных игр; и ii) возникновение сообщества пользователей/разработчиков, преследуя независимых игровых проектов.

Эти тенденции происходят с конечными пользователями, изменение кода для расширения и настройки их игровой опыт. Задолго до включения конечных пользователей в производственный цикл стал обычной практикой, многие игры, такие как Wolfenstein 3D, стал популярным после того, как их форматы были обратной инженерии. Это разблокирована возможность для масс для редактирования спецификаций по умолчанию (например, сценарии, карты, символы и правила взаимодействия), таким образом «modding» игровой среды в соответствии с предпочтениями пользователя. Некоторые игры компаний, таких как id Software и Epic Игры, стали активно и начали явно кооптировать их пользователей баз в производственный цикл, вызывая развитие и совместное использование создаваемого пользователями контента. В большинстве случаев они преднамеренно открыли периферийные характеристики своих игровых платформ или общей части кодекса согласно либеральных условий лицензирования. Некоторые представили конкретные инструменты, такие как редакторов карт, направленных на облегчение участия технически неквалифицированных пользователей.

Появление онлайн игровых сообществ укрепили эту тенденцию. Онлайн игра позволила индивидуальных игроков, чтобы их интересы в рамках общины. Именно через это поверхностное участие, что большинство игроков стал первым «modders» и по времени, напрямую разработчикам. Ранние общины вращались вокруг проектов, опираясь на крупные несвободные программы, которая впоследствии была выпущена как открытым исходным кодом. Это позволило модификации и разработка вариантов F/потери собственных версий игр. Появление независимых открытых сообществ разработки оригинальных игр с тех пор стали более частыми.

Компьютерные игры, кажется, очень популярны среди общин F/потери: по состоянию на Октябрь 2008 SourceForge репозиторий показывает 29,831 игровых проектов. Программное обеспечение, разработанное в этих общинах включает ролевые игры, моделирование игры, Multi пользователя подземелья, первого лица стрелков, аркады и платы/карты/стратегии игры. SourceForge в ранг деятельности показывает, что среди 100 самых активных проектов 7 относятся к категории «Игры/развлечения». Почти 60% компьютерных игровых проектов у конечных пользователей как их предполагаемой аудитории. Остальные являются проекты программного обеспечения, такие как наборы инструментов, моделирования, рендеринга и анимации двигателей рамок, предназначенных для разработчиков.

Природа F/потеря сообществ

Эскиз цикла разработки для типичных F/потери компьютерной игры проекта из-за весьма неоднородный характер F/потерь общин трудно. В то время как ранние исследования убедительно противопоставляются F/потери развития с закрытыми исходными моделями, они включены существование «единое сообщество с общими ценностями, мотивы и подходы к развитию». В целом эти исследования не смогли понять природу процессов развертывания, развития и осуществления F/убытков, а также контексты, в которых происходят эти процессы. Недавно было признано, что более плодотворным для изучения F/потерь развития с точки зрения атрибутов сложного социально технической системы, вместо того, чтобы технические усовершенствования. в последнее время. Этот новый подход фокусируется на взаимодействии между различными субъектами и различные артефакты для интерпретации сложного характера социально технических процессов, которые происходят в общинах F/потерь.

Есть несколько артефактов в общинах F/потери, которые имеют «возможность подключения различных социальных миров и поддержания социально технического взаимодействия» (см. публикацию авторами следующей статьи в этом выпуске). Это можно увидеть в схемы, которые выступают в качестве механизмов с участием заинтересованных участников, таких, как хакеры от F/потери сообщества и программного обеспечения корпорации в промышленности OSS лицензирования. Различные виды лицензий предоставляют различные стимулы для участия в инновационном процессе, в соответствии с конкретной бизнес-модели, используемые фирмой. Например лицензии GPL, как, в отличие от лицензии BSD, как ограничить включение дополнительных и совокупных инноваций в собственнический продукт. Это отпугивает участие от фирм, которые сильный акцент на схемах прямых доходов, а привлечение фирм из взаимодополняющих отраслей или с дополнительных бизнес-моделей.

Различные лицензии представляют артефакты этой структуры деятельности и практики путем введения различных политических и технических границ, затрагивающей участие субъектов и внедрения инноваций. Соответственно свободного identity является результатом переговоров между участниками повседневных взаимодействий и практики. Например решение выпустить код по конкретной лицензии рассматривается как результат участников переговоров о направлении, в котором хочет технологии эволюционировать, границы сообщества, и так далее.

Несмотря на трудности в получении единой модели процесса развития по-прежнему можно в целом описать, какие процессы и практика являются популярными в F/потери компьютерных игровых проектов. При этом, мы постараемся осветить основные различия с собственной моделью. Типичный проект вращается вокруг сообщества заинтересованных сторон, в которых конечные пользователи и разработчики имеют перекрывающиеся роли и самобытности. Социальная структура проекта лук как, что позволяет различать между различными уровнями участия в проекте. Центральное значение для проекта основных разработчиков, которые способствуют большая часть кода и кто может принимать участие в принятии основных решений для проекта, например дизайн архитектуры. Внешние слои представляют собой более частичное участие в деятельности в области развития и включают в себя со-разработчиков, которые обеспечивают: i) патчи и исправления ошибок; II) локализации деятельности; или iii) более эпизодический взносы большей части кода. Активных пользователей, которые участвуют в различных мероприятиях обратной связи, такие как тестирование и ошибка отчетности представляется более внешний слой. Как правило основополагающую роль играет Руководитель проекта - часто инициатор проекта, который активно участвует в развитии ранних выпусков программного обеспечения. Со временем руководитель проекта проводит более общей деятельности по координации проекта.

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

Общая картина довольно далек от Раймонда идею «Великого журчащий базар различных программ и подходов [...] из которых последовательной и стабильной системы может казалось бы возникнуть только путем правопреемства чудес». Большую часть времени, вклад в проект весьма Мониторим и рецензируемых различными формами иерархического элемента управления с целью сохранения, хотя и в весьма децентрализованной разработки среды, концептуальная целостность проекта.

Разработка игрового программного обеспечения в полностью собственной среде

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

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

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

С учетом этого представляется очевидным, что разработчики маргинальные субъекты в сети взаимозависимости, которые в конечном итоге создать конечный продукт, как они полностью зависят от консоли производителей и издателей. Однако это мнение не отражает один из основных компонентов разработки успешных кусок игрового программного обеспечения: возможность использования сильно асимметричные источники идей, творчества и технического опыта кодирования. С этой точки зрения мы обнаруживаем несколько уровней сложности, которые едва ли можно считать вторичной для всего процесса. Мы считаем, что социальная роль средств разработки и промежуточного программного обеспечения как инструменты контроля и граничных объектов между своеобразных областями знаний и идей является ключом к пониманию этой модели разработки.

Большинство проектов включают концепции и разработка нескольких модулей функционального кода, которые объединяются в конечный продукт. Мы выделяем две категории модулей: i) основные модули, которые продукт отдельно от конкурирующих продуктов и где разработчики концентрируют большую часть их опыта; и ii) периферийные модули, которые полный и интегрировать ключевые компоненты и менее критично для успеха игры. Периферийные модули часто полагаются на сторонних средств разработки для порта процесса от высокого уровня кода, творческих художников в рамках группы развития в конкретные, скомпилированный код, который может выполняться на любой комбинации аппаратного обеспечения. Это позволяет разработчикам сосредоточиться на внутренней механики программного обеспечения, которые они производят без инвестирования ресурсов в изучении конкретных аппаратных архитектур каждой платформы.

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

Этот разрыв в знаниях не могут быть заполнены как правило, большинство разработчиков, поэтому важность промежуточного программного обеспечения производителей. Технически подкованных разработчики могут в принципе, сможет восполнить этот пробел. Однако внутреннее развитие инструментов обычно экономически нежизнеспособным. Таким образом тенденция покупать инструменты на рынке. Недостатком является производным от отказа от контроля к третьим сторонам осуществления высокого уровня идей в рабочий код. Мы должны подчеркнуть, что, по крайней мере в принципе, более комплекс оборудования и более быстрые циклы развития для этих платформ менее разработчик скорее всего будет принять стратегию сделать для своего промежуточного программного обеспечения. Мы считаем, что прогрессирующая потеря компетенции механизмов перевода от высокого уровня, описательные языки, обычно используемые творческие художники в нижнего уровня код, необходимый на различных платформах.

Сравнение и некоторые критические замечания

Сравнение проприетарные и F/потери с точки зрения прав собственности на код программного обеспечения может ввести в заблуждение. Первый полезный аспект, вдоль которого сравнить эти процессы могут быть определены заинтересованными сторонами. В процессе развития F/потерь обычно существует хороший уровень технических знаний однородности между основными разработчиками, контент-провайдеров или более периферийных устройств пользователей. Пользователь/разработчики являются характерной чертой развития F/убытков, и нет эквивалента в собственной области. Однако эти субъекты серьезно ограничены с точки зрения координации, редко будучи рядом и часто не разделяя четко определенный производственный план. В собственности случае мы находим обратное. Субъектов, участвующих в процессе развития обычно не страдают от проблем в области координации. В рамках компании координации решает иерархии хотя межфирменных координация осуществляется через двойной механизм контрактов и контроля качества взаимодействия. Однако качество знаний и неоднородности представляют собой основные проблемы. В консоли разработки пользователи не считается значимым источником обратной связи и даже непосредственно субъекты обладают высокой продифференцированным компетенций, строго связанные с этапом процесса развития они специализируются.

Мы наблюдаем появление двух дифференцированных наборов инструментов, используемых разработчиками. В мире F/потеря средств координации, таких, как списки рассылки и CVS-репозиториев широко распространены, но редко используются программные средства, используемые непосредственно производить другие фрагменты кода. В собственной консоли рынке разработки программного обеспечения инструменты мост программного обеспечения высокого уровня, творческих произведений, обычно производимых художниками или сказочников с очень мелкой опыт программирования и код нижнего уровня, который может быть скомпилирован на данной платформе. Наличие асимметрии в областях знаний между различными субъектами создает возможности для третьих сторон представить инструменты, которые усиливают эти асимметрии. Если производитель нижнего уровня программы, он будет в конечном итоге потерять эту способность, либо непосредственно, из-за отсутствия практики, или косвенно, потеряв tech подкованных персонала или не привлекать компетентных программистов.

В отличие от что обычно происходит в общинах F/потери, собственные разработчики имеют ограниченное влияние в пути средства разработки изменена и изменения консоли производителя для внутренних слоев комплекта программного обеспечения, или производителей промежуточного программного обеспечения для внешних слоев, которые взаимодействуют с языком высокого уровня. В этой связи мы могли бы добавить, что промежуточное программное обеспечение является посредником между производителем оборудования консоли и разработчик программного обеспечения конечного продукта не только с технической точки зрения. В самом деле возможность фильтрации, выберите и анализировать работы производителей промежуточного программного обеспечения является одним из основных инструментов, которые производитель консоли должен влиять на работу разработчика. Напротив F/потеря компьютерных игровых сообществ можно рассматривать как архетипической экземпляр управляемого пользователя или сообщества на основе инновационной модели, в которой конечные пользователи рассматриваются в качестве основных драйверов в процессе генерации инноваций.

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

Эта статья была адаптирована с проектирования, производства и использования артефактов консервативного фирмы знаний: Свидетельство собственности и открытых процессов разработки программного обеспечения. Università degli studi di Trento. DISA технический доклад, 116, 2006.

Рекомендуемые ресурсы

Понимание требований для разработки открытых программных систем

Свободная практика разработки в игре сообщества

Доля этой статьи:

Цитируете эту статью:

Оцените содержание: 
6 голосов были поданы с средний балл 3.33 звёзд