Памятка начинающему разработчику компьютерных игр
Данная статья ориентирована на школьников, студентов, и тех, кто постарше, кто никогда не пробовал, но очень хочет начать писать компьютерные игры. Кто в детстве не играл в компьютерные игры, и не хотел написать свою игру, которая будет лучше, чем GTA или Crysis? И я хотел, и, как ни странно, всё ещё хочу. И за несколько лет практики обучения таких же программированию, набралось несколько заметок, куда двигаться и что делать.
Статья не претендует на полную точность и достоверность, она написана всего лишь одним человеком, собравшим свой опыт всего за несколько лет. Так же, в ней рассматривается только практическо-романтическая сторона: тут не освещаются вопросы монетизации и получения с игр какой либо выгоды, кроме удовлетворения себя любимого, и, возможно — окружающих.
1. С чего начать?
С практики. Чем ниже уровень, на котором мы работаем — тем лучше.
Можно на чистом C и OpenGL/DirectX, это путь самурая, потому что обучаться этому с нуля, без каких-либо абстракций довольно сложно.
Можно воспользоваться фреймворками вроде SDL, или более высокоуровневыми LibGDX/PyGame/LÖVE2D, если C/C++ кажутся слишком замороченными. Тут уровень абстракции чуть-чуть повыше, так что работать чуть проще, но всю организацию внутренней структуры игры придётся делать самостоятельно, осознавая, что такое игровой цикл и как в нём организовать систему событий. Данный подход обеспечивает неплохой уровень знаний и навыков, но, поначалу, не даёт стимула забиратсья в глубину железных дебрей.
И, наконец, можно взять игровой движок вроде Unity/Unreal/CryEngine/Godot, и сделать на нём игрушку.
Итак, как же нам выбрать из всего этого разнообразия? А ведь это только малая часть. Типовая ловушка, в которую попадает начинающий ещё-не-разработчик — это выбор инструмента. Фреймворк/движок и язык. Читается множество статей, смотрятся видеоуроки, где-то про что-то говорят отличные штуки, где-то про то же самое рассказывают гадости… Идеальной системы нет и не существует, в противном случае уже давно был бы изобретён Идеальный Игровой Движок (вместе с Идеальным Идеальным Языком Программирования), и все корпорации искали бы просто «программистов», а не программистов в какой-то конкретной экосистеме. Мы просто берём тот инструмент, который лучше подходит под нашу задачу, или просто больше нравится, а выбирающий может оставаться на том же месте на каком и был годами, без какого либо прогресса.
Так как выбрать? Мы можем просто взять первое попавшееся, и начать разбираться. Не понравилось, при использовании дольше недели-другой? Берём что-то следующее, и сразу сходу пишем что-то простое вроде змейки, попутно читая документацию к выбранному инструменту и ища в гугле всё остальное, и выписывая дизайнерский документ своей Супер Игры, которая убьёт Дьябло и Doom одновременно. Зачем же начинать с чего-то простого, когда у нас уже есть идея Супер Игры? Всё очень просто, уровень навыка начинающего разработчика всегда настолько низок, что переписывать свою Супер Игру он будет двадцать раз, результаты не будут оправдывать ожиданий, и за этой фрустрацией — полное остывание к идее написания своей игры и программирования в целом. На старте обучения, мы делаем простые вещи, которые можно сразу пощупать и тут же в них поиграть с друзьями, соревнуясь в рекордах. Это наш стимул, это наша радость от самообучения и продуктивной мозговой деятельности, это то что не даёт нам перегореть. После змейки, можно сначала посмотреть на эту змейку и попробовать её переписать «по нормальному», потому что первая змейка, даже совершенно рабочая, будет иметь монстроподобную внутреннюю структуру, изменить внешний вид змейки будет очень сложно, а добавить в неё новый бонус — ещё сложнее. А потом ещё раз переписать, или перейти уже к чему-то следующему, а то эта змейка уже в печёнках сидит. Теперь будем делать, например, шарик, отпрыгивающий от стен, которым надо попасть в кольцо, не важно, что на самом деле, была бы идея.
Есть только пара советов по выбору: на мой взгляд, не стоит брать что-то слишком низкоуровневое, потому что мы тут как бы игры пишем, а не битовые флаги перебиваем и не с указателями балуемся. С чем-то сильно низкоуровневым, очень легко уйти в далёкие дебри, и потратить несколько месяцев практически впустую. И не стоит брать что-то слишком высокоуровневое (вроде движков), потому что они дают слишком высокий уровень абстракции. Пока мы не знаем как устроены движки, нам нет особого смысла пользоваться чужими наработками, нам бы самим понять как оно устроено, потому что у всех в мире движков есть множество внутренних ограничений, с которыми в будущем придётся бороться, а у нас руки и ноги связаны недостатком информации и понимания процесса, плюс как только какая-то дыра движка протечёт, мы ничего не сможем сделать пока полностью не разберёмся в его внутренней структуре. Баланс сложности изучения и свободы действий.
2. Как учиться?
Тут нам пригодится один крайне полезный навык, под названием «гуглинг». С помощью %имя_поисковика%, интернет — это огромный источник информации, который почему-то, на моей памяти, принято недооценивать, а уж вторая страница гугла — уже что-то недосягаемое. Поэтому учимся задавать вопросы поисковику, чтобы он давал нужную нам выборку. В целом, на старте, сойдут видеоуроки. А ещё можно учебников почитать. У видеоуроков есть преимущество в том, что они сразу дают осязаемый результат в сжатые сроки, что очень полезно для мотивации, но в них есть большие проблемы с полнотой информации, поэтому учебники и документацию никто не отменял. Примеры кода можно искать и смотреть на гитхабе, это крайне полезное занятие, из которого можно подчерпнуть не меньше, чем из учебников. Смотрим всё непонятное в чужом коде, и ищем в сети, что же это тут только что было. Потом используем (или нет, хе-хе). Воровство идей и концепций только поощряется (если код был под свободной лицензией). Если что-то прям совсем сложное, но очень нужное — не возбраняется обращаться к другим людям на форумах и в чатах, но этим способом очень легко начать злоупотреблять, поэтому не желательно и только если совсем припечёт, и несколько часов грамотного поиска остались безуспешными. Из областей математики очень советую прочитать и осознать векторную алгебру, аналитическую геометрию, теорию вероятности и ещё очень много умных слов, благо это довольно универсальные области, полезные не только в играх. Из языков — очевидный английский, большая часть документации написана на английском языке. Пользоваться переводчиками не возбраняется. Опять-таки, нам тут нужнее всего научиться учиться и искать информацию, это пригодится везде и всегда, не только в данной области. Тем не менее, обучение не должно затмевать практику и наоборот. Желательно держать соотношение времени между написанием и изучением на уровне 20/80, и то, практику можно только добавлять, вечные студенты — это хорошо, но непрактично. Балансируем время.
3. Захотелось чего-то посерьёзнее?
После прошлого этапа и нескольких (десятков) прототипов игр, мы уже научились сносно писать, может даже с не очень большим количеством вложенных if-elseif-elseif. Мы нашли и прочитали несколько десятков чужих проектов, и пусть половины не поняли — это всё равно не очень страшно, ведь мы уже кажется готовы делать что-то серьёзное, вроде Супер Игры? Придержим коней. У нас есть несколько прототипов, и они даже отлично играются, но мы пока даже не попробовали закончить свою работу. Как только что-то становилось более-менее работающим, мы просто переходили к чему-то более интересному, но нас ещё ждёт крайне суровый этап, на котором ломаются очень многие (и я в том числе, хе-хе): создание Законченного Проекта. Чем он отличается от наших прототипов? А вот чем: Законченный Проект — это тот же самый прототип, но над которым просидели в три раза дольше чем делали прототипную часть, сделали все менюшки, настройки, проверили что оно нормально работает на разных разрешениях экрана и с разными клавиатурами, там есть хотя бы десяток уровней или выбор уровня сложности, чтобы в это было интересно играть не только автору и его друзьям, но и случайным людям в школе или университете. Самая рутинная часть, что сказать, но самая полезная, и очень хорошо тренирует волю к победе. Если не пройти этот этап, можно на всю жизнь остаться писателем прототипов. Балансируем себя в рутине и интересностях.
4. Где искать библиотеки?
Если внимательно прочитать второй пункт, ответ становится вроде бы очевидным: в сети, в репозиториях и от других людей. И как бы всё хорошо, мы экономим время и сразу делаем что-то крутое. Но пока мы учимся и у нас есть время, и мы имеем возможность строить велосипеды — грех не воспользоваться случаем. Если чтение учебников и статей, и просмотр уроков это расширение наших знаний, то написание собственных библиотек — углубление, причём сразу по нескольким фронтам: реализация удобных API (отсечение лишнего и баланс производительности и удобства использования), углубление и исследование внутренностей нашей языко-железной экосистемы, и создание небольших законченных модулей, даже если они частично дублируют функционал уже существующих. Но тут главное — не зацикливаться. Мы же всё-таки игры пишем, и инструментарий к ним, тут точно так же можно стать библиотекописателем, и так и не сделать ни одного Законченного Проекта. Но тут тоже огромный пласт общего опыта.
5. Заключение.
Осталось ещё много неосвещённых вопросов, на некоторые из них будет кратко отвечено тут.
Что такое дизайнерский документ и для чего он нужен? Это такая вики по ещё не созданной игре, чем полнее, тем лучше. И эту штуку стоит сделать ещё до начала игры, примерно прикинув время разработки имеющимся количеством людей и отсекая фичи.
Зачем отсекать фичи? Проходя предыдущие этапы, можно приблизительно прикинуть время, за которое тебе и твоей команде надоест заниматься этим проектом. Если мы в ситуации подвальной инди-разработки без финансирования и расписания работ, есть очень высокие шансы появления разброда и шатания вместо реализации проекта. Все прикольные штуки реализуются очень быстро, и остаётся очень много рутины, которую тем не менее надо сделать, и наша задача сбалансировать прикольность и рутину так, чтобы всё-таки закончить.
Где искать художников/музыкантов/дизайнеров? Для начала, можно сделать Почти Законченный Проект, без графики и звуков, с накарябанными в msPaint спрайтами и такими же корявыми анимациями и трах-бахами из свободных ресурсов, найденных в сети. Очень не рекомендую нагружать других людей чем-то, что ещё не закончено и имеет высокие шансы остаться незаконченным.
Я вообще-то собирал (ся/ась) устраиваться в Valve, EpicGames или куда бы то ни было ещё, и работать там, зачем мне всё это? Большая часть программистов в мире — самоучки, зачастую с обширным «подвальным» опытом, более того, прототипы и небольшие игрушки являются отличным портфолио для устройства в крупные компании, причём не только на должность разработчика игр.
Бонус: Большая часть данных методик подходит к совершенно любой области, не только программирование игр, но и просто программирование. Более того, можно получить художественное образование или научиться фигурной резьбе, пользуясь этими же инструкциями после небольших правок в нужную сторону.
Спасибо за прочтение, статья подвержена критике и дополнениям.
