ITCS - Разработка компьютерных игр. Общая информация-2 - РАЗРАБОТКА КОМПЬЮТЕРНЫХ ИГР
Сегодня: Понедельник, 05.12.2016, 23:39 (МСК)| Здравствуйте, Гость| Мой профиль | Регистрация | Вход | RSS

Домашние системы
3D-видения

Роботы и экзоскелеты

Роботы и экзоскелеты

Новинки в области цифровых камер

Adobe Audition 3. Лучшая в 2010-м
Главная » РАЗРАБОТКА КОМПЬЮТЕРНЫХ ИГР

Разработка компьютерных игр. Общая информация-2

26.07.2010
Уф-ф, конечно, хотелось бы побыстрее приступить к технической практике, к чему призывают некоторые читатели… но, давайте все делать планомерно. Давным-давно во французском городе Шартр строился собор. Тогда спросили у рабочих, чем же они занимаются? Первый ответил, что замешивает раствор, второй — носит кирпичи, третий — воздвигает леса, и только один сказал: «Я строю Шартрский Собор!».
Каждая современная игра, в переносном смысле, — это шартрский собор, а для его постройки необходим точный план. Впрочем, создание подробного плана также является серьезным техническим этапом, которым, к сожалению, очень часто пренебрегают.  

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

Какие 20-30 профессий, связанные с геймдевом вы имели в виду…?

В принципе, есть ранжирование, то есть при достижении определенного профессионального уровня специалист должен возглавить определенный отдел, то есть, с некоторого момента он должен иметь и навыки руководителя. А так можно выделить основные профессиональные направления:
  • Литературное. Написание сценариев для игры (сюжета), отдельных квестов и уровней. 
  • Звуковое. Музыкальное и звуковое оформление игры, сюда же входят программисты, которые отвечают за звуковой движок. 
  • Графическое. Это 2D-художники, 3D-моделлеры, аниматоры, текстурщики. Программирование графического движка, пользовательского интерфейса. Визуализация спецэффектов (взрывов и т.п.). 
  • Алгоритмическое. Физика персонажей и виртуальных сред, искусственный интеллект для NPC, аниматов, компьютера при варианте оффлайн кампаний. Оптимизация алгоритмов. Программирование. Реализация и эргономика управления, многопользовательского режима. Создание или использование языков представления знаний (ЯПЗ). Расстановка целей. 
  • Тестирующее. Тестирование игры и ее отдельных модулей. 
  • Локализационное. Перенос игры на другие платформы (Mac, игровые приставки), перевод на другие языки.
  • Сервисное. Поддержка обратной связи с пользователями, сайта и т.п.
  • Менеджмент, в данном случае мы его рассматриваем как управление. То есть, руководство.
  • HR-отдел. Поиск и набор новых работников в команду.
  • Коммерческий отдел. Распространение, договора с издателями и так далее. 
  • Технический отдел. Главным образом, это касается онлайн игр, для функционирования которых нужно содержать сервер, производить администрирование и т.п.
Как вы понимаете, здесь обрисована общая утрированная картина, и в каждом конкретном случае команда имеет свою структуру, тем более, что некоторые сегменты являются смежными, а сама разработка делится на определенные фазы. Спрос существует буквально на все профессиональные направления, и даже если вы пройдетесь по форумам и найдете там большое количество предложений от композиторов и писателей сценариев, то это не значит, что они не востребованы и рынок в этих сферах заполнен. Нет, просто есть явная конкуренция, и чем сложнее профессия, тем конкуренция меньше.   

На какие книги следует обратить внимание?

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

Хочу посвятить себя разработке компьютерных игр. С чего следует начать?

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


О самом важном


Теперь переходим непосредственно к продолжению материала. В предыдущей части, которую можно считать вступлением, мы практически бросились «из огня да в полымя», и, в принципе, так и нужно было сделать. Но сейчас имеет смысл подробно рассмотреть самые начальные фазы работы над игровым проектом, их три, а именно, разработки идеи, создания наброска и определения требований. А в целом это выражается в создании диздока (димзайн-документа), на базе которого формируется список требований к технической части, решаются вопросы финансирования, вырабатывается конкретный план дальнейших действий. Не смотря на кажущуюся ненужность, обсуждение этого вопроса и его практическое понимание является чуть ли не самым важным. 
При разработке идеи или создании диздока вы изначально должны (рекомендуется) ответить на следующие вопросы:
  • К какому жанру относится проектируемая игра (шутер, квест, логическая, симулятор, RTS, TBS, RPG)?
  • Каков сюжет?
  • Данная игра является простой или сложной?
  • Какая графика будет применяться — трехмерная или двухмерная? Какая будет проекция обзора у игрока?
  • Какие цели у данной игры, а также что будет являться победой, а в каком случае получается поражение?
  • Игра большей частью тактическая или стратегическая?
  • На какое время рассчитано прохождение всего сюжета? Сколько предусматривается уровней, если они имеются, и какое время будет затрачено игроком на прохождение каждого из них?
  • Игра рассчитана на одного игрока или является многопользовательской? Или и то, и другое?
На самом деле, это только первоначальные вопросы, они помогут в создании предварительного наброска, который уже более детально описывает структурные области игры. При этом на данном этапе нужно попытаться для себя как можно более широко ответить на вопросы экономической целесообразности: для кого рассчитана эта игра, на какие сегменты она рассчитана и каковы спрос и конкуренция в планируемой нише?
После составления предварительного наброска, который включает в себя все ключевые описания самой игры следующим этапом идет составление списка требований для каждого отдельного пункта. Причем именно он (этот список) будет являться отправной точкой для дальнейшей разработки и использоваться там в качестве основы. Поэтому описать все нужно как можно более определенно и полно. 


Пример


Давайте приведем конкретный пример, возьмем его, что называется «с потолка». Сначала отвечаем на предварительные вопросы, которые написаны выше:
  • Стратегия реального времени (RTS).
  • Война в космосе в 3020 году. Военизированным отрядам десанта необходимо зачистить место высадки на планете Х от монстров, организовать там свою базу, собрать ресурсы для формирования новых войск и выступить против космической коалиции, которая расположена в другой части планеты Х. Изначально герой является сержантом и управляет небольшим отрядом и так далее…
  • Средней сложности.
  • Трехмерная графика, вид сверху.
  • Цель — захватить планету Х, получить звание главнокомандующего. Победа в случае успешного выполнения всех операций (прохождения уровней), поражение — гибель героя (либо для отдельных уровней невозможность уложиться в указанное время). 
  • Игра большей частью тактическая. Движение сюжета идет «от ролика к ролику».
  • Прохождение всей игры займет несколько дней, на каждый уровень будет тратиться от 20 минут до 3 часов, всего уровней — 20.
  • Игра предусматривает однопользовательский режим (кампания).
Исходя из этого, делаем набросок с исходными данными:
  • Основной сюжет — сражения в космосе, требуются: реалистичное воссоздание фантастического мира, тщательное моделирование событий, предусмотренных общим сюжетом и сценариями уровней.
  • Сражения — уровень отрядов космической пехоты, механизированных подразделений, воздушные войска. Игрок командует отрядами, формируя их по своему выбору. Соперники — крупные и мелкие монстры, населяющие планету (наземные и воздушные), войска коалиции (пехота, техника).
  • Ресурсы — плутоний, железная руда. Для их добычи необходимы специальные юниты. 
  • Строения игрока — завод по производству оружия, завод по производству легкой техники, фабрики синтеза еды, казармы и т.п. Строения соперников…
  • Реализм — туман войны, уникальные особенности природного ландшафта, возможность составления нескольких вариантов маршрутов следования, наличие тупиковых путей.
  • Игроки — человек (игрок) за звездный десант, компьютер за монстров, компьютер за коалицию. 
Как видите, мы уже составили вполне понятный набросок, в рамках которого очень много проясняется. После этого идет фаза составления требований, предъявляемых к каждому отдельному пункту. Например, описание «реалистического воссоздания фантастического мира» может занять несколько страниц с подробными требованиями о том, каким этот мир должен быть, например, указав даже гравитацию… Поскольку мы подразумеваем движение «от ролика к ролику», то лучше всего сделать наброски для каждого уровня по отдельности дополнительно, а потом сформировать требования и для них. 
Список требований является практически главным документом. После того, как он сделан, а это, на самом деле, отнимает очень много времени, все передается разработчикам, которые в свою очередь все переводят на технический язык, разбивают на технологические этапы с конкретными указаниями, то есть составляют техническое задание — это четвертая фаза работы над проектом. 
Честно сказать, не смотря на то, что первые три кажутся не очень значимыми, на самом деле это далеко не так. Причем, такое поверхностное видение чаще всего свойственно начинающим командам разработчиков, которые пытаются за все ухватиться сразу. Еще более критические моменты возникают, когда начальным фазам вообще не уделяется внимания, а некоторые пункты ставятся как «само собой разумеющееся». Например, когда меня недавно пригласили в качестве AI программиста в один небольшой проект, ваш покорный слуга попросил ТЗ (техническое задание). Вместо него мне прислали одну страницу doc-файла с весьма абстрактными описаниями: «ну здесь типа тетриса, только блоки имеют различные формы». И все! Какие формы у блоков, как они выбираются — осталось загадкой. На такое ТЗ можно смотреть с двух сторон, а именно, серьезно ли относятся к проекту вообще, и, скорее всего, ТЗ нужно будет делать самостоятельно. 
Помимо этого первоначальные фазы планирования позволяют:
  1. Избежать гигантомании и «монстеризации» проекта. Например, в фазе идей предусмотрено очень многое, но потом даже на уровне формирования наброска вы уже начали понимать, что реально воплотить, а что не очень.
  2. Дать полное руководство для разработчиков с минимумом неопределенностей и абстракций, в результате чего они сделают хорошее ТЗ. 
  3. Структуризировать проект. 
  4. Более точно сформулировать идею.
  5. Сэкономить много времени на разработке в дальнейшем.
  6. Сделать проект конечным!  
Само создание наброска идет в плотной взаимосвязи с фазой формирования требований. И вообще, первые три фазы для серьезных проектов могут занимать много месяцев. Они не будут потрачены зря. 
При этом, лучше, если в рамках данного этапа участвует не один человек, а некая команда специалистов. Уже классический пример с Gothic3 — когда разработчики почти закончили игру, обнаружилось, что среди персонажей виртуального мира практически отсутствует… женский пол:). То есть, целый мир населен мужиками. Конечно, эта история у многих вызывает улыбку, тем более ясно, что игру такого уровня без качественного планирования создать практически невозможно. Просто на первом этапе данный момент остался незамеченным, не было еще одного взгляда со стороны. 
Очень часто (это мы уже не говорим о Gothic3 и Pluto13 Gmbh) в более-менее крупных проектах можно встретить и частый стандартный подход в формировании команд, которые образуются вокруг одного человека, и он в свою очередь тянет на себе буквально все. Это ошибка. Тут, как и в футболе, выигрывает не отдельный игрок, а команда. 


***


Первоначальная идея — не самое главное, хотя в некотором смысле и основополагающее. Наиболее важным является ее качественная проработка на всех уровнях от проектирования до непосредственно самой разработки. Например, ту игру, которую мы сейчас виртуально спроектировали, можно загубить в корне, сделать неинтересной, если все сведется к добыванию ресурсов и формированию армии из тысячи единиц. С другой стороны можно сделать конфетку, предусмотрев разнообразие уровней, интересное развитие, нелинейность основного сюжета, добавление дополнительных сюжетных линий, внесению ограничений. На уровне разработки также есть место техническому творчеству. Например, сделать компьютерный ИИ более разнообразным в выборе тактик. 
Не так давно мне дали проект игры, в котором предусмотрено 43 вида юнитов для формирования армии. Это также излишество, которое, во-первых, усложняет положение игрока, во-вторых, усложняет саму разработку, а о балансе сил (у соперника другие юниты:)) говорить совсем уж не приходится. То есть, необходимо соблюдение оптимальности и баланса. 
Все написанное выше имеет самое прямое отношение к практике, тем более, что пренебрежение начальными фазами работы над проектом встречается очень и очень часто. И, в конце концов, разработчики, сломав копья и устав импровизировать в real-time режиме, переходят к идее качественного изначального планирования. Опыт.
На самом деле, создателям кинопродукции гораздо легче, потому как в качестве руководства им может служить сценарий. За исключением фантастики, где нужно дополнительно качественное отображение и представление множества деталей. В играх же все еще сложнее, потому как подразумеваются целые виртуальные миры с множеством интерактивных связей, и они должны быть органичными. 

Микро- и макро- уровни


Сегодня все игровые жанры смешиваются, поэтому единственное ключевое разбиение, которое имеет смысл вводить — микро- и макро- уровни.  Большинству специалистов и просто геймеров эти понятия знакомы. 
Под «микро-» подразумевается уровень одного или нескольких героев, управления им или ими. К данному случаю относятся все RPG, квесты, шутеры, симуляторы и тому подобное. 
А «макро-» обозначает управление сразу множеством персонажей или объектов. То есть, это относится ко всем стратегиям, как военным, так и экономическим. 
В обоих случаях предусмотрена различная методология по расстановке целей. И даже если микро- и макро- смешиваются, что бывает удачным очень редко за исключением Warcraft III и некоторых Sims’ов, все равно есть тяготение к той или иной модели. 
О расстановке целей мы сейчас и поговорим…


Расстановка целей


Большинство современных игр имеют ограниченные миры. То есть, пользователям предлагается в глобальном смысле поуровневое движение «от ролика к ролику». Помимо этого, на каждом уровне разработчиками вносится определенная система ограничивающих условий, например, из пункта А в пункт Б можно добраться только по одному или по нескольким путям, но если в Б есть дверь, которую нужно открыть ключом, который находится в ветке В, то игрок пойдет и туда. 
В стратегических играх, хоть мы и подразумеваем достаточно свободные миры с большими игровыми пространствами, цели можно расставлять и по-другому. Самый очевидный пример: нужны люди -> требуется больше пищи, для производства которой необходимы еще люди. Получается замкнутый круг или взаимосвязь. 


Пример с Dune II


Игра Dune II очень хорошо знакома старому поколению геймеров, хотя новички без особых усилий разберутся в этой военной стратегии, а фанаты данного жанра даже проведут с ней несколько дней. На ряду с очень немногими другими играми в начале 90-х, Dune II явилась во многом базисом для современной продукции в жанре RTS, точно также как Doom повлиял на шутеры. Меняются технологии (аудио, видео), но внутренняя структура сохранена. 
Популярность Dune в те времена объяснима и тем, что сама игра сделана по мотивам очень популярной одноименной саги в жанре фантастики, ею зачитывался широкий круг любителей этого литературного направления, снималось популярное кино и т.п. То есть, одно из главных условий, великолепный сценарный базис, уже было априори. 
Сюжетная линия такова: есть три враждующих расы, которые борются за господство на определенной планете, где имеется уникальный природный ресурс — спайс.  
Разработчики Dune II идентично использовали данный сюжет, и в рамках своей игры запланировали три расы, у каждой из которых имеются свои типы вооружений. При этом учтите, если на данном этапе современные разработчики, видя какой-либо сюжет, примерно понимают, как его соотнести с одним из игровых жанров, опираясь на уже существующие примеры, в то время такого не было, очень многое изобреталось с нуля. 
Dune II — это прекрасный пример расстановки целей, и именно эту игру мы взяли для описания, потому как в ней все очень хорошо сбалансировано. 


На рисунке пример расстановки целей в Dune II: cлева расположен необходимый от игрока(!) план действий, который делится на несколько промежуточных более мелких этапов по нарастающей (показано правее по стрелкам) То есть, для реализации плана, игрока нужно в буквальном смысле заставить купить завод, чтобы он начал добывать ресурсы, после чего построить электростанцию (а в игре, в начале миссий других зданий просто не дается) и так далее. Естественно, армия нужна для защиты от нападений и т. п.

На самых первых уровнях перед игроком не (!) ставится задача создания мощной армии и победы над противником, ему нужно обучиться азам, а именно как и что строить, понять взаимосвязь между сооружениями. Честно сказать, события ваш покорный слуга восстанавливает по памяти, поэтому могу перепутать этапы, но это не так важно в рамках нашего обсуждения. Игроку дается начальный капитал, и ставится множество промежуточных задач: первая — построить завод по добыче спайса, этот ресурс является денежным эквивалентом, организовать добычу. После этого возникает (! — обратите внимание на слово «возникает») необходимость в постройке электростанции, которая питает все здания. То есть, до момента появления такой проблемы, игрок и не знает о существовании электростанций, и это очень правильно! Вариант решения проблем по факту их поступления гораздо выгоднее по сравнению с тем, что вы предоставите все возможности для игрока сразу. Практически все популярные игры это предусматривают. 
Причем давайте рассмотрим ситуацию, когда в рамках миссии стоит задача добычи 2.000 единиц спайса, пользователь построил необходимые сооружения, и даже ускорил процесс добычи, и что ему остается: наблюдать за процессом накопления? Как заставить его строить казармы и тратиться на производство армии? Правильно, создать трудности или условия для этого. Например, предусмотреть небольшую атаку со стороны противника.
По существу хронология развития и появления целей вплотную взаимосвязано с возникновением новых ситуаций. Таким образом, дерево развития предусматривает некую интерактивность между игроком и виртуальной средой.
Это есть во всех игровых жанрах. 


Эволюция технологий


Эволюция технологий или дерево технологий в рамках игровых сюжетных реализаций обычно вращается вокруг трех основных моментов:
  • Развитие инфраструктуры.
  • Развитие вооружений.
  • Модернизация технологий.
Первый пункт очень важен при проектировании стратегических игр любой направленности, где предусмотрено строительство сооружений и т.п. А последние два вы можете увидеть практически во всех жанрах. То есть, это развитие навыков, получения более мощного оружия, возможность модернизации и так далее. 
Dune II в нашем примере является примитивом — всего один тип добываемого ресурса, некоторые здания могут быть построены при условии уже возведенных определенного типа, модернизация технологий происходит после нажатия кнопки Upgrade. 
Но, по существу, на таком же базисе держатся все современные игры, правда, с усложнениями и дополнениями.


За всем должна быть математика


Помимо создания деревьев целей и развития, планирования эволюции технологий вы должны определиться со шкалой стоимости, создать таблицу, в которой должно учитываться все.
Например, если мы говорим о военных RTS, то это, прежде всего, касается юнитов. А именно, броня (защита) и огневая мощь (атака). Помимо этого дополнительно стоит учитывать ряд дополнительных факторов. Например, техника передвигается быстрее пехоты, тяжелые юниты медлительнее по сравнению с легкими и так далее. Другими словами, вам нужно создать таблицу, в которой все будет расписано от и до. Особенно это важно, если вы создаете несколько рас и необходимо рассчитать баланс сил. И еще не получив данные в виде программной реализации, вы уже можете себе представить, какие соотношения будут в рамках игры. Даже более того, такая математическая модель описаний позволит скорректировать дерево целей для каждого уровня.  Да, и вообще, позволит сделать игровой процесс более динамичным. Например, в Starcraft Broodwar имеются уровни, где игроку не позволяют создавать воздушные войска. Следовательно, он сможет развиваться только по определенным логическим ветвям и так далее.
Что касается экономических стратегий, то в их основе зачастую используются реальные экономические математические модели. Причем на различных уровнях: торговли, транспортной логистики, инфраструктурного развития и взаимодействия.  


Введение ограничений


Помню, когда военные RTS приобрели огромную популярность, и спрос на них стал значительно превышать предложение, появилось очень много второсортной продукции из данного жанра. Играть в нее было уже неинтересно после прохождения двух-трех уровней. Я не буду говорить названия, в силу их большой раскрутки в то время, но все было предельно тупо и сводилось к добыче ресурсов, постройке и модернизации некоторых зданий, а после — формирования огромной армии и победы. Причем, как потом оказывалось, соперник был явно слабее и менее численный, а его атаки были предсказуемы (например, враги приходили только по одной дороге). Очень часто, особенно, в разработках среднего звена можно было увидеть варианты, когда на игрока сразу сваливается множество возможностей, не предусмотрена логическая структура следования по сюжету и развития. И по существу пользователь не понимает, за что браться в первую очередь (это, кстати, нередко отличает mod'ы от официальных версий игр). В общем, ошибка, которую мы рассматривали выше.
Поэтому ограничение количества юнитов — необходимый минимум. И, вообще, во всех хороших стратегиях, будь то RTS или TBS (пошаговые стратегии), игрок никогда не должен расслабляться, особенно на начальных этапах миссий. Отдых должен быть заслуженным. Поэтому в рамках составления кампаний, искусственному игровому интеллекту нужно следить за развитием игрока, всячески мешать ему, а при планировке задач необходимо соблюдать баланс сил.
В Warcraft III вообще было введено очень интересное ограничение. При достижении определенной численности, ресурсы начинают добываться с потерями в 30%, а если армия разрастается, то и всех 60. Поскольку само количество ресурсов ограничено, игрок должен выбирать между большой армией и малым количеством добываемого, либо искать некий баланс. Этот момент сделал игру гораздо динамичнее.
В Gothic3 (как и в предыдущих версиях "Готики") каждый уровень опыта игрока приобретается при получении определенного количества очков, они начисляются при выполнении миссий, сражений с врагами и дикими животными. Но… при достижении определенного уровня, требуемое количество очков для перехода на следующий, увеличивается на 500. Сначала это не так заметно, а когда вы достигнете, к примеру, 52 уровня, то вам уже нужно будет набрать около 25000 очков, чтобы перейти на 53-й, и здесь уже приходится выполнять более трудные квесты, сражаться с сильными животными и так далее. Введенное таким образом ограничение является прекрасной мотивацией.


Упрощение


Примерно три года назад к вашему покорному слуге обратились знакомые российские разработчики, которые хотели создать интересную игру по сюжету, связанному с национальными историческими темами. Любыми, был даже объявлен небольшой конкурс сценариев. В принципе, основу для сюжета я искал долго, но потом остановился на корабельном путешествии Крузенштерна и Лисянского к берегам Аляски. Таким образом, предполагалась смесь RTS и квеста с элементами экономики. При этом можно было включить морской юмор, морские сражения с пиратами и американцами, наземные с индейцами, осаду городов и т.п. В качестве бонуса предусматривалось абсолютное отсутствие движения от ролика к ролику, то есть, большой и свободный для передвижений виртуальный мир, сделанный по морским картам тех лет. 
Но разработчики, ухватившись за эту идею, решили иначе, а именно, захотели создать на ее базе симулятор управления парусным судном плюс RPG-квест. Как вы понимаете, все это (морская навигация большим парусным судном) подразумевает целую науку, которая нашему современнику слабо известна, причем, есть много непонятной терминологии хотя бы на уровне названий парусов. Помимо этого нужно качественно эмулировать физику, что можно сделать только при содействии людей, которые хорошо разбираются в данном вопросе и имеют опыт хождения под парусом, а также учитывать все течения, ветра и их направления, которые есть в Атлантическом, Индийском и Тихом океанах.  
Таким образом, проект из достаточно простого превращался в мега-сложный. Я не был сторонником такого развития ситуации, хотя решил поучаствовать. После столкнулся с проблемой: проект мега-сложный для разработчиков, но они никак не хотели его упрощать для игрока. Терминология на понятный для современника язык не расшифровывалась, интуитивное обучение не предусматривалось, направления ветра, течения и т.п., все показывалось множеством стрелок-векторов, для самого управления была задействована чуть ли не вся клавиатура, то есть все стало напоминать управление болидом космической Формулы-1. Соответственно, появилось много ошибок. Мало того, к технической реализации приступили сразу на сыром материале, то есть, очень многое стало додумываться в процессе, что скорее мешало, чем помогало. 
В результате всего этого, я просто попросил гонорар за идею и вышел из команды, потому как без качественного изначального планирования и учета пользовательской эргономики не видел будущего у данного проекта, как, впрочем, не вижу и у многих других. Кстати, оказался прав, поскольку, хоть на него быстро нашли издателя, он так и не был закончен к сроку, а после трансформировался во что-то другое.
Переходя к другим примерам, стоит отметить, что все должно быть понятно для игрока, и даже если используется непонятная терминология, например, в рамках фантастических виртуальных миров, пользователь должен знать, что, как и для чего. 


Психология


Классический пример из психологии, учитывающейся в играх — система начисления очков. В большинстве случаев в ней не используется разряд единиц, а оперируют десятками, сотнями и тысячами. Это один момент из многих.
Учет психологии необходим и при построении дерева целей, о котором мы говорили выше. Также это важно при построении уровней и карт для них. Например, из озвученных нами ранее исследований, в которых приводились результаты сравнения поведения обычных игроков в шахматы, очевидно, что в 70% человек поступает интуитивно. И, например, нужно, чтобы игрок в определенной ситуации пошел направо, а не налево. Помимо введения ограничений это можно сделать и на психологическом уровне. 


В завершение


Все, вводная часть закончена. В следующих материалах мы приступим к практике технической реализации проекта. Объяснение будет производиться на базе языка С++, с подчеркиванием только ключевых моментов, а в качестве основного технологического пакета мы будем использовать DirectX SDK. То есть, общего назначения. 

Кристофер

Перепечатка материалов или их фрагментов возможна только с согласия автора.







Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]
Ассоциация боевых роботов
Рекомендуем...
Новости

Разделы

Опросы

Какой язык программирования вы считаете наиболее актуальным сегодня?
Всего ответов: 308

Друзья

3D-кино






Найти на сайте:








Об авторе       Контакты      Вопрос-ответ        Хостинг от uCoz