Ударившись в разработку мы забыли про обновления. А так то Мы скоро выпускаем демо игры!
Идут проверки на разных интернет площадках.
Дед - это не возраст и даже не семейное положение, подразумевающее наличие внуков. Дед - это состояние души, в котором ты делишься мудростью, даже если тебя об этом не просили. Вот и я решил запилить очередную простыню на тему разработки инди-игор.
Типичные ошибки новичка-разработчика я уже разбирал. Возникает справедливый вопрос: окей, как не надо делать - понятно… а как надо? Где та самая инструкция, в которой по шагам описано, как выпустить мега-хит? Так вот же она!
Если серьёзно, то ни у кого такой инструкции по очевидным причинам нет. Однако никто не мешает мне собрать небольшое руководство для повышения шансов сделать хоть что-то - и постараться, чтобы получилось хорошо!
Эта статья будет полезна в первую очередь тем, кто очень хочет делать игры, но не знает, с чего начать. Опытные разрабы давно выработали свой подход, но, возможно, они тоже найдут здесь что-то интересное.
Всё описанное ниже ни в коем случае не является истиной в последней инстанции или универсальной методологией. Это просто выжимка из моего опыта и наблюдений, приправленный примерами из Princess Hunter. Следовать ей или нет каждый решает сам :)
Создание игры можно условно разделить на три больших стадии:
Каждая стадия состоит из этапов. В этой статье я расскажу про Подготовку.
Коммерческая разработка начинается с исследования рынка, определения ниши, рентабельности затеи и попытки угадать тренды на основе текущих тенденций. Это обстоятельный метод для минимизации рисков тех, кто, в первую очередь, хочет заработать денег.
Инди-игра рождается из идеи. Не важно, идея это механики, сэттинга, сюжета или чего-то на стыке - главное то, что она пришла вам в голову и теперь не даёт покоя. А реализовать вы её хотите именно в виде игры.
Это может быть задумка для абстрактной головоломки (Baba is you), дикий мешап вселенных (Wizard with the Gun), посылка вроде “смесь милоты и оккультизма” (Cult of the Lamb) или даже удачный набросок главного героя, из которого вырастет целая вселенная (Hollow Knight). А может быть просто навязчивое желание сделать “свой ответ Civilization” или “классные гонки на асфальтоукладчиках”.
Как я уже писал в прошлой статье, сами по себе идеи (без реализации) не особенно ценны. Однако без них все прочие шаги просто не будут иметь смысла.
The Elder Scrolls III: Morrowind
У большинства разработчиков с идеями, как правило, проблем нет: ещё до завтрака они на-гора выдают десяток концептов разной степени адекватности.
Другие могут запнуться уже на этом этапе: креативный зуд есть, а вместо мыслей, что бы такое сделать - пустота. Прозвучит банально, но вдохновение можно найти… везде. На идею для игры вас может подтолкнуть фильм, книга, поездка на дачу, строчка из песни, переезд, попытка собрать полку из Икеи. Не торопитесь хвататься за первую попавшуюся мысль: если вы сами не уверены, что хотите поиграть в будущую игру, не стоит её делать. Важно - эта установка справедлива только для стадии Подготовки. В следующих стадиях, если вы до них дойдёте, вы успеете свою игру возненавидеть!
Если же абсолютный творческий ступор полностью блокирует фантазию, а не делать игры вы физически не можете (я знаю и такие случаи), то можно воспользоваться следующим способом. Возьмите несколько игральных костей и присвойте каждой грани какую-то механику, сюжетный троп или сэттинг. Например:
1 - РПГ
2 - Аркада
3 - Гонки
…
1 - Про вампиров
2 - С остановкой времени
…
Кубиков, граней на них и бросков может быть любое количество, тематика - на ваше усмотрение: жанры, герои, произведения, временные периоды. Делайте броски до тех пор, пока получившееся сочетание не заставит в голове щёлкнуть: “Ага!”
Обычно озарение приходит в момент, когда маховики фантазии начинают раскручиваться и дополнять получившийся набор рандомных вводных деталями: “Гонки в темноте, постапок… А что, если настал буквально КОНЕЦ СВЕТА и мир погрузился в вечную тьму? Гонки… игроки ездят по мёртвому миру между освещенными городами и видят только небольшой кусочек пространства, которое выхватывают из мрака фары его багги… О, можно будет апгрейдить машину не только на скорость, но ещё и обвешивая фонариками… А почему гонки? Может, во тьме за этими машинками охотятся монстры? Нет, ещё круче: в темноте чем медленнее ты двигаешься, тем быстрее течёт время, и если не жать на педаль, то машина будет ветшать на глазах, а водитель умрёт от старости!”
С этим уже можно работать!
--
[Дополнение]: Уже после написания статьи мне подсказали, что есть цифровые варианты генераторов идей:
Менее лампово, но удобней!--
Идея игры Princess Hunter родилась сразу из нескольких, последовательно пришедших предпосылок:
- (Что?) Вдохновленный Helltaker гаремник, но с монстродевочками, а не демонессами;
- (Как?) Классная боевка из Guild of dungeoneering, но не в виде рогалика, а сюжетное приключение;
- (Где?)Тёмная Башня Кинга + Сказ о Федоте-Стрельце Филатова в духе Adventure Time;
- (А ещё…) Дружба и романс персонажей, как в Hades, но с нелинейными диалогами классических CRPG.
От какой бы посылки мы ни отталкивались, теперь нам стоит проработать её чуть подробнее: сформулировать базовые правила, вычленить кор-геймплей или описать так называемые столпы геймплея - самые-самые жизненно необходимые механики.
Существует две одинаково опасные крайности на этом этапе:
Написать слишком мало. Например, описанный выше ход мыслей о гонках в темноте - хорошая почва для концепта, но всё ещё не концепт.
Написать слишком много: уходить в частности, отвлекаться на мета-геймплей, придумывать диалоги и названия апгрейдов.
Задача концепта - лаконично, но понятно сформулировать содержание основных игровых механик. То есть ответить на вопрос "Как в это играть?".
Игра целиком и полностью вертится вокруг сюжета, а геймплейно является полным клоном другой игры? Опишите синопсис истории - без лишних подробностей, но по всем основных вехам. Даже если вы делаете классический текстовый квест или кинетическую новеллу, всё равно не поленитесь уделить пару абзацев тому, как именно игрок будет играть в это.
У одного проекта может быть сразу несколько параллельных концептов, отличающихся деталями или фундаментально. Например, те самые гонки в темноте можно расписать как трёхмерную игру с видом от третьего лица, а можно и как топ-даун 2д аркаду в духе Вангеров. Эти концепты пригодятся нам на следующем этапе.
Ещё один важный момент - не гнушайтесь использовать референсы, изучать и декомпозировать вдохновляющие вас игры. Чтобы сделать отличную игру не обязательно производить революцию в жанре или создавать новый. Эрик Барон, создатель Stardew Valley просто делал “что-то типа Harvest Moon”.
Продумывая концепт Princess Hunter, я сразу определил, что игра будет состоять из трёх столпов:
- Перемещение по уровням (в том или ином виде) - здесь было больше вопросов, чем ответов. Про варианты, которые мы перебрали, расскажу ниже.
- Карточная боевка. Костяк команды уже имел опыт в ККИ, к тому же я искренне люблю колодостроение. Поэтому мы смогли использовать и экспертизу, и кое-какие наработки.
- Диалоги. У меня противоречивое отношение к Визуальным Новеллам. С одной стороны, они нравятся мне с точки зрения интерфейса - ростовой спрайт персонажа, смена эмоций и относительно короткие реплики классно выглядят и легко читаются. Но прокликивать километры текста до того, как тебе предложат выбор (нередко уровня “Привет” и “Здравствуйте”) всегда вызывало тоску и уныние. Поэтому я решил совместить красивую обёртку ВН и мощную вариативную начинку в духе Fallout 1-2, где Choices, как говорится, действительно Matters.
Отлично, у нас есть Идея и Концепт нашей будущей игры! Вижу цель - не вижу препятствий, начинает полноценную разработку… или нет?
Именно на этом этапе большинство начинающих разработчиков идёт совершенно не туда. Им кажется, что они уже кристально ясно видят игру, нужно лишь дословно переместить её из головы в реальность.
Жестокая правда заключается в том, что даже самая расчудесная идея на практике с ненулевой вероятностью окажется совершенно неиграбельным шлаком… или неподъёмной глыбой. Отлично играющаяся в уме игра может получиться в итоге скучной, глупой или просто раздражающей.
Поэтому перед тем, как начать полноценную разработку, очень важно провести прототипирование. Сделать грубые наброски будущей игры - без графики, буквально “на кубиках” (или бесплатных ассетах), из самых базовых, скелетных фич.
Если механика позволяет - имитируйте её на бумаге; нет - реализуйте в движке. Используйте костыли, изобретайте велосипеды, игнорируйте слово “архитектура”, смейтесь в лицо тем, кто заикнётся о масштабировании или оптимизации. 99% написанного на этом этапе кода всё равно пойдёт в мусорку. Единственная важная задача сейчас - за минимальное количество времени нащупать интересный игровой процесс, перепробовав максимальное число вариантов.
Главные правила Поиска:
- Делайте максимально быстро, реализуйте только самые необходимые для игры вещи. Нет, 28 видов машинок с разными характеристиками это не самая необходимая вещь. Даже одна моделька машинки сейчас не важна, сойдёт и летающая коробочка.
- Не зацикливайтесь на тупиковом варианте. Чувствуете, что не получается малой кровью сделать игровой процесс интересным в две-три итерации? Начинайте заново, ищите другой концепт или пересматривайте текущий. Если игра про фехтование уныла с мечом, добавления копья и лука скорее всего ситуацию не исправит.
- Не копируйте бездумно. Референсы важны, но они не эталон для слепого подражания. Конкретная механика может отлично работать в другом проекте, а в вашем - быть не к месту, всё сломать… или требовать слишком большого количества ресурсов на реализацию. Постоянно анализируйте вдохновляющие вас игры. К слову, это касается и сюжетов!
- Экспериментируйте. Даже если вы чудесным образом с первого раза собрали что-то прикольное (вероятность этого мала, но не нулевая) - не поленитесь сделать ещё 2-3 варианта, варьируя правила. В худшем случае это просто убедит в правильности пути, в лучшем - позволит найти что-то лучше или даст задел на новые игры.
- Не бойтесь выбрасывать прототипы в мусорную корзину. Всё израсходованное сейчас время вы с лихвой компенсируете потом.
Прототипирование повсеместно используется в "большом" геймдеве, потому что позволяет сократить траты. Согласитесь, очень больно потратить год-два на разработку игры, создание арта, кода… и на финальном этапе понять, что она абсолютно никакая с точки зрения игрового процесса. При том проблемы не в балансе, а носят фундаментальный характер.
Это случается сплошь и рядом даже в попытках дословно повторить какой-то проект - не учли всех нюансов, переоценили свои скиллы… Формально легендарная
обладает всеми характерными признаками файтинга, но вот реализация слегка подкачала.Детали процесса поиска зависят от жанра и проекта. Так, например, если вы делаете классический 2d-квест, с упором на историю и атмосферу, вам нет смысла экспериментировать с геймплеем (лучше вообще взять движок, заточенный под это из коробки - например, AGS), но стоит поискать арт-стиль и собрать играбельную локацию.
В Princess Hunter мы отдельно и разными подходами протипировали Исследование и Боёвку.
Карточные сражения с простенькой механикой без проблем можно было собрать и потестить “на столе”. Я взял пакетики-протекторы, засунул в них карты старой отечественной ККИ “Берсерк” (это нужно для стандартизации рубашек и нужной “плотности”, чтобы колоду можно было легко тасовать) - а поверх них поместил свои, самодельные карты без иллюстраций, с рабочими названиями и свойствами. Здоровье игрока и противников отмечал монетками. В таком виде я не только протестировал игру, но даже попробовать несколько первых итераций баланса.
Эта фотография с другого проекта, Echo of Combats, но смысл тот же самый.
После этого мы быстро собрали самый примитивный компьютерный билд на черновой графике. К счастью, выбранная нами система не требовала сложного ИИ.
На квадратно-тайловую систему меня натолкнул пост со стадиками реакторчанина Stanivuk.
Но попробовав разные варианты, мы поняли, что они плохо вяжутся с остальной игрой. Трёхмерные (при отсутствии моделлера) к тому же дороги в разработке.
В процессе поисков мы даже собрали диабло-подобный вариант со свободным перемещением по уровню, но он вообще не сочетается с пошаговой боевкой.
В конечном счёте мы пришли к концепции уровней, состоящих из тропинок и полянок. Чем-то напоминает Slay The Spire, но в Princess Hunter игрок может возвращаться на ранее посещенные полянки, повторно взаимодействовать с объектами и персонажами, перемещаться между локациями.
...до черновой графики.
В принципе, на этом этап прототипирования можно было бы закончить, но нам была важна не только сама механика исследования, но и визуализация, импакт. Поэтому мы решили сразу более глубоко проработать исследование не только с технической, но и со стилистической точки зрения.
Этот скетч зактронул какие-то срунки в наших сердцах!
Перепробовав уйму вариантов, мы, в конечном счёте пришли к 2.5d: трёхмерная сцена, на которой расположены спрайты объектов и персонажей. Эмпирическим путём нащупали угол и настройки камеры, и, в конце концов, добились классного эффекта объёма и глубины.
Анимация перемещения появилась значительно позже, но в остальном билд выглядел именно так.
Собрав начерно первый уровень, мы поняли: это оно! Вот в этом нам хочется поиграть!
Конечно, этот билд уже совсем не “на кубиках”, и по-хорошему это можно выделить в отдельный этап. Но излишний формализм вредит не меньше полного раздолбайства. Помните: вы сами определяете приоритетность каждого шага. Для некоторых проектов стоит начать именно с поиска стиля. Другие начинаются с музыки и настроения. Любая игра требует индивидуального подхода.
На этом заканчивается Подготовка. Про Разработку и Релиз я расскажу в следующей части. Как всегда, самое вкусное - напоследок.
Спасибо всем, кто смог осилить этот пост. Надеюсь, было интересно.
Я пришел к вам в час великой нужды, пидоры-кодеры и пидоры-геймдэвы. С недавних пор мною одолело желание разработать хентайную игру, но не эту вашу визуальную новеллу, а полноценный 3D симулятор менеджера гладиаторов со стилизованными рабынями/рабами и всякой БДСМщиной. Я сам занимаюсь 3D/2D и от кода далёк, да и с геймдевом знаком лишь как продвинутый потребитель, иногда делавший простейшие моды и ковырявший редакторы Warcraft 3 и героев, поэтому иллюзий не питаю и воспринимаю проект исключительно как развлечение в свободное время, но пока что, на удивление, получается и даже интересно/весело. Но кое-что меня угнетает и решение привычными способами не гуглится.
Дело в том, что несмотря на использование универсального рига (скелета) пропорции тел у персонажей разные. Это приводит к досадным багам при синхронизации анимаций двух персонажей, скажем, при удушении, персонаж душит воздух в паре-тройке сантиметров вокруг шеи врага или наоборот утопает пальцами в его шее. В дальнейшем, вангую, те же проблемы возникнут при большинстве сексуальных взаимодействий. Выглядит крайне всрато и ломает погружение. Попросту скорректировать анимации под каждую пару персонажей и подгружать нужные - не вариант, так как предполагается что большая часть гладиаторов будут кастомными, созданными за счет 3D морфов в редакторе персонажей, а также процедурно сгенерированными на основе рандомных значений в том же редакторе. Т.е. с уверенностью сказать какими будут длинна рук, толщина шеи, размер сисек персонажа и так далее невозможно.
Я попытался подсмотреть какие решения используют сенпаи из Иллюжена, также использующие синхронизацию анимаций персонажей, а также морфы для тел, в результате обнаружил что... Никакие. Они эту проблему игнорируют, в результате чего персонаж в ряде случаев своей "головой кобры" пробивает животы особо худых или мелких партнерш или утопает по основание кисти в бидонах милф. Пакетик, хочу сделать лучше.
Но я не знаю как это воплотить в жизнь и возможно ли это.
Пока вижу два возможных решения:
1. Инверсная кинематика с дополнительными костями у рига, если её возможно настроить таким образом, чтобы учитывались скелеты других персонажей.
2. Модификация стандартных анимаций с учетом размера отдельных частей тела противника. Создание эдаких морфов для 3D анимаций, если это возможно. То есть, например, имеется минимальная толщина шеи, обозначенная как 0, максимальная, обозначенная как 1, есть всё что между, обозначаемое как 0.Х. На основе этого числа игра определяет на каком расстоянии пальцы/руки должны быть от шеи и корректирует их положение при использовании стандартной анимации, сдвигая каждую кость по осям X/Y/Z.
Возможно ли воплотить это в жизнь и как? Если нет или моё решение слишком тупое/нубское/трудоёмкое, в какую сторону гуглить и чьи маны или туторы читать/смотреть? Есть ли платные/бесплатные плагины для реализации нужного мне?
С меня нихуя, ибо если когда-нибудь будет альфа-версия поделия, её и так сюда выложу.
Если это важно: Анимации делаю в Cascadeur, с допиливанием в Blender, саму игру делаю в Unreal Engine 5.2.
Привет! Пришло время продолжить историю о моем пути в геймдев.
Сразу сделаю уточнение, что этот текст является продолжением прошлой статьи, и тем, кто хочет полноценно погрузиться, рекомендую сначала прочитать предыдущий лонг. Для тех, у кого нет такого желания, максимально краткий пересказ: меня зовут Дима, сейчас мне 31, с детства мечтал разрабатывать игры. Закончил школу, бездельничал пару лет, в 20 благодаря своей женщине полюбил программу 3ds Max и в итоге стал архитектурным визуализатором. Несмотря на хороший заработок, настолько нагрузил себя работой, что превратил некогда любое занятие в завод, выгорел дотла и просто стал люто ненавидеть свое ремесло. Однако, в страхе стать бомжом, продолжал покорно брать заказы, и так все было до 24 февраля 2022 года, когда в одно мгновение изменилась моя жизнь и все ценности. Поблагодарив 3D за все и обняв напоследок, я начал свою дорогу в геймдев. Продолжим.
Не имея никаких идей для будущей игры, я понимал, что главное — начать обучение, а со всем остальным буду разбираться по ходу дела. Для поиска нужных уроков, первое с чем нужно определиться — это игровой движок. Выделив два лидера на сегодняшний день — Unreal Engine и Unity, мой окончательный выбор пал на Unreal, так как он больше заточен под 3D (в котором у меня большой опыт) + у нас уже было небольшое знакомство — я переносил несколько своих архитектурных 3D проектов в интерактивные сцены на UE4.
Еще был очень весомый аргумент — визуальное программирование. Кто не знает, на Unreal Engine можно сделать игру любой сложности, не напечатав ни одной строчки кода. За это отвечает нодовая система визуального программирования Blueprints (далее блупринты) и вместо того, чтобы писать руками код для передвижения героя из точки А в точку Б, ты просто ставишь ноду движения и вписываешь координаты, откуда и куда нужно добраться персонажу. Да, их тоже нужно уметь грамотно применять, но это всяко лучше, чем куча непонятных букв и цифр на экране. Смотря на код своих друзей программистов, у меня всегда было отторжение, будто меня заставляют читать египетские письмена. Так что блупринты были спасением.
Скачав целую кучу уроков и UE5 Beta, я начал изучать как от кружка, нарисованного на бумаге, дойти до шарообразного игрового персонажа; что такое игровая логика, как через пробел научить героя прыгать, почему физику нужно умножать на дельта секунды и как можно случайно попасть в бесконечный цикл и нужно будет завершать процесс в диспетчере задач. Полностью посвящая себя изучению 24/7, слушая разные подкасты про разработку игр, смотря видео на youtube от других разработчиков и читая инди раздел на DTF я чувствовал свое ментальное перерождение. Мысли и идеи кипели в моей голове. Вспоминая последние годы рабской рутины, я снова почувствовал себя живым. К тому же, каждый день приближал меня к своей собственной игре. Но…
В жизни часто возникает свое "но", и в моем случае, чем больше я вникал в игровую тематику, тем больше я понимал, что на первую разработку я потрачу три, а то и больше лет. Смотрите, в мои планы не входило выучить Unreal и пойти в контору делать 3 в ряд, начиная как старший помощник младшего конюха; я не хотел открывать свой Blizzard, так как у меня пока нет таких амбиций и финансов, чтобы платить людям зарплату; ну и еще вариант найти себе подобных инди разработчиков и начать создавать проект своей мечты. Возможно последнее — это то, что нужно, но желания делать подобное у меня отсутствовало. Вы спросите почему, но я снова (как и в прошлой статье) не смогу ответить на некоторые вопросы. Возможно, хочу, чтобы мой продукт игрался и выглядел так, как только я хочу, не знаю… В общем, перспектива одиночного долгостроя меня не привлекала, но и в команду мне не хотелось.
Продолжая изучать UE, я задавался этим вопросом каждый день, и вот однажды у меня искрой проскользнул выход из данной ситуации, который я молниеносно отогнал от себя. Но чем больше времени проходило, тем чаще и чаще эта мысль посещала меня и будучи моей внутренней занозой, она добилась своего и я перешел на новый этап принятия неизбежности. Буду с вами честен, протаптывая тропинку геймдева, я не думал, что через 3 месяца она свернет в эту сторону. Но чтобы окончательно сложить все в голове, мне нужно было поговорить с еще одним человеком. Я встал с кресла, подошел к своей женщине и начал диалог:
- Лена, у тебя есть минутка? Мне нужно с тобой серьезно поговорить.
- Ты меня пугаешь. Что такое?
-Нет, нет, успокойся, все хорошо. Мне всегда нравились твои художественные работы. Ты же училась на дизайнера, у тебя было много уроков по рисунку, да?
- Ну, когда-то было, да, нравилось рисовать, но это все было так давно. А что такое?
- Слушай, ты знаешь, что такое пиксель-арт?
- Нуууу… это стиль как на старых приставках?
- Да-да-да.
- И что?
- Слушай… Мне нужна твоя помощь. Я сам не верю, что это говорю, но по всей видимости, у меня нет другого выхода. Как смотришь на то, чтобы ты взяла на себя всю графику моей… или уже нашей игры, а я займусь всем остальным?
- Ну покажи/расскажи мне все подробно, а там будет видно, я в целом не против попробовать.
- Хорошо, я сейчас тебе скину примеры и попробую найти уроки по твоей теме.
- А в твоем “Анреале” можно и 2D игры делать?
- Ой, не спрашивай… Нет, UE4 не был приспособлен делать 2D игры, а в пятой версии вообще вырезали все, что связывало Unreal с 2D.
- Так, а что теперь делать?
- Unity… Мне нужно выучить Unity…
После разговора мне хотелось панически смеяться. Я просто не мог поверить, что моя когда-то там будущая игра из 3D превратилась в 2D, что теперь за весь дизайн отвечает моя жена, что мне нужно с нуля учить Unity и писать код! Последнее меня «веселило» больше всего. Но (сегодня будет много но, но что поделать) все это в перспективе должно принести свои плоды, и мне не придется делать первый проект до старости (я надеюсь).
Что касается моей женщины, Лены, то сомнений в ней у меня никаких не было. Не хочу бросаться красивыми словами, но на данном этапе жизни она мой верный партнер и единомышленник. Несмотря на не самый большой игровой опыт, эта индустрия ее всегда интересовала, а прошлые навыки рисования пригодятся сейчас как никогда (диплом дизайнера до сегодняшнего дня, так ни разу ей и не понадобился) . Я накидал ей кучу примеров игр в стилистике пиксель арт, уроков; попытался объяснить, что мне в будущем будет нужно и сказал, что время на обучение есть, так как мне предстоит разобраться с Unity…
Все “прелести” Unity можно почувствовать уже на этапе скачки/настройки. Для начала нужно определиться, какая версия тебе нужна — свежая или LTS? В чем ты будешь писать код, обычный Visual Studio, например, или Visual Studio Code? А какого года выбрать — 2019 или 2022? Сейчас ответить на все эти вопросы я могу за минуту, но тогда в голове была такая каша, а руки так и тянулись запустить родной Unreal Engine. Но решение принято и дороги назад нет.
Когда все было настроено, а многочасовой курс с 95% положительных отзывов скачан, я впервые запустил Unity. Изучаем интерфейс, создаем квадрат, физика, коллайдеры и вот момент, когда я должен написать свой первый в жизни код. Сказать, что я был в шоке, это ничего не сказать!
В смысле, я должен все это сам писать? Я что, должен все это запомнить? Вот это гигантское предложение из непонятной белеберды, я должен запомнить? Прям обязательно точка с запятой в конце? Какие еще фигурные скобки, как в школе, что ли? Почему на новой строке? В смысле, опять ошибка? Где? Я что, должен все это запомнить?
Цитата ежедневных мыслей в первый месяц изучения программирования для Unity
В общем, стадия принятия — гнев, во всей красе. Приступы тихой ярости одолевали меня каждые пару минут, и это повторялось изо дня в день. Написание кода, по сравнению с блупринтами в UE, казалось прошлым веком. Мозг воспринимал "переезд" как пытку и на отрез отказывался перестраиваться с Unreal’а на другой движок. К тому же, вот с чем мне пришлось столкнуться — если по началу у меня получалось написать хоть какой-то код и я мог выводить “Hello, world!”, то через время я дошел до урока, в котором абсолютно ничего не понимал. С одной стороны, это не мешало двигаться дальше, просто проскочить непонятный урок, но в чем смысл? Если я даже с обучением основ не справился. Я раз за разом проходил данный урок и все так же ничего не понимал. Даже начинание всего курса с нуля не принесло никаких результатов. А потом ко мне пришла гениальная мысль, что это курс плохой, и мне нужен другой, хороший! Логично?
Новый курс скачан: урок 1, 2, 3 и ступор, преподаватель что-то требует, но я не понимаю что. Повторяю все по видео, но этого мало. Помимо повторения, нужно еще и понимать, что ты делаешь, а с этим проблемы. Как вы поняли, этот урок тоже плохой!
Открываю новый, на определенном этапе все снова повторяется. И так 5 или 6 разных курсов подряд, после чего приходит осознание, что я тупой и писать код не способен. Но перед тем, как бросить Unity, я зачем-то решаю открыть самый первый курс и попробовать пройти его еще раз, и Эврика! А теперь-то я все понимаю! Это странно (хотя ничего странного) , но у каждого преподавателя я учился чему-то новому и полученные знания, например, в четвертом курсе помогли мне пройти первый, а потом уже опыт первого решал все проблемы третьего (извините если запутал).
С тех пор все пошло как по маслу. Я проходил курс за курсом, в которых учился делать разные простенькие игры, записывал любые идеи, приходящие мне в голову, бесконечно мечтал во время принятия пищи и продолжал кодить в голове, после выключения компьютера, находясь в кровати. Что касается Лены, ее жизнь была похожа на мою, тоже все свободное время на обучение, только в ее случае — рисованию и анимации пиксель-арта.
Вот так прошли примерно 6 месяцев нашей жизни. Не знаю, много это или мало, но пришел день, когда все уроки, которые я находил, для меня были примитивны, а найти что-то для среднего уровня оказалось крайне тяжело. И тогда я начал осознавать, что мое обучение по курсам подошло к концу.
Далее я решил еще немного “потренироваться на кошках” и написать своими руками механики из игровой классики. Так появились свои вариации “змейки”, “бомбермена”, “танчиков” и других игр. Конечно, без видео с ответом под рукой было не так легко, но главная причина, почему я выбрал Unity, а не например Godot (который сейчас набирает дикую популярность), это то, что на 95% твоих вопросов уже дали ответ в интернете, и почти любая проблема, скорее всего, кем-то решена. Вообще я понял — главное научиться мыслить как программа, и писать код станет легко. Даже в повседневной жизни этот навык может помочь (привет дурдом).
Однажды, копируя механику из очередной старой игры, я задумался — зачем я вообще сижу и повторяю что-то чужое, если можно придумать свое и пытаться это написать? И, о черт! Неужели этот момент пришел? Неужели с учебой покончено? Я что, начинаю делать свою игру…!?!
Как-то так проходило мое обучение. А сейчас я покажу вам, чему будет посвящена будущая статья. Моя первая игра сейчас находится в активной разработке, и я прошу вас добавить ее в желаемое (в Steam) , это очень поможет в ее продвижении. В следующий раз, я расскажу как искал идеи для игры, делал прототип, десятки раз перерисовывал одни и те же карты и многое, многое другое.
Большое спасибо за прочтение и добавление игры в желаемое, вы большие молодцы! Подписывайтесь и пишите комментарии, до встречи.
PS Сделаю небольшое отступление, чтобы ответить на возможные вопросы, которые у вас могли возникнуть, читая эту статью.
Дима, неужели все может быть так легко, по-детски в 30 лет?
И да, и нет. Пожалуйста, не забывайте, что мне понадобилось почти 20 лет, чтобы прийти к себе и то событие, которое сломало мою прошлую жизнь.
Тебе очень повезло с Леной.
Да, наверное да.
Лене заняться больше нечем? Она что, не работала?
Работала, но обстоятельства поставили ее работу на паузу. Она мой друг, а игры часто делаются с друзяшками.
Мужик, прошло 7 месяцев, ты что по слову в день писал?
Сразу после написания прошлого лонгрида я решил, что выложу продолжение после того как игра будет в играбельном состоянии (впереди еще очень много работы) + будет готова страница в Steam. Вчера Steam одобрил игру в магазине, сегодня статья выложена в сеть.
Да Димон, первая статья то покруче была.
Читать рефлексию по нескольким десяткам лет интереснее, не спорю; я сам это понимал. Но пихать данный текст в первую часть не было смысла, а начинать этим сочинением будущий лонг тоже не вариант. В итоге, имеем две готовые публикации — дорога в геймдев, обучение; а вскоре напишу, как стартовала разработка, и о всех этапах до сегодняшнего дня.
Почему не выбрал визуальное програмирование в Unity (Bolt, Playmaker)?
Я это рассматривал, но по нему не так много уроков, как по c#; он не такой гибкий и удобный как в UE (как мне показалось, может я не прав) и самое главное - я решил, что если уже учу Unity буду как взрослый, исключительно через программирование, чтоб делать абсолютно все что в голову придет.
Очередной пиксель-арт, ты с дуба рухнул?
Понимаю и, возможно, соглашусь с вами, но для меня важно придумать, сделать и выпустить игру, а пиксель-арт — это инструмент, который поможет воплотить все это в жизнь, не растягивая разработку двух человек на годы.
И что думаешь, ты в будущем выпустишь свой Minecraft и все побегут его покупать?
Хммм… хотелось бы конечно, но сейчас самое главное для меня то, что я получаю огромное удовольствие от того, чем занимаюсь, а что будет дальше, время покажет.
Я пришел за ответом, как пересобрать себя и не сойти с ума, а не читать скудоумный рассказ ноунейма!
Тут каждый должен сам решать, я не психотерапевт. В моем случае это максимальный выход из зоны комфорта, просто начать делать то, о чем мечтал много лет. Далее понимаешь, что менять жизнь не так уж страшно. Задаешься вопросом: "Какого черта так долго тянул и не сделал этого раньше?" Потом приходит удовольствие от процесса познания чего-то нового.
Правда ли, что дикие лошади спят стоя?
Да, как и многие другие дикие животные. Это связано с вероятностью нападения хищных зверей; секундное промедление, которое потребуется, чтобы занять вертикальное положение, может стоить жизни.
Грандиозные планы по завоеванию цифрового мира рассказал владелец Facebook Марк Цукерберг. Он собирается устроить технологическую революцию. Компания занимается разработкой "метавселенной" - цифрового мира с возможностью "телепортироваться" в любую часть света, не выходя из дома.
- Сам термин пришёл из научной фантастики. Под "метавселенной" подразумевается объединение физической, дополненной и виртуальной реальности в едином онлайн-пространстве.
- Благодаря этому пользователи преодолеют ограничения физики и смогут перемещаться по цифровому миру в виде аватаров так же, как по комнатам в собственном доме. Сам Цукерберг называет "метавселенную" аналогом телепортации.
- К примеру, пользователь, находясь в любом месте, сможет создавать вокруг себя виртуальное рабочее место с кучей окон, документов и мониторов. Другой человек вместо обычного созвона получит возможность "телепортироваться" к нему в виде голограммы для обсуждения или решения каких-либо вопросов.
- Аналогично "мультивселенная" будет работать и в других сферах. Пользователи смогут создавать игры, виртуальные товары, одежду, шоу или новую работу. Таким образом внутри технологии сформируется собственная экономика и экосистема.
- Facebook считает, что это следующий этап развития технологий после мобильных устройств. Также Цукерберг подчёркивает, что "мультивселенная" должна стать воплощением интернета с децентрализованным управлением. Иными словами, там планируется полная свобода "телепортаций" между сервисами и развлечениями. Правда, компаниям придётся об этом как-то договариваться.
- В целом реализовать технологию Facebook намерен в течение следующих пяти лет. Разработчикам пока надо придумать, как запихнуть "метавселенную" в небольшие гарнитуры с поддержкой разных платформ: от VR до компьютеров и консолей.
Это будет необычный пост, почти без картинок, с кучей букв, поэтому не думаю, что он выберется из минусов. Но, вопреки распространённому заблуждению, разработка игр состоит не только из придумывания на-гора клёвых идей. Это уйма рутины - именно она, чаще всего, и ставит крест на большинстве “гаражных” проектов.
Начну с удара под дых - идея ничего не стоит. Можно придумать гениальную концепцию невиданного доселе шедевра, но если вы не можете её реализовать (или найти средства на её реализацию), то ей, к сожалению, грош цена. Все современные визионеры геймдева, от Кодзимы до Сида Мейера, прошли долгий путь и сделали кучу проектов “руками”, прежде чем заслужили свою репутацию, под которую дают деньги на разработку. Если вы придёте с улицы и с грохотом водрузите на стол инвестора концепт-док про ограбление корованов, его никто даже не откроет - вам сразу укажут на дверь. До момента, пока ваше мнение обретёт вес, пройдёт много выпущенных проектов. И то это не гарантирует шансы на успех, лишь несколько их повышает.
Подсластим пилюлю - проекты не обязательно должны быть блокбастерами. Да, если вы релизнули мега-хит, это сразу делает вас важной шишкой, но несколько игр, которые хотя бы отбили разработку или даже пять-десять провальных - тоже неплохая заявка и плюс к авторитету. Почему? Всё просто. Человек, который сделал 10 провальных проектов как минимум доказал, что он в принципе способен сделать проект, притом не один. К тому же, если он не совсем дурак, из каждой неудачи он делал выводы и копил опыт, повышая шансы следующей игры выстрелить. Это особенно котируется, если вы пытаетесь совершенствоваться в какой-то своей нише, а не скачете от жанра к жанру. Как говорится, не стоит бояться человека, который знает 10 000 ударов - нужно бояться человека, который натренировал один удар 10 000 раз. Ауф!
Теперь самая главная истина, которая воспринимается всеми неофитами в штыки и становится эпитафией 99 из 100 начатых проектов - не переоценивайте свои возможности.
Да, все хотят начать с проекта мечты и сразу делать нелинейную рпг-метроидванию с элементами сурвайвла, или реалистичный ммо-хоррор шутер с кастомизацией оружия и альтернативной физикой, а не размениваться на мелочи. Мы же сюда самореализовываться пришли, верно?
К сожалению, именно на этом горят почти все энтузиасты - они взваливают на себя производство игры, которую не всякая коммерческая студия осилит, через боль, слёзы и скандалы делают от 1 до 30% запланированного, после чего выгорают, бросают, иногда спиваются или кончают жизнь самоубийством. Мизерное количество доползших до релиза проектов, часть из которых даже обретает некую популярность, порождает чудовищную ошибку выжившего.
Итак, ты - юный девелопер, который хочет сделать игру. За плечами нет ничего, кроме энтузиазма. Как мы уже выяснили, ноунейму околачивать двери издательств с расписанным концептом бесполезно - ни денег, ни команды не дадут. Что же делать?
Для начала попытаться ответить на вопрос кем ты хочешь стать, когда вырастешькакие твои сильные стороны и чем ты можешь быть полезен проекту. Сразу оговорюсь, если ответ “придумывать классные идеи”, то лучше на этом завершить свою карьеру. Инди-команды не могут себе позволить отдельную позицию креативного директора, и поэтому ты или учишься работать руками (код, арт, текст, управление или продвижение), или становишься бесполезным - даже вредным - балластом.
Чисто по моему опыту самая востребованная профа, повышающая шансы на успех всего мероприятия - это программирование. Прогеров самый большой дефицит в инди-командах, именно пропажа прогера может похоронить проект почти на любой стадии производства. А кроме того, прогер - это (за супер-редким исключением) единственный спец в команде, который может позволить себе стать полноценным соло-разрабом, хотя я лично не рекомендую этот путь, о чём напишу ниже.
Однако если вы, как и автор данных строк, с юности страдаете от гуманитария головного мозга, не стоит отчаиваться.
Постарайтесь определить свои самые сильные стороны, скилы (и ваших соратников, если они на данном этапе уже есть). Сфокусируйтесь на них. Найдите жанр или механику, которые лучше всего раскроет ваши сильные стороны и меньше всего будет зависимы от слабых.
Например - ты пишешь гениальные (по мнению твоей бабушки) тексты, а друг в школе рисовал на полях анимешных тянок. Погромиста нет и не предвидится. Значит, лучше всего будет сделать небольшую визуальную новеллу на RenPy (набор необходимых для этого команд способен освоить даже дегенерат) на 20 минут геймплея.
Друг отказался? Не страшно. Пили текстовый квест (да, у них тоже есть своя аудитория) на движке Instead. Да хоть порно-новеллу - если сделаешь хорошо и задорно, игроки найдутся. Помните, что чем уже ниша, тем приятнее процесс ниже конкуренция и больше шансов найти в ней своих игроков.
Ты художник, у которого есть вижн, но не очень с геймдизайном и графоманией? Открой туториал “делаем сокобан на Юнити за три дня с нуля”, попытайся его повторить и замени ассеты на самодельные. Если что, это реальный кейс безумно мною любимого и вдохновившего меня на Princess Hunter`а нашумевшего Helltaker.
Судьба сделала тебя программистом, который не умеет рисовать и писать ничего, кроме кода? Сейчас есть тонны офигеннейших бесплатных или супер-дешёвых ассетов. Плюс на инди-сцене прогеры как рок-звёзды, к ним очереди выстроятся желающих привлечь на свой проект, если нет мыслей и даже желания думать, что можно было бы сделать.
Самый запущенный случай - ты геймдизайнер, который хорош в придумывании механик, но плох во всём остальном. Но даже тут есть два пути. Первый - это изучить любой движок хотя бы на таком уровне, чтобы можно было собирать прототипы хотя бы на кубиках. Сейчас это не так сложно, как лет 10 назад - здравствуй, новый инструментарий, туторы и блупринты Анрила. К тому же этот путь сразу сделает тебя полубогом, позволив перешагнуть даже некоторых безыдейных прогеров. Второй путь проще, хуже, но тоже жизнеспособный - делай PnP, то есть “бумажные” прототипы, настолки. Да, это ограничивает в выборе механик, 3д-экшен или диаблу таким образом запрототипировать будет сложно. Но очень много игр вполне себе может быть воплощено таким образом. И получить дальнейшее развитие уже в цифровом виде. Например, боёвка “Принцессок” создавалась и проходила первоначальные тесты именно в виде бумажных карточек.
В любом из выбранных вариантов стоит постоянно бить себя по рукам, когда захочется увеличить масштабы, прикрутить ещё фичу или две, добавить три новых сюжетных ветки. Здесь нужно как мантры повторять три постулата:
Лучшее - враг хорошего.
Лучше маленькая простая выпущенная игра, чем огромная, офигенная и незаконченная.
Сначала кор-геймплей, потом всё остальное.
Сосредоточьте силы и внимание на базовых механиках и доделайте сначала их, прежде чем добалять финтифлюшки.
Чтобы что?
Каждый раз придумывая фичу, задавайте себе вопросы - зачем её добавлять в игру и какие проблемы она РЕШИТ, а какие создаст. Ответы “ну эт тип прикольно” и “ну я в другой игре это видел” - неправильные. Даже если это работает в одном проекте, в другом может всё порушить. Фичи должны решать реальные проблемы и вписываться в общий дизайн. А также, что очень важно, иметь приоритеты! (см. мантру 2)
Немного про управление.
Очень многие инди-команды забивают болт даже на минимальный менеджмент внутри команды, считая, что все эти таск-трекеры и прочие ПМы просто раковая опухоль на теле разработки, а в маленькой команде всё само собой организуется, достаточно быть талантливыми и трудолюбивыми.
Что ж… это не так. И это второй главный бич инди-проектов, который сводит их в могилу.
Правда заключается в том, что без управления даже команда из трёх человек работает неэффективно, делает много лишней работы, а также не понимает ход и масштабы разработки. Всё это приводит к тому, что разработка тянется годами и даже самый яркий энтузиазм гаснет. Нередко заканчивается ссорами, криками, мордобоем, но почти никогда - выпущенной игрой.
Поэтому на кого-то из команды должно лечь бремя ответственности за планирование и менеджмент, коммуникацию между всеми членами команды, построение графика работы, примерного роадмапа. Этим нужно заниматься постоянно, а не один раз в начале проекта. Но эффект будет ощутимым. Достигая очередного майлстоуна, команда получит заряд веры в проект и буст энтузиазма. Вы будете планомерно двигаться в нужную сторону, а не вихлять, как маркитантская лодка.
Если ни у кого из команды нет желания и способностей взвалить на себя эту ношу, то я настоятельно советую привлечь такого человека извне, потому что без него вы будете делать не один проект сообща, а каждый - свой проект, в своём темпе. И вряд ли что-то дельное закончите.
В завершении этого лонгрида, расскажу немного про соло-разработчиков.
Главный плюс соло-индюка в том, что он абсолютно независим от других людей. Фактор автобуса с его случае равен нулю (если принять как данность то, что если автобус собьёт самого соло-индюка, проект в принципе потеряет смысл и актуальность). Это очень жирный плюс, так как энтузиазм редко иссякает у всех одновременно, и обычно проект подкашивается от потери кого-то одного - художника, прогера, гд. Как пелось в песне - если у вас нет техлида, его не отравит сосед... Вы полностью контролируете разработку от начала и до конца.
Несколько натянутый для меня плюс в том, что так называемый Вижн (видение) проекта не размазано на нескольких людей, а максимально сконцентрировано. Лично я не считаю это преимуществом, так как синергия талантливых людей, по моему опыту, даёт более интересный результат, чем единоличная работа, но для некоторых проектов чисто авторский подход может быть критичным.
На этом плюсы заканчиваются и начинаются минусы.
Самый главный из них - это очень долго. Даже если вы очень круты во всех сферах геймдева, в сутках только 24 часа, а вы не можете писать код и музыку одновременно. Разработка увеличивается по срокам в 3-5, а то и 10 раз. Есть успешные кейсы вроде Stardew Valley, но там, напомню, в качестве необходимой фичи нужна жена, которая будет обеспечивать вас на протяжении 5+ лет и безоговорочно верить в то, что вы гений, а не битард. Для меня это опять же ошибка выжившего.
Чаще же человек не может одинаково хорошо делать разнородные задачи, у него что-то получается лучше, что-то хуже, а то и всё не очень. Тут зависит от вашего перфекционизма и видения игры. Для игры типа Baba is you арт вполне может нарисовать прогер-гд. Но это подходит не для всех проектов. В общем, это существенно ограничивает вас в путях, но частично лечится использованием покупных ассетов или наёмной силы, благо с этим сейчас проблем нет.
Болезнь или любой другой катаклизм полностью замораживают разработку, так как один человек не может параллелить процессы. Если этот период затягивается, это может подкосить даже самый несгибаемый энтузиазм.
Таким образом я считаю соло-разработку отличным вариантом для каких-то очень локальных проектов с коротким сроком разработки, и только в том случае, если вы - это мощный сплав гд, прогера и, в идеале, например, пиксельарт-художника.
Сам я таким набором талантов не обладаю, поэтому стараюсь работать в команде. Во-первых здорово, когда человек занимается тем, что у него получается лучше всего. Во-вторых, мне нравится, когда другие люди привносят в игру свои идеи, задумки, предложения, реализуют какие-то вещи неожиданным образом. Именно за эту синергию я и люблю геймдев.
Бонус - мои чисто прикладые советы.
Участвуйте в геймсджемах (соревнования на заданную тематику, где небольшие команды собираются для создания мини-игр\прототипов за 1-3 дня). Это супер прокачивает скилы и даёт конкретный результат. Этакий интенсив. И не забывайте, что из одного такого геймсджем-прототипа в итоге вырос Hollow Knight!
Реферы - это круто. Чтобы научиться что-то делать, не зазорно сначала дословно повторить чужие работы. Это офигенно помогает прокачаться во всех аспектах. Да и потом не стесняйтесь смотреть на другие проекты, чтобы черпать идеи и вдохновение. 99,9% игр это не открытие новых механик, а удачные или неожиданные комбинации уже имеющихся.
Занимайтесь реверс-инжинирингом. Анализируйте понравившиеся вам игры не как игрок, а как разработчик. Учитесь задавать себе вопросы и находить на них ответы - почему здесь сделано так, а не иначе? Это хорошо или плохо? Ищите ошибки даже в играх, которые считаете идеальными, размышляйте, как бы вы их улучшили. Анализируйте чужие провалы и недостатки.
Насмотренность - это важно. Играйте, слушайте музыку, читайте книги и комиксы, смотрите фильмы, сериалы, мультики, аниме. Не замыкайтесь в себе и в разработке. Вдохновение и идеи могут прийти откуда угодно. Одна задумка игры родилась у меня после прочтения статьи в местной газете году этак в 2007ом. Помните - творчество порождает творчество. В этом плане мне очень нравится Джойреактор, который для меня неисчерпаемый источник вдохновения, идей, реферов, именно за счёт своего разнородного контента, бОльшую часть которого я бы специально не искал. Но вы, пидоры, несёте его сюда, и я вам за это благодарен. Ну и сам стараюсь по мере сил.
Если этот лонгрид хоть десять комментов наберёт, я, конечно, охренею.
А теперь немного подробностей, многоуважаемый читатель. Если ты любишь стратегии, средневековье, ОСАДЫ, мехов и при этом знаешь что-то о програмировании и разработке такого рода игр, то тебе сюда. Если ты хочешь попытаться создать свою эпическую " Katawa Sojo " только от мира стратегий, то тебе точно сюда !
Немного предыстории - уже почти год я раздумываю о создании хорошей стратегии и отличной игры в целом у меня были 80 страниц широченного блокнота исписанных описаниями общей концепции и всего вообще от сюжета до нюансов механик , но как часто бывает - когда думаешь о чем-то большом , рождаются конкретные идеи , которые могут быть не такими масштабными но ОЧЕНЬ ГОДНЫМИ.
Так вот буквально во время очередного " припадка вдохновения " я буквально за два дня полностью сформулировал эту вторую идею, на 8 страницах текста.
Немного о себе - я начинающий 3-д artist ,очень начинающий, пока балуюсь хайполи-моделями, но " база " как сделать остальное вроде бы есть, самое главное - я хочу делать классные модели и классные вещи, насколько бы меня это не выматывало и насколько бы моя криворукость и отсутствие ощутимых подвижек не выпивали из меня душу.
Так же я думаю, что у меня есть вполне себе хороший вкус и кое-какое понимание того, какой должна быть по настоящему хорошая история.
Вот мои скромные первые модельки - https://sketchfab.com/TrytoLive
Я осознаю, что если я буду пытаться ковыряться еще и в ПРОГРАМИРОВАНИИ и в работе с кодом, то я скорее всего увижу релиз своей игры только в болезненном предсмертном припадке.
Поэтому , я ищу на ректоре , тех людей которые в этом разбираются, в частности, если вам нужен пример предстоящей работы, чтобы приблизительно оценить масштаб, то это будет очень близко к игры - " Frostpunk " , поэтому если вы представляете хоть приблизительно как такое можно сделать и если вы чувствуете НЕПРЕОДОЛИМОЕ ЖЕЛАНИЕ сделать что-то классное в своей жизни, как и я и довериться идеи незнакомого пидора с реактора, то это точно судьба !
И когда я говорю о НЕПРЕОДОЛИМОМ ЖЕЛАНИИ, то оно должно быть именно таким , потому что только это сможет провести нас через производство, только чистый, неподдельный энтузиазм.
Я не хочу чтобы все мои мечты и идеи умерли из-за невозможности воплотить их в одно лицо.
И я надеюсь что среди вас найдутся те, кто заинтересуется моей идеей, и сможет разделить ее со мной, насколько бы бесконечно наивно это бы не звучало/читалось.
Я могу взять на себя все включая общую концепцию, которая готова, кое-какие 3дмодели и сюжет, в общем почти все не считая самого главного - работы с движком который нам подойдет и кроме програмирования.
Почему пример был именно с Фростпанком ? Потому что это игра достаточно отличается от привычных дешевых игр, которые можно состряпать на инструментарии бесплатных движков .
Я не излагаю идею полностью тут, хотя намеки есть, потому что вот в чем а в ИДЕЕ я уверен ! И мне не хотелось бы вот ее, " свою самую лучшую в мире идею " отправлять " по рукам " ! Так что, надеюсь на вашу порядочность.
В заключении скажу лишь, что я уверен на 100 %, по объективным причинам, что если сделать игру хотя бы на 1/3 от заложенной идеи, то она " взлетит " и ТОЧНО окупит все старания и труды и принесет много радости игрокам и гордости - нашей маленькой команде ! В конце концов - у " Katawa Sojo " на 4chan вышло , чем Joyreator хуже ?!
Неужели у нас тут нет талантливых людей, которые нужны и которые смогут воплотить это в жизнь ?)
Люблю вас, пидоры .
Дисклеймер: эта серия постов не про UEFI. Это не значит, что я не знаю о существовании UEFI. Про UEFI будет отдельная серия постов. Почему я не пишу про UEFI прямо сейчас? Потому что UEFI - это уровень абстракции над железом, а мне интересно именно железо и работа с ним.
Продолжаем? Сейчас наш загрузчик второго уровня работает в "немом" режиме - без возможности подать сигнал об ошибке или выполнении операции. Это необходимо исправить. Самое очевидное решение - вывод информации на дисплей. Мы уже условились, что на нынешнем этапе для работы нашей ОС будет необходима VGA-совместимая карта и дисплей, так что вправе рассчитывать на их наличие.
Программирование VGA-контроллера - сложная штука. Однажды мы ею обязательно займёмся, но сейчас, раз уж мы всё ещё в Реальном режиме, есть вариант попроще: функции BIOS. Функции, связанные с работой дисплея, доступны через прерывание 10h. Мы уже пользовались им для вывода текста в первичном загрузчике, но так как теперь мы не ограничены в размере программы, функционал можно будет расширить.
Первое, что нам стоит сделать - установить нужный видеорежим на случай, если BIOS этого не сделала. Кроме того, понадобятся функции считывания положения курсора, прокрутки экрана и вывода строки. Весь код, связанный с вводом/выводом будет храниться в отдельном файле. У меня он называется io.inc. Мы ещё не использовали подключаемые файлы, но ничего сложного тут нет: в TASM они объявляются директивой include, после которой идёт путь и имя файла. Единственная тонкость тут в том, что подключенный файл не будет вынесен в какую-то изолированную область памяти, как это делается в языках высокого уровня, а окажется в исполняемом файле именно там, где был объявлен. Поэтому лучше объявлять подключаемые файлы где-нибудь в конце, за пределами основного кода.
VGA имеет набор стандартных режимов отображения, с которым можно ознакомиться тут:http://www.columbia.edu/~em36/wpdos/videomodes.txt
Нас интересует режим номер 3 - 80х25 символов, 16 цветов. Для его включения создадим в файле io.inc процедуру set_vmode3. Её полный текст будет выглядеть так:
set_vmode3 proc
push ax
push bx
pushf
xor ax,ax
mov ah,0Fh
int 10h
cmp al,03h
je @@exit_good
mov ax,0003h
int 10h
xor ax,ax
mov ah,0Fh
int 10h
cmp al,03h
jne @@exit_bad
@@exit_good: mov byte ptr vmode,al
mov byte ptr vcol,ah
mov byte ptr vrow,19h
mov byte ptr vpage,bh
popf
clc
pop bx
pop ax
ret
@@exit_bad: popf
stc
pop bx
pop ax
ret
set_vmode3 endp
Начинается процедура, как и почти всегда у меня, с сохранения состояния используемых регистров в стеке. Это нетипичный для ассемблера подход. Обычно, создавая низкоуровневый код, программист стремиться максимально оптимизировать использование инструкций, по возможности обходясь без обращений к памяти, использования стека и вызова процедур. К сожалению, при работе над большим проектом это невозможно, и я на горьком опыте выяснил, что лучше потратить лишние циклы на инкапсуляцию процедуры, чем потом мучительно отлавливать баг, который появился из-за того, что какой-то регистр внепланово изменил значение.
xor ax,ax mov ah,0Fh
int 10h
cmp al,03h
je @@exit_good
Этот блок нужен для того, чтобы остановить выполнение процедуры, если режим 3 уже установлен. Сначала регистр AX обнуляется, чтобы мы точно знали его значение. Функция 15 (0Fh) прерывания 10h возвращает в регистре AL номер установленного режима. Далее мы сравниваем результат с нужным значением (3), и если они равны, то переходим к завершению процедуры, метка @@exit_good. Если режим 3 не установлен, продолжаем.
mov ax,0003h int 10h
Здесь мы опять вызываем прерывание 10h со следующими параметрами: AH = 0(функция 0, установка видеорежима), AL = 3(номер режима). После этого снова идёт проверка режима. Если AL всё ещё не равен 0 - вероятно, возникла проблема, которую мы не сможем решить. Переходим к метке @@exit_bad. Если AL равен 3, продолжаем от @@exit_good. Первым делом - сохраняем в переменные параметры режима, которые вернуло прерывание 10h. В AL - номер режима; в AH - количество колонок символов; в BH - активную страницу видеопамяти (об этом позже). Параметр vrow не возвращается, потому что технически количество символьных строк ограничено только объёмом видеопамяти, а не размером дисплея. После этого восстанавливаем сохранённые в начале регистры, устанавливаем CF (флаг переноса) в нужное положение и завершаем процедуру.
Готово. Теперь в основной модуль после call read_BPB добавляем call set_vmode3 и после этого jc panic. JC - инструкция условного перехода. Переход выполняется при установленном флаге CF. То есть, если наша процедура set_vmode3 завершилась неудачно, программа продолжится от метки panic. Так как невозможность установить видеорежим говорит либо о серьёзных неполадках, либо о несовместимом оборудовании, продолжать выполнение смысла нет. После метки panic останавливаем программу инструкциями cli и hlt.
Далее стоит вывести какое-нибудь приветствие или заголовок, просто чтобы уведомить пользователя о том, что программа работает. Для этого первым делом стоит узнать положение курсора, ведь на экране скорее всего уже есть какой-то текст от BIOS. Это тоже можно сделать с помощью прерывания 10h. Добавьте в io.inc процедуру get_cursor_pos:
get_cursor_pos proc push ax
push bx
push cx
push dx
pushf
mov ah,03h
mov bh,byte ptr vpage
int 10h
mov byte ptr cursor_X,dl
mov byte ptr cursor_Y,dh
popf
pop dx
pop cx
pop bx
pop ax
ret
get_cursor_pos endp
Про сохранение/восстановление используемых регистров объяснять больше не буду, а в остальном тут всё просто: вызываем функцию 3 прерывания 10h, в BH передаём активную страницу видеопамяти. Прерывание возвращает в DL позицию курсора по X, а в DH - по Y. Сохраняем в переменных. Готово. Далее нам понадобится процедура для прокрутки содержимого дисплея. Тут чуть сложнее, добавьте в io.inc:
scroll_up proc push ax
push bx
push cx
push dx
pushf
mov ah,06h
mov bh,CS_DEFAULT
xor cx,cx
mov dl,byte ptr vcol
dec dl
mov dh,byte ptr vrow
dec dh
int 10h
popf
pop dx
pop cx
pop bx
pop ax
ret
scroll_up endp
Функция прокрутки экрана BIOS требует, во-первых, цветовую схему, которой будут заполнены очищенные строки, а во-вторых, координаты верхнего левого и правого нижнего углов сдвигаемой области. Цветовая схема передаётся в регистре BH и состоит из цвета фона и цвета символа. Мы ещё не объявляли константы, давайте посмотрим, как это делается. Константы в отличие от подключаемых файлов можно объявлять где угодно, так как они нужны только на этапе компиляции и не попадают в исполняемый файл. В TASM для объявления констант используется инструкция equ. Вся конструкция выглядит так: ИМЯ КОНСТАНТЫ equ ЗНАЧЕНИЕ КОНСТАНТЫ. Так как в стандартной палитре третьего режима всего 16 цветов, уместно будет определить их в виде констант. Добавьте в код такую запись:
;Цвета фона.BC_BLACK equ byte ptr 00h
BC_BLUE equ byte ptr 10h
BC_GREEN equ byte ptr 20h
BC_CYAN equ byte ptr 30h
BC_RED equ byte ptr 40h
BC_MAGENTA equ byte ptr 50h
BC_BROWN equ byte ptr 60h
BC_LIGHTGRAY equ byte ptr 70h
;Цвета символа.
SC_BLACK equ byte ptr 00h
SC_BLUE equ byte ptr 01h
SC_GREEN equ byte ptr 02h
SC_CYAN equ byte ptr 03h
SC_RED equ byte ptr 04h
SC_MAGENTA equ byte ptr 05h
SC_BROWN equ byte ptr 06h
SC_LIGHTGRAY equ byte ptr 07h
SC_DARKGRAY equ byte ptr 08h
SC_LIGHTBLUE equ byte ptr 09h
SC_LIGHTGREEN equ byte ptr 0Ah
SC_LIGHTCYAN equ byte ptr 0Bh
SC_LIGHTRED equ byte ptr 0Ch
SC_LIGHTMAGENTA equ byte ptr 0Dh
SC_LIGHTBROWN equ byte ptr 0Eh
SC_WHITE equ byte ptr 0Fh
;Несколько готовых цветовых схем.
CS_DEFAULT equ BC_BLACK or SC_CYAN
CS_CLASSIC equ BC_BLACK or SC_LIGHTGRAY
CS_DARK equ BC_BLACK or SC_DARKGRAY
CS_BLUE equ BC_BLUE or SC_LIGHTBLUE
CS_ALARM equ BC_BLACK or SC_RED
CS_DEBUG equ BC_BLUE or SC_WHITE
CS_INVERT equ BC_LIGHTGRAY or SC_BLACK
CS_PANIC equ BC_RED or SC_BLACK
Как видите, для передачи цвета фона/символа используется один байт. Нижние 4 бита отвечают за цвет символа, верхние - за цвет фона и некоторые другие эффекты (подчёркивание, мигание), которые нам сейчас не нужны. Теперь разберёмся с рабочей областью. Мы хотим сдвинуть вверх весь экран, поэтому верхняя левая точка будет в (0,0), а правая нижняя - в (число символов по X-1,число символов по Y-1). Первая передается в CX, вторая - в DX. Таким образом, код процедуры расшифровывается так:
AH=номер функции (6)BH=цветовая схема
CX=верхний левый угол рабочей области (0,0)
DX=правый нижний угол
Вызвать прерывание 10h
Процедура принимает число строк, на которое нужно прокрутить экран вверх, в AL. Добавьте после jc panic такой код:
call get_cursor_pos mov al,01h
call scroll_up
Последнее, что мы рассмотрим сегодня - вывод строки. Это функция 19 прерывания 10h. В качестве параметров она требует: сегмент и смещение строки в ES:BP; цветовую схему в BL; активную страницу видеопамяти в BH; позицию начала вывода по X в DL; позицию начала вывода по Y в DH; длину строки в CX; режим вывода в AL. Номер функции как всегда передаётся в AH.
Зная всё это, давайте подумаем, как организовать процедуру. В принципе тут всё почти однозначно, но что\ делать с длиной строки? Заносить в CX вручную перед каждым вызовом процедуры? Можно, но зачем раздувать код. Лучше включить эту информацию в саму строку. Например, приняв, что первые 16 бит строки будут содержать число символов в ней. У меня строка с заголовком загрузчика выглядит так:str_title dw 31 ;Длина строки. db '=== Tardigrada Loader v.1.1 ===' ;Строка. Теперь давайте напишем саму процедуру в io.inc. print_string proc push ax Наша процедура будет принимать два параметра: смещение строки в BP и цветовую схему в BL. Практически весь код - это заполнение регистров для вызова прерывания. В основном модуле после call scroll_up добавим: mov bl,CS_DEFAULT mov bp,offset str_title Этот код выведет заголовок и прокрутит экран ещё на одну строку вверх. Если всё сделано правильно, должно получиться что-то вроде этого:
push bx
push cx
push dx
push bp
push es
pushf
mov ax,0050h
mov es,ax
mov ax,1300h
mov bh,byte ptr vpage
mov cx,es:[bp]
mov dh,byte ptr cursor_Y
mov dl,byte ptr cursor_X
add bp,0002h
int 10h
popf
pop es
pop bp
pop dx
pop cx
pop bx
pop ax
ret
print_string endp
call print_string
mov al,01h
call scroll_up
Исходники: https://drive.google.com/file/d/144cHXVlBskSiKt9zTAR1V535UQCeUyBL/view?usp=sharing
Bochs: https://drive.google.com/file/d/16k2Gpr7oPSekq4rAhmtBV0IPnIteDLlE/view?usp=sharing
 | nashi5364Подписчиков: +221 |
 | аниМемыПодписчиков: +69 |
 | mr_plagu3Подписчиков: +42 |
 | DarbarnirПодписчиков: +36 |
 | эльфийка и мужик (merrivius)Подписчиков: +20 |
 | madaotheoryПодписчиков: +143 |
 | sincosПодписчиков: +131 |
 | z0mbiraptorПодписчиков: +102 |
 | QuantumHeadAIПодписчиков: +101 |
 | Anime Ero DFCПодписчиков: +97 |
Отличный комментарий!