Наконец-то добрались руки до серии книг по Unity и C#. Решил начать с самой старой и толстой, предварительно убедившись, что подходящие версии движка в принципе доступны для использования. Не могу сказать, что счас мне книга сильно понравилась, но кто знает, где бы я был, если бы она попала мне в руки в 12 лет… Тогда у меня был только ZX Spectrum, пара брошюр по ассемблеру и товарищ, у которого была возможность делать дамп памяти в любой произвольный момент :)

КДПВ

В целом, книга условно делится на три большие части: - проектирование игр на бумаге, цифровое проектирование и практическую.

Первое, что бросается в глаза при чтении первой части книги - это то, что в книге много ссылок на другие книги. Есть те, которые уже прочитал, вроде “Геймдизайн. Как создать игру, в которую будут играть все” Джесси Шелла или “LevelUp! Руководство по созданию классных видеоигр” Скотта Роджерса, которая только в планах. Но есть и такие, о которых прежде даже не слышал. Например, “Homo ludens. Человек играющий”, исследование культуролога Johan Huizinga, которое, казалось бы, должно закрыть вопрос о том, что такое игра. Но, к сожалению оно было опубликовано примерно 100 лет назад и тогда о компьютерных играх ничего не знали, а значит, что тема - не закрыта. Да и “Человек играющий” - это скорее философский трактат, который мало применим к компьютерным играм. Разве что, он может привести к мысли, что делать игры ради денег - это плохо. Игры надо делать для души :) Да, я его прочитал в поездке, еще до того, как закончил эту книгу.

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

В книге есть ссылка на оригинальный сайт, который ей посвящен и из которого я узнал, что уже вышла третья часть. Что не удивительно, во-втором издании рассматривается версия Unity 2017, которой скоро будет 10 лет. Хорошо, что она всё еще доступна в архиве на сайте движка и все примеры можно проработать в оригинальном окружение, не адаптируя его под современный, как это требуется в “Создание хоррор-игр в Roblox” Андрея Корягина, например. За это им отдельное уважение. Но блин, 10 лет изданию…

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

В целом, первые части книги посвящены разработке игры как таковых. В них вообще не затрагивается ни Unity, ни C-sharp. И мне кажется, что в этих частях очень много материалов взято из книг и лекций других авторов. В общем, что это скомпилированный материал. Как бы там ни было, но с частью этого материала я согласен и не могу сказать, что встретил много лишнего. При этом сам автор объясняет наличие такого большого количества ссылок примерно так: - “Определения помогают яснее выражать свои мысли при общении с другими людьми, действующими в этой же сфере. В этой главе больше ссылок и сносок, чем в любой другой в этой книге, потому что я хочу дать вам возможность исследовать философские аспекты игры, далеко выходящие за рамки этой книги. Следуя по этим ссылкам и читая первоисточники, вы сможете улучшить свое понимание игр”.

Для себя отложил в Яндекс.Книгах электронную версию “Философских исследований” Людвига Витгенштейна: https://books.yandex.ru/books/GgIbwgUZ (все таки, отдавать 700 рублей за 120 страниц философии я пока не готов). А перевод статьи “Игра в игру” сохранил в “научпопе” своего диска. Может быть, когда-нить доберусь и до них. Хотя, после прочтения “Homo ludens. Человек играющий” уже не уверен. Все таки, философия - это своеобразная тема, тяжело читается.

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

  • Сложность игры соответствует целевой аудитории? Игра слишком сложная, слишком простая или сложная ровно настолько, насколько нужно?
  • Результат игры зависит от избранной стратегии или от везения? Не слишком ли сильно исход игры зависит от случайностей или, может быть, игра детерминирована настолько, что после захвата лидерства одним игроком другие лишаются шанса нагнать его?
  • Допускает ли игра осмысленные, интересные решения? Когда вы получаете право сделать ход, есть ли у вас выбор между несколькими альтернативами и насколько интересным может быть выбор между ними?
  • Вызывает ли игра интерес, когда право хода получают другие игроки? В состоянии ли вы оказать влияние на ходы, выбираемые другими игроками, или, может быть, другие игроки способны повлиять на ваш выбор?

Все эти вопросы подводят к идее, что для того, что бы игроку было интересно, у него должна быть возможность выучить какие-то механики, которые помогут ему продвинуться дальше тех, кто эти механики не выучил/не разобрался. И что выбор должен иметь значение, что если просто бездумного выбирать “всегда А”, можно забрести туда, куда не планировал (проиграть).

Немного странно то, что в главе о разработке сюжета не вспоминается “Тысячелетний герой” Кэмпбелла с его вариантом развития сюжета, но при этом описываются трех- и пятиактные структуры. Мимо Кэмпбелла проходить точно не следует.

В процессе описания динамической механики встретил вариант разделения аудитории от Ричарда Бартли, на четыре типа:

  • Карьерист (♦ Бубны): старается набрать большее количество очков. Стремится доминировать над игрой.
  • Исследователь (♠ Пики): стремится найти все скрытые места в игре. Пытается понять игру.
  • Социофил (♥ Червы): любит играть с друзьями. Пытается понять других игроков.
  • Киллер (♣ Трефы): любит провоцировать других игроков. Стремится доминировать над другими игроками.

Более подробно можно почитать тут: https://mud.co.uk/richard/hcds.htm и за одно скачал его книгу Design Virtual Worlds в оригинале. Вряд ли когда-нить осилю, но всё же…

Вообще, возвращаясь назад могу сказать, что материал в принципе интересный. Есть куда подсмотреть, если что. Правда, я уже подзабыл что о этом писал Шелл, может быть там всё это лучше расписано. Тут темы не успевают раскрыться подробно, всё таки.

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

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

Снова встретил главу о мозговых штурмах, которые не плохо разобрал Альтшуллер в своей кгиге “Найти идею. Введение в ТРИЗ - теорию решения изобретательских задач”.

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

Вначале мне понравилось заявление о соглашении об именах. Вроде того, что константы только ЗАГЛАВНЫМИ буквами, использовать camelCase и все такое. Но, позже, когда я познакомился с кодом автора, у меня мнение изменилось. Все эти переменные, вроде _sTR или _tX - это не очень хорошие примеры, мягко говоря. Зачем автор экономил буквы, особенно сейчас, когда автодополнение работет из коробки и повсеместно. Ведь, из имени переменной должно быть более-менее понятно, что там вообще находится, уж из имени и типа - точно. А тут какая-то дичь, на мой взгляд. Что касается имен приватных переменных, которые автор предлагает начинать с символа нижнего подчеркивания, то в той же IDEA так не получится. Точнее, получится, но идешка будет ругаться, так как это моветон. И это не единственный момент из примеров кода, который мне не понравился.

Из того, что мне еще люто не нравилось, это использование каких-то структур или методов до того, как они будут добавлены в код. То есть, вначале автор пишет в коде что-то вроде Vector3 startPosition = getPos();, а только потом где-то в коде определяет, что это это за метод такой. О том, что в коде полно методов которые вызываются только ради побочных эффектов, вроде void someMethod() { ... } внутри которого происходит магия, тоже стоит упомянуть. Это плохие примеры, не надо так делать.

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

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

Если говорить о Unity, то не понравился способ вызова методов через Invoke, например. Легко ошибиться в имени метода, которых надо вызвать, а искать ошибку будет тяжело. Примерно, то же самое касается группировки переменных по значению Header(...), но там заметить будет проще, переменные не будут отображаться в инспекторе.

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

Прикольно то, что автор рассказывал о важности тестирования, но в примерах кода о тестах вообще ни слова. Как будто его и не существует. Хотя, с таким подходом к организации кода, как у автора, тесты писать будет сложно, чего уж. И о сборке тоже ничего особо не написано, если взять сухой остаток, то автор отсылает к документации Unity.

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

Что касается качества издания, то отдельно хотел отметить шакалье качество иллюстраций в книге. Хотя, немного не так, в бумажной книге они более-менее приличные, но при этом в электронной версии, которую удобнее использовать при работе с кодом, качество просто ужасное. И заканчивается книга как-то… неожиданно, без всяких послесловий. Посмотрел оригинал, там так же. Четвертый раздел “Следующий шаг” появился только в третьей редакции. В остальном - качество повторяет остальные книги издательства “Питер”. Хорошая бумага, приятные шрифты и крепкий переплет. По крайней мере, после прочтения книга не развалилась и выглядит, как новая.

Автор(ы):

  • Jeremy Gibson Bond

Год издания: 2019
Количество страниц: 928
Оценка: 3/5

Издатель: Питер
Ссылка на страницу книги на сайте издательства: https://www.piter.com/collection/programmirovanie-razrabotka-programnogo-obespecheniya/product/unity-i-c-geymdev-ot-idei-do-realizatsii-2-e-izd

Оригинальное название: Introduction to Game Design, Prototyping, and Development: From Concept to Playable Game with Unity and C#
Год издания оригинала: 2017