Как стать автором
Обновить

Комментарии 26

определитесь с игровой нишей, в которой хотите работать

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

И с этим категорически не согласен, создавать нужно прежде всего что хотелось бы, иначе интерес быстро пропадет. Разве интересно клепать банальные клоны коих полно да еще и низкого качества которые не будут востребованы? С первого раза и не должно получится что то путное, но это будет большой опыт который поможет влиться в среду геймдева.
+
Если делать только то что можешь, когда будешь развиваться?
По поводу первого вы действительно правы, но отрицать важности данного аспекта при входе в сферу геймдева было бы довольно глупо. Это важно также, как и определение нашей жизненной позиции, поскольку позволит целенаправленно совершенствовать навык, не тратя при этом кучу времени (ценного времени) на деятельность, которую вы впоследствии отбросите. Формально, ответ на этот вопрос является основой дальнейшей деятельности. По этой причине я включил этот пункт в публикацию. Во всяком случае, мой дальнейший вопрос о технологической стороне будущих проектов помогает, хоть и минимально, но помогает обрезать сферу дел, которыми может заняться потенциальный разработчик. Перескакивать с лодки на лодку — пустая трата времени. Выбрав основной вектор развития, человек в дальнейшем уже сам сможет более тонко определить, к чему лежит его душа.
И с этим категорически не согласен, создавать нужно прежде всего что хотелось бы, иначе интерес быстро пропадет.

Почему вы так считаете? В данный момент я работаю над простейшими платформером(имитирую Марио, дабы получить какие-то практические знания), хотя в будущем планирую создавать ActionRPG и интерес до сих пор не угас, а наоборот приумножился. Здесь ребром стоит вопрос о процессе, а не итоговых результатах. Игры, к какому бы жанру они ни принадлежали, имеют общие черты в рамках процесса разработки. Создавая простейшее, человек будет приобретать навыки и понимание того, с чего следует начать и как следует продолжить. Например: в рамках взаимодействия каких-либо объектов в игре крайне полезна система хитбоксов. В Марио она примитивна, что позволит мне без особых усилий освоить данную вещь. Если бы я взялся за что-то посложнее, то мой прогресс сильно бы застопорился, поскольку те задачи, перед которыми меня поставит более сложный проект, я скорее всего не решу. Почему? — Банально не знаю, основ. Я не знаю, как ответить на вопрос в самом примитивном виде. Марио даёт мне этот самый примитивный ответ, от которого я буду отталкиваться в будущем.
Разве интересно клепать банальные клоны коих полно да еще и низкого качества которые не будут востребованы?

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

Это правда. Вы, конечно, можете броситься сразу в пекло, но это приведет к малым результатам, поскольку перед вами встанет миллион вопросов, на которые необходимо ответить чуть ли не одновременно, и вероятность того, что вы ответите на них правильно без какого-либо опыта, крайне мала. По этой причине стоит начинать с малого — не всё сразу.
Стоит начать с малого, но все же не с того, что умеешь. Я лично думаю, что нужно писать то, что ты не умеешь и не простые вещи. Например какой-нибудь шутер, где есть достаточно много аспектов разработки. Писать как можешь, писать костылями, ужасно запутанным кодом. Потом от этого сам начнешь понимать, что было сделано неудобно и неправильно.
Дело в том, что если вы учитесь на простом, вы не затрагиваете множество всего. Например аспекты ООП или КОП, взаимодействия с различными объектами разными способами и прочее.
Но вот на сложном проекте вы все это пройдете. На этом и стоит учиться. Более того, в наши дни движки предлагают такой инструментарий, что что-то простое на них делать не очень-то удобно. Например тот же Unity, который все же заточен под 3D. И геморится с, на каказось бы, простым 2D там не очень-то удобно.
Хочу уточнить. Не стоит, конечно, начинать делать сразу ММОРПГ и все такое. Но и делать какой-нибудь понг тоже, думаю, вряд ли будет шибко полезным. Точнее, оно будет полезным, но не так, как если бы вы писали что-то посложнее.

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

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

Я в свое время тоже не начинал с таких простых игр. Сразу выбрал 3D игру с достаточно шустрым геймплеем. Писал лишь бы работало, много чего узнал и понял (особенно благодаря UE4 и БП). После этого мог писать уже что угодно и через пол года выложил в сеть свою первую игру, написав её за 2 месяца.
www.youtube.com/watch?v=UbAox4khRKY Вот, кстати, и она. Квест, вроде портала, только с управлением временем.
У меня первым, что я писал — был ММОРПГ. На Ansi C, и ничего так, отлично пошло.

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

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

Первое и основное — делайте то, что любите. Без любви у вас ни за что не хватит ни сил, ни времени, ни упорства, чтобы что-то освоить. Есть мнение, что для профессионализма надо наработать в районе 10000 часов в сфере деятельности — без любви к своему делу вы столько не проработаете.

Далее более конкретно:
— На начальном этапе разрабатывайте однопользовательские игры для ПК. На мобильных устройствах вам придется много возится с окружением и оптимизацией — это нужно для коммерческих продуктов, но не для вашего развития. Поддержка онлайн-игры для многих людей — тоже не сахар.
— Фантазируйте и придумывайте. Ваша задача — попробовать самые разные жанры, чтобы выработать свой собственный стиль. Вы можете остановиться в любой момент в реализации — совершенно не обязательно доводить всё до конца, чтобы получить опыт и фан. Моя статистика приблизительно такая — мне приходят в голову идеи около 100 проектов. Из них 10 заслуживают какого-то внимания, раздумия. Один доходит до этапа реализации. (Интервью с Полуниным — там тоже есть про фантазирование и остановку на любом этапе)
— Используйте простейшие инструменты для реализации идей. Не надо использовать что-то навороченное вроде Unreal Engine. GameMaker — отлично; еще могу порекомендовать RenPy в случае, если хочется попробовать что-то вроде визуальных новелл, на которых можно научиться делать сторителлинг.
— Попробуйте сделать мод к своей любимой игре. Во-первых, это весело. Во-вторых, это недолго (а вам надо набрать 100 идей). В-третьих, вы немного поймете, какими вещами оперируют разработчики игр.
— Реализуйте в простейшем варианте парочку классических игр — например, Пакмана или арканоид. Вы почувствуете их и получите ценный опыт программирования.
— Для вдохновения стоит почитать классические книги про разработчиков игр и про сторителлинг. Моя подборка: Тристан Донован. «Играй! История видеоигр», Дэвид Шефф «GAME OVER Как Nintendo завоевала мир», Роллингз Э., Моррис Д. «Проектирование и архитектура компьютерных игр». Возможно, «Тысячеликий герой» Кэмпбелла, хоть он и заезжен. От книг по программированию (напишите цикл А и условие Б) по моему личному мнению, пользы сильно меньше.
— Заглядывайте в соседние области — изучайте настольные, ролевые игры, игры живого действия.
Хочется отметить крайнюю полезность данного комментария. Прекрасные мысли, мне даже добавить нечего.
НЛО прилетело и опубликовало эту надпись здесь
> Интересно было почитать подход «программиста», от подхода «игрока)

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

> Считаю что для вдохновения надо читать или художественную литературу, или научную для общего кругозора.

Согласен :) Кстати, то, что мной перечислено — скорее неплохие научно-популярные работы. В частности, очень много подчерпнул из исторических обзоров развития игровой индустрии: как менялись предпочтения игроков со временем, как образовывались жанры. Например интересны факт — классическую Bejeweled (первый пример механики «3-в-ряд») издатели не хотели издавать — она не соответствовала идее классического «соревновательного» процесса в играх.
Не надо использовать что-то навороченное вроде Unreal Engine.

Вот с этим не могу согласиться. "Навороченность" UE4 – миф, на данный момент. Возможно, так было раньше. Сейчас это отличный движок, чтобы попробовать себя в геймдеве. Однако, его не стоит выбирать, если цель – 2D игра. Всё-таки, UE4 больше заточен под 3D.

Возможно — каюсь, я смотрел UE где-то лет 6-7 назад. Тогда было разобраться тяжело; а в пример неудобного инструмента привести что-то хотелось.

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

В Unrel Engine как раз есть очень хорошие инструменты для новичков, которых нет больше нигде. Например Блупринты на замену C++, которые очень сильно облегчают задачу, дают легче понять, как строится логика, и что не менее важно, не дают сделать ошибок.
Так же в анриале есть редактор материалов, который заменяет HLSL код, позволяя строить свои шейдера.

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

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


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


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


концепты

image
image


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


Если кому интересно – код игры доступен в репозитории, за исключением сторонних ассетов (из-за EULA).

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

В общем, туториалы, мануалы и другие всякие «getting started» — это здорово!
смотря на процесс разработки игр изнутри, одно приходит на ум (извините, что с своим уставом)…

простое что-то, типо пятнашки — можно самостоятельно реализовать, как полноценную игру, пусть то мобильное нативное иос, андроид, или юнити кросплатформенное…

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

Здесь видел статьи, когда программист делал игру в течении месяцев-лет, но вопрос: можно ли программиста считать gamedeveloper'ом, если он пишет свою игру вечерами, и маловероятно, что она увидит мир, не говоря про продажи и заработок.
НЛО прилетело и опубликовало эту надпись здесь
Вот это советы…
Матрицы 44 нету. И из чего состоит нету
Вращения по осям нету
Матрица камеры-взгляда, модели, проекции неу
Определение угла между векторами нету. С помощью atan2 и прочие.
Что cos/sin считает в радианах нету
Основных законов движения v = v0 + att/2 и p = p0 + vt нету
Преобразование local2global и global2local нету
Движение по сплайну и анимации нету
Интерполяции нету
Единичная, Обратная, Транспонированная матрица нету
Для чего вы используете матрицы, приведите пару примеров? Лично я пока что не нашёл им явного применения (возможно пока что), кроме как матрицы состояний для конечного автомата.

Выше имелись ввиду матрицы 4*4, которые активно используются в 3д графике (и в 2д тоже — например, для сортировки спрайтов по глубине). Без начальных знаний линейной алгебры далеко не уйти.
Я начинал с книжки F.Dunn I.Parberry "3D math primer for graphics and game development". Она на английском, но зато начинается с самых самых азов типа векторов и их свойств, а потому можно потихоньку привыкнуть к английским обозначениям и прочитать её целиком. Кроме того, благодаря этой книжке я осознал суть кватернионов и потом спокойно использовал их. Там есть примеры на С++ с реализацией кватернионов, матриц и простейших моделей освещения.

Матрица нужна для хранения трансформа объекта в какой-либо системе координат: камеры, мира, экрана.
Хранит в себе направление базиса, перемещение, масштаб и вращение по осям базиса.
На деле всё немного сложнее. Ведь матрицы нужны только на этапе растеризации. И разработчик игровой логики, может воообще не знать формулу LookAt или Матрицы Проекции. И обходиться только vec3 для позиции и углами Эйлера.

Добавлю свои 5 копеек: я анализирую игры, в которые играл или смотрел происхождение. Не на уровне "графика красивая, геймплей уныл", стараюсь разобраться в причинах — выделяю неудачные и, наоборот, удачные моменты в геймплее, пытаюсь понять, почему разработчик сделал так, а не иначе. Иногда получается, что внесение вроде бы маленького изменения потребует ещё кучу переделок, которые перевенут игру.
И чтобы мои размышления не пропали, записываю их. Так же делаю записи, когда читаю что-то интересное.


P.S. Кстати, могу ли я взять какую-нибудь главу из книги по геймдизайну, которая не издавалась на русском, перевести и опубликовать на хабре? Ко мне никаких претензий со стороны правообладателей не возникнет?

Статья полезная, но на самом деле вы написали статью о том, как научиться программировать игры. Стоило написать про вводные и про моделирование, про создание уровней или геймдизайн. Все же разработка игр это далеко не одно программирования. Как вы сами написали, это всего 10-20%.

Добавочка как раз тем, кто хочет научиться придумывать и стать геймдизайнером… Можно читать книги, можно смотреть на другие игры. Однако тут будет проблема в том, что вы не сделаете ничего нового. Все же копируя что-то, лучше не сделаешь.
Хорошей стороной считается то, что вы можете придумать игру не играя в игры и не читая о них, а смотря на окружающий мир.
Например всем известная игра, когда нельзя наступать на линии между плитками, когда идешь по улице. Это наблюдение, а не копирование.
Геймдизайнерам советую ещё следующую практику. Выйдите на улице или откройте какой-нибудь сайт, и пытайтесь придумать игру на основе того, что увидите.
Например я вижу, как человек чистит автомобиль от снега. Сразу наскакивает идея игры, где нужно как можно быстрее чистить машину от грязи/снега/песка на время. Или даже сделать экономический симулятор сети автомоек :)
Или, скажем, видите новость о том, что какого-нибудь чиновника посадили за отмывание денег. Сразу делаем игру о том, что нужно искать доказательства того, что человек как-то отмывает или ворует деньги. Смотреть документы с его выписками, собирать в игре новости и прочее.

Совмещая идеи получаем игру про мойку денег, например. Уже третий сценарий, а всего-то два наблюдения.

Все конечно здорово, но в конечном итоге в 90% случаев успех игры зависит от маркетинга. Как бы человек не вылизывал игру, какие бы невероятные механики не придумывались, в 90% случаев все решит маркетинг. Если в игре будет хорошая монетизация, грамотное продвижение — игра будет успешной, в противном случае, никакие уникальные идеи не спасут (конечно же, в 90% случаев, оставим 10% на исключения). На своем примере, за полтора месяца в своей игре набрал еле-еле 50к установок, передал игру другому разработчику, он за 2,5 месяца смог превысить рубеж в 1млн установок. В общем, нужно учиться продвигать игры, сейчас это к сожалению гораздо важнее, чем сама игра.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации