КАТЕГОРИИ:
АстрономияБиологияГеографияДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРиторикаСоциологияСпортСтроительствоТехнологияФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
|
Engineering
1 Technical Design Document(Технический дизайн документ). Часто видеоигра включает в себя множество сложных систем, не имеющих ничего общего с механикой, но отвечающих за появление определенных элементов на экране, отправку информации по сетям и за другие исключительно технические моменты. Обычно никто вне команды программистов не думает об этих деталях, но если ваша инженерная команда состоит из более чем одного человека, будет полезно отмечать все эти моменты в одном документе, так, чтобы когда к команде присоединялись другие люди, они сразу понимали, что и как должно работать. Так же, как и Рабочий проект, этот документ редко дописывают до конца, но его написание крайне важно для того, чтобы держать под контролем всю программную составляющую игры. 2 Pipeline Overview. Большая часть сложностей, сопряженных с программированием игры, связана с правильной интеграцией элементов арта в игру. Существует множество “можно и нельзя”, которым должны следовать художники, если они хотят, чтобы их арт правильно отображался в игре. Этот документ обычно составляется инженерной командой специально для художников, и чем проще он написан, тем лучше. 3 System Limitations (Системные ограничения). Дизайнеры и художники часто не имеют ни малейшего представления о том, что возможно, а что невозможно в той системе, материал для которой они создают (или они просто притворяются). Для некоторых игр программисты создают специальные документы, в которых дают четкое представление о границах системы, которые нельзя пересекать – о количестве фигур, одновременно показанных на экране, количестве сообщений об обновлениях за секунду, количестве одновременных взрывов на экране и т.д. Часто эта информация подается более детально, но если вы обозначите ее (желательно, в письменном виде), это может впоследствии сохранить вам много времени, к тому же подобные документы могут положить начало дискуссиям, на которых часто находятся креативные решения, позволяющие выйти за эти границы. 4 Art Bible (Библия арта). Если несколько художников собираются работать над одной игрой, то для того, чтобы создать единый целостный вид этой игры, им нужна некая инструкция, по которой можно было бы следить за соблюдением этой целостности. Библия арта – это документ, который и является подобной инструкцией. Это могут быть листы с персонажами, примеры окружения, примеры использования цвета, примеры интерфейса, а также всё остальное, что определяет внешний вид каких-либо элементов игры. 5 Concept Art Overview (Обзор концепт-арта). В команде есть много людей, которые должны понимать, как будет выглядеть игра еще до того, как работа над проектом стартует. Это достигается посредством концепт-арта. Но одного арта недостаточно – лучше всего использовать его в дизайн документе, поэтому часто художники работают вместе с дизайнерами, чтобы определиться с набором изображений, по которому можно будет увидеть то, как весь арт будет выглядеть в контексте дизайна игры. Эти ранние изображения можно увидеть везде – в Обзоре дизайна игры, в Рабочем проекте, или даже в технических документах, в которых они используются для того, чтобы лучше проиллюстрировать тот внешний вид игры, которого нужно достичь посредством технологий.
|