Как написать игровой движок? Какой движок выбрать для создания своей игры
Разработка игр на плаву, она перспективна и набирает популярность. Мы подготовили подробную инфографику о пути изучения разработки игр.
С геймдевом связано много областей, и каждый этап обучения основан на этапе предшествующем. Например, не стоит сразу перескакивать на игровые движки. Начните с разработки ПО, изучения математики с заточкой под программирование игр и только после переходите к геймдеву. Каждый из представленных этапов – это пошаговое руководство, включающее в себя книги и другие материалы.
0. Разработка игр для детей
Многие книги ориентированы на работу с легендарной и интуитивно понятной средой разработки для детей Scratch, в том числе ScratchJr. После базиса следует информация о Python Pygame. Есть книга для пятилетних, но большая часть материалов подойдет для детей в возрасте от 8 лет.
1. Информатика
Теоретическая подковка – обязательная составляющая, без которой дальнейшее изучение лишено смысла. Эта подборка обучающей литературы включает в себя основы, сведения об алгоритмах и математику в разрезе изучения информатики.
2. Языки программирования
Разговаривать на языке компьютера непросто, но возможно. И таких способов уйма. Например, язык C существенно повлиял на индустрию ПО, поделившись своим синтаксисом с популярными C#, C++ и Java. C++, в свою очередь, является мощным языком для создания эффективных программ и программных комплексов. Многие также пишут игры на C#: язык шустрый, удобный и позволяет быстрее стартовать разработку.
А вот Lua перенял кое-что от C++. Скрипт-язык хорош для игровой логики. Он упростит инициализацию уровня, привязку задач к объектам, смену поведения NPC в интерактивном режиме без необходимости перекомпилировать проект и многое другое.
3. Создание приложений
И если информатика – это базис теоретический, то здесь больше практики. Разработка игр – ухабистая стезя, и начать лучше с приложений. Книги с практическими заданиями, а также информацией о паттернах и UML помогут разобраться, что к чему.
4. Математика для разработки игр
Нет, здесь не будет школьного курса алгебры и геометрии. Подборка разбита на основы математики в сфере геймдева и более продвинутый уровень.
5. Игровое программирование
Аппаратные платформы, операционные системы, наборы API, алгоритмы, кроссплатформенность и другие важные аспекты, которые лягут в основу разрабатываемой игры. Книги дополнены рядом геймдев-статей, в которых содержится полезная информация по программированию.
6. Разработка игрового движка
Движок – это сердце игры, которое «закачивает» функциональные возможности и необходимый инструментарий. В первых книгах вы познакомитесь с архитектурой и дизайном. Дальше «игровые движки» разделяются на инструменты, оптимизацию, скрипты и дополнительные материалы в виде статей. В ходе ознакомления затрагиваются паттерны, алгоритмические трюки, оптимизация в Unity и прочие нюансы.
7. Компьютерная графика
Да, содержимое – это важно, но именно компьютерная графика является аналогом интерфейса приложения, который будут видеть пользователи. Поэтому ей стоит уделить особое внимание.
Недаром этот раздел самый большой. Сюда включены основы программирования с Real-Time 3D, DirectX и OpenGL. Все дополнено информацией о рендеринге и технологиях. Отдельного внимания в подборке удостоились Direct3D и OpenGL.
8. Игровое аудио
Разработка игр касается и аудио: это звуки, издаваемые NPC, главным героем, явлениями или предметами, а также музыка. Аудио программирование обошлось всего двумя книгами, но в них доступно изложена необходимая информация.
9. Игровая физика и анимация
Один из самых сложных этапов. Кроме программной основы и картинок, должны быть законы, по которым все это взаимодействует. Игровая физика и анимационное программирование раскрыты в 17 книгах. Отдельно затронута имитация жидкости.
10. Игровой искусственный интеллект
Управляемых компьютером персонажей немало: это могут быть мобы, квестгиверы и даже обычные шахматы. Обилие книг позволит понять принципы работы ИИ. Ниже приведен перечень тематических полезных статей.
11. Многопользовательское игровое программирование
Разработка игр для одного игрока сильно отличается от многопользовательских вариантов. Здесь нужно учитывать соединение, работу потоков и другие нюансы. Подборка разбилась на статьи и книги о серверном программировании, сетевом программировании и сетевом протоколе.
Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться? На кого равняться? И что необходимо сделать в первую очередь?
Большинство любителей рок-музыки рано или поздно берут в руки гитару. Фанаты спорта страстно мечтают о выходе на футбольное поле, баскетбольную площадку или теннисный корт. Ну а те, кто совершил сотни угонов в GTA, провел десятки часов в компьютерных клубах за Counter-Strike или достиг немалых успехов в MMORPG, наверняка задумываются о карьере разработчика игр.
Проблема в том, что данному направлению обучают в считанных учебных заведениях. Посему большинство разработчиков игр – самоучки, некогда сами составившие учебную программу. Но какие нюансы они учитывали? С чего начинали и к чему стремились? Какой язык учили в первую очередь? На эти и другие актуальные вопросы мы и постарались ответить.
К чему стремиться?
Перед походом в магазин вы составляете список покупок (хотя бы в голове). Перед поездкой в другой конец города – прокладываете маршрут. Ну а перед тем, как обучаться разработке игр, целесообразно задаться вопросом: чем именно вы хотите заниматься? Создавать мобильные приложения или браузерные игры? Трудиться в крупной компании или маленькой? Профессионально заниматься разработкой игр или посвящать этому свободное от работы время? И если первое, то что интересует вас больше: создание интерфейса, отшлифовка геймплея или написание скриптов?
Правильная постановка цели поможет сэкономить уйму времени и сил. Кроме того, позволит достичь конечного пункта кратчайшим путем. Без риска сойти с дороги или угодить в болото.
Какой язык учить?
Кроме того, от цели зависит и ответ на животрепещущий вопрос: с какого языка программирования стоит начинать?
Так, будущим разработчикам игр вроде Minecraft и мобильных приложений под Android стоит обратить пристальное внимание на Java. Для начала советуем пройти интенсив , тем более, что это бесплатно. Тем, кто заглядывается в сторону iOS – на Objective-C. Для браузерных игр порой хватает знания Ruby-On-Rails. Для совсем маленьких и простых временами достаточно HTML. В производстве Flash-игр используется ActionScript, а для написания скриптов любой сложности вам понадобится JavaScript или, возможно, не столь распространенная Lua. Для создания же небольших консольных игр требуется знание C#.
Что до наиболее крупнобюджетных игр (так называемого класса AAA), то большинство из них оснащены своим или заимствованным у коллег "движком". Нередко, впрочем, весь "движок" или его большая часть написана на C++. Именно этот язык использовался при создании множества известных "игрушек" – от Doom 3 и Call Of Duty до FIFA и The Sims. В то время как классика вроде Quake была написана на C.
Впрочем, в освоении C++ есть и загвоздка – чрезмерная сложность. Недаром ведь говорят, что браться за C++, не зная других языков, – все равно, что начинать изучение математики с линейных уравнений.
Достаточно ли одного языка?
Одна из прелестей программирования – возможность постоянного саморазвития. В разработке же игр (особенно крупных) самосовершенствование, в том числе изучение как можно большего количества языков, – не прихоть, а жизненная необходимость. Так, опытные разработчики, трудящиеся на благо гигантов игровой индустрии, нередко сталкиваются с необходимостью поочередно писать на 7-8 языках. При этом, помимо вышеуказанных языков, им приходится изучать, к примеру, Python либо и вовсе SQL (как вы понимаете, для создания баз данных).
Поэтому, если вы решили связать судьбу с производством крупных игр, будьте готовы стать "полиглотом". Кроме того, чем больше языков вы освоите, тем более интересные и разнообразные задачи перед вами поставят. Ну и, конечно, шансы на получение работы мечты заметно возрастут.
С ЧЕГО НАЧАТЬ?
Перед тем, как совершить кругосветное путешествие, нужно научиться ходить. Ну а перед серьезным игровым проектом необходимо попробовать силы в чем-то менее значимом.
Практически все опытные разработчики вне зависимости от регалий и таланта начинали с небольших приложений: настольных игр, вариаций известных "игрушек", простеньких "флэшек". Тогда они не думали о крупных выставках вроде E3, а накапливали бесценный опыт. Почему бы не последовать их примеру? При этом не обязательно писать архисложный код. Для дебюта достаточно использования специальных программ для создания игр (к примеру, Game Maker). Ведь даже благодаря несложному инструментарию вы значительно облегчите себе жизнь. Во-первых, в миниатюре поймете логику и структуру практически любого игрового приложения. Во-вторых, набьете шишки, которые заживут во время перехода к серьезным проектам. Наконец, в-третьих, обогатите портфолио. Ведь даже простая "игрушка" требует массу времени, терпения и творчества для выдумки концепции, написании кода и устранения багов. Кроме того, показывает, что с производством игр вы знакомы не только в сухой теории.
Что брать за ориентир?
Тот, кто мечтает стать писателем, прочитает сотни книг перед тем, как напишет хотя бы одно слово. Мастера игры на фортепиано на зубок знают лучшие произведения Штрауса, Шопена и Бетховена. Известные же художники перед крупными выставками наизусть заучивали историю искусств.
В разработке игр действует тот же принцип. Вы не сможете развиваться в вакууме. Поэтому играйте, вдохновляйтесь мастерами и, как губка, впитываете лучшее. При этом старайтесь смотреть на приложения не глазами "геймера", а взором разработчика. Иными словами: транспонируйте игру. Задумайтесь, почему в данный момент времени "бот" побежал налево, а не назад? Из-за каких факторов меняется сила и точность удара в спортивном симуляторе? Как создать "эффект усталости" при долгом беге персонажа? Как сделать так, чтобы во время дождя игрок слышал звук капель, а не свиной визг? В общем, проникайте в суть. Постарайтесь воссоздать в голове алгоритмы, с которыми сталкиваетесь во время игры. Поверьте, подобный конструктивный подход поможет вам в будущей нелегкой, но чертовски увлекательной карьере разработчика игр.
Пост о воплощении мечты и о создании игры с нуля. И о граблях разной величины.
0. Дано
Когда-то, во времена не столь от нас отдаленные, когда интернет в Уфе был ещё с помегабайтной оплатой, я занимался созданием и разработкой локальных «фришных» серверов Lineage и WoW. Но вот появились безлимитные тарифы, а локальные сервисы начали терять свою актуальность и я ушёл в вебразработку.
В некотором роде, как хобби я даже сохранил своё отношение в Геймдеву, правда, с другой стороны – разработка ботов и всего такого.
Шли года, а мысль написать что-нибудь свое, с преферансом и поэтессами не переставала меня терзать. В какой-то момент я понял, что либо сейчас, либо уже никогда.
1. Идея и Прототип
С чего начинается разработка? C прототипа. А прототип - с идеи. Для первого проекта стоит создать что-то небольшое и простое. Питая любовь к головоломкам и пошаговым стратегиям, я увлекся мыслью, что нужно сделать какую-нибудь пошаговую головоломку. Поразмыслив, вспомнил одну интересную игру времён Спектрума (стоит отметить, что автор не так стар, как может показаться) идея которой была прекрасна в своей простоте. Игрок ходит на 1 клетку, обходя препятствия, а враги его преследуют и ходят на 2 клетки, но препятствия не обходят.
Если взять ситуацию “A,” то мы можем спокойно ходить вверх и вниз, а монстр просто будет упираться в стену. В ситуации “B” монстр находится в загончике, а мы можем спокойно ходить справа, сверху и снизу от него. Поскольку игра у нас детерминированная, то существуют два типа монстров, которые отличаются по цветам и алгоритму поиска пути. Это для того чтобы не было неопределённости куда пойдёт монстр, когда он стоит наискосок. Красный всегда сначала сокращает расстояние до нуля по оси X ситуация “C”, в ней монстр зайдёт в загончик и упрётся в стенку. Фиолетовый же по оси Y ситуация “D”, в ней монстр пойдёт вниз, а потом уже направо и съедает главного героя.
Тут ещё мог бы быть большой абзац про выбор «движка» для написания игры. Но, пожалуй, можно обойтись и парой слов; перед тем как попробовать Unity3D, я поковырялся в нативном Obj-C, Corona SDK, UE, Cocos2d и ещё пару 2D Фреймворках, название которых, так глубоко в стеке памяти, что уже и не откопать.
В итоге, выбор пал на Unity3D, он мне показался оптимальным и я неспешно начал писать. Через месяц появилось вот такое приложение для iPad.
В нём мы играли за мужичка в красном и убегали от мужичков в синем, параллельно собирали сердца – читай звезды. В тот момент мы ещё использовали кубы как стены, но затем для экономии пространства на экране заменили их.
Хотелось бы отметить, что до этого момента, я никогда не писал на C#, но писал на JS, поэтому прототип был написан UnityScript (это такой диалект JS в рамках Unity3D). И это были первые большие грабли, послужившие нам уроком. Пришлось переписывать всё на C# и это заняло пару месяцев.
2. Команда
Как верно то, что я писал на десятке языков, так верно и то, что я не в состоянии нарисовать даже прямую линию. Поэтому после создания прототипа я начал искать художника\3Dшника, для этого я зашёл на сайт по фрилансу и посмотрел первых три сотни человек, с десятком - списался. Найти человека, за долю в довольно рискованном проекте, задача не из легких. Но она разрешилась, и в проекте появился талантливый художник Рамиль; итак – нас стало двое.
Параллельно я искал инвестора. Дело не в отсутствии денег, чтобы купить плагины или устройства для теста, а в том, чтобы создать обязательства, которые помогут не забить (не сложить с себя полномочия) при определенных обстоятельствах. И такой инвестор нашелся, в виде друга, решившего вложить свои кровные, в эту сомнительную, как ему казалось, затею. Итак, нас стало трое. Отмечу, что к моменту запуска, бюджет игры составил всего около 100.000р., при этом, в эту сумму входит покупка нескольких Android устройств для тестирования, плагинов и озвучки.
3. Расширение базовой концепции игры
С самого начала предполагалось, что невзирая на то, что игра будет максимально простой, необходимо будет привнести несколько новых идей в базовую концепцию. Так у нас появились односторонние телепорты (позже станет ботинком), ловушки и одноразовые грибы съедающие тех кто к ним подойдёт.
Концепт Арт
Основной фишкой игры мы планировали сделать то, что персонаж может вернуться во времени, на несколько ходов назад. Т.е. не отмену хода, а возможность переместиться 1 раз за уровень на клетку, где персонаж был 3 хода назад. Это давало огромное количество вариантов хода, но на первых же тестах выяснилось, что обычные игроки не в состоянии пройти такие уровни. Слишком сложно. Может стоить таки сделать Brainiac Edition?
Также мы много экспериментировали с размером уровней, в итоге остановились на том что весь уровень должен вмещаться на экран, даже на устройствах с небольшим экраном. Так у нас получились уровни 5х8 клеток. Но при этом у нас есть pinch zoom, для большепальцых или уровней 6х10. Кроме сокращения размера уровней, отключения возврата во времени, для упрощения была ещё добавлена отмена хода, до 5 раз за попытку.
4. 2D vs 3D
В какой-то момент наши тестовые билды выглядели так:
Ужас ужас
Приходило осознание того, что мы не в состоянии сделать картинку, которую мы хотели бы видеть в 3D с нормальным fps. Тестовая сцена для сравнения производительность 2D и 3D показывала не утешительные результаты.
Скриншоты из сцены
В итоге на iphone4, слева(3D) было всего 20 кадров в секунду, а справа(2D), стабильные 60. При этом, справа, качество картинки, как вы видите, на порядок лучше. Сейчас конечно если ориентироваться на минимальную производительность уровня iphone5+ и делать специально несколько квадратную графику, кошерные шейдеры + lightmapping + lightp robes, можно и для 3D сделать отличную графику
В итоге было принято решение всё переделывать на 2D. Но тут мы совершили ошибку, которую уже потом было не исправить. 2D анимация может быть 2 типов, первый это последовательность кадров, второй это наложение и смещение спрайтов.
Наглядное сравнение
Поскольку у нас были 3D модели, мы выбрали первый вариант. В итоге это выльется в большой вес приложения, даже с учётом огромного кол-ва оптимизаций мы не сможем уложиться в 50 мегабайт.
5. Форс-мажоры - это возможность
Не знаю можно ли назвать рождение ребёнка и переезды форс-мажорами, но именно эти события исключили нашего художника из работы над проектом, на несколько месяцев. Эти же обстоятельства сослужили службу и мне. В целях самообучения и познания тонкостей магазинов, я сделал другое небольшое приложение – обычную угадайку фильмов.
Для тех кто не понял о чём речь
На этом приложении я смог протестировать интеграцию с соц. сетями, несколько рекламных сетей, внутреннею аналитику и покупки внутри приложения.
6. Техническая часть
Думаю, настало время поднять градус гиковости. Значимую часть времени разработки заняло создание генератора уровней. Генератор писался на питоне, потому как он был мне духовно близок и numpy позволял быстро оперировать матрицами.
Сам генератор на выходе создавал txt файл(который парсился Юнити для создания сцены) и серию картинок, показывающих пошаговое прохождение уровня.
Сейчас я могу сказать, что писание внешнего генератора на другом языке, это - плохая идея. Главным образом, тем, что игровая логика начинает прописываться в двух разных местах. А это - риск рассинхрона. Особенно, если учесть, что внутри игры, есть такие понятия, как анимация и время её исполнения. И в генераторе, и в игре каждая клетка сама следила за тем, что в ней происходит: кто вошёл, кто вышел, кто умер и т.д. Но клетки, вида телепорт или мухобойка (атакует близлежащие клетки), связывали несколько клеток между собой. И если в генераторе это не вызывало проблем, то в игре повторить то же было сложнее т.к. анимации персонажей из разных клеток должны были засинхронизироваться между собой.
Огромный кусок времени заняла интеграция нативных библиотек. Cкажу прямо: если можно купить готовую реализацию того, что вам нужно, смело покупайте. При этом желательно всё брать у одного продавца, потому как в Unity3D в манифесте (Андроид), есть такая штука как mainactivity и это место где разные плагины могут конфликтовать. Потом для iOS, скорее всего, у вас будут плагины, которые занимаются различным постпроцессингом, это тоже место для конфликтов. В целом нативные либы, это место где вы легко можете получить очень трудно выявляемые ошибки. Поэтому, почти всё, что связанно с нативным кодом, мы покупали у Prime31.
Полный список плагинов и несколько слов о каждом
7. Статистика
В релизе около 400кб, написанного мной кода. Ещё 150кб - это генератор и некоторые смежные скрипты.
В самой игре, на данный момент, 3 главы по 16 отобранных уровней. Также есть режим Испытаний, где ещё около 700 уровней, динамически распределённых по сложности.
В среднем уровень без звёзд можно пройти за 25 ходов. Самые сложные уровни со звёздами около 55.
8. Монетизация и продвижение
Пока нет каких то точных цифр, но у нас как и у сайлонов есть план.
На примере угадайки фильмов мы поняли, что на рекламе можно заработать, только если у вас от 300к+ пользователей. Поскольку проект у нас, как ни крути нишевой, думаю это не вариант. Но при этом делать платное приложение для Андроида - самоубийство. В итоге была выбрана стандартная нынче модель: показ рекламы и продажа монет. С любой покупкой монет идёт в комплекте полное отключение рекламы. Монеты даются при прохождении уровней и за них можно узнать идеальное прохождение уровня.
Я определил, какие у движка должны быть библиотеки. Но то была больше теория. Сегодня я создал проект и применил теорию на практике. Вот что у меня получилось:
Вот так вот я организовал структуру своего движка. Давайте я рассмотрю подробней. Начну с папок. Всего создано шесть папок. Первая - _Doc, будет содержать ссылки на используемую документацию по движку (история, лист задач и т.д.). Фишка: обратили внимание на подчеркивание? Так вот, это сделано специально чтобы папка была в самом вверху и не смешивалась с папками движка (папки сортируются по имени).
Application - это уровень приложения. Как вы видите в ней всего один проект с тем же именем. Данный проект - это динамическая библиотека (подробнее о видах библиотек можете прочитать http://ru.wikipedia.org/wiki/Библиотека_(программирование)). Пользователь в идеале должен будет работать только с этой библиотекой.
Папка Core - это основа из схемы. Она содержит 4 проекта. Каждый проект - это статическая библиотека.
Папка Engine - это ядро из схемы. Все проекты из папки, также являются статическими библиотеками.
Папка Framework пуста, потому что пока нет смысла в ней что-то делать.
И папка Test будет хранить приложения для тестирования частей движка.
То есть в итоге у нас одна динамическая библиотека, одинадцать статических которые будут линковаться к динамической. И проект.
Я не стану пояснять как я создал такой проект, так как это долго. Да и не расчитанно на новичков.
На этом подготовка завершена. Продолжим.
Любое приложение должно с чего-то начинаться. Это называется точкой старта (или входа) приложения. Обычно это или main() или WinMain(), а также все их производные... Но в движке нет точки старта, потому что движок не запускается сам по себе. Точку старта задает пользователь при создании приложения. Но я начну именно с нее проектировать и писать код. Наша точка старта будет в приложении test.
Пользователь должен при старте, создать наследника от класса Application, полиморфировать нужные методы, инициализировать наследник, запустить его на выполнение и затем очистить ресурсы.
То есть получается так:
Поясню. Start - это условный момент запуска приложения. End - это условный момент завершения приложения. WinMain и MyApplication - это уровень приложения. Данные сущности пишутся пользователем. iApplication - это интерфейс из библиотеки Application. Как вы видите, я выделил их цветом согласно схемы из предыдущей статьи. Я так буду поступать и дальше чтобы вам было легче ориентироваться.
Начнем писать код. Для начала создадим класс приложения. Находим Application и пишем:
Application.h
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#include "export.h"
Class ENGINE_DLL Application
{
public:
Application();
virtual ~Application();
// Инициализация приложения.
bool Create();
// выполнение одного кадра
bool RunOneFrame();
// Выполнение приложения.
void Run();
// Завершение приложения.
void Shutdown();
Bool IsInit(){return _isinit;}
bool IsExit() {return _exit;}
Protected:
virtual bool _init() = 0;
// пользовательский кадр
virtual bool _frame() = 0;
// пользовательская очистка
virtual void _close() = 0;
Private:
bool _isinit;
bool _exit;
};
Application.cpp
200?"200px":""+(this.scrollHeight+5)+"px");">
#include "Application.h"
Application::Application() :
_isinit(false),
_exit(false)
{
}
Application::~Application()
{
// чистим за нерадивым программистом
if (_isinit==true)
Shutdown();
}
Bool Application::Create()
{
/*
Инициализация всех систем движка
*/
// пользовательская инициализация
if (_init() == false)
return false;
// сообщаем что приложение инициализировано
_isinit=true;
// сбрасываем флаг сообщающий о выходе
_exit = false;
return true;
}
Bool Application::RunOneFrame()
{
// следим чтобы не было попытки рисовать при неудачно инициализации
if (_isinit == false)
return false;
Return _frame();
}
Void Application::Run()
{
// Инициализируем
if(_isinit == false)
Create();
// выполняем бесконечный цикл
while (_exit==false && _isinit==true)
{
_exit = !(RunOneFrame());
}
// очищаем ресурсы
Shutdown();
}
Void Application::Shutdown()
{
_isinit = false;
}
Если вам нужен файл export.h, то он такой:
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#ifdef WIN32
#ifdef _BUILD_ENGINE
#define ENGINE_DLL __declspec(dllexport)
#else
#define ENGINE_DLL __declspec(dllimport)
#endif
#else
#define ENGINE_DLL
#endif
При этом, где-то в Application должен быть объявлен _BUILD_ENGINE. В проекте на который я дал ссылку выше, все это уже есть.
Теперь вернемся к приложению:
main.cpp
200?"200px":""+(this.scrollHeight+5)+"px");">
#include
#include "../Application/Application.h"
Class MyApp: public Application
{
private:
protected:
// пишем пользовательские классы
virtual bool _init() { return true; }
virtual bool _frame() { return true; }
virtual void _close() {}
};
Int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pScmdline, int iCmdshow)
{
MyApp app;
Return 0;
}
Собственно вы уже можете собрать (но не забудьте прилинковать Application). Но запускать не советую - уйдет в бесконечность:) Мы ведь еще условий выхода не написали.
Так, теперь двигаемся дальше. Вспомним для чего нам был нужен Application - для обертывания остальных сущностей. Среди которых главной была Engine. Значит теперь ее нужно создать. Далее, по текущей задаче мы должны создать окно и инициализировать рендер. Значит в модуле рендера появляются два класса - Window и Render. Но так как мы решили что сущность рендера абстрактна, то тогда нужен еще один класс RenderDX11 и WindowWin32, которые будут выполнять реализацию использования в рендере DirectX 11 в окне операционной системы Windows.
Схема усложняется:).
Начнем выполнение с конца. Находим библиотеку рендера и пишем код:
Window.h
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#include
Class Window
{
public:
Window();
virtual ~Window();
/// Создать окно
virtual bool createWindow(const std::wstring &caption, unsigned int width, unsigned int height)=0;
/// Закрыть окно.
virtual void closeWindow()=0;
/** Показать/Скрыть окно.
@param
value определяет, показывать ли окно (при true) или не показывать.
*/
virtual void showWindow(bool value)=0;
/// Вернуть заголовок окна
virtual const std::wstring& getWindowName() const {return _caption;}
/// Изменить заголовок окна.
virtual void setWindowCaption(const std::wstring& _caption)=0;
Protected:
std::wstring _caption; ///< заголовок окна
unsigned int _width; ///< ширина клиентской части окна
unsigned int _height; ///< высота клиентской части окна
};
Window.cpp
200?"200px":""+(this.scrollHeight+5)+"px");">
#include "Window.h"
Window::Window()
{
_width = 800;
_height= 600;
_caption = L"Engine";
}
Window::~Window()
{
}
Теперь нам нужен класс Render. Но тут я хочу сказать вот что - наш рендер должен быть единственным. Реализуем мы это через паттерн синглтон (погуглите, кому интересны подробности, прям по запросу "паттерн синглтон"). Так что сначала надо написать сам паттерн. Переходим к библиотеке Common. и пишем:
macros.h
200?"200px":""+(this.scrollHeight+5)+"px");">#pragma once
#include
#define Assert(a, b) assert(a && b)
Singleton.h
200?"200px":""+(this.scrollHeight+5)+"px");">
#pragma once
#include "macros.h"
/** Singleton pattern implemented using templates.
@remarks
Using singleton is useful for objects such as engine
or managers which should have no more than a single
instance in the whole application.
@remarks
If you want to make object of some class singleton you
have to derive this class from Singleton class.
@remarks
If something goes wrong during singleton object creation,
deletion or on attempt to access it, assertion arises.
By "something going wrong" I also mean attempts to create
more than single object of class marked singleton.
*/
template
class Singleton
{
public:
/** Creates singleton of type T.
*/
Singleton()
{
Assert(!s_pSingleton, "Singleton class already instantiated.");
#if defined(_MSC_VER) && _MSC_VER < 1200
int offset=(int)(T*)1-(int)(Singleton
s_pSingleton=(T*)((int)this+offset);
#else
s_pSingleton=static_cast
#endif
}
Virtual ~Singleton()
{
s_pSingleton=0;
}
/** Returns reference to a singleton.
*/
static T& getSingleton()
{
Assert(s_pSingleton, "Singleton class not instantiated.");
return(*s_pSingleton);
}
/** Returns pointer to a singleton.
*/
static T* getSingletonPtr()
{
return s_pSingleton;
}
/// A static pointer to an object of T type.
/// This is the core member of the singleton.
/// As it is declared as static no more than
/// one object of this type can exist at the time.
static T* s_pSingleton;
};
Template
Паттерн не мой, поэтому сохранен язык оригинала:-D
Вообщем, я к сожалением на сегодня на этом завершаю:-(Хотел бы написать дальше, но 12 часов - пора спать. Ждите до завтра, будет продолжение. Мы наконец-то создадим окно и инициализируем движок.
Приветствую. Хотите узнать как создать игру самому и какие бывают этапы создания игры? В наше время чтобы создать простую игру на PC или телефон не обязательно нужно быть в этом большим специалистом, существуют специальные программы, которые позволяют создавать игры с нуля в одиночку.
В этой статье весь мой личный опыт
Конечно, качество такой игры, если у вас нет опыта и знаний, может быть очень низким, но все с чего-то начинали. В этой статье вы узнаете что вам нужно чтобы создать игру и какие есть основные этапы создания игры.
Куда больше материалов вы можете найти на специальной странице в этом блоге:
Я выделил 7 основных этапов создания игры.
Как создать игру самому?
Для создания игры вам нужно знать язык программирования, а сейчас все они на английском, да и они сложные, там есть свой, так называемый синтаксис, который тоже нужно знать. Так вы себе представляете создание игры, верно?
Не совсем.
Конечно, почти все высоко бюджетные игры делаются с помощью одного из ключевых языков, однако для новичка даже этого знать не обязательно.
Существуют специальные программы для создания игр, одной из которых является Game Maker. Они были созданы специально для создания игр (программа так и называется - создатель игр). Лично я работаю в Game Maker и он позволяет делать вполне качественные игры под любые платформы, от андроида, до ios.
Так-же можно посоветовать Unity или Construct 2 , в качестве хороших альтернатив.
Лично моё мнение, Game Maker - одна из самых удобных программ для создания игр именно для новичков, тогда как освоение Unity с нуля может занять куда больше времени.
Если вы выбираете Game Maker - то мой блог и канал вам существенно помогут в его освоении, ну а если вам выбор остановится на Unity или чем-то еще, тотам тоже существует огромное количество бесплатных обучающих материалов высокого качества на Русском.
В любом случае, первый (нулевой:) этап - это выбор программы для создания игр.
Первый этап - дизайн документ
Далее вам нужно создать дизайн документ для новой игры. Другими словами - вам нужна идея игры. О чём будет игра? Что там будет происходить? Какой это будет жанр? Сколько времени и денег займёт разработка? Таких вопросов очень много и перед началом создания игры очень полезно составить какой-то примерный план.
Базовые вещи о том, как написать дизайн документ для игры, вы можете найти тут:
Ну не прям вот ужас, да? Плохо конечно, но не прям вот?
Ну вот, это я рисовал компьютерной мышкой в очень простом графическом редакторе, а учился рисовать я 1-2 месяца, рисуя по 1 картинке в неделю, максимум.
Я думаю за год можно выйти на очень неплохой уровень, если выделять по 1-3 часа в день на рисование и на изучение теоретической базы.
У меня есть видео (16 минут)
:
Там я рассказываю свои мысли о том как учиться рисовать и зачем это нужно.
Четвертый этап - звук
Звук и саундтрек в играх - очень важная часть, которая, однако, очень часто игнорируется начинающими разработчиками. Подумайте, у игрока, как и у любого человека, есть всего несколько основных органов чувств, а чем больше органов чувств в игре задействовано, тем лучше погружение игрока в процесс.
Сколько органов чувств задействовано у игрока?
Обоняние? Нет. Осязание? Иногда, что связанно с некоторыми системами управления в играх. Зрение? Вот на зрении всё и строиться, это основа.
Поэтому такая высокая важность графики и визуальных элементов. И по сути дела кроме зрения в играх можно задействовать еще только одно чувство - слух.
Если вы раньше играли в компьютерные игры, то у вас наверняка есть любимые, а так-же есть какой-то любимый OST (Музыка из игр). И игра вам могла запомниться именно за счёт музыки. Про мой любимый OST я писал вот тут:
Звуки - это еще один удар по органам чувств, звук сопровождающий действие может как-бы усиливать эффект от этого действия. Просто выстрел и вылет пули - скучно. Верный звук перезарядки, выстрела, столкновения пули с поверхностью (разные для разной поверхности), падение гильзы на пол и прочее существенно усиливают погружение игрока в процесс.
Вы же знаете про всякие специальные звуки и фразы в таких играх как Unreal Tournament и насколько сильно они увеличивают фан от игры.
Другими словами - верные звуки и музыка делают игру атмосферной, эмоциональной, человечной и куда более интересной.
У меня был небольшой опыт когда я делал игру Lonely Dude.
Тогда для этой игры мой знакомый написал уникальный OST, а остальные звуки я просто взял из бесплатных источников.
Что я хочу сказать? Для простой игры совершенно необязательно сильно заморачиваться со звуком, достаточно просто поместить в игру звуки для основных действий (выстрел, взятие бонуса, завершение уровня, прыжок и т.п.) и это уже существенно усилит общее впечатление от игры. Музыку написать конечно существенно сложнее, но иногда можно купить трек за каких-то $1-5, ну или посидеть с такими программами как FL Studio, дабы написать пару простых треков для своей игры.
Чем больше вы тестируйте (вы сами и ваши друзья, если вы инди разработчик), тем лучше игра получиться в момент релиза. Всего один баг где-то вначале игрового процесса способен испортить всё впечатление от игры, заставив игроков писать негативные отзывы.
Поэтому игру нужно допиливать напильником как можно более тщательно и делать это нужно до релиза. Как нужно тестировать игру?
Просто играйте в ней как можно больше и пробуйте разные варианты. Думайте как думал-бы игрок, а не как думает разработчик, который всё знает. Сажайте за игру вашу девушку и пусть играет она, записывайте какие у неё проблемы возникают и как она их решает, если вообще решает. Где затыки, где дисбаланс и где баги. Всё нужно поправить.
Седьмой этап - продажа игры и распространение
В любом случае, рано или поздно, вы свою игру доделайте, если вам хватит сил и упорства. Ну а дальше вы её продаёте, либо распространяете бесплатно, в любом случае вам-же хочется чтобы люди в ней поиграли?
Как это можно делать я уже писал в своей старой статье:
Общие принципы сохраняются практически для любой игры.
Паблики ВК, свой ютуб канал, трейлер, базовое понимание продвижения и поисковой оптимизации и всё такое прочее.
Всё это (как и каждый этап тут) - совершенно отдельная и большая тема, но задача данной статьи это ознакомление с процессом создания игр, не более того.
На этом всё. Надеюсь я ответил на ваш вопрос - как создать игру самому и осветил основные этапы создания игры. Делать игры - это очень увлекательная работа (или хобби), а так-же реальная возможность заработать.
Удачи вам в этом нелёгкое деле!
