Читаем Ошибки разработчиков видеоигр. От идеи до провала полностью

Основной критерий, по которому эти крошечные игры можно отнести к разряду «отвратительных» и «непроходимых», почти всегда заключается в степени их «понятности». Подход к объяснению механик у новичков очень неуклюж. Если при игре в «Ведьмака 3» трудно не разобраться, какие кнопки нажимать для бега, атаки или взаимодействия (ибо назначения этих кнопок постоянно находятся в нижнем правом углу экрана), то в играх, сделанных на джем, иной раз приходится методично простукивать по всей клавиатуре, чтобы найти задействованные в игровом процессе клавиши, а потом долго разбираться, в какой момент эти действия нужно применять.


Наблюдение за игроками

Как же так получается, что разработчики создают нечто, что будет непонятно многим игрокам? Мы же с вами сами когда-то учились играть в игры. Самостоятельно нарабатывали игровой опыт, запоминали моменты в других проектах, вынуждавшие нас искать прохождение в интернете, иной раз злились, сидя за компьютером или игровой приставкой. Но теперь мы сами порождаем игры, которым предстоит мучить игроков, вместо того чтобы радовать их. И, что самое удивительное, мы-то сами прекрасно понимаем, как в нашу игру нужно играть, чтобы получить от нее удовольствие. Оттого вплоть до самого выхода проекта в свет мы можем не осознавать, что создали нечто, в чем невозможно разобраться.

Чтобы успеть выяснить, что ваша игра является крайне малопонятным произведением, не обязательно тянуть до выпуска: можно понять это еще на стадии зарождения первого играбельного прототипа. Но многие разработчики упускают эту возможность, демонстрируя свою игру не так, как это следует делать.

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

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

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


Правильная демонстрация

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

Во-вторых, поведение игрока и время его нахождения в игре гораздо важнее его слов. Однажды игрок провел в Reflection of Mine полтора часа, изучив каждый уголок моей демоверсии, но в итоге сказал, что моя игра из рук вон плоха. Другой же поиграл пять минут и высказал восторженное мнение, что Reflection of Mine – это шедевр. Разумеется, оба этих игрока меня обманули.

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

Перейти на страницу:

Похожие книги

Язык программирования C++. Пятое издание
Язык программирования C++. Пятое издание

Лучшее руководство по программированию и справочник по языку, полностью пересмотренное и обновленное под стандарт С++11!Р'С‹ держите в руках новое издание популярного и исчерпывающего бестселлера по языку программирования С++, которое было полностью пересмотрено и обновлено под стандарт С++11. Оно поможет вам быстро изучить язык и использовать его весьма эффективными и передовыми способами. Р' соответствии с самыми передовыми и современными методиками изложения материала авторы демонстрируют использование базового языка и его стандартной библиотеки для разработки эффективного, читабельного и мощного кода.С самого начала этой книги читатель знакомится со стандартной библиотекой С++, ее самыми популярными функциями и средствами, что позволяет сразу же приступить к написанию полезных программ, еще не овладев всеми нюансами языка. Большинство примеров из книги было пересмотрено так, чтобы использовать новые средства языка и продемонстрировать РёС… наилучшие СЃРїРѕСЃРѕР±С‹ применения. Эта книга — не только проверенное руководство для новичков в С++, она содержит также авторитетное обсуждение базовых концепций и методик языка С++ и является ценным ресурсом для опытных программистов, особенно желающих побыстрей узнать об усовершенствованиях С++11.Стенли Р'. Липпман работал старшим консультантом в Jet Propulsion Laboratory, архитектором РіСЂСѓРїРїС‹ Visual С++ корпорации Microsoft, техническим сотрудником Bell Laboratories и главным инженером- программистом по анимации в кинокомпаниях Disney, DreamWorks, Pixar и PDI.Р–РѕР·и Лажойе, работающий ныне в кинокомпании Pixar, был членом канадской РіСЂСѓРїРїС‹ разработчиков компилятора C/C++ корпорации IBM, а также возглавлял рабочую группу базового языка С++ в составе международной организации по стандартизации ANSI/ISO.Барбара Э. Му имеет почти тридцатилетний опыт программирования. На протяжении пятнадцати лет она работала в компании AT&T, сотрудничая с Бьярне Страуструпом, автором языка С++, и несколько лет руководила РіСЂСѓРїРїРѕР№ разработчиков С++.• Узнайте, как использовать новые средства языка С++11 и стандартной библиотеки для быстрого создания надежных программ, а также ознакомьтесь с высокоуровневым программированием• Учитесь на примерах, в которых показаны передовые стили программирования и методики проектирования• Р

Барбара Э. Му , Жози Лажойе , Стенли Б. Липпман

Программирование, программы, базы данных
Programming with POSIX® Threads
Programming with POSIX® Threads

With this practical book, you will attain a solid understanding of threads and will discover how to put this powerful mode of programming to work in real-world applications. The primary advantage of threaded programming is that it enables your applications to accomplish more than one task at the same time by using the number-crunching power of multiprocessor parallelism and by automatically exploiting I/O concurrency in your code, even on a single processor machine. The result: applications that are faster, more responsive to users, and often easier to maintain. Threaded programming is particularly well suited to network programming where it helps alleviate the bottleneck of slow network I/O. This book offers an in-depth description of the IEEE operating system interface standard, POSIX (Portable Operating System Interface) threads, commonly called Pthreads. Written for experienced C programmers, but assuming no previous knowledge of threads, the book explains basic concepts such as asynchronous programming, the lifecycle of a thread, and synchronization. You then move to more advanced topics such as attributes objects, thread-specific data, and realtime scheduling. An entire chapter is devoted to "real code," with a look at barriers, read/write locks, the work queue manager, and how to utilize existing libraries. In addition, the book tackles one of the thorniest problems faced by thread programmers-debugging-with valuable suggestions on how to avoid code errors and performance problems from the outset. Numerous annotated examples are used to illustrate real-world concepts. A Pthreads mini-reference and a look at future standardization are also included.

David Butenhof

Программирование, программы, базы данных