С чего начать разработчику игр
Как стать разработчиком игр имея за пазухой только здравый смысл?
Вступление
Давно мечтаешь создать игру? Чтобы любой человек планеты смог без проблем ее найти на пространствах интернета и сыграть? Но у тебя нету ни средств для того чтоб оплатить должную учебу или мотивации чтоб поднять свой «ленивый зад» и начать кодить? Или ты просто сантехник, которому надоело каждый день сидеть за унитазом соседей и хочешь попробовать что-то новое в жизни? Ты, естественно, без проблем можешь начать разрабатывать игры. Только тебе нужно определиться с одним вопросом. А реально нужно тебе это? Если да, то какой толк ты хочешь вынести из всего этого?
Чтоб заработать кучу денег и прославиться?
Чтоб утереть нос другу, который не первый день хвалится что он крутой разработчик во всем мире?
Или просто так, для души, потому что ты еще тот геймер и у тебя есть довольно неплохая идея для разработки игры, которая будет не хуже, чем те, которые находятся в топе любого магазина.
Если так, то завари чашку кофе и погнали разберем несколько пунктов которые могут помочь тебе стать на путь разработчика игр ну или просто забавно провести время и отвлечься от дневной суеты.
Начальная разработка. Ожидание-реальность
Будь готов к тому, что на начальных этапах у тебя мало что будет получаться. И попытки создать Хагрида из Гарри Поттера
Рис.1. Ожидаемый результат
могут превратится в анекдот. Хорошо если у тебя получится что-то такое:
Рис.2. Хороший результат
Но если в итоге выйдет что-то такое:
Рис.3. Ржачный результат
То я уверен, что после того как сравнишь с оригиналом, то ржач будет стоять целый день.
Ну а вообще самое главное на начальном этапе это хоть какой-то результат. Как говорится «отрицательный результат, тоже результат». Ведь потом эти свои наработки будешь улучшать и со временем выйдет что-то годное. Не бойся экспериментировать и создавать что-то свое. Пусть на первый взгляд это будет устрашающе выглядеть. Ведь знаменитые компании не с первого раза стали знаменитыми. Все начиналось с мелочи. И, возможно, у кого-то первые наработки были созданы на коленке в гараже у соседа. Кто знает, может и твой начальный ужастик со временем наберет популярность и вырвется в топ лучших.
Что лучше? 2д или 3д на начальном этапе?
Многие начинающие разработчики могут сказать, что 2д проще. Тем что это 2д. Ну согласиться я не могу. Лучше то, что нравится. Нравится 3д? делай в 3д. Нравится 2д? Делай в 2д. Ведь разница тут только в координатной плоскости. А суть та же самая. Ведь что в 2д что в 3д тебе придется двигать персонажа. Что там, что там обрабатывать триггеры. Что там, что там писать ИИ (искусственный интеллект) для врага. То, что имеет меньшую размерность не значит, что проще. Как говорит знаменитая пословица: «Главное не размер, а умение пользоваться». Так что главное не размерность координатной плоскости, а то как ты умеешь с ней обращаться. Везде есть свои плюсы и минусы. Если рассматривать на уровне графики, то в 2д тебе нужно нарисовать спрайт и потом секвенцию кадров для анимации, ну а в 3д, нужно смастерить 3д модель и анимировать с помощью костевой анимации (если живое существо) или достаточно просто создать шар и используя ключи анимации просто двигать его, вращать, масштабировать и т.д. Но если нет художественного вкуса, то может получится что-то консервное (вспомним Хагрида). Так что, если говорить уж про размерность, то каждый выбирает по вкусу. Тот, кто хорошо владеет 3д пространством, тот с легкостью может перейти на 2д, а тот, кто хорошо владеет 2д, то тому нужно представить еще одну ось и адаптироваться.
Стоит ли платить за обучение?
Этот вопрос для каждого индивидуален и зависит от каждого. Можно и без преподавателей обучиться, но это будет долгий процесс поиска нужной информации в гугле. Можно вступить в разные группы единомышленников, но не надейся, что с тобой там нянчиться будут. Могут помочь советом, а могут и послать нафиг за наглость. Помочь могут с каким-то определенным алгоритмом и направить на ресурс, который может ты и читал, но не внимательно. Но не надейся что там будут объяснять «как создать переменную» и «зачем ставить ‘;’ в конце строки» в С-подобных языках программирования. Такие вещи могут рассказать преподаватели в учебных заведениях, или те, которым ты будешь платить деньги на курсах. Я не призываю категорически отказываться от платных курсов. Так как там собрано большинства материала, который ты бы сам годами собирал на пространствах гугла (ну если ты конечно не красноглазый задрот, который днями и ночами сидит за компом и даже не выходит на улицу, потому что дневной свет слепит глаза). Есть курсы, которые предлагают первое бесплатное занятие. На нем ты конечно и не узнаешь весь ожидаемый материал, но зато оценишь преподавателя, его манеру общения и сможешь решить стоит ли тебе платить за курс обучения с ним или, как обычно говорят на рынках «я посмотрю еще и тогда вернусь».
Unity vs Unreal Engine (UE)
Как ты уже догадался речь пойдет о игровых движках. Какой лучше выбрать? Ответ дам простой – какой понравится. Ведь в этом то я тебя ограничивать не буду. Есть много игровых движков, как профессиональных, так и простых. Но Unity и UE считаются самыми популярными. Но ты можешь посмотреть и множество других, таких как CryEngine, Godot, Creation Engine или какой-то конструктор по типу Construct, или вообще можешь написать свой и ни от кого не зависеть.
Плюсов от своего движка много, но главный и единственный минус это разработка. Нужно знать много чего о графике, нагрузке на систему и прочее чтоб не просто сделать «какое-то дерьмо», а действительно подходящий движок, который можно использовать еще много лет и усовершенствовать. Или можно выбрать из уже готовых и не утруждать себя, и не брать лишние проблемы на свою голову. Можешь попробовать один или оба (чтоб сравнить какой ближе по душе) этих игровых движков. Могу сказать вкратце:
Unity – может справиться даже из слабыми ПК, ну конечно не из самыми древними мумиями, но 4 гб оперативы и 1 гб видеокарты потянет. Не для масштабного ААА проекта, а для какой-то простенькой игрушки вполне сойдет.
Конечно программировать будешь на C#, так как JavaScript был выпилен из движка. Ну а если ты жестокий фанат JS, то можешь скачать раннюю версию и наслаждаться разработкой. Также можешь использовать внешние плагины чтоб программировать например на Python.
А вообще на этом движке можешь создавать хоть ААА проекты, хоть обычные 2D платформеры для различных устройств (хоть для Android, PC, IOS, tvOS (только представь, твой чудик, который создашь, будет бегать по всех теликах планеты)) так как он считается кроссплатформенным. Только набей свой комп хорошей начинкой и в «бой за орденами».
Unreal Engine – как минимум 8 гб оперативы точно нужно. Так как это мощный игровой движок и Unity уступать ничем не собирается. Тут без проблем создавай что хочешь, хоть ААА, хоть 2D, хоть 2D с элементами ААА. Только одень свой ПК пристойно, чтоб он не залагал только при нажатии на сам ярлык. А так этот движок тоже кроссплатформенный, как и Unity. Правда язык программирования тут С++ и BluePrint (визуальный скриптинг для тех кто не шарит в программировании). Все что душе угодно. Разработчики так устроили это логово чтоб заманить всех кто шарит и тех кто не шарит в программировании. Все что вашей душе угодно лишь бы вы хоть что-то делали.
А так эти два мирных существа (о движках идет речь) еще имеют свои магазины ресурсов где ты можешь скачать различные модели, скрипты, текстуры вплоть даже до кусков сцен или игр, которые можешь переделать под себя и наслаждаться разработкой.
Сможет ли сантехник с нулевыми знаниями стать геймдев разработчиком?
Бессрочный ответ – да. Разработчиком может стать кто угодно. Хоть даже повар, который не умеет готовить. Может просто готовка это не его, а где-то в глубине души он прирожденный игродел.
А если работа не приносит удовольствия, то это каторга. Особенно если эта каторга за копейки. Многие, кто работают на нелюбимой работе просто говорят, что они ничего не умеют и это единственный их доход, а на лучшую работу нужно лучшие навыки. ТАК БЛИН ЧТО ЖЕ МЕШАЕТ ТЕБЕ ИХ ПРИОБРЕСТИ? Ты можешь временно работать на этой работе для того чтоб получать з/п и с голоду не откинуться, а в свободное время можешь приобретать навыки в любимом занятии.
Только не делай хобби работой, так как работа может угробить это хобби и в свободное время сложно будет чем-то заняться если хобби было одно, и то которое напоминает о работе. Как говорят «работа должна быть любимым занятием, а не каторгой», так как в такой ситуации поступить? Просто. Нужно иметь больше чем 1 хобби. Одно можно превратить в работу, а следующие как отдых. И работа увлекательная и в свободное время есть чем заняться и отвлечься.
Выводы
В итоге стало понятнее, чтобы стать разработчиком не обязательно нанимать дорогих преподавателей чтоб оттачивать свои навыки. Можно это сделать самому. Да – это долго. Да – это сложно. Но зато результат на лицо будет и денег сэкономишь и навыки приобретешь.
Но также, эти навыки можно приобрести и немного быстрее наняв преподавателя. Если знания нулевые, то сойдет любой преподаватель. Так как в таком случае он шарит больше чем ты. А если бюджет позволяет, то лучше нанять качественного. А, также, нужно иметь желание, тонны пачек нервов, самоорганизованность и конечно стремление и любовь к играм. Так как без этих параметров навряд ли ты сможешь продвинуться если будешь опускать руки после каждой неудачи. Илон Маск тоже не с первой попытки стал успешным. Так что работай над собой, выбери свою дорогу, цель и следуй ей. И помни что эта дорога будет подобна различным раннерам, то есть на этом пути обязательно будут вещи или люди, которые будут стараться сбить тебя с пути и не дойти к цели. А если потерпишь неудачу и сдашься, то свернешь с пути раньше, чем узнаешь какой приз ждет тебя в конце этого пути. И каждый навык расценивай как чекпоинт в играх, приобретая который, ты сохраняешь свой прогресс на пути и после неудачи можешь воскреснуть с этой точки сохранения. Все в твоих руках! Главное верь в это, и ты добьешься своего успеха!
Как начать разрабатывать игры даже если до этого вы были бухгалтером
До того как я стал разработчиком игр, я (да и все в моем окружении) считал себя дизайнером сайтов.
Не плохим, кстати, но дизайнером сайтов. Профессия, которая почти никак не используется в разработке игр. 
Есть такой стереотип — когда кто-то говорит, что он в разрабытавает игры без команды, все сразу представляют его программистом. На самом деле, стереотип не так далек от правды: скорее всего, разработчик, описанный выше, действительно умеет программировать, но программистом он может себя не считать.
После одного игрового проекта со стримом всего процесса разработки мне часто пишут начинающие разработчики, что-то спрашивают, что-то показывают и на что-то жалуются. Недавно мне пришлось влезть в спор двух ребят, где темой спора было: “Что круче знать 3д-моделирование или программирование, если собираешься разрабатывать игры?”. Влез к ним в спор с предложением сделать первый шаг из схемы, что родилась в процессе участия в игровых проектах и создания своих.
Шаг 0. Станьте разработчиком игр
Именно первый, а точнее даже “нулевой”, шаг сделает Вас сразу разработчиками игр. Это не проекты, которые, может, уже есть у Вас за плечами, не навыки, котороми Вы, может, владеете, а простой, но очень важный шаг: скажите себе, а заодно и всему миру, что вы разработчик игр. Как только у вас уляжется в голове ответ на вопрос, чем вы занимаетесь — разработкой игр, — вы сразу станете для себя и окружающих разработчиком игр.
Как это сказать себе и другим?
Все, вы разработчик игр. Действительно, элементарный шаг вам может дать доступ к столь “закрытой” профессии как разработчик игр. Правда, без опыта и регалий, но никто (ни вы, ни окружающие) уже не оспорит, что вы разработчик игр.
Шаг 1. Найдите себе применение как разработчику игр
Теперь, когда Вы смело можете считать себя разработчиком игр, надо найти себе применение. Как писатели могут пребывавать в двух состояниях: ищут идею книги, пишут книгу, — так и разработчики: ищут проект (идею), делают проект. Бывает, конечно, еще и поддерживают проект, но лично я его всегда объединяю с процессом поиска нового.
и множество других способов.
Выйти из состояния “поиска проекта” нужно как можно быстрее, и желательно выйти в состояние “делаю проект” и делать проект с шансами на успех: релиз и популярность.
Этот этап — первая проверка для начинающего разработчика. Сделать выбор при полном отстутствии опыта очень сложно, но, к счастью, любой выбор принесет нам опыт.
Например, я сделал маме подарок на НГ — 3д-игру по психологической методике:
У меня не было опыта разработки на C# и программировать я особо не умел (немного знал python) и никогда до этого не моделил.
Шаг 2. Помогите себе закончить хотя бы ОДИН проект!
Если вы закончили свой первый проект как разработчик игр, скорее всего, вы что-то делали не так. Даже эпилептоид не сможет закончить свой первый проект, а к первому релизу у него в архиве будет пара-тройка (минимум) замороженных проектов. Это нормально. Мы учимся на своих ошибках, а не совершают их только идиоты или те, кто ничего не делают.
Но в какой-то момент нужно будет собрать весь свой опыт, полученный из проб и ошибок, и, наконец, сделать свой первый релиз.
У каждого разработчика своя история первого релиза, но у меня есть пару советов, которые обязательно вам помогут:
Например, в своем первом 48 часовом марафоне (на нем я только рисовал), я за первую треть времени нашел стиль игры, нарисовал основной, игровой экран и все спрайты врагов. И за оставшееся время сделал 170+ спрайтов анимации и дорисовал интерфейс.
Шаг 3. Сделать полноценный релиз
Когда прошлые шаги позади: релиз за плечами и опыт какой-то уже есть, — хочется, чтобы ваше хобби (не приносящий доход род занятий) переросло в настоящую профессию и источник хорошего, постоянного дохода. Каждый разработчик понимает, что для этого ему нужен полноценный релиз, не тот (те), что мы получили из второго шага, а полноценный релиз с шансом на успех. Увы, но релиз из прошлого шага нужен только для ощушения победы, а не успеха.
Инструкция начинающего разработчика игр
В данной инструкции я попытался осветить основные моменты разработки игр. Инструкция будет полезна для людей, собирающихся заняться разработкой игр в роли лидера (главного разработчика и организатора).
Хочу отметить, что игры бывают разные – большие и маленькие, сложные и лёгкие, и поэтому для каждой игры эта инструкция верна в какой-то своей определённой степени. Охватить всё не удалось, но передать общие моменты, думаю, получилось.
И так Вы решили сделать свою игру, о чём Вам нужно подумать…
Думаем – нужно ли это тебе
Перед тем, как за что-то взяться, необходимо всё обдумать. А перед тем, как заняться разработкой игр, необходимо обдумать всё очень хорошо. Очень часто начинающие разработчики, достигнув определённых успехов в чём-то (сделал мод для игры, небольшой фан-сайт и пр.), начинают грезить созданием своей игры. Это происходит из-за того, что они имеют слабое представление о процессе разработки игр.
Я перечислю основные ошибки в их представлении:
Концепция и ТЗ
Когда-то давно я написал довольно неплохую статью о концепции проекта. За последние пару лет мои взгляды слегка поменялись, но суть осталась та же.
Контент
Я специально выделил этот раздел, так как он является решающим в процессе разработки игр. Под контентом понимается всё содержимое игры, с которым взаимодействует пользователь. Это графика (растровая, векторная, 3D), музыкальное и звуковое сопровождение, видеоряд, сценарий и текст. Также сюда следует добавить медиаматериалы, используемые для продвижения игры (реклама, банеры и прочие).
В английском языке есть такое понятие как «artist» обозначающие сразу художников, музыкантов, режиссёров, писателей и прочих творцов. К сожалению, в русском языке нет нормального аналога этого слова, поэтому я дальше буду использовать понятие «создатель контента».
Разберём основные моменты этого раздела.
Программирование
Как ни странно, создание программного кода для игр не является самой сложной задачей, но в тоже время и не является простой.
Тестирование
О тестировании начинающие разработчики обычно не задумываются, а зря, так как на него тратиться немногим меньше времени, чем на написание программной части. В этом разделе есть два важных момента:
Организационные моменты
Послесловие
Инструкция получилась большой, материала много. Крайне советую прочесть её начинающим разработчикам игр, так как, возможно, она поможет им избежать ошибок в будущем.
UPD: Статья получилась успешной, даже очень. Но в комментариях прослеживаются замечания по поводу отсуствия романтики и отвращения к играм. Поэтому я прокомментирую эти моменты.
Многие опускают тот факт, что статья для начинающих разработчиков игр, претендующих на роль лидера (первый абзац статьи). Не буду отрицать, что со временем, когда приобретаешь опыт разработки игр и жизнь складывается удачно, возвращается романтика и отвращение спадает. Но в самом начале, когда начинаешь с нуля, после того как столкнёшься с первыми серьёзными проблемами, эта романтика и любовь к играм исчезает ко всем чертям. Разработка игр — это не прогулка по ковровой дорожке в розывых очках, а блуждание в лабиринте Минотавра, где много тупиков.
Я не собираюсь своей статьёй вселять в начинающих разработчиков уверенность. Они должны знать, что путь разработчика игр сложен, что они могут встретить нерешаемые проблемы, что их нерализованный проект будет для них символом поражения.
Памятка начинающему разработчику компьютерных игр
Данная статья ориентирована на школьников, студентов, и тех, кто постарше, кто никогда не пробовал, но очень хочет начать писать компьютерные игры. Кто в детстве не играл в компьютерные игры, и не хотел написать свою игру, которая будет лучше, чем 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. Заключение.
Осталось ещё много неосвещённых вопросов, на некоторые из них будет кратко отвечено тут.
Что такое дизайнерский документ и для чего он нужен? Это такая вики по ещё не созданной игре, чем полнее, тем лучше. И эту штуку стоит сделать ещё до начала игры, примерно прикинув время разработки имеющимся количеством людей и отсекая фичи.
Зачем отсекать фичи? Проходя предыдущие этапы, можно приблизительно прикинуть время, за которое тебе и твоей команде надоест заниматься этим проектом. Если мы в ситуации подвальной инди-разработки без финансирования и расписания работ, есть очень высокие шансы появления разброда и шатания вместо реализации проекта. Все прикольные штуки реализуются очень быстро, и остаётся очень много рутины, которую тем не менее надо сделать, и наша задача сбалансировать прикольность и рутину так, чтобы всё-таки закончить.
Я вообще-то собирал(ся/ась) устраиваться в Valve, EpicGames или куда бы то ни было ещё, и работать там, зачем мне всё это? Большая часть программистов в мире — самоучки, зачастую с обширным «подвальным» опытом, более того, прототипы и небольшие игрушки являются отличным портфолио для устройства в крупные компании, причём не только на должность разработчика игр.
Бонус: Большая часть данных методик подходит к совершенно любой области, не только программирование игр, но и просто программирование. Более того, можно получить художественное образование или научиться фигурной резьбе, пользуясь этими же инструкциями после небольших правок в нужную сторону.
Спасибо за прочтение, статья подвержена критике и дополнениям.