На чем писать игры: На каких языках программирования пишут игры

Содержание

Как начать писать игры / Хабр

Оригинал: Starting out on Game Programming

Путь в индустрию игровых разработок не близок. Эта статья призвана помочь понять с чего лучше начать это путешествие.

Вы только что закончили ваш первый курс по С++ и хотите начать делать игры. Кто-то указал вам на этот сайт и вы, возможно, поэкспериментировали немного с руководством. Вы изучили несколько лаконичных примеров, но не нашли руководства о том, как сделать целую игру. И на то есть причина.

Руководства хороши для обучения чему-то шаг за шагом, например тому, как перемещать изображение точки по экрану. Для того чтобы собрать игру воедино, вам нужны навыки решения возникающих проблем, приобретаемые лишь с опытом. Это не то, чему можно научиться из руководств. Лучший способ научиться делать игры — это начать их делать.

Выбор проекта

Итак, с чем же начать? Проще ответить с чего начинать не стоит, а именно с больших проектов, типа полноценной 3D FPS, MMO или даже длинного платформера 16-битной эпохи. Самая распространенная ошибка начинающих разработчиков это начать с большого проекта основанного на Крутой Идее или взять проект, который кажется простым, и закончить с полузаконченной кучей спагетти-кода. Поначалу следует создавать небольшие проекты.

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

Поэтому помните: не подлетайте слишком близко к солнцу на ваших новых программистких крыльях.

Принимая во внимание все выше написанное, вот пара советов с чего начать.

Графика и обработка событий

Если вы никогда не программировали ничего связанного с графикой или GUI, вам следует начать с чего то маленького, чтобы «обмочить ноги». Моим первым проектом были крестики-нолики, так что даже у меня было скромное начало. Пара идей для первого проекта:

Симулятор однорукого бандита

Black Jack

Крестики-нолики

Четыре в ряд

Цель вашего первого проекта перейти от консольной разработки к разработки событийных графических приложений. Он так же научит вас фундаментальным основам игровой логики и архитектуры. Я рекомендую что-нибудь пошаговое, потому что игры с движением это совсем другой зверь.

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

Есть один момент, на который я хочу указать тем, кто будет делать крестики-нолики или четыре в ряд. Не стоит сейчас сильно беспокоиться об искусственном интеллекте. Сделать игру только для двух игроков или для игры с компьютером, который делает случайные ходы вполне достаточно для начала.

Если до этого вы имели дело с графикой и обработкой событий и чувствуете себя комфортно в этой области, можете приступить прямиком к следующему шагу.

Синхронизация, движение, столкновения, анимация

Теперь, когда вы наигрались с графикой, пора заняться чем-нибудь в реальном времени. Вот пару предложений:

Здесь вы познакомитесь с движением, временем, анимацией, обнаружением столкновений, игровым циклом, вычислениями очков, побед и поражений и другими важными базовыми концепциями используемыми в каждой игре.

Duck Hunt и Pong — хорошие проекты для тех, кто уже имеет опыт в программировании графики и событий. В них есть простое обнаружение столкновений и все важные основы игр в реальном времени.

Space Invaders и Galaga — хороший выбор для второго/третьего проекта. В них есть уровни, поэтому вам нужно будет узнать как передвигаться от уровня к уровню, при помощи конечного автомата. Вы можете прочитать про конечные автоматы здесь(англ.). Игры в стиле «перестреляй их всех» так же требуют создать простые шаблоны поведения для врагов, что является шагом в сторону искусственного интеллекта.

Тетрис хорош для второго/третьего проекта. В нем совсем немного логики нужной для создания игры-головоломки. Это игра приличного размера, так что вам придется научиться разделять вашу программу на несколько исходных файлов, о чем вы можете больше прочитать здесь(англ.). Не недооценивайте Тетрис. Я недооценил и только посмотрите на это жуткое месиво в коде Lazy Blocks.

Переинженеринг

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

Когда я был начинающим я переинженерил AI для крестиков-ноликов. Я хотел сделать игру с непобедимым AI. Мне удалось достигнуть этого, запрограммировав компьютер на знание всех возможных ловушек. Звучит круто не правда ли? Это заняло почти 40 000 тысяч строк в основном скопированного кода и месяц моего свободного времени.

Позже я выучил структуры данных и узнал про алгоритм Минимакс, который при меньшем размере кода не только делал нужное, но еще и делал это лучше.

Так что учитесь на моих ошибках и не будьте излишне амбициозны. Концентрируйтесь на обучении тому как делать игры, а не просто делайте их.

Планирование, анализ столкновений, физика, уровни, искусственный интеллект

Теперь, когда у вас за плечами две или три маленьких игры, пришло время сделать первый крупный проект.

До сих пор, вы, вероятно, программировали как придется. Это закончится на этом этапе. В реальном мире большинство процессов разработки завершается до того, как будет написана первая строчка кода. Ничто не может быть хуже, чем осознание того, что для того чтобы добавить в вашу игру то, что вы хотите, вам придется выкинуть весь написанный код, потому что вы не спланировали все заранее. Теперь, когда у вас есть опыт создания игр, вы знаете из чего состоит процесс разработки. Теперь вы можете планировать игры, перед тем как начинать их делать.

Теперь про вашу следующую игру. Break Out и Puzzle Bobble хороши для третьего проекта, потому что они включают в себя продвинутое распознавание столкновений и физику. Физика важна, поскольку дает игре реалистичное ощущение. Даже в Super Mario Brothers есть ощущение гравитации и инерции. Бильярд отличный проект для тех, кто хочет напрячь извилины физикой.

В играх типа бильярда вам нужно не только обнаруживать столкновения, но и обрабатывать их в определенном порядке. Обработка столкновений разительно отличается от их обнаружения. Хотя создание бильярда или 2D платформера может показаться простым делом, анализ столкновений в правильном порядке — запутанный процесс, и не должен быть недооценен.

Break out и Puzzle Bobble так же включают дизайн уровней и требуют загрузки и освобождения их ресурсов. Хорошим опытом будет создание редактора уровней для игры. Редакторы позволяют вам легко создавать уровни и не вынуждают впаивать их в приложение. У меня есть статья(англ.) про создание редактора уровней.

Так же вы возможно хотите попрактиковаться в написании искусственного интеллекта (AI). Один из вариантов — вернуться к крестикам-ноликам или четырем в ряд и написать непобедимый AI. Теперь вы уже должны знать структуры данных и сможете использовать знания о деревьях для использования алгоритма Минимакс. С этим алгоритмом вы можете просчитать все возможные исходы крестиков-ноликов и создать непобедимый AI. Забавно расстраивать им своих друзей. Так же вы возможно захотите сделать разные уровни сложности. Игра не приносит радости, если в нее нельзя выиграть.

Pac Man — отличный способ попрактиковаться в написании AI. Нужно будет знать структуры деревьев/графов и алгоритмы поиска, типа A*, для того чтобы призраки могли пройти через лабиринт. Так же нужно будет сделать чтобы призраки работали в команде. Все это пригодится когда вы будете делать игры со сложным AI, типа стратегий в реальном времени. Об основах AI можно прочитать тут(англ.).

Платформеры, Action/Adventure, RPG, RTS, движки

Теперь, когда вы получили опыт создания хорошо спланированной игры, вы готовы к созданию Action/Adventure/Платформера. Это будет кульминация графики, движения, анимации, анализа/обнаружения столкновений, физики, AI, программной архитектуры и всего остального, что вы изучите к этому моменту. Тем кто более амбициозен, можно предложить сделать стратегию в реальном времени(RTS) или ролевую игру(RPG). Будьте осторожны, потому что RPG и RTS действительно огромные проекты.

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

RTS также сложны архитектурно, а так же требуют много AI. Вам нужно будет делать поиск пути для юнитов, получение ими команд, разное поведение в зависимости от полученных команд. Если вы никогда до этого не делали AI, будет лучше начать с клона Pac Man’а для начала.

Вероятно вам впервые придется делать движок для вашей игры. Чего следует избегать, так это создания универсального движка. Создавая движок не пытайтесь сделать его подходящем для любой игры. Если ваша игра требует x, y и z, делайте движок который умеет x, y и z. Движки создают исходя из того что нужно для конкретной игры, а не из того что любой игре может потенциально понадобится.

Другая распространенная среди новичков ошибка — это попытка создать движок в качестве первого проекта. И обычно это универсальный движок. Вам не нужен движок с фантастической графикой для создания Pong’а или Space Invaders. Программируя, легко закопаться в деталях. Концентрируйтесь на общей картине и завершайте свои игры.

Сеть

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

Добавление сети значительно усложняет игру. Когда один игрок что-то делает, вы должны послать информацию об этом всем остальным. Это все равно что если бы ваша правая рука не знала о том, что делает левая. Так же вам придется выбирать между загрузкой сервера и тем что он может контролировать. Чем больше делает серверная часть, тем меньше возможностей жульничать у клиента, но это также означает большую нагрузку на сервер. Для action и других игр с высоким темпом геймплея, вам придется беспокоится о сетевой задержке и потере пакетов.

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

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

3D игры

Перед тем как делать 3D игры, вам следует сделать хотя бы одну хорошо спланированную игру и иметь хорошее понимание трехмерной векторной математики, линейной и Ньютоновской физики. Тут вам придется иметь дело с вершинами, текстурами, освещением, тенями, опредением взаимодействия с объектами в трехмерном пространстве, загрузку моделей и прочими сложно звучащими вещами.

Хорошая новость в том, что если вы уже сделали 4 или 5 игр, вы уже знаете основы необходимые для создания игры. Вы уже хорошо знакомы с процессом разработки и знаете свои возможности как программиста. Неважно трехмерный шутер или двухмерный, он по прежнему шутер. 2D RPG или 3D RPG по прежнему RPG.

Не считайте это оправданием пропустить 2D и сразу перейти к 3D. Прежде чем научиться бегать, нужно научиться ходить.

Быстрый способ

Говорите, что вы учитесь быстрее если сразу возьметесь за дело и будете просто писать вашу 3D MMOFPSRTSRPG и научитесь тому, что нужно по мере необходимости? Чтож, вот пару советов, которые вам помогут:

Идите на местный рынок

Купите целую рыбину. Рекомендую взять лосося или треску, хотя и сом тоже подойдет. Форель, кстати, тоже довольно эффективна

Идите домой и включите компьютер

Запустите вашу любимую IDE

Теперь возьмите купленную рыбу и влупите себе по голове

Повторите пункт 5, пока мысли о быстром способе не покинут вас

Вы не научитесь алгебре решая вычислительные задачи. Вы учите основы и опираетесь на них. Тоже самое и с программированием. Если вы ищите быстрый способ я тут как тут, чтобы сказать вам что его нет. Не торопите себя. Еще раз: учите основы и опирайтесь на них. Иначе вас ждет фиаско.

Путешествие начинается

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

Выберите свой темп

Доделывайте игры до конца

Концентрируйтесь на обучение, а не просто на создании

Удачи вам на пути разработки игр!

языки, движки и все, что нужно знать начинающему разработчику — руководства на Skillbox

Игровая механика — это то, какими способами игрок взаимодействует с миром. Совокупность игровых механик составляет игровой процесс. Например, вы уже реализовали возможность ходьбы и прыжков. Эта игра, скорее, платформер.

А если добавите механику получения опыта, повышения уровней, прокачки навыков, — игра станет походить на RPG. Механика — такая же важная составляющая игры, как и сюжет или графика.

Ещё один пример: вы написали сценарий к игре, в которой нужно сбежать из тюрьмы. Даже если игра будет самой линейной в мире, игровая механика может всё изменить:

если добавить стрельбу, то будет экшн;
если игрок будет безоружен, — стелс;
если ещё и замки нужно взламывать, то это уже головоломка или пазл.

Будучи программистом, придётся уделять много времени механике.

Раньше графика создавалась с помощью программного кода, потом придумали текстуры и спрайты, а для 3D-игр используются модели. Подготовив все текстуры и модели, нужно добавить их в игру.

В движке достаточно просто загрузить нужные файлы и прикрепить их к нужным моделям. Иначе — прописывать всё вручную, в том числе и анимацию.

Пример анимации двумерного персонажа

Для анимации 2D-объектов создаётся текстура по типу той, что на изображении выше. Она разбивается на равные части, которые сменяют друг друга. То есть игрок сначала видит первый кадр, который потом сменяется на второй, а затем на третий — это создает иллюзию движения.

Анимация в действии

Если брать 3D-модель, то используется скелетная анимация — модель как бы нанизывается на специальный каркас (скелет) с подвижными частями. Движение этих частей прописывается в коде.

На скриншоте видно, как персонаж сгибает руку в местах с точками (вершинами). Таких точек может быть очень много, если требуется сложная анимация — жесты, мимика и так далее.

Создаётся анимация так: прописываются точки координат или захватываются движения реального актера.

Первый способ сложный, но дешёвый, потому что от программиста требуется только прописать движения — сдвинуть точку A1 на координаты (50,240).

Второй проще, потому что достаточно одеть актеров в специальные костюмы с маячками, отснять это и перенести в игру. Но тут, конечно, придётся оплатить костюмы, павильон, работу операторов, постановщиков и актёров.

Инструкция начинающего разработчика игр / Хабр

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

Хочу отметить, что игры бывают разные – большие и маленькие, сложные и лёгкие, и поэтому для каждой игры эта инструкция верна в какой-то своей определённой степени. Охватить всё не удалось, но передать общие моменты, думаю, получилось.

И так Вы решили сделать свою игру, о чём Вам нужно подумать…

Думаем – нужно ли это тебе

Перед тем, как за что-то взяться, необходимо всё обдумать. А перед тем, как заняться разработкой игр, необходимо обдумать всё очень хорошо. Очень часто начинающие разработчики, достигнув определённых успехов в чём-то (сделал мод для игры, небольшой фан-сайт и пр.), начинают грезить созданием своей игры. Это происходит из-за того, что они имеют слабое представление о процессе разработки игр.

Я перечислю основные ошибки в их представлении:

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

Трудно и даже невозможно. Многие после нескольких (или даже одного) успешного проекта наполняются уверенностью, что написать игровой проект им по силам. На самом деле, игры – это одно из самых сложных направлений разработки. И чем «серьёзнее» игра, тем проект сложнее. В процессе создания игры разработчик может столкнуться с нерешаемыми проблемами, которые убивают на корню энтузиазм даже у самых упёртых.

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

Конкуренция и качество продукта. Играми занимаются многие студии и независимые разработчики. Существует своеобразный «уровень вхождения» в этот бизнес. Сейчас нельзя сделать успешную игру, нарисованную акварелью (да, такие игры встречались в начале 2000-х). Она просто не выдержит конкуренции. Соответственно, абы что не сделаешь. Тут скрывается важный психологический момент – начинающий разработчик вынужден делать хороший продукт, иначе он будет испытывать постоянное чувство страха неуспешности своего продукта.

Время и ресурсы. И самая распространенная ошибка – это то, что ресурсов (время, деньги, знания) им хватит. Чтобы понять объём работ, читайте следующие пункты.

Концепция и ТЗ

Когда-то давно я написал довольно неплохую статью о концепции проекта. За последние пару лет мои взгляды слегка поменялись, но суть осталась та же.

Что же такое концепция? Концепция игрового проекта — это документ, описывающий цели, задачи, основные особенности проекта, исследование рынка и целевой аудитории, условия его выполнения. Также, так как проект игровой, обязательно описание игровой механики, игровых понятий, примерный сценарий и концепт-арт. Если Вы ещё рассчитываете делать проект не в одиночку (что весьма вероятно), то понадобится ещё техническое задание (ТЗ) – документ, содержащий описание необходимых работ, сроки и условия.

Зачем нужна концепция? Очень хороший вопрос. Зачем заниматься какой-то «писаниной», когда нужно собирать команду и писать код?

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

Во вторую очередь концепция нужна для того, что бы другие поняли то, что Вы хотите сделать. Все члены команды должны работать над одним общим проектом. Об этом общем проекте члены команды узнают из документа концепции проекта. Это нужно, чтобы не было расхождений в представлениях о конечном результате. Если Вы решили создать игру и для этого собираете команду, то первые вопросы от будущих членов команды будут: «А что предстоит мне сделать? Что в итоге мы должны получить?». Вы должны будете им предоставить концепцию проекта и ТЗ. Без концепции и ТЗ Вы не привлечёте ни одного нормального специалиста.

Объёмы. Весьма интересен вопрос объёма концепции. Тут необходимо отталкиваться от сложности игры и её разработки. Если у Вас простая игра, Вы работаете один и Вы способны удержать идею игры в своей голове, то можно вообще не писать концепцию. Если удержать в памяти все моменты нельзя, то необходимо перенести их на бумагу (или другой носитель). Если Вы будете работать в команде или использовать помощь других людей (инвесторы, художники и прочие), то Вам просто необходима развёрнутая концепция и ТЗ для каждого человека. Критерий один – понятность. Нужно чтобы любой человек, ознакомившись с концепцией и ТЗ, представил конечный результат, так же как и Вы.

Обратите внимание на то, что, если Вы понимаете свою концепцию, то это не значит, что её поймут другие. Написание концепции выполняет роль «лакмусовой бумажки». Если Вы не можете написать понятную концепцию (примерно, 5 страниц для небольшой игры, несколько десятков страниц для большой), то вряд ли Вы закончите в итоге проект.

Детальность. В концепции должны быть ответы на все вопросы. После прочтения концепции должно сформироваться полное представление о проекте. Специалисты первым делом смотрят на концепцию, если концепция окажется для них не полной и непонятной, то они не будут с Вами работать.

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

Русский язык. Для многих это серьёзная проблема. Если документ концепции содержит множество грамматических, орфографических и синтаксических ошибок, то ни один специалист не воспримет его всерьёз. Помните: незнание русского языка очень вредит бизнесу.

Время. Желательно в сразу в ТЗ указать сроки выполнения работ. Проблема в том, как оценить это время, если никогда подобным не занимался. Точно ответа на этот вопрос Вы никогда не получите, всё придёт с опытом. Я только дам один совет: учитывайте не только время разработки, но и время на исправление ошибок (примерно 50% от времени на разработку).

Контент

Я специально выделил этот раздел, так как он является решающим в процессе разработки игр. Под контентом понимается всё содержимое игры, с которым взаимодействует пользователь. Это графика (растровая, векторная, 3D), музыкальное и звуковое сопровождение, видеоряд, сценарий и текст. Также сюда следует добавить медиаматериалы, используемые для продвижения игры (реклама, банеры и прочие).

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

Разберём основные моменты этого раздела.

Сложность. Это самая главная проблема в вопросе контента. Оказывается, в большинстве случаев подготовка контента является самой сложной задачей, сложнее написания программного кода, сложнее тестирования и отладки, и сложнее реализации игры. Естественно, если игра маленькая, то это не так заметно, а если большая, то на долю создателя контента выпадает до 80% работы по проекту.

Объёмы. Часто из-за того, что разработчики никогда не выполняли задачи создателей контента, им очень сложно оценить объёмы. Кажется, что там такого ¬– пара десятков картинок и 3-4 звука. Но если посчитать, то получается 40 крупноразмерных изображений, 400 мелких изображений, два десятка звуков (я привел пример среднестатистической BMMORPG). Хорошо, что это всё можно подсчитать при подготовке концепции.

Качество. Во-первых, надо понимать, что игроки работают непосредственно с контентом. Во-вторых, надо помнить, что существует огромное количество игр-конкурентов с хорошим контентом. Можно сделать вывод: игра с плохим контентом будет не конкурентоспособна, т.е. контент в игре должен быть высокого качества.

Время. Вполне логично, что на подготовку больших объёмов качественного контента уходит очень много времени. Времени уходит больше, чем на все остальные направления вместе взятые (маленькие игры не в счёт). Учитывайте это, когда будете планировать и рассчитывать сроки.

Стоимость контента. Хороший контент стоит «хороших» денег. Очень «хороших» денег, которых у начинающих разработчиков игр обычно нет. Многие разработчики питают иллюзорную надежду найти «бесплатного» создателя контента (или дешёвого). Найти можно, но он либо будет создавать низкопробный контент, либо создаст для Вас немного контента, а затем переметнётся к тем, кто будет ему платить. Короче говоря, «бесплатного» создателя хорошего контента Вы никогда не найдёте. Именно по этой причине нет хороших «OpenSource» игр.

Воровство. Из-за существования проблемы дорогого контента, иногда появляются разработчики игр, которые его воруют. Мол, что такого?.. возьму-ка я из этой игры десяток картинок, а фоновые изображения найду на DA, а в качестве фоновой музыки поставлю пару любимых песенок Rammstein. Проблема в том, что авторское право контента достаточно легко подтвердить. У «жертвы» воровства есть либо исходные файлы контента, либо документ о передаче контента от его создателя. Для воров контента очень велик шанс нарваться на статью 146 УК РФ.

Единый стиль. Ещё один важный момент, о котором часто забывают. Что бы игра смотрелась цельной и продуманной, ей нужно иметь единый стиль. Создатели контента не роботы, поэтому делают работы в своём индивидуальном стиле. Отсюда можно сделать вывод: желательно чтобы содержимое игры создавало как можно меньше человек.

Дилемма. После прочтения описанных выше моментов можно построить следующую цепочку: Конкурентоспособная игра требует использование качественного контента. Качественный контент может сделать только профессиональный создатель контента. Профессиональный создатель контента стоит недёшево. Решений данной проблемы всего лишь три:
1. Не делать игру, то есть отказаться от направления разработки игр.
2. Найти инвестора. Но тут сразу нас поджидает проблема концепт-арта. Кто будет подготавливать концепт-арт, если нет денег на художника? А без концепт-арта никто не будет инвестировать в Вас.
3. Решать проблему собственными силами. То есть кто-то из членов команды должен быть создателем контента и должен получать зарплату, даже если все остальные сосут палец.

Программирование

Как ни странно, создание программного кода для игр не является самой сложной задачей, но в тоже время и не является простой.

Команда. В отличие от создателей контента программистов для своей команды найти легко. Это объясняется тем, что при определённом уровне подготовки написание программного кода игры не такая уж сложная задача. Можно найти «бесплатных» программистов, готовых работать ради интереса. А за плату и «имя» (упоминание, как разработчика игры) можно найти программиста, который будет писать хороший годный код. Но… сейчас не начало 2000-х и программисты поумнели. Первым делом адекватный программист попросит разработчика продемонстрировать концепцию и ТЗ. Затем спросит про создание контента или финансирование, которое пойдёт на его создание. Специалисты прекрасно понимают, что незачем вкладывать силы в изначально провальный проект. Если у Вас нет концепции и не решен вопрос с контентом, то нормального программиста Вы не найдёте.

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

Что сначала контент или код? Прочитав раздел про контент, Вы уже, наверное, поняли, что современные игры основаны на контенте, а не на программировании. Отсюда дилемма – код подгонять под контент или контент подгонять под код. Оба подхода имеют место в современном процессе разработки. Если подгонять код под контент, то нагрузка падает на программиста, время разработки увеличивается. Это дешёвый способ. Если контент подгонять под код, то нагрузка с программиста спадает, и при учёте, что контент подготавливают наёмные работники, время разработки сокращается. Это дорогой способ, так как нагрузка падает на наёмных создателей контента. Заранее оцените ситуацию и придерживайтесь одного из подходов.

Нерешаемые ошибки. Это даже не проблема, а предубеждение. Разработка игры весьма сложный процесс. Бывает, что разработчик сталкивается с нерешаемыми проблемами (либо решаемыми крайне тяжело) и ему приходиться пересматривать чуть ли не весь проект. Психологически это очень трудно. Многие, даже самые упёртые разработчики, попав в такой «тупик», теряют энтузиазм и закрывают проект. Предубеждение в том, что все считают, что с ними такого не случиться. Совет один: будьте психологически готовы пересмотреть весь проект и выполнить работу заново.

Журналы. Совет лично от меня. Ведите три журнала:
1. Журнал выполненной работы по проекту для отслеживания динамики разработки;
2. Журнал идей по проекту, чтобы не забыть их и, если возможно, включить в концепцию;
3. Журнал найденных багов и ошибок, которые необходимо исправить в будущем.
Эти три журнала помогут избежать ошибок и двойной работы в процессе разработки.

Время. При определении времени, которое планируется на написание кода, часто делают одну ошибку – не учитывают затраты времени на исправление багов и отладку кода.

Авторство программного кода. Определённый «маразм» наблюдается, у некоторых программистов. Они считают, что обладают абсолютными правами на код, который ими написан, что даже после релиза игры они могут предъявить права на «часть кода» игры. Что бы защитить это «священное» право они могут пойти на всякие низости (программные бомбы, бакдоры, отказ от передачи исходных кодов и прочие). Мой совет прост – остерегайтесь таких неадекватных программистов. Программный код не контент. Доказать его авторство очень сложно. Поэтому нормальный программист сначала договаривается, что он получит за код; затем его пишет; потом передаёт разработчику и получает вознаграждение; после чего уже ни на что не претендует. Также должно быть организовано и в команде.

Тестирование

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

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

Женщины. Когда-то я написал неплохую статью про женщин и игры. Смысл в том, что женщины видят всё по другому. Поэтому, желательно, чтобы в тесте игры участвовала хотя бы одна женщина (девушка), даже если игра не рассчитана на женскую аудиторию. Их обратная связь будет невероятно полезна.

Организационные моменты

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

Конечно, можно заниматься разработкой и в одиночку. Есть такие «сумасшедшие», которые и пишут код, и рисуют графику, и сочиняют музыку, но это их проблемы.

Собрать команду при наличии финансирования легко – форумы программистов и создателей контента, биржи фрилансеров Вам в помощь. При отсутствии финансирования можно найти только программиста, а вот нормального создателя контента не найдёте – здесь надо надеяться либо на себя, либо на удачу.

Юридическое оформление. Здесь всё просто. Хотите иметь с игры деньги и обезопасить себя от рейдерского захвата (когда кто-то внаглую ворует вашу игру), то вам нужно юридическое оформление на уровне индивидуального предпринимателя. Если Вы ещё собираетесь распределять проект по долям, то нужно оформление на уровне ООО. Поэтому если при поиске членов команды Вы обещаете долю в проекте, то не удивляйтесь, что Вас будут просить предъявить реквизиты вашей организации.

Контакты. Никогда не пренебрегайте знакомствами. Знакомьтесь с другими разработчиками, общайтесь и обменивайтесь контактами. В будущем, возможно, знакомство с ними принесёт Вам пользу.

Реклама. Так как игр на рынке много, то чтобы пользователи выбрали именно вашу игру, нужно привлечь к себе внимание. Делается это при помощи рекламы на различных ресурсах. Логично, что реклама эта требует: во-первых денег, а во-вторых, рекламный контент (банеры, видеоролики, статьи). Возможны и другие способы ¬– связи, спам, рекламные акции и прочие, но они не всегда эффективны.

Без рекламы игра, точно также как и без контента, является провальным проектом. Обратите на это внимание. Но тут ситуация может достаточно легко исправлена инвестированием и сторонней помощью.

Инвестирование. Понятное дело, что с деньгами игру делать гораздо легче, но без развёрнутой концепции (с концепт-артом), команды и рабочего прототипа никто не будет финансировать ваш проект. То есть на начальных этапах на финансирование не надейтесь. А вот на последних этапах разработки ситуация может в корне поменяться – могут появиться инвесторы и Вам всё равно будут нужны деньги для организации рекламной компании.

Чтобы найти инвесторов, собирайте контакты.

Сторонняя помощь. Вместо инвесторов можно найти стороннюю помощь (реклама за рекламу, помощь в распространении за процент и прочие). Тут надо ориентироваться по ситуации. Чтобы найти стороннюю помощь, так же собирайте контакты.

Послесловие

Инструкция получилась большой, материала много. Крайне советую прочесть её начинающим разработчикам игр, так как, возможно, она поможет им избежать ошибок в будущем.

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

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

Я не собираюсь своей статьёй вселять в начинающих разработчиков уверенность. Они должны знать, что путь разработчика игр сложен, что они могут встретить нерешаемые проблемы, что их нерализованный проект будет для них символом поражения.

Разработка игр. С чего начать? | GeekBrains

Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться?

https://d2xzmw6cctk25h.cloudfront.net/post/25/og_cover_image/3fcc2b06afe428005c9026582ebcf7b2

Что должны учитывать будущие разработчики игр? С какого языка начать обучение? К чему стремиться? На кого равняться? И что необходимо сделать в первую очередь?

Большинство любителей рок-музыки рано или поздно берут в руки гитару. Фанаты спорта страстно мечтают о выходе на футбольное поле, баскетбольную площадку или теннисный корт. Ну а те, кто совершил сотни угонов в GTA, провел десятки часов в компьютерных клубах за Counter-Strike или достиг немалых успехов в MMORPG, наверняка задумываются о карьере разработчика игр.

Проблема в том, что данному направлению обучают в считанных учебных заведениях. Посему большинство разработчиков игр – самоучки, некогда сами составившие учебную программу. Но какие нюансы они учитывали? С чего начинали и к чему стремились? Какой язык учили в первую очередь? На эти и другие актуальные вопросы мы и постарались ответить.

К чему стремиться?

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

Правильная постановка цели поможет сэкономить уйму времени и сил. Кроме того, позволит достичь конечного пункта кратчайшим путем. Без риска сойти с дороги или угодить в болото.

Какой язык учить?

Кроме того, от цели зависит и ответ на животрепещущий вопрос: с какого языка программирования стоит начинать?

Так, будущим разработчикам игр вроде Minecraft и мобильных приложений под Android стоит обратить пристальное внимание на Java. Для начала советуем пройти интенсив «Основы 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). Ведь даже благодаря несложному инструментарию вы значительно облегчите себе жизнь. Во-первых, в миниатюре поймете логику и структуру практически любого игрового приложения. Во-вторых, набьете шишки, которые заживут во время перехода к серьезным проектам. Наконец, в-третьих, обогатите портфолио. Ведь даже простая «игрушка» требует массу времени, терпения и творчества для выдумки концепции, написании кода и устранения багов. Кроме того, показывает, что с производством игр вы знакомы не только в сухой теории.

Что брать за ориентир?

Тот, кто мечтает стать писателем, прочитает сотни книг перед тем, как напишет хотя бы одно слово. Мастера игры на фортепиано на зубок знают лучшие произведения Штрауса, Шопена и Бетховена. Известные же художники перед крупными выставками наизусть заучивали историю искусств.

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

Автор: Александр Мороз

Как создать игру без навыков программирования / Хабр

Мечтаете создать свою игру, но мысли о том, что придётся учить языки программирования пугают вас? Вы гуманитарий? А может, у вас просто не хватает времени на изучение C# или Java? В любом случае, речь в этом посте пойдёт об игровых конструкторах. Для тех, кто не в курсе, это программы, в которых можно делать игры без написания кода. Конструкторы подходят для создания прототипов и участия в коротких Game Jams, которые сейчас популярны.

Первое знакомство

Однажды мне довелось побывать на мастер-классе по прототипированию у одного известного левел-дизайнера, работавшего в одной из крупнейших IT-компаний в России. На мастер-классе каждому участнику предложили создать свою игру за 1 час, а в конце часа показать игру остальным. То есть я первый раз запускаю программу и через час должен создать игру? Обладая некоторым опытом работы в программах, где необходимо писать код, я не поверил, что такое возможно. К моему удивлению, все (я в том числе) успели сделать свою первую маленькую игру. Пусть и простую, но в нее можно было играть. Так во мне зародилась любовь к конструктору под названием Clickteam Fusion 2.5 (раньше назывался Multimedia Fusion). Ещё популярными конструкторами являются Game Maker Studio и Construct 2. В основном, я работаю в Clickteam Fusion 2.5 (далее CF 2.5). На её примере раскрою принцип работы таких программ и их возможности.

Как это работает

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

При создании новой игры необходимо определить, для какой платформы хотите творить. Конструкторы дают возможность создавать игры для PC, IOS, Android, Html 5, Flash и т.д. Например, чтобы создать игру не только для PC, но и для IOS в программе CF 2.5, придётся докупить или скачать export module ios. Модуль конвертирует игру в код платформы – Xcode. Затем, через несколько нажатий, вы уже сможете тестировать игру на устройствах Apple (также нужен аккаунт разработчика Apple).

Ваша игра будет состоять из кадров (сцен). В каждом кадре можно создавать объекты, которые помогут вам решить любую задачу. Например, если это главное меню и вы хотите создать кнопку «Start», вам необходимо создать объект «active».

Окно «Редактор кадра».

Нажимаем правую кнопку мыши и выбираем «Insert object».

Выбираем объект «active».

Затем, нужно вставить в объект изображение кнопки или нарисовать во встроенном редакторе. В этом окне также можно создать покадровую анимацию. Один объект может иметь несколько анимаций (герой стоит, герой бежит, герой летит).

Окно «Графический редактор».

Осталось придумать событие, которое будет происходить с этим объектом.

Для этого, переходим с вкладки «редактор кадра» на вкладку «редактор событий».

Выбираем из списка необходимые события (условия), при которых, произойдут установленные вами действия над выбранным объектом, группой объектов, кадром.

Если игрок нажимает левой кнопкой мыши на объект «Start», то —

— происходит переход на следующий кадр.

Вот так просто, без программирования, можно создавать различные события, из которых будет состоять ваша игра.

Ещё несколько примеров:

— Если объект «шар» коснулся объекта «шип», то на экране появляется надпись «вы проиграли», а объект «шар» меняет анимацию на «шар лопнул».

— Если прошло более 5 секунд с начала запуска кадра, то в правом верхнем углу появляется объект «аптечка».

— Если объект «птичка» коснулся объекта «червяк», то «червяк» исчезает, в объект «счётчик очков» прибавляется единица и один раз проигрывается звук «жалобный крик червя».

Не изучая программирование, вы сможете создавать самые разные механики, используя фантазию и большое количество вспомогательных объектов. Перечислю некоторые из них:

Active object – самый популярный объект, его используют для создания объектов взаимодействия (главный герой, враги, платформы, ящики и т.д.). Он может содержать много разных анимаций (герой стоит, герой бежит, герой стреляет), иметь встроенные стандартные механики движения и управления.

Counter object – создает всевозможные счётчики жизней, денег, очков и т. д. Может быть представлен как в виде цифр, так и в виде шкалы.

INI object – сохраняет данные после выхода игрока из игры. Можно использовать для сохранения месторасположения любых объектов в кадре.

Physic engine object – появление этого объекта в кадре создаёт гравитацию, параметры которой можно регулировать.

Joystick control object– для touch-устройств создаёт эмулятор джойстика.

IOS store object – даёт возможность сделать внутриигровые покупки для AppStore.

Admob object – позволяет поместить баннерную рекламу в игру.

Touch object – учитывает все касания к экрану touch-устройства. Например, можно создать такое событие:

если игрок одновременно коснулся экрана тремя пальцами, то игра останавливается на паузу.

Если что-то не получается

У CF 2.5 есть отличная техподдержка, которая в течение 24 часов всегда отвечала мне. Ещё у них неплохой форум, на котором выложено много готовых кусков игр и рассказывается, как работать с новыми объектами. Не знаю, как дела с технической поддержкой у других конструкторов, но думаю, не хуже. Game Maker более популярен, чем CF 2.5 и, как мне кажется, тоже должен иметь хорошую поддержку. Один мой знакомый работает на Construct 2, он никогда не слышал, чтобы возникали трудности. А на youtube.com выложено много роликов, где разжёвывают создания популярных механик для большинства конструкторов.

Список популярных игр созданных на конструкторах

Five nights at fraddy’s

Hotline miami

Uncanny valley

Hiper light drifter

Gods will be watching

Echo of the wilds

Arcane Soul

Savant – Ascent

Brazin’ Aces

Super Ubie Land

Airscape: The Fall of Gravity

Our Darker Purpose

Mortar Melon

Who Is The Killer (Episode I)

Magnrtized

The Next Penelope

Concert jungle

Fort meow

Pitiri 1977

Итог

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

Как написать собственный игровой движок на C++ / Хабр

Перевод статьи Джеффа Прешинга (Jeff Preshing) How to Write Your Own C++ Game Engine.

Как написать собственный игровой движок на C++

В последнее время я занят тем, что пишу игровой движок на C++. Я пользуюсь им для создания небольшой мобильной игры Hop Out. Вот ролик, записанный с моего iPhone 6. (Можете включить звук!)

Your browser does not support HTML5 video.

Hop Out — та игра, в которую мне хочется играть самому: ретро-аркада с мультяшной 3D-графикой. Цель игры — перекрасить каждую из платформ, как в Q*Bert.

Hop Out всё ещё в разработке, но движок, который приводит её в действие, начинает принимать зрелые очертания, так что я решил поделиться здесь несколькими советами о разработке движка.

С чего бы кому-то хотеть написать игровой движок? Возможных причин много:

Вы — ремесленник. Вам нравится строить системы с нуля и видеть, как они оживают.

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

Вам нравится ощущение контроля. Организовать код именно так, как вам хочется, и всегда знать, где что находится — это приносит удовольствие.

Вас вдохновляют классические игровые движки, такие как AGI (1984), id Tech 1 (1993), Build (1995), и гиганты индустрии вроде Unity и Unreal.

Вы верите, что мы, индустрия игр, должны сбросить покров таинственности с процесса разработки движков. Мы пока не очень-то освоили искусство разработки игр — куда там! Чем тщательнее мы рассмотрим этот процесс, тем выше наши шансы усовершенствовать его.

Игровые платформы в 2017-ом — мобильные, консоли и ПК — очень мощные и во многом похожи друг на друга. Разработка игрового движка перестала быть борьбой со слабым и редким железом, как это было в прошлом. По-моему, теперь это скорее борьба со сложностью вашего собственного произведения. Запросто можно сотворить монстра! Вот почему все советы в этой статье вращаются вокруг того, как сохранить код управляемым. Я объединил их в три группы:

Используйте итеративный подход

Дважды подумайте, прежде чем слишком обобщать

Осознайте, что сериализация — обширная тема.

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

Используйте итеративный подход

Мой первый совет — не задерживаясь заставьте что-нибудь (что угодно!) работать, затем повторите.

По возможности, начните с образца приложения, которое инициализирует устройство и рисует что-нибудь на экране. В данном случае я скачал SDL, открыл Xcode-iOS/Test/TestiPhoneOS.xcodeproj, затем запустил на своём iPhone пример testgles2.

Вуаля! У меня появился замечательный вращающийся кубик, использующий OpenGL ES 2.0.

Моим следующим шагом было скачивание сделанной кем-то 3D-модели Марио. Я быстро написал черновой загрузчик OBJ-файлов — этот формат не так уж сложен — и подправил пример, чтобы он отрисовывал Марио вместо кубика. Ещё я интегрировал SDL_Image, чтобы загружать текстуры.

Затем я реализовал управление двумя стиками, чтобы перемещать Марио. (Поначалу я рассматривал идею создания dual-stick шутера. Впрочем, не с Марио).

Следующим делом я хотел познакомиться со скелетной анимацией, так что открыл Blender, создал модель щупальца и привязал к нему скелет из двух костей, которые колебались туда-сюда.

К тому моменту я отказался от формата OBJ и написал скрипт на Python для экспорта собственных JSON-файлов из Blender. Эти JSON-файлы описывали заскиненный меш, скелет и данные анимации. Я загружал эти файлы в игру с помощью библиотеки C++ JSON.

Как только всё заработало, я вернулся в Blender и создал более проработанного персонажа (Это был первый сделанный и зариганный мной трёхмерный человек. Я им весьма гордился.)

В течение следующих нескольких месяцев я сделал такие шаги:

Начал выделять функции работы с векторами и матрицами в собственную библиотеку трёхмерной математики.

Заменил .xcodeproj на проект CMake

Заставил движок запускаться и на Windows, и на iOS, потому что мне нравится работать в Visual Studio.

Начал перемещать код в отдельные библиотеки «engine» и «game». Со временем, я разделил их на ещё более мелкие библиотеки.

Написал отдельное приложение, чтобы конвертировать мои JSON-файлы в бинарные данные, которые игра может загружать напрямую.

В какой-то момент убрал все библиотеки SDL из iOS-сборки. (Cборка для Windows всё ещё использует SDL.)

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

Этот подход итеративен, потому что фокусируется на небольших практических результатах. Он хорошо работает при написании игрового движка, потому что на каждом шаге у вас есть работающая программа. Если что-то идёт не так, когда вы выделяете код в новый модуль, вы всегда можете сравнить изменения с кодом, который раньше работал. Разумеется, я предполагаю, что вы пользуетесь какой-нибудь системой контроля версий.

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

Готов поспорить, что больше времени тратится при противоположном подходе: пытаться заранее продумать архитектуру, которая будет делать всё, что вам понадобится. Две моих любимых статьи про опасности чрезмерной инженерии — The Vicious Circle of Generalization Томаша Дабровски и Don’t Let Architecture Astronauts Scare You Джоэла Спольски.

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

Итеративный подход дал мне куда более элегантную архитектуру, чем я мог бы вообразить, глядя на чистый лист бумаги. iOS-сборка моего движка сегодня на 100% состоит из оригинального кода, включая собственную математическую библиотеку, шаблоны контейнеров, систему рефлексии/сериализации, фреймворк рендеринга, физику и аудио микшер. У меня были причины писать каждый из этих модулей самостоятельно, но для вас это может быть необязательным. Вместо этого есть множество отличных библиотек с открытым исходным кодом и разрешительной лицензией, которые могут оказаться подходящими вашему движку. GLM, Bullet Physics и STB headers — лишь некоторые из интересных примеров.

Дважды подумайте, прежде чем слишком обобщать

Как программисты, мы стремимся избегать дублирования кода, и нам нравится, когда код следует единому стилю. Тем не менее, я думаю, что полезно не давать этим инстинктам управлять всеми решениями.

Время от времени нарушайте принцип DRY

Приведу пример: мой движок содержит несколько шаблонных классов умных указателей, близких по духу к std::shared_ptr. Каждый из них помогает избежать утечек памяти, выступая обёрткой вокруг сырого указателя.

Owned<> для динамически выделяемых объектов, имеющих единственного владельца.

Reference<> использует подсчёт ссылок чтобы позволить объекту иметь несколько владельцев.

audio::AppOwned<> используется кодом за пределами аудио микшера. Это позволяет игровым системам владеть объектами, которые аудио микшер использует, такими как голос, который в данный момент воспроизводится.

audio::AudioHandle<> использует систему подсчёта ссылок, внутреннюю для аудио микшера.

Может показаться, что некоторые из этих классов дублируют функциональность других, нарушая принцип DRY. В самом деле, в начале разработки я пытался повторно использовать существующий класс Reference<> как можно больше. Однако, я выяснил, что время жизни аудио-объекта подчиняется особым правилам: если объект закончил воспроизведение фрагмента, и игра не владеет указателем на этот объект, его можно сразу же поместить в очередь на удаление. Если игра захватила указатель, тогда аудио-объект не должен быть удалён. А если игра захватила указатель, но владелец указателя уничтожен до того, как воспроизведение закончилось, оно должно быть отменено. Вместо того чтобы усложнять Reference<>, я решил, что будет практичнее ввести отдельные классы шаблонов.

95% времени повторное использование существующего кода — верный путь. Но если оно начинает вас сковывать или вы обнаруживаете, что усложняете что-то, однажды бывшее простым, спросите себя: не должна ли эта часть кодовой базы в действительности быть разделена надвое.

Использовать разные соглашения о вызове — это нормально

Одна из вещей, которая мне не нравится в Java — то, что она заставляет вас определять каждую функцию внутри класса. По-моему, это бессмысленно. Это может придать вашему коду более единообразный вид, но также поощряет переусложнение и не поддерживает итеративный подход, описанный мной ранее.

В моём C++ движке некоторые функции принадлежат классами, а некоторые — нет. Например, каждый противник в игре — это класс, и бо́льшая часть поведения противника реализована в этом классе, как и следовало ожидать. С другой стороны, sphere casts в моём движке выполняются вызовом sphereCast(), функции в пространстве имён physics. sphereCast() не принадлежит какому-либо классу — это просто часть модуля physics. У меня есть система сборки, которая управляет зависимостями между модулями, что сохраняет код достаточно (для меня) хорошо организованным. Заворачивание этой функции в произвольный класс никоим образом не улучшит организацию кода.

А ещё есть динамическая диспетчеризация, которая является формой полиморфизма. Часто нам нужно вызвать функцию объекта, не зная точного типа этого объекта. Первый порыв программиста на C++ — определить абстрактный базовый класс с виртуальными функциями, затем перегрузить эти функции в производном классе. Работает, но это лишь одна из техник. Существуют и другие методы динамической диспетчеризации, которые не привносят так много дополнительного кода, или имеют другие преимущества:

С++11 ввел std::function, и это удобный способ хранить функции обратного вызова. Также можно написать собственную версию std::function, не вызывающую столько боли, когда заходишь в неё в отладчике.

Многие функции обратного вызова могут быть реализованы с помощью пары указателей: указателя на функцию и непрозрачного аргумента. Требуется только явное приведение внутри функции обратного вызова. Это часто встречается в библиотеках на чистом C.

Иногда базовый тип известен во время компиляции, и можно привязать вызов функции вообще без накладных расходов времени выполнения. Turf — библиотека, которой я пользуюсь в своём игровом движке, сильно полагается на этот способ. Взгляните на turf::Mutex для примера. Это просто typedef над платформо-специфичными классами.

Иногда самый прямой путь — создать и поддерживать таблицу сырых указателей на функцию своими силами. Я использовал этот подход в своих аудио микшере и системе сериализации. Интерпретатор Python также на полную использует эту технику, как будет показано ниже.

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

Динамическая диспетчеризация — обширная тема. Я лишь поверхностно рассказал о ней, чтобы показать как много способов реализации существует. Чем больше растяжимого низкоуровневого кода вы пишите — что не редкость для игрового движка — тем чаще обнаруживаете себя за изучением альтернатив. Если вы не привыкли к программированию в таком виде, интерпретатор Python, написанный на C — отличный пример для изучения. Он реализует мощную объектную модель: каждый PyObject указывает на PyTypeObject, а каждый PyTypeObjeсt содержит таблицу указателей на функцию для динамической диспетчеризации. Документ Defining New Types — хорошая начальная точка, если вы хотите сразу погрузиться в детали.

Осознайте, что сериализация — обширная тема

Сериализация — это преобразование объектов времени выполнения в последовательность байтов и обратно. Другими словами, сохранение и загрузка данных.

Для многих, если не большинства, движков игровой контент создаётся в разных редактируемых, таких как .png, .json, .blend или проприетарных форматах, затем в конце концов конвертируется в платформо-специфичные форматы игры, которые движок может быстро загрузить. Последнее приложение в этом процессе часто называют «cooker». Cooker может быть интегрирован в другой инструмент или даже распределяться между несколькими машинами. Обычно, cooker и некоторое количество инструментов разрабатываются и поддерживаются в тандеме с самим игровым движком.

При подготовке такого пайплайна выбор форматов файлов на каждой из стадий остаётся за вами. Вы можете определить несколько собственных форматов, и они могут эволюционировать в процессе того как вы добавляете функциональность в движок. В то время как они эволюционируют, у вас может возникнуть необходимость сохранить совместимость некоторых программ с ранее сохранёнными файлами. Не важно в каком формате, в конце концов вам придётся сериализовать их в C++.

В C++ есть бесчисленное множество способов организовать сериализацию. Один из довольно очевидных заключается в добавлении функций save и load классам, которые вы хотите сериализовать. Вы можете добиться обратной совместимости, храня номер версии в заголовке файла, затем передавая это число в каждую функцию load. Это работает, хотя код может стать громоздким.

    void load(InStream& in, u32 fileVersion) {
        // Загрузить ожидаемые переменные-члены
        in >> m_position;
        in >> m_direction;

        // Загрузить более новую переменную только если версия загружаемого файла больше 2.
        if (fileVersion >= 2) {
            in >> m_velocity;
        }
    }

Можно писать более гибкий, менее подверженный ошибкам код сериализации, пользуясь преимуществом рефлексии — а именно, созданием данных времени выполнения, описывающих расположение ваших C++ типов. Чтобы получить краткое представление о том, как рефлексия может помочь с сериализацией, взглянем на то, как это делает Blender, проект с открытым исходным кодом.

Когда вы собираете Blender из исходников, выполняется много шагов. Во-первых, компилируется и запускается собственная утилита makesdna. Эта утилита парсит набор заголовочных файлов C в дереве исходников Blender, а затем выводит краткую сводку со всеми определёнными типами в собственном формате, известном как SDNA. Эти SDNA-данные служат данными рефлексии. SDNA затем компонуется с самим Blender, и сохраняется с каждым .blend-файлом, который Blender записывает. С этого момента, каждый раз когда Blender загружает .blend-файл, он сравнивает SDNA .blend-файла cо SDNA, скомпонованной с текущей версией во время исполнения и использует общий код сериализации для обработки всех различий. Эта стратегия даёт Blender впечатляющий диапазон обратной и прямой совместимости. Вы всё ещё можете загрузить файлы версии 1.0 в последней версии Blender, а новые .blend-файлы могут быть загружены в старых версиях.

Как и Blender, многие игровые движки — и связанные с ними инструменты — создают и используют собственные данные рефлексии. Есть много способов делать это: вы можете разбирать собственный исходный код на C/C++, чтобы извлечь информацию о типах, как это делает Blender. Можете создать отдельный язык описания данных и написать инструмент для генерации описаний типов и данных рефлексии C++ из этого языка. Можете использовать макросы препроцессора и шаблоны C++ для генерации данных рефлексии во время выполнения. И как только у вас под рукой появятся данные рефлексии, открываются бесчисленные способы написать общий сериализатор поверх всего этого.

Несомненно, я упускаю множество деталей. В этой статье я хотел только показать, что есть много способов сериализовать данные, некоторые из которых очень сложны. Программисты просто не обсуждают сериализацию столько же, сколько другие системы движка, даже несмотря на то, что большинство других систем зависят от неё. Например, из 96 программистских докладов GDC 2017, я насчитал 31 доклад о графике, 11 об онлайне, 10 об инструментах, 3 о физике, 2 об аудио — и только один, касающийся непосредственно сериализации.

Как минимум, постарайтесь представить, насколько сложными будут ваши требования. Если вы делаете маленькую игру вроде Flappy Bird, с несколькими ассетами, вам скорее всего не придётся много думать о сериализации. Вероятно, вы можете загружать текстуры напрямую из PNG и этого будет достаточно. Если вам нужен компактный бинарный формат с обратной совместимостью, но вы не хотите разрабатывать свой — взгляните на сторонние библиотеки, такие как Cereal или Boost.Serialization. Не думаю, что Google Protocol Buffers идеально подходят для сериализации игровых ресурсов, но они всё равно стоят изучения.

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

Я люблю сравнивать наблюдения по этой теме, так что мне очень интересно услышать мнение других разработчиков. Если вы писали движок, привел ли ваш опыт к тем же выводам? А если не писали или ещё только собираетесь, ваши мысли мне тоже интересны. Что вы считаете хорошим ресурсом для обучения? Какие аспекты ещё кажутся вам загадочными? Не стесняйтесь оставлять комментарии ниже или свяжитесь со мной через Twitter.

Языки программирования для создания игр

Несмотря на постоянное развитие IT-индустрии, создание современных приложений и игр невозможно без программирования. Если раньше выбрать было особенно не из чего, то сейчас у программистов появился такой шанс. Да, вы можете сказать, что для разработки игр достаточно мощного конструктора (Unity или Unreal Engine). Однако на практике необходимость написания собственного кода была и остается важной частью для создания качественного продукта.

В этой статье преподаватели Высшей школы бизнес-информатики НИУ ВШЭ, авторы образовательных программ “Менеджмент игровых проектов” и “Основы создания игр”, расскажут про актуальные языки программирования, которые используются в разработке современных проектов для ПК, консолей и мобильных устройств.

Какой язык выбрать

Каждый языка хорош в определенных задачах. При создании игры профессиональные программисты редко ограничиваются одним вариантом. Тем не менее, самыми «ходовыми» в геймдеве языками программирования являются C# и Java.

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

Кроме того, в процессе создания игр могут быть использованы и другие языки программирования. Например, Python и PHP. Их часто используют для реализации отдельных элементов игрового кода.

Где учиться программированию в геймдеве

ВШБИ НИУ ВШЭ приглашает всех желающих пройти обучение по программе “Основы создания игр” и “Менеджмент игровых проектов”. Во время лекционных и практических занятий вы познакомитесь со всеми аспектами разработки, сможете создать с нуля свою игру и закрепить свои навыки написания программ с использованием самых популярных языков в индустрии компьютерных развлечений.

Еще больше информации вы найдете на канале
МИП ВШБИ на YouTube. Подписывайтесь и не пропускайте свежие записи с открытых мероприятий ВШБИ НИУ ВШЭ.

← Назад к списку

Письменные игры и задания для детей ESL

Игра «Составь слова» . Напишите на доске несколько случайных букв. Предложите учащимся работать в парах / небольших группах, чтобы составить как можно больше слов из букв (например, буквы: g, h, a, t, p, e, c. Возможные слова: кошка, колышек, чай, шляпа, получить , тап, погладить, пометить, у, домашнее животное и т. д.) Команда, написавшая больше всего слов, становится победителем и получает приз.

Остановить автобус . Все, что студентам понадобится, это карандаш и бумага, чтобы играть в эту игру.Чайник пишет на доске письмо и кричит: «Заведи автобус». Затем ученики запишут столько слов, начинающихся с этой буквы, сколько они смогут придумать. Когда один студент кричит: «Остановите автобус!» все должны перестать писать. Все студенты получают по одному баллу за каждое слово. Учащийся, набравший больше всего слов, получает 2 дополнительных очка. Это может быть или не быть тем, кто кричал: «Останови автобус». (Представлено Кэти МакАртур)

Story Pass . Повесьте картинку или первое предложение в качестве подсказки к письму.Разделите студентов на небольшие группы и предложите им создать историю на основе этого подсказки. Каждый ученик по очереди пишет одно предложение, чтобы добавить к рассказу, и передает его следующему ученику. Продолжайте рассказывать в группе, пока они не закончат его (может быть полезно установить ограничение по длине или по времени, чтобы истории не выходили из-под контроля!). Голосуйте за лучший рассказ, основанный на творчестве и потоке. (Представлено Кристиной Дебаландро)

Горшки для йогурта и словарь .Это определенно только для детей начальной школы, которые только учатся говорить по-английски.

Для этой игры вам понадобится несколько пустых, чистых и желательно одинаковых маленьких контейнеров для йогурта. Не более 32 горшков.

На внешней стороне каждого горшка напишите как можно больше различных английских слов, используя черный перманентный фломастер. Напишите слова разборчиво, но бессистемно — одни правильно, а другие боком или вверх ногами. Попробуйте написать на каждом горшке от 10 до 20 слов.Затем внутри кастрюли на дне напишите уникальный серийный номер, начинающийся с 1. Убедитесь, что вы также ясно дали понять, с какой стороны следует читать номер — например, легко перепутать 6 и 9, если вы не поставите строку под ними.

Обязательно составьте основной справочный список, в котором укажите, какие слова вы пишете на каких числах горшков, иначе вы вообще не сможете хорошо управлять этой игрой.

Когда вы играете в игру, каждому ребенку понадобится один чистый лист бумаги формата А4.Попросите детей сложить и плотно сложить бумагу пополам по ширине, затем снова сложить пополам и затем еще раз в третий раз. Когда бумага развернута, она будет разделена на восемь частей сверху вниз. Затем попросите их сложить его пополам и согнуть вдоль. Это делит статью на 16 разделов.

Попросите их перевернуть бумагу так, чтобы она лежала на столе перед ними в «альбомном» режиме. Попросите их написать числа от 1 до 16 в верхней части каждой из 16 секций, изображенных складками бумаги.Убедитесь, что они написаны очень маленьким шрифтом. Затем пусть они перевернут лист и напишут на обратной стороне больше чисел от 17 до 32 (или до самого большого пронумерованного банка, который вы добавили в игру. Если хотите, во время складывания их листов вы можете попросить их правило несколько линий по его длине).

Ваши горшки ДОЛЖНЫ располагаться в строгом, непрерывном порядке номеров, чтобы ваши ученики не запутались.

Затем вы распределяете горшки из расчета по одному на ребенка — или, если у вас большой класс, сделайте один горшок между двумя детьми и дайте каждой паре детей только один лист бумаги.Таким образом они работают как одна команда. Если вы хотите поставить больше горшков, чем детей (или команд), держите остаток на своем столе на виду.

Их работа состоит в том, чтобы записать все слова из КАЖДОЙ банки в соответствующие пронумерованные разделы своей статьи. Слова из Горшка №3 должны быть написаны только в области №3 на их бумаге и так далее. Настаивайте на том, чтобы они писали разборчиво и аккуратно.

Как только дети поймут эту игру — они уйдут прочь! Сделайте их целью первый ребенок (или команда), который соберет ВСЕ горшки в игре.Может быть, небольшой приз за первых троих?

Пожалуйста, обратите внимание, что вы ДОЛЖНЫ настаивать на том, чтобы они могли иметь только ОДИН горшок на своем столе в любое время и что когда они закончат горшок и захотят другой, они должны вернуть готовый горшок вам и получить от вас еще один — без прямого поменяйтесь местами внутри класса, иначе будут драки.

Эту игру любят дети младших классов. Потому что все они читают и пишут с разной скоростью, и если вы сделаете несколько горшков очень простыми, а некоторые очень сложными — тогда некоторые из горшков станут «предметами коллекционирования». Ваш стол быстро станет центром вселенной в вашем классе.

Большинство детей не будут жульничать в этой игре, но постараются хотя бы появиться, чтобы сверить слова, написанные тремя лучшими детьми или командами, по основным спискам, которые вы должны были составить. Убедитесь, что они видят, как вы это делаете.

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

Если это окажется успешным в вашем классе, вы можете использовать эту игру, чтобы «классифицировать» их словарный запас, используя разные «наборы» горшков с разной длиной слов или темами, или словами, начинающимися с определенных букв или содержащих определенные буквы.Названия городов, стран, рек, животных и т.д. и т.д.

Это просто, дешево и очень быстро. Самое главное, детям это нравится! Будьте готовы к ОЧЕНЬ шумным и активным занятиям в классе и к тому, что дети будут пытаться перелезть через вас, чтобы добраться до горшков, которые им необходимы для выполнения своих заданий. (Представлено Дэйвом)

Как написать хорошую историю для видеоигры — E.M. Welsh

Как и любой навык повествования, написание истории из видеоигры требует практики. Но входной барьер намного ниже, чем вы можете себе представить. И хотя вам не следует просто погружаться в более чем 100-часовой сценарий видеоигры самостоятельно, написание более короткой игры вполне правдоподобно.

Уловка в организации вашего подхода! Используя эту серию из трех частей о том, как написать видеоигру, вы получите основу, необходимую для написания своего первого сценария видеоигры.

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

Что делает историю хорошей видеоигры?

В хорошей видеоигре так много особенностей — бой, мир, механика, интерактивность. Но если оставить в стороне эти особенности, что делает историю в видеоигре хорошей?

Как и в случае с любым другим средством повествования, не существует секретной формулы того, что делает историю хорошей видеоигры.Одна видеоигра может иметь пошаговый бой, длиться более 100 часов и иметь нулевой выбор для игрока, тогда как другая игра может длиться 20 минут и не иметь ничего, кроме выбора.

Это даже не учитывает предпочтения, которые всегда определяют то, что мы считаем хорошей историей, независимо от средства массовой информации. Некоторые люди не выносят сюжетную игру — им нужны исследования и время для выполнения случайных побочных квестов или случайных заданий, — тогда как для других было бы хорошо, если бы в видеоиграх вообще не было сражений!

Несмотря на все эти различия, остается один элемент, который есть в каждой видеоигре и который необходимо учитывать — динамика игрока и персонажа.

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

Другими словами, игрок играет в видеоигру — а не смотрит фильм — потому что он хочет чувствовать, что у него есть контроль, и каждая хорошая история видеоигры вызывает у игрока такое ощущение, даже если у него нет другого выбора. сделана или нет видимой истории.

Каковы элементы повествования видеоигры?

Двумя элементами любого хорошего повествования видеоигры являются:

Динамика персонажа-игрока
Интерактивное пространство для исследования игроком

Хотя мы уже обсуждали динамику персонажа-игрока, немного углубимся в нее. кроме того, эта динамика гарантирует, что у игрока никогда не будет момента, когда он подумает про себя: «Подождите, мой персонаж этого не сделает». (Часто поэтому второе лицо в прозе почти не работает.)

Хорошая история видеоигры понимает этот баланс, даже если у их главного героя есть отличная личность, как Элой в Horizon Zero Dawn . Конечно, у нее могут быть определенные черты характера, которые не похожи на игроков, но она никогда не ссылается на случаи, о которых игроки не знают, и не говорит о вещах из ее прошлого, о которых они еще не знали. Вот почему многие видеоигры полагаются на костыль амнезии — чего по большей части следует избегать. Это упрощает динамику игрового персонажа.

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

Эта интерактивность имеет множество различных форм. В Persona 5 это может быть что-то вроде выбора полива растений вместо просмотра телевизора, или это может быть исследование целого мира, как в Skyrim, где каждый предмет можно потрогать и поднять.Хотя этот элемент может быть не первым, о чем вы думаете при написании рассказа, его так же важно помнить при написании сценария видеоигры, как и динамику персонажа и игрока.

Как написать видеоигру?

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

Шаг 1. Обрисуйте основную сюжетную линию

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

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

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

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

Шаг 2. Решите, какой это будет тип игры.

После того, как вы узнаете общую структуру вашей истории и как будут развиваться события, вы захотите решить, какой это будет тип игры.

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

Итак, прежде чем продолжить свою историю, решите, какой это будет тип игры:

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

Шаг 3. Развивайте свой мир

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

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

В видеоигре мир выглядит с точки зрения вашего персонажа, поэтому во многом это то, как игроки воспринимают развитие персонажа.

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

Шаг 4. Создайте своих главных героев

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

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

Шаг 5. Создайте блок-схему своей основной истории

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

Шаг 6. Начните писать основную историю

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

Вы можете написать основную историю либо как краткое изложение, либо вы действительно можете погрузиться в написание сцены.

Как вы это сделаете, зависит от вас, но начинать с кат-сцен с минимальной интерактивностью — это отличная основа для обоснования вашей истории. Если вы мне не верите, примите во внимание тот факт, что большинство видеоигр имеют версии, предназначенные только для кат-сцен. на YouTube, где можно посмотреть историю как в кино. Используйте эти версии роликов в качестве вдохновения и напишите эту голую версию своей истории, прежде чем погрузиться в интерактивность, побочные квесты и другие возможности.

Шаг 7. Добавьте побочные квесты, неигровых персонажей и другие мелкие детали.

После того, как вы написали основную историю, вы можете добавить все самое интересное.

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

Если вы не знаете, с чего начать, вот несколько общих вещей, которые вы можете добавить, чтобы заполнить свою историю:

Неигровые персонажи — Люди, с которыми ваш игрок может взаимодействовать.Часто они могут просто весело «лаять», когда выражают свое мнение, раскрывают информацию об окружающем мире или даже дают вам подсказки. Другие NPC предлагают побочные квесты и награды с более обширной сюжетной линией.
Побочные квесты — Если ваша история достаточно велика, вы можете захотеть, чтобы побочные квесты были разбросаны по всему миру. Эти побочные квесты могут быть связаны с миром, культурой, знаниями или исследовать предыстории некоторых из ваших персонажей. Они совсем не должны влиять на основной сюжет, иначе они могут помешать успеху миссии.
- Предметы — предметы, которые используют ваши персонажи, выходят за рамки оружия и доспехов. Также могут быть заметки, письма и другие вещи, которые помогают в квестах. У драгоценного камня может быть своя история, или заброшенный дом может быть заполнен оставленными вещами. Когда дело доходит до предметов, нет предела — так что проявите творческий подход! (И используйте электронную таблицу, чтобы отслеживать все свои идеи.)

В игре есть более мелкие детали, но это самые общие из них, которые вы увидите, и часто у вас будет много весело и действительно отличить свою историю!

Что нужно для написания видеоигр?

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

Опыт игры в видеоигры

Как говорится, если вы хотите быть писателем, вам нужно много читать, так что что если вы хотите быть автором видеоигр, вам нужно сыграть в множество игр.

Хотя я думаю, что это верно для всех типов письма — если вы хотите писать фильмы, вы обязательно должны их смотреть — это особенно верно для видеоигр, потому что вы должны учитывать не только сюжет, но и элементы игрового процесса.

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

Например, в таких играх, как Horizon Zero Dawn и The Witcher , герои — охотники, которым часто поручено уничтожать зверей и других неприятных врагов. Это меняет то, как мир взаимодействует с ними и квесты, которые им даются, а также влияет на то, как ощущается бой.

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

Чтобы получить дополнительную информацию об этом и список различных игр, узнайте, почему видеоигры помогают всем типам повествования.

Программа для написания сценария видеоигры

Хотя не существует «официального» способа написания сценария видеоигры, есть несколько различных программ, к которым вы можете обратиться за помощью.

Текстовый процессор — Да. Каким бы простым это ни казалось, текстовый процессор, такой как Google Docs или Pages, можно использовать для написания сценария видеоигры. Не верите мне? Ознакомьтесь с шаблоном, который я использовал для написания своего первого квеста, здесь.
FinalDraft — Хотя это программное обеспечение используется для написания сценариев, его также можно использовать для написания сценариев видеоигр!
Twine — Хотя я никогда не использовал Twine, говорят, что это отличный способ написать нелинейный рассказ.Кроме того, вы можете опубликовать свою работу где угодно после того, как она будет сделана, чтобы найти других разработчиков, которые помогут вам поработать над ней!
Inklewriter — Хотя технически Inklewriter является постоянной бета-версией, он предлагает хорошую альтернативу Twine, если вы хотите написать более интерактивную историю вместо стиля ветвления, который предлагает Twine.

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

Часто это оказывается более простой идеей, поэтому постарайтесь не писать тройную RPG для первого раза. За такими играми стоит целая команда, так что с первого раза снимайте что-нибудь вроде Undertale или A Stanley Parable.

Итак, вы хотите писать для видеоигр?

Многие сценаристы мечтают писать сценарии для видеоигр и получать прибыль от индустрии, которая намного более прибыльна, чем кино- и телеиндустрия, в которую сценаристы стремятся проникнуть сегодня, — но когда дело доходит до писатель игр.

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

Согласно отчету Global Games Market Report, в 2016 году мировая индустрия видеоигр принесла доход в размере 99,6 миллиарда долларов. В том же году Голливуду удалось заработать «всего» 36 миллиардов долларов.

Grand Theft Auto V , непревзойденный рекордсмен видеоигр, заработал 815,7 миллиона долларов в первый день выпуска . Это не опечатка — это первые дней выпуска . Некоторым из крупнейших летних блокбастеров в кинотеатрах нужно три месяца или больше, чтобы собрать такую сумму во всем мире — если им повезет.

«Хорошо, где мне зарегистрироваться ?!»

Здесь все становится сложно — и некоторых это немного удручает.

Вы не пишете оригинальный сценарий для игры и не продаете его по спецификации

Многие сценаристы мечтают написать блестящий сценарий, который идеально подходит для интерпретации видеоигр. Они думают, что могут донести его до крупных компаний, занимающихся видеоиграми, сделать свое предложение, как с любой голливудской студией или продюсерской компанией, продать его, а затем сотрудничать с разработчиками игр, чтобы сделать следующий большой успех.

Это просто не так.

Автор игры не продает свою концепцию и не смотрит, как игровые дизайнеры воплощают свое видение в жизнь с помощью красивой графики и интерактивного игрового процесса. Руководители проектов — те, кто руководит шоу. И зачастую именно они владеют концепцией и вместе со своей командой дизайнеров отвечают за создание концептуального дизайна и игрового процесса.

Game Writer обычно вступает в игру довольно поздно, вообще говоря.

Видеоигры — это не фильмы. Они начинают не со сценариста и со сценария. Они начинают с директоров проектов и дизайнеров игр, а также множества других технических профессионалов.

А игровые сценарии совсем не похожи на средний сценарий. Это технические документы с сотнями страниц визуального описания, блок-схем, ветвящихся диалогов, кат-сцен и т. Д.

Так что же на самом деле пишут авторы игр?

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

Геймерам нравится сюжет и глубина персонажей в своих играх, но когда дело доходит до крайности, им нужна игра с потрясающим интерактивным игровым процессом.

Так что пишут авторы игр?

Вот общая разбивка:

Блок-схемы — В наши дни игры очень сложные, особенно РПГ (ролевые игры).Игрокам придется принимать множество решений на протяжении всей игры. Таким образом, игре придется разработать все возможные варианты, которые позволят игроку почувствовать, что он действительно органично управляет персонажем в этом мире. Блок-схема очень похожа на экстремальную версию тех старых книг Choose Your Own Adventure . Это звучит интересно, но в нем очень сложная техническая составляющая с простой историей и развитием персонажей — ровно настолько, чтобы оставаться интересной для геймера.

Побочные квесты — Во многих играх есть небольшие миссии и квесты, которые персонажи могут выполнять.Это тоже нужно написать.

Описания и биографии персонажей — Каждый персонаж должен иметь описание и разбивку, чтобы игровые дизайнеры могли должным образом разработать их вместе, в зависимости от того, кто эти персонажи, как они выглядят и на что они способны.

Сцены диалога с неигровыми персонажами — Геймеры и персонажи, которыми они управляют, будут взаимодействовать с неигровыми персонажами на протяжении всей блок-схемы игры.Для этих многих моментов нужно писать диалоги.

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

Окончательный сценарий раскадровки — Если есть что-то похожее на сценарий художественного фильма в процессе разработки видеоигры, так это сценарий раскадровки.Это пишется после того, как все вышеперечисленное выполнено. Считайте, что это основная раскадровка, которая документирует игровой процесс и элементы истории от начала до конца.

Вот общий пример:

Расположение : Темный собор с витражами. НИП стоит на коленях перед каменной шкатулкой в центре главной комнаты

Музыка : Фоновая музыка органной игры вводит сцену, но затихает

Персонажи : Главный игрок, NPC по имени Томас

Цель игрока : Узнать местонахождение подземного логова

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

Блок-схема : На данный момент никаких решений не принято: Если битва завершена, Томас открывает вход в подземное логово, и игрок переходит на этот уровень. Если игрок потерпел поражение в битве, вернитесь в сцену смерти (11) и переместитесь, чтобы повторить попытку.

Примечания : Игрок заперт в соборе, и выхода нет.Единственный реальный выход — установить контакт с Томасом. Случайные существа-оборотни могут быть активированы, если игрок исследует собор перед разговором с NPC.

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

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

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

Но сценаристы У есть место в индустрии видеоигр, верно?

Несомненно, существует много переменных. Технически, да, сценариста можно было бы нанять, чтобы конкретизировать работу, которую делает команда игровых дизайнеров, и предложить повествование и диалоги.

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

Итак, сам автор игры, опять же, вторичен по отношению ко всему игровому дизайну и концептуализации.

Ричард Дански, Центральный Том Клэнси Сценарист Ubisoft Red Storm, говорит: «Хороший писатель понимает, что игра не о них, или их истории, или их остроумных диалогах.Остальная часть команды не для того, чтобы реализовать свое видение, и не для того, чтобы восхищаться их талантом. Сценарист игры, с которым я хочу работать, хочет сотрудничать с командой, чтобы создать лучший игровой опыт. Это означает создание сюжета, демонстрирующего особенности игры ».

Далее он говорит: «Написание игр действительно отличается от любого другого стиля с точки зрения того, что они требуют от писателя — это единственное место, где писатель не рассказывает свою историю или историю главного героя, но скорее история игрока.Да, игрок берет на себя роль главного героя, будь то аватар, который он создает сам, или известный культовый персонаж, такой как Сэм Фишер, но факт остается фактом: все, что входит в игру, является лишь возможностью до момента, когда игрок взаимодействует с это и таким образом создает свою собственную историю о том, что произошло ».

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

Итак, как вам устроиться на работу писателем игр?

Дэвид Гайдер работал с BioWare в качестве дизайнера повествования над такими играми, как Baldur’s Gate 2 , Knights of the Old Republic , Neverwinter Nights и был ведущим сценаристом серии Dragon Age. : Dragon Age: Origins , Dragon Age 2 и Dragon Age: Inquisition в 2014 году .Позже он перешел в Beamdog Studios в качестве их креативного директора. Он написал в своей статье о Polygon, как сложно получить желаемую всем позицию.

Комментарий Гайдера, «Я знаю игры, которые действительно интересуют сюжет , но на ранней стадии разработки будут настоящие писатели. У других написание будет выполняться кем-то, кто также занимается чем-то другим в команде, например, программистом, потому что им просто нужно.А больше всех? В их игре нет особого смысла рассказывать, и точка, потому что это просто не такая игра ».

Но ведь есть ли писательские вакансии? «Шансы получить какую-либо писательскую работу в игровой индустрии невелики».

Далее он говорит: «Письмо — это трудный навык. Вы могли бы быть гением в дизайне повествования, но доказать, что вы гений? Очень трудно. Более того, людям, которые нанимают писателей, действительно сложно понять, кто способен.Это не похоже на трехмерную модель, на которую вы можете посмотреть и объективно сказать, есть ли у того, кто ее создал, есть отбивные или нет — мы говорим о неточной науке, и нет никаких степеней, скажем, в интерактивной ветвящейся фантастике. Так что вы пишете свои блестящие материалы и пытаетесь выделиться среди всех остальных ».

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

«Вам нужно играть в игры. Все типы игр, а не только те, которые вам нравятся больше всего. Вам нужно смотреть на разные истории и думать о том, что они сделали в повествовании, хорошее или плохое. Если это было хорошо, подумайте, как им это удалось. Если это было плохо, подумайте, почему это могло быть сделано именно так и что могло быть лучше. Один из наиболее частых вопросов, которые мы задаем в интервью, — это то, что писатель думает о повествовании в играх, в которые они играли, и, в частности, что им не понравилось и почему.Умение критиковать — это один из навыков, которые вам абсолютно необходимы, не говоря уже о том, чтобы показать, что вас интересуют игровые истории, выходящие за рамки наслаждения одной игрой, созданной разработчиком ».

Он также предлагает вам попрактиковаться.

«Да, это навык, который можно улучшить и развить. Многие думают, что писательство — это исключительно талант, но это только его часть. Я говорил людям, что они должны попробовать моддинг, но создание мода включает в себя целый ряд других навыков, которые многие люди считают слишком сложными, чтобы даже думать об изучении.Легче сказать, чем сделать, присоединиться к команде разработчиков, поэтому лучше всего приобрести такую программу, как Twine. Он основан исключительно на письменной форме, он позволит вам обдумать идею ветвления, и вы создадите что-то, что вы сможете не только показать позже, но и продемонстрировать, что вы нашли время, чтобы изучить простой скриптинг программы. как требуется Twine. «У меня достаточно технических возможностей, чтобы научиться пользоваться редактором бесед» — это фантастика, и вы выделитесь ».

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

С учетом сказанного, он предлагает несколько рекомендаций. «Мой личный совет — постарайтесь сделать все возможное. Если вы пишете отдельный диалог, сделайте что-нибудь действительно умное в первых нескольких строках.Если вы пишете несколько, убедитесь, что первый лучше всего демонстрирует ваши навыки. Если вы даете план квеста, убедитесь, что меня захватывает предпосылка или что первая часть квеста самая интересная. Было бы хорошо, если бы мы жили в мире, где я до самого конца передавал ваше представление, чтобы произвести впечатление, но мы этого не делаем. Я нетерпелив и устал, и мое внимание довольно быстро рассеивается. Сомневаюсь, что я единственный.

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

«[Когда вы подаете заявку] не делайте это о своих идеях, а о своих навыках».

Написание видеоигр — это уникальная должность и умение. И суть этого поста заключалась в том, чтобы сначала развенчать фантазию сценаристов, когда дело доходит до написания видео для видеоигр, — что они могут концептуализировать свои собственные истории, персонажей и концепции и продавать их индустрии видеоигр, как они бы это делали. попытаться продать специальные сценарии киностудиям.

И даже помимо мифа о спецификациях, ясно, что писатель игры — это совершенно другая игра с мячом, полностью ориентированная на игровой дизайн и игровой процесс, а не на сюжет и повествование персонажей.

Да, видеоигры стали более глубокими в этом отношении, но, в конце концов, это не фильмы или сериалы. Это видеоигры , дополненные сюжетом и персонажами .

Так что, если вы заинтересованы в написании кинематографических историй, придерживайтесь функций. Если у вас есть страсть к сюжетам и исследованиям персонажей, пишите для телевидения.

Но если вы любите видеоигры и хотите участвовать в этом творческом процессе, поймите, что это совсем другой путь, чем путь сценариста. Проведите исследование, найдите несколько отличных отраслевых книг по этой теме (многие из них доступны ЗДЕСЬ на Amazon), изучите свои сетевые карты, чтобы узнать, знаете ли вы кого-нибудь в индустрии видеоигр, с которым вы можете связаться, и подумайте о том, чтобы войти в отрасль через различные технические дорвеи игрового дизайна.

Быть гейм-дизайнером — это одно — быть гейм-дизайнером с писательским талантом? Это может быть ваш вход.

Кен Миямото проработал в киноиндустрии почти два десятилетия, в первую очередь в качестве связного со студией Sony Studios, а затем в качестве читателя сценариев и аналитика сюжетов в Sony Pictures.

У него за плечами много студийных встреч в качестве сценариста, он встречался с такими компаниями, как Sony, Dreamworks, Universal, Disney, Warner Brothers, а также со многими производственными и управляющими компаниями. У него был предыдущий контракт на разработку с Lionsgate, а также несколько писательских заданий, в том числе продюсированный мини-сериал Blackout с Энн Хеч, Шоном Патриком Флэнери, Билли Зейном, Джеймсом Бролином, Хейли Дафф, Брайаном Блумом, Эриком Ла Саллем и Брюс Бокслейтнер.Следуйте за Кеном в Twitter @KenMovies

Чтобы быть в курсе всех последних новостей и обновлений ScreenCraft, подписывайтесь на нас в Twitter, Facebook и Instagram.

Как написать игру, меняющую цели

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

Мое личное мнение о постановке целей таково, что о них слишком много думали и говорили в последние несколько десятилетий. Это стало слишком сложным и продолжает оставаться чем-то, что мы просто не выполняем — я сам очень виноват в этом.

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

Зачем писать голы ???

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

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

Итак, каждый раз, когда вы пишете цель, вы на самом деле вдохновляете себя настоящим моментом, а также помогаете себе действовать прямо сейчас, а не завтра!

Ниже приведены шесть простых шагов, которые я выполняю для написания целей, меняющих правила игры.Не стесняйтесь использовать некоторые или все из них, когда пишете свои собственные.

1. Старайтесь ставить меньше десяти

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

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

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

2. Свяжите их со своим видением

Одной из целей, которые я записал в свой список, было присоединиться к Toastmasters и научиться публичным выступлениям. Перечитав цель, я понял, что публичные выступления не являются частью моего видения, и это уродливая фраза, которой боится большинство из нас.

Итак, что я советую исправлять эти типы проблем, так это записать цель и упомянуть свое видение в описании. Для меня это означало переписать цель: «завершить три месяца Toastmasters, чтобы я мог начать вдохновлять людей своими выступлениями».

Добавляя часть о вдохновении людей, я напрямую связываю цель с частью своего видения , которая должна вдохновлять мир своей работой. Вы обязательно должны это сделать для своих целей.

Если вы смотрите на свои цели каждый день, и они не вдохновляют вас и не вызывают у вас энтузиазма, вы никогда не достигнете их.Вы бы не хотели этого сейчас, не так ли?

3. Установите крайний срок

Обратите внимание, как на этом шаге упоминается крайний срок, а не временные рамки? Это потому, что крайний срок должен быть соблюден, но временные рамки обсуждаются.

По мере того, как вы записываете свои цели, у вас должен быть отдельный столбец с указанием крайнего срока. Рядом с каждой целью вы должны указать дату, к которой эта цель должна быть достигнута. Как только все ваши цели будут записаны, вернитесь и посмотрите на даты. Убедитесь, что дата, которую вы поставили для каждой цели, является реалистичной и максимально точной.

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

Если все ваши цели истекают в один и тот же день или в один и тот же месяц, вам следует заново переписать сроки.

4. Записывайте их в правильном настроении.

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

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

Попробуйте это и посмотрите, как это влияет на формулировку ваших целей.Перед сеансом постановки целей я рекомендую посмотреть фильм «Помни о титанах», а книгу, которую я бы порекомендовал, — «Манифест мотивации», если вы зациклились на идеях.

5. Храните их в бумажнике

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

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

Это простое задание поможет вам вспомнить, что важно и почему вам следует как можно больше игнорировать отвлекающие факторы, которые не имеют отношения к этим целям. Я обнаружил, что цели создают фокус, и для любого, кто, как я, постоянно отвлекается, это держит вас под контролем.

6. Обеспечьте подотчетность с некоторыми ключевыми людьми

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

Другое важное преимущество не так очевидно, и позвольте мне привести вам пример. Одна из целей, которые я записал, заключалась в том, чтобы встретиться с неким венчурным капиталистом Кремниевой долины по имени Билл Тай. Я включил его в список потому, что хотел, чтобы люди, читающие мои цели, знали, что для меня важно.

Когда ключевые люди вокруг вас знают, что для вас важно, они также следят за тем, как они могут помочь вам в достижении ваших целей (особенно если этот ключевой человек имеет фундаментальное значение для одной из ваших целей). Пока мне не повезло встретить Билла Тая, но пока я продолжаю говорить людям, что это важно для меня, в конечном итоге эта цель будет достигнута.

Я просто использовал эту самую точку и продемонстрировал ее вам. Как? Сказать всем вам, что это моя цель на случай, если кто-то из вас знает Билла Тая. Может быть, это поможет мне достичь цели, а может, и не скажет, но то, что он сделает, повысит мои шансы на достижение этой цели.