Есть такая вероятность, что в этом году вы наконец-то решили сделать собственную игру. Отличная цель! И она определённо того стоит!
Вы уже наверно много раз слышали один и тот же совет от сотен других людей: делайте игру простой. В своей замечательной статье Эдмунд Макмиллен писал «если вы новичок, то начинайте с малого, а потом сделайте игру ещё меньше». В столь же хорошем посте ему вторит Томми Рефенес: «Просто сделайте свою игру так, как можете, начинайте с малого, а об остальном думайте потом».
На канале Extra credits есть хорошее видео о том, что же значит «маленькая игра».
Но «простой» — это не стандартная единица изменения. Если вы никогда до этого не делали игр, то откуда вам знать, насколько проста или легка игра? Означает ли «простая» MMO ВСЕГО с тремя играбельными классами? Лёгкая игра — это открытый мир всего с двумя типами биомов и тремя деревьями технологий?
Я понимаю вашу растерянность.
В целом я выпустил пять игр и перед началом разработки трёх из них я думал, что они будут «простыми». Во всех трёх случаях я ошибался. На завершение первой готовой игры мне понадобилось больше полутора лет. Это было не «просто».
Самую распространённую проблему провалившихся игровых проектов я вижу в том, что их создателей затягивает в болото бесконечной разработки, они теряют интерес и мотивацию, а затем отказываются от своей мечты стать разработчиком игр.
Оказывается, в разработке игр полно скрытых липучих ловушек, которые на первый взгляд кажутся простыми, но вытягивают у разработчиков месяцы и годы работы, пока те, наконец, не откажутся от проекта.
Хорошая новость заключается в том, что вы можете создать интересную игру, при этом не попадаясь во все эти мешающие разработке ловушки.
Взгляните на всех этих дизайнеров игр, считавших, что они смогут быстренько создать MMO в открытом мире с транспортом, PvP и крафтингом процедурно генерируемого двуручного оружия.
Задача этого поста — дать определение «простой игры», чтобы вы могли реализовать свою цель и выпустить игру.
Серьёзный разговор
Я буду очень консервативен в перечислении тех игр, которые можно считать простыми. Дело в том, что в процессе создания игра всегда расширяется, пытаясь заполнить весь вакуум, и чтобы на самом деле закончить простую игру, вам нужно сдерживать себя.
Некоторые могут сказать, что мои примеры полны не очень оригинальных игровых идей. Или что игра, сделанная по этому списку, не сможет выжить на высоко конкурентном рынке. Или удивятся моей нелюбви к сюжету.
Большинству я могу ответить, что ваша первая игра НЕ будет выделяться. Игры так сложно делать, что вам потребуется чрезвычайно контролируемая среда для их завершения. Вы можете быть потрясающим опытным кодером или отличным художником в большой студии, но на самом деле самостоятельное создание игры требует жонглирования графикой, кодом, дизайном и маркетингом в самых неожиданных для вас сочетаниях. Вам придётся принять 1000 решений, и каждое из них будет увеличивать масштаб игры. Нужно просто настроить правильный баланс, и не стоит при этом взваливать на себя дополнительное бремя создания уникального шедевра, способного остаться в веках. Поэтому для первой попытки сделайте всё необходимое, чтобы игра была выпущена. А уже затем начните сначала и создайте игру своей мечты, которая станет новым словом в жанре «хоррор-фарминг с открытым миром».
Стоит также учесть, что этот список применим к вашей первой паре игр. Когда вы освоитесь с процессом выпуска игр, тогда можете переходить к экспериментам. Повторюсь, я не говорю, что НИКОГДА не нужно делать игр такого типа, я просто советую не браться за них, если вы не выпускали ничего раньше.
И последнее — вам нужна смелость для выпуска своей игры
Существует огромная разница между созданием игры и сохранением её на жёстком диске и настоящим выпуском чего-то в Интернете с получением за это денег.
Будьте смелыми. Выложите свою простую игру и укажите цену в 1 доллар. Да, некоторые люди скажут, что она отстойная и захотят вернуть деньги. Вероятно, они будут правы. Верните им деньги. Но вы должны начать продавать её. Совершенно другой взгляд на вещи возникает, когда вы выпускаете игру под своим именем и просите за неё настоящие деньги. Это может заставить вас трудиться упорнее.
Даже если вы делаете это из любви к созданию игр, а не ради заработка, вам всё равно нужно просить за игру деньги. Игроки честнее (и в плохом, и в хорошем), когда платят вам деньги. Когда кому-то не нравится бесплатная игра, то он просто закрывает её и занимается чем-то другим, поэтому вы не узнаете о ней больше, чем при получении отзыва покупателя.
До выпуска моей первой игры у меня была куча провалившихся проектов. Причина заключалась в том, что где-то в глубине сознания я говорил себе, что просто учусь и нарабатываю опыт. Поэтому я легче забрасывал свои проекты, не доходя до их завершения.
Одной из первых провалившихся попыток был клон Tetris. В какой-то момент я реализовал всего 4 из 7 тетромино и сказал себе: «Я уже достаточно понял, как всё будет дальше, и взял от этого всё, что нужно», после чего забросил проект. Я ошибался! На самом деле я не научился ничему.
Даже если вы написали игру, в которую можно играть, и в ней есть даже экран Game Over, то это ещё не значит, что она завершена. Она готова всего на 10%. С ней ещё нужно сделать очень многое: реализовать API магазина, сохранения, маркетинговые материалы, меню опций, и, наконец, усовершенствование игры до такого состояния, чтобы люди согласились выкладывать за неё деньги. Если вы выложите игру в магазин и поставите цену в 1 доллар, то на вас дополнительно будет давить общество, что заставит вас больше стараться. Даже если для вас это всего лишь хобби, всё равно продавайте игру.
Кроме того, вам нужно осознать тот факт, что игра не станет хитом. Вы — новый разработчик игр, о котором никто не слышал. Чего же вы ожидаете? Более подробно эта тема рассмотрена в ещё одной моей статье.
Игровая пресса любит писать радужные истории о любителях-разработчиках, заработавших миллионы долларов на своей первой игре. Поймите — это чрезвычайно редкие случаи. И то, что ваша первая игра неидеальна, не означает, что однажды вы не создадите шедевр. Это не значит, что вы не гений. Двигайтесь дальше и продолжайте выпускать игры. Большинство из нас просто возвращается к работе и продолжает выпуск.
Так что же такое «простая игра»?
На самом деле я дам определение через описание того, что «простым» не является. Многие из этих ошибок я совершил в собственном процессе разработки. Рядом с каждой из ловушек, в которые попался сам, я поставил звёздочку. Пожалуйста, не повторяйте моих ошибок.
(Ещё одно напоминание, если вы не прочитали моё предыдущее примечание)... Я не говорю, что вам никогда не нужно делать игры с такими характеристиками… Я просто имею в виду, что не надо пытаться реализовать их в ПЕРВОЙ игре. В разработке игр есть скрытые ловушки, которые могут отвлечь вас и растянуть процесс работы, увеличивая вероятность того, что вы забросите свой почётный труд.
Не попадайтесь в такие ловушки:
* Игра с сюжетом
Для вас это может оказаться разочарованием, если вас привлекают игры с богатым лором, сюжетом и персонажами классических RPG. Однако создание целостного сюжета — трудный навык, которому сложно научиться.
Попытка жонглировать персонажами, многоактной структурой, кульминацией, развязкой и темами, одновременно с освоением технологий для точной передачи всех этих аспектов похожа на попытку сборки корабля в бутылке во время управления настоящим кораблём посреди урагана.
В процессе разработки вы столкнётесь с конфликтом сюжета и геймплея в виде лудонарративного диссонанса, и вам придётся переделывать геймплей или сюжет, или и то, и другое. НЕ НАДО пытаться реализовать это в первой игре.
* Игры с головоломками
Если вас вдохновили на создание собственной игры Braid, Limbo, Talos Principle или более новые игры, например, Gorogoa, то будьте осторожны. Головоломки очень непросто сделать достаточно сложными, чтобы они были интересными, но не такими сложными, чтобы люди отказались от игры. Чтобы попасть в это игольное ушко, вам придётся постоянно тестировать игру на пользователях, которые никогда в неё не играли, и рекалибровать каждую головоломку, добиваясь нужного уровня сложности. Это значит, что вам придётся постоянно перерабатывать игру, чтобы сделать её интересной. Создание игры на основе головоломок на самом деле похоже на создание игры, составленной из нескольких маленьких.
* Диалоги
Этот пункт связан с пунктом о сюжете. Это скользкая дорожка в болото нарратива, поскольку если у вас есть диалоги, то как только персонажи открывают рот, они начинают рассказывать истории.
Мультиплеер
Хотя в такие игры очень интересно играть, вы потратите кучу времени на балансировку правил, чтобы они ощущались справедливыми. Единственный способ протестировать свою игру — найти людей, которые будут играть против друг друга, и это ещё одна ноша, замедляющая процесс разработки. Кроме того, после выпуска сложно будет найти одного человека, который бы согласился купить игру, когда в ней ещё недостаточно игроков, против которых можно играть.
Сетевая часть
Писать сетевой код сложно, и вы потратите много времени на его правильную реализацию ещё до того, как приступите к работе над самой игрой. Кроме того, сетевой код подразумевает, что вы скорее всего будете разрабатывать мультиплеерную игру или MMO. См. пункты «Мультиплеер» и «MMO».
Открытый мир
Если в вашу игру неинтересно играть в одной комнате, то она не будет интересна и в открытом мире. Сначала изучите основы того, как сделать игру интересной, а потом создайте открытый мир в сиквеле. Единственное, что значит открытый мир — вам нужно будет создавать целую кучу контента, чтобы игроки не чувствовали, что исследуют пустыню.
Искусственный интеллект
Проблема с ИИ в том, что он может высосать бесконечно много времени разработки всего лишь с минимальными улучшениями. Вместо этого попытайтесь сосредоточиться на играх, позволяющих обойтись заданием простого поведения врагов — пусть они случайным образом бегают вокруг или движутся к игроку по прямой.
Процедурная генерация
То же самое, что и с ИИ. Вы можете потратить бесконечную прорву времени, в каждой итерацией внося только минимальные улучшения. Если вам действительно нужно внести вариативность в мир, сделайте его случайным и на этом остановитесь.
* Платформер (и 2D, и 3D)
Я знаю, что Super Mario Bros. выглядит очень простой, но на самом деле это не так. Создание платформера, который «ощущается» правильным — чрезвычайно сложная задача. Вы потратите кучу времени на правильную реализацию физики. Если вам не удастся это, то ощущения от игры будут ужасными. Не пробуйте делать этого в своей первой игре.
* Игра, действие которой происходит в кругу
Это красивая схема, но одновременно и ловушка, на которую вы потратите много лишнего времени разработки. Любая игра, которая интересна на круге, интересна и на прямой. Управление в круговых играх очень хитрое и его сложно реализовать правильно.
Rotato была «простой игрой», из-за которой я дополнил список этим пунктом. Не повторяйте моей ошибки.
* Катсцены
Катсцены кажутся безобидными. Но если в вашей игре нужна катсцена, то это показывает, что в ней есть нарратив. Хуже всего то, что «катсцены порождают катсцены». Если у вас есть катсцена в начале игры, то значит, что понадобится и в конце, а потом вам понадобится создавать контент для заполнения времени между началом и концом. См. пункт «Игра с сюжетом».
Босс
Это ещё один тайный намёк на то, что в вашей игре есть нарратив. Наличие босса означает, что у вас есть какой-то контент, приводящий к нему, то есть для приближения к боссу нужно увеличить напряжённость игры. А после победы над боссом потребуется анимация кульминации победы. Более того, битвы с боссами сами по себе являются головоломками, в которые нужно добавлять слабые места босса, фразы и его различные формы.
* Уровни
Под уровнями я подразумеваю создаваемый вручную контент, который игрок пройдёт за малую долю того времени, которое вам понадобилось для его создания. Вам может потребоваться месяц на то, что игрок может потребить меньше, чем за 30 минут. Вместо уровней задумайтесь об использовании алгоритмических волн. Каждая волна должна быть немного сложнее предыдущей, потому что мы привязываем сложность (скорость, здоровье, наносимый урон врага и т.д.) к постоянно растущей кривой функции. Но не слишком углубляйтесь в алгоритм (см. пункт «Процедурная генерация»).
MMO
См. все вышеперечисленные пункты.
Что же нам остаётся?
Это был довольно жестокий список, и я думаю, что вы уже думаете, какие же игры ещё остались, укладывающиеся в эти ограничения.
Хорошая новость — творчество возникает из ограничений. Когда вы устанавливаете жёсткие границы, то испытаете больше прозрений, чем просто смотря на пустой экран, когда вам доступна любая возможность.
Это Чак Клоуз. У него прозопагнозия, он пережил инсульт и страдает параличом, но тем не менее создаёт на удивление творческие картины. Думаю, вы можете попробовать создать игру с меньшими ограничениями, чем у него.
Начните с основ видеоигр
Если вы всё ещё не знаете, с чего начать, то вам стоит взглянуть на историю видеоигр. Оказывается, большинство аркадных игр того периода, начиная с 1962 года (с выпуска Spacewar) до Donkey Kong из 1982 года, смогли избежать этих хитрых игровых ловушек. Ниже я перечислю хорошие источники вдохновения для выбора начальной точки. Я разделил их на категории:
Игры со столкновениями — Pong (1972 год), Breakout (1976 год)
Стрелялки — Galaga (1981 год), Space Invaders (1978 год), Centipede (1980 год)
Серии препятствий — Frogger (1981), Marble Madness (1984)
Шутеры — Robotron 2084 (1982), Gauntlet (1985), Asteroids (1979), Missile Command (1980)
Игры-скроллеры — Spy Hunter (1983), Toobin (1988)
Игры-собиралки — Pacman (1980), Crystal Castles (1982), «Змейка»
Головоломки — Tetris (1984), Klax
Игры на точность — боулинг, гольф
Игры про строительство и разрушение — Rampart (1980)
Головоломки с повторением — Sudoku (1979), Solitaire, Minesweeper (1989)
Игры со световым пистолетом — Duck Hunt (1984), Operation Wolf (1987)
Игры с подъёмными кранами
Дона Бейли — создательница одной из самых качественно разработанных игр всех времён: Centipede. Кроме того, это на удивление «простая» игра.
Эти старые игры обычно оставались простыми из-за технических ограничений, а также из-за их бизнес-модели — игроки должны были скармливать аркадным автоматам как можно больше четвертаков. Если вы «пройдёте» одну из этих игр, то скорее всего, больше к ней не вернётесь. То есть прохождение должно быть основано на постепенном увеличении сложности базового игрового цикла. Каждая волна врагов должна приближаться к вам быстрее и наносить больше урона.
Цель игрока — не наблюдать за тем, как развивается сюжет. Он пытается попасть в таблицу лучших. Дизайнеры первого Pacman даже не ожидали завершения игры, они просто позволяли памяти закончиться, после чего игра зависала.
Игре Pacman не нужен был конец, всё заканчивалось переполнением памяти.
Существуют и современные простые игры
Хотя они стали гораздо более развитыми по сравнению со своими предшественниками с автоматов, у них всё равно очень простой игровой цикл. Но следует учесть, что к ним было добавлено множество непростых элементов, чтобы они ощущались современными. Однако если рассмотреть базовый игровой цикл, то они всё равно остаются «простыми играми».
- Игры жанра Tower Defense
- Fruit Ninja
- Plants vs Zombies
- Физические игры: Goat Simulator 2014, Angry Birds 2009
- Bejeweled 2001
- Doodle Jump 2009
В целом, интересность всех этих простых игр заключается в выполнении одной из этих простых задач:
- Набрать максимальное количество очков
- Уничтожить всё на экране
- Собрать всё на экране
- Объединить или выровнять всё на экране
Игры, которые кажутся простыми, но на самом деле являются ловушками
Хотя раскопки истории игр в поисках идей — это отличный способ нахождения простых игр, стоит быть аккуратными, потому что и в некоторых из них есть ловушки:
Сайд-скроллеры и платформеры
Примеры: Donkey Kong, Burger Time, Moon Patrol, Joust, Super Mario Brothers. Успех или провал платформеров определяется ощущениями от них. Вам могут потребоваться годы практики программирования, множество проб и ошибок, чтобы набраться достаточно опыта для создания правильного платформера. Если вы попробуете разрабатывать их как первую игру, то существует реальная опасность потратить кучу времени на обеспечение правильного поведения игры. Отложите платформеры на то время, когда лучше освоите создание игр.
Адвенчуры
Программирование простейшего движка адвенчуры — на самом деле достаточно простая задача. БОльшая часть логики заключается в анимировании персонажей и проверке того, перетащили ли объект A на объект B. Однако вы быстро столкнётесь с двухголовой проблемой: сюжетом и головоломками. На разработку адвенчуры вы можете запросто потратить годы работы.
Roguelike
Да, они возникли ещё в 1980 году и в них почти нет графики. Поэтому кажется, что они могут стать отличным выбором для создания простой игры. Однако здесь липкая ловушка заключается в процедурной генерации. Более того, при разработке rogue-like существует искушение создания бесконечной глубины симуляции. Просто посмотрите на то, сколько времени находится в разработке Dwarf Fortress. Сложность rogue-like можно повышать бесконечно, так что опасайтесь.
Опасайтесь сирен процедурной генерации
Как сделать так, чтобы разработка простой игры не надоела
Допустим, вы нашли идеальный, простой базовый цикл. Вы решили, что целью игры будет получение очков, а прохождение выполняться волнами. Но вы не чувствуете радости. Вам нужна мотивация.
На этом этапе мой совет вам: режьте, режьте, кромсайте и снова режьте. Но в простую игру определённо стоит следующие элементы.
«Сок» и тряска экрана
Даже если ваш базовый игровой цикл стар, как эра Рейгана, это не значит, что такой же должна быть и графика. Приправьте её специями и мелочами — это одна из самых интересных вещей в разработке игр. Графика и «сок» добавляют игре интересности. Лучше всего это демонстрирует следующая пара видео. Посмотрите их и добавьте как можно больше мелочей в вашу простую игру.
Маркетинг
Да, я помню, что советовал вам готовиться к провалу первой игры. Но есть вероятность того, что ваша игра станет виральной. Поэтому всегда следует добавлять возможность подписаться на ваш список рассылки внутри игры. Когда вы будете делать вторую, не такую простую игру, то вам нужно будет связаться с игроками, которые нашли первую.
Тема
Мне не нравится сюжет. Это ловушка. Но незначительными штрихами можно добавить в игру эмоциональную глубину. Один из лучших примеров этого — CANABALT. Эта игра — ПОЧТИ идеальный пример простой игры (в ней есть 2d-платформинг, который может оказаться сложным для первой игры). Простой дизайн (набор очков в зависимости от пройденного расстояния и бесконечно увеличивающаяся сложность) сочетается в ней с загадочным антуражем, превосходящим основной игровой цикл.
Почему этот человек в костюме бежит? Откуда взялись эти роботы-разрушители? Почему звук приглушён? Почему птиц не пугает эта ситуация? Ни на один из этих вопросов нет ответа, но просто добавив захватывающее графическое окружение, авторы без участия диалогов и катсцен создали историю.
В своей простой игре вы должны стремиться к тому же. Добавьте несколько неотвеченных вопросов. Однако чтобы не отклоняться от прямой линии, всегда добавляйте элементы, создающие антураж, а не сюжет.
Не делайте клонов
Мы оглядываемся на классические игры и отбрасываем лишние детали не за тем, чтобы клонировать другую игру. Если вы не копируете слепо дизайн другой игры, то ваша индивидуальность всё равно будет проглядывать. Невозможно полностью скрыть себя из своей работы. При разработке своей игры прислушивайтесь к своей творческой стороне.
Подведём итог
Если вы избежите ловушек, завершите игру и окажетесь достаточно смелым, чтобы опубликовать её, то попадёте в закрытый клуб гейм-дизайнеров. Выпустить игру невероятно сложно, а самым трудным кажется выпуск первой игры.
Многие очень умные и талантливые люди потратили годы на игру, так и не выпустив её, потому что в душе они решили — первая игра должна быть чем-то особенным и точным, в противном случае они просто посредственные гейм-дизайнеры.
Джефф Фогель сказал в контексте разработки RPG следующее, но это относится к любому жанру:
«Разработка RPG похожа на секс. Первый раз ужасен и всё идёт не так. Каждый последующий раз однообразен, а небольшие изменения поддерживают интерес».
У вас всё будет хорошо.
Комментарии (30)
AbstractGaze
28.02.2018 17:02Я вот одного понять не могу. Все статьи, что читаю на данную тематику — рекомендуют начинать с малого. Но, почему нет ни одного подтверждения обратного? Где статьи вроде «Вот начали делать сразу огромный проект, он не взлетел и тогда начали с малого, сделали несколько, и после этого вернулись и создали большой проект»? А то создается ощущение что те, кто делают простые игры — продолжают их делать и в будущем т.е. постоянно.
Я не говорю про коммерчески успешные студии, я говорю про инди (соло) разработчиков, которым и рекомендуют начинать со «складывания кубиков», а не с «создания радиоуправляемой лодки или вертолета».
По моему, если ты учишься складывать кубики — ты только и научишься их складывать. Если нет цели создать что то больше — значит нет смысла искать возможные реализации и собирать информацию для решения возникших трудностей. Этих трудностей просто нет.
Либо ты попадаешь в суровый мир, где пытаешься выжить любыми способами, решая возникшие проблемы при создании своей игры и это тебя развивает.
Либо ты сидишь в удобной песочнице и делаешь «пасхи» по готовым и проверенным шаблонам и будешь там сидеть вечно — без трудностей нет развития. Никто не говорил что создавать игры это легко.Azoh
28.02.2018 21:03Советуют в основном из-за того простого факта, что нуля сделать игру сложно. А большую игру невероятно сложно. Ведь многие новички приходят с идеями в стиле "я хочу сделать игру как третий ведьмак, но с добавлением вот этих замечательных идей (тут идет перечисление на три листа)".
Почти любая деятельность начинается с небольших проектов, где люди оттачивают базовые навыки, которые нужны постоянно. При этом разработка игр сложна тем, что требует множество различных навыков. И один из самых сложных — умение управлять проектами, даже большие успешные студии, делающие AAA проекты, постоянно испытывают сложности с этим. Сделав небольшой работающий проект будет уже понятно, что программисты умеют работать с движком и реализовывать игровую логику, геймдизайнеры имеют представление о том, как делать и балансировать игровые механики, сценаристы умеют придумывать сюжет и делать интересных персонажей, и т.д.
Более того, на поздних стадиях начинаются задачи, которые на начальных этапах вообще никак не появляются. Поиск издателя, работа с сообществом, даже банальный вопрос того, как об этой игре будут узнавать будущие игроки. И будет очень грустно, если крупный проект, который довели невероятными усилиями до приемлемого состояния, развалится на этой стадии. У начинающих студий чаще всего нет людей, которые это уже умеют. Просто потому что эти все вопросы решили люди, которые выпустили уже игру. И нужно либо в экстренном режиме получать новые знания, либо искать новых людей, которые это умеют.
Поэтому небольшой проект даст хотя бы некоторое представление о том, способны ли эти люди в принципе реализовать что-то. Очень просто может оказаться, что на каком-то этапе часть потеряет интерес, часть поссорится со всеми, часть окажется просто плохи в том, за что они взялись, а часть поймет, что разработка игр им на самом деле не интересно, а они хотят от жизни что-то совсем другое.
Коммерческое инди имеет довольно узкий коридор целесообразности проектов (я не говорю про тех, кто это делает по фану, получая основные средства из других источников). Типичная инди студия не обладает огромным бюджетом для разработки в течении долгого времени большой коммандой. Игру нужно сделать в краткие сроки ограниченным количеством людей, либо будет грустно и голодно. Даже если задумывать большой проект, нужно из него выделить небольшую часть, которую можно быстро сделать и выпустить, начав получать средства на дальнейшее развитие. Поэтому многие остаются на уровне некрупных проектов. Они нашли свою нишу, где они делают хорошие, продаваемые проекты, которые приносят стабильный доход.
Плохо ли это? Зависит от ситуации конкретного человека или студии. Готовы ли они на большой риск? Есть ли у него семья? Скажем, студия может начать с кучки 20-летних студентов, готовых работать за
едуидею. Но время идет, у кого-то появилась семья, кто-то взял ипотеку, кто-то не может работать в авральном режиме за копейки, кто-то просто хочет более высокий уровень жизни. Крупный проект может иметь цикл разработки в несколько лет. И если начать с него, то высока вероятность, что к этому моменту он будет просто не готов, а люди не будут готовы продолжать работать за идею.
Поэтому многие статьи сразу говорят "не пытайтесь откусить сразу столько, сколько вы не сможете прожевать".
AbstractGaze
28.02.2018 21:51Вот опять… я слышу фразу «крупный проект невероятно сложно».Я не вижу разницы в сложности сделать платформер или ммо или квест, в каждом свои сложности, в ммо это больше технических сложностей, в квесте надо считай написать целую книгу — это не техническая сложность, но потребует возможно даже больше времени, то же время в рпг где нужно «создать» целый мир, а это книжка может быть еще толще, чем в квесте.
Логично что «крупный проект» это несколько лет, даже простой проект займет много времени, по мне так от года, пусть и проскакивали статьи «как я сделал игру за месяц». Тут скорее зависит от уже имеющихся навыков, и те которые надо поднимать с нуля.
Вот вам самим не кажется, что все в подобных статьях заменяют слово «долго» на «сложно», потому что большинство не может оценить затрачиваемое время и усилия, и поэтому выгорает через пол года год, а не потому что, что то не могут сделать. По мне, так если брать техническую сторону, то это может сделать вообще любой (ну или почти) — было бы желание.Azoh
01.03.2018 00:23Нет, не кажется. Если проект делать очень долго, то это уже сильно добавляет сложности само по себе. У людей есть жизнь, которая имеет ограниченную продолжительность, и потребности, которые требуют материальных ресурсов для их удовлетворения. И выгорание — реальность жизни, если человек готов потратить полгода на проект, значит нужен проект на полгода. Либо нужен другой человек через полгода.
Грубо говоря, есть большая разница в организационной сложности. Большим, продолжительным проектом значительно труднее управлять, планирование становится кошмаром, бюджеты сложно оценивать, а из-за постоянных изменений (которые неизбежно будут) все заранее намеченные вчера планы завтра могут кардинально измениться. Более того, сложившаяся практика управления может быть просто не подходящей для доведения проекта до конца. В конечном счете, именно управление процессами может спасти или утопить проект при том самом выгорании.
Во-вторых, есть большая разница в сложности создания цельного и увлекательного игрового процесса. Множество различных механик порождает огоромное количество сочетаний, добавление новых влечет изменения в старых, которые порождают новые изменения и т.д. Это такой порочный круг, причем большее число механик делают круг только больше. И это только на стадии их создания. Потом, после их реализации, приходит понимание о необходимости изменений, по разным причинам, от простых "это не интересно" или "это сильно сложно" до классической "это отрицательно влияет на игровой баланс". В итоге может получиться, что вроде и возможностей очень много, но чего-то цельного не получается. Иногда идеи просто не работают.
В-третьих, техническая сложность нелинейна от размера. Чем больше кодовая база, тем сложнее вносить дополнения или изменения. А так как стабилизация требований будет происходить очень поздно в цикле разработки, это повлечет огромное количество этих самых изменений. Что очень часто негативно сказывается на качестве.
В конечном счете "невероятно сложно" значит очень простое "очень мало кто на это способен". И неспособность потратить на что-то неограниченное количество времени — одна из причин. Точно так же почти кто угодно может (в теории) переплыть Ла-Манш, но сколько людей реально это могут?
AbstractGaze
01.03.2018 08:18Точно так же почти кто угодно может (в теории) переплыть Ла-Манш, но сколько людей реально это могут?
А скольким людям это действительно нужно? Вот у тебя цель — переплыть Ла-Манш, а тебе говорят, переплыви переплыви реку в 4 метра ширины. Переплыть реку сможет любой кто хоть чуть чуть умеет плавать, да даже держаться на воде.
Даже если вы переплыли 100 рек, это не значит что вам будет легче переплыть Ла-Манш — довольно разные среды.
В данном случае чем это поможет? Да ни чем, человек не научиться плавать долго, переплывая короткие реки. Когда он оценит масштаб Ла-Манша, он пойдет в 100 метровый бассейн и будет без остановки пытаться проплыть этот маршрут, что более менее приблизит его к цели.
А в этой статье так вообще говорят, какая река? вон лужа, там ваше место. Я не вижу чем это поможет в соотношении затрачиваемое время/опыт, с учетом что как вы правильно заметили — у людей есть жизнь, и жизнь имеет свое время.
Про управление проектами мне не рассказывайте, я читал не одну книжку про это, и продолжу читать в будущем, вопрос был не про это, не про сложности организации команды, а про сложность самого процесса. Сколько надо создать простых игр чтобы продвинуться выше? сколько должно пройти времени? 10-20 лет или 10-20 игр? Зачем заниматься не интересной «простой» работой, когда цель поставлена была другая? Почему нельзя заняться сразу, увидеть весь объем проблем и начать их решать? а не делать то, что и так легко получается?
Я ищу ответ на этот вопрос, минусующие наверное знают его, но не отвечают)) А жаль.JustRoo
01.03.2018 09:19Одну простую. Потом одну чуть сложнее. Потом одну ещё чуть-чуть сложнее. И так далее.
С моей точки зрения, тебе говорят «переплыви четырёхметровую реку, а потом переплывай Ла-Манш» не потому, что полученный опыт приблизит тебя к решению задачи (хотя и это тоже, особенно в программировании, где после завершения проекта у тебя остаются и опыт, и куски кода), а потому, что пока ты не переплыл ни одной реки, ты вообще не понимаешь, твоё это или нет. И лучше понять, что на самом деле ты не хочешь этим заниматься, на середине четырёхметровой речки, когда всё, что ты вложил — это пять минут на попробовать, чем на середине Ла-Манша, когда ты уже чёрт знает сколько барахтаешься в этой воде и ненавидишь себя, Ла-Манш, воду и всё человечество.AbstractGaze
01.03.2018 13:16А с другой стороны не смотрели? Может человеку интересно заниматься «сложным» проектом, а не «простым». Да он попробовал простой, увидел что ему не нравиться, и забросит это дело. Пробовать на том, чем ты не хочешь заниматься — как то странно. Это как пробовать писать программы на примере решения математических задач, не нравиться складывать числа — значит писать программы и создавать системы тебе явно не понравиться. Где логика?
JustRoo
01.03.2018 13:29Конечно, кому-то проще так. А кто-то упорно собирается покорять Эверест, хотя мог бы сначала подняться на 500-метровый холм и понять, что ему вообще не нравится ни процесс, ни результат. Сколько людей, столько и подходов =)
antonn
01.03.2018 09:08Вот вам самим не кажется, что все в подобных статьях заменяют слово «долго» на «сложно», потому что большинство не может оценить затрачиваемое время и усилия, и поэтому выгорает через пол года год, а не потому что, что то не могут сделать
Проводя время на сайтах игроделов указанную причину в цитате могу отнести к 50% случаев забрасывания проекта. И еще 49% — это «начало строительство дома с крыши и обоев», что неизменно приводило к первой причине.AbstractGaze
01.03.2018 13:13Вторая причина это замечательный совет подобных статей — сделайте что нибудь визуальное и хоть как то работающее и вам будет легче продолжать. Только почему то никто не пишет, что создав «обои и крышу» к ним привязываются и ничего не могут изменить по своему же желанию, а результат работы через не хочу вполне очевиден.
antonn
01.03.2018 16:11Работая над игрой «своей мечты» (небольшая TD) заставлял прям себя для визуализации обходиться примитивами (рисуя через MoveTo/LineTo линии и кружочки), хотя очень руки чесались приступить наконец к графическому движку и начинать выжимать fps'ы и писать видеоэффекты :) До этого писал так же мелкие TD где графика появилась на пол-пути, и в конце на ней было завязано куча логики (а то и логика была притянута к графике), без вариантов серьезного изменения механики, дорабатывать и развивать такие поделки желания вообще небыло. Так что, не смотря на хотелки в разработке, опыт предыдущих поделок помог соблюдать какой-никакой план разработки, точнее последовательность кодинга способствующая не свалиться в костыли.
Dezk
01.03.2018 13:12Мне кажется тут вопрос мотивации и знания программирования в целом.
Если человек начинает делать игры не имея опыта в программировании, то «складывание кубиков» как раз таки поможет освоить движок и язык. Так же как изучение программирования начинают с простых алгоритмов и программ, а не с большого проекта.
Сужу в том числе по своему опыту: я уже около 5 лет работаю как .Net разработчик, уже год делаю свою игру (как хобби проект) и очень ограничиваю свою фантазию, чтобы наконец его закончить. Например: пошаговый бой (облегчает обработку команд игрока и ИИ), боевой ИИ просто выбирает действие по скриптованым приоритетам, перемещения в бою опять же нет.
И опыт промышленной разработки очень помогает в структурировании кода, в моём представлении человек который с нуля хочет стать инди и начинает сразу с ммо просто запутается в своём коде и игра так и не получится.AbstractGaze
01.03.2018 13:24Все правильно. Я про это в принципе и говорю.
Вот инди разработичк, ему советую сделать простую игру перед началом того, что он хочет. Для создания совсем простой игры, сейчас, не надо знать программирования и много чего еще. Можно в каком нибудь гейммейкере мышкой набросать и «игра» будет работать. Человек это сделает, может быть займется продвижением, потратит на это год. Результат?
А в результате он пойдет дальше, увидит что ему все же нужно знать программирование и надо начинать его изучать — а вот год, который он занимался тыканьем мышкой — по сути потрачен зря. Вероятно даже что 80% навыков, которые он использовал даже не понадобятся. А ведь может понадобиться не только программирования, точнее этого точно будет мало.
Разве это не отодвинет еще дальше от намеченной цели? Ведь сейчас у него бы уже были азы программирования, и возможно он бы уже мог устроиться допустим на основной работе уже по этой специальности и совмещать хобби с работой.
Я считаю, что начиная с того что ты хочешь, ты определишь для себя многие основные проблемы и технологии которые надо узнать, и начнешь их решать/изучать сразу или стремиться к этому, не отвлекаясь на другое, что по большому счету скорее всего даже не понадобиться.
ToshiruWang
01.03.2018 14:04Почему все рекомендуют начинать с прописей и никто с написания трилогии?
Те, кто начинал делать проэкт, где 5 разных расс, тонны оружия и обязательный онлайн — так и остались на уровне поста в gamedev.ru с узнаваемой грамотностью (некоторые слова стали даже отдельными терминами — пара строчкой выше есть).
Я не вижу разницы в сложности сделать платформер или ммо или квест
Сложность ММО уже в первой букве (да вообще в каждой), без понимания этого не понять остального.
AbstractGaze
01.03.2018 14:12-1А вы уверены, что они остались на уровне поста по этой причине, а не потому что они любой проект не продвинули бы дальше написания краткой идеи? Я вот не уверен.
Вы обратные примеры видели? Только не примеры которые развивались вместе с игровой индустрией, а современные, скажем за последние лет 5?ToshiruWang
01.03.2018 16:14Есть вариант что те, кто смогли — начали с минимального. Пример сразу крупного проекта, который видел — E5 (но это не 5 лет назад), но его хитрость в том, что он не был сразу крупным, первые несколько лет(!) это было вообще потихоньку развивающееся технодемо движка и только потом, после появления издателя, оно стало игрой.
А вот так сразу написать игру/ОС/СУБД или ещё что, то как-то не приходят на ум.
tas
01.03.2018 10:14Добавлю еще одну потенциальную мину разработки игр — готовый инструментарий к неготовой игре. Это актуально не для всех игр, но если все таки актуально, то многие на него попадаются…
В какой-то момент разработки Вы поймете, что Вам нужно либо создавать библиотеку контента, либо генерировать его случайным образом.
Создавать библиотеку вручную довольно муторно, кроме того во многих случаях генерация случайного контента является несомненным плюсом игры, поэтому Вы говорите себе: «Я сейчас сделаю генератор и потом буду использовать его в игре, и это будет хорошо!».
После какого-то времени разработки этого у Вас получается отличный генератор, но сил на саму игру уже не хватает… Даже если сил хватает, то неготовая игра еще «дышит» и может значительно меняться — это нормально. Но у Вас уже есть готовый инструментарий, который необходимо поддерживать, чтобы он соответствовал изменениям игры. И силы уходят не туда…
Правильно делать игру с MIN контента и лишь на финальной стадии делать инструментарий…
k0t0vich
01.03.2018 14:30+1Да. Очень распространённая ошибка пилить игровой движок, вместо, собственно, игры)
Как пример — Alternativa3D.
Есть и обратные примеры — это store.steampowered.com/app/466560/Northgard для которого написали новый движок (heaps), на своём языке(haxe).
Правда это далеко не первый проект.
Makasin
01.03.2018 10:26Автор в статье приводит ссылку на свои игры и я решил рассмотреть их подробнее на предмет того, насколько можно доверять его опыту.
Итак, начнем с того, что автор пишет «обязательно продайте игру, не выкладывайте в свободный доступ». Однако у него они все бесплатны.
Pixel Art Shooter.
«Pixel Art Shooter is a physics-based puzzle game» — цитата из описания. Игра не основана на физике, шарики просто падают вниз, без сложных столкновений или чего-то такого. С тем же успехом можно и тетрис так назвать. Хотя нет, после более детального осмотра физика там нашлась (если подбить шар в полете — он вылетит за пределы экрана), просто в геймплее она роли не играет.
Ужасное управление, клавиши от 1 до 6 и энтер, цифру еще и нужно держать пока шар летит. Управление щелчком мыши было бы проще и интуитивнее, реализовать его в GameMaker'e (а игра сделана там) было бы не сложнее. Еще HTML5 и книжная ориентация намекают на то, что игра для мобильных платформ, что делает управление еще более странным.
С самого начала нет никакого туториала или даже намеченной цели, но это не такая уж и проблема, ведь вся игра сводится к раскладыванию шариков по цветам и выкидыванию лишних за пределы поля. Если сделать это проще и красочнее — может получиться неплохая игра для детей до пяти лет.
Rogue Drop.
Для того, чтобы в неё поиграть нужно послать автору письмо, чего я не буду делать. Хватит и тех нескольких скриношотов.
Итак, пиксельарт. Просто и примитивно, рисуй в Paint'e как хочешь, пихай в игру и будет хорошо? Нет, нет и нет. На скриншотах как-раз яркие примеры плохого обращение с пиксельартом. Видите, некоторые пиксели словно прямоугольные и в целом картинка выходит кривой? Это связано с тем, что нельзя масштабировать пиксельную графику на значения не кратные степеням двойки. Звучит сложно, но написано чуть ли не в каждом адекватном туториале на тему. Особенно ужасно, кстати, это отразилось на шрифтах. Еще нельзя поворачивать отдельно взятый спрайт на произвольное значение. Да и вообще поворачивать нельзя, нужно рисовать отдельно. Что выходит видно на первом же скриншоте.
Zombie Ride Share.
Даже не буду долго задерживаться. Это не игра. На GameMakere такую поделку за вечер сделает школьник не имеющий опыта в программировании, а при небольшом опыте работы в программе — и вовсе минут за 15.
Wizard Golf RPG.
Увы, не имею яблочной продукции, чтобы посмотреть а по ссылке (!) скриншоты недоступны. Даже не могу уверенно сказать, своя у автора графика или из ресурс-пака.
Drill Planet.
Пример того, как делать не нужно, а именно не нужно выпускать игру, которую даже не пытался тестировать.
Третья кнопка в меню: окошко с именем переменной «global.HiScore» вместо значения. Ну ошибся человек, поставил, зачем-то, лишние кавычки в коде, но разве трудно проверить хоть раз одну из трёх кнопок?
Опять же, в игре нет туториала. Да, она примитивна, но туториал — это одно из обязательных требований издателей к таким играм. Еще одно — паузу, которой здесь тоже нет. Зато есть стирание рекорда без подтверждения. Графика из ресурс-пака, кстати.
Игровой процесс. При попытке управлять мышью главный герой бежит к курсору, что неинтуитивно на круге-то, и дергается на месте, когда добегает до курсора. А еще становится неуязвим к противникам, уж не представляю, какие там в коде костыли.
Вместо вердикта.
Эта статья написана в духе «я пытался сделать так-то, у меня не получилось, поэтому не пытайтесь и вы». Хотя и написана хорошо, какое-то доверие даже внушает, пока на «игры» автора не взглянешь.Durimar123
01.03.2018 13:01Судя по вашей аналитике вы уже сделали несколько игр, есть удачные?
Makasin
01.03.2018 13:15Увы, в своё время я не наткнулся на такую статью, поэтому разработка моих проектов затянулась. Надеюсь в ближайший год-два один из них увидит свет.
Хотя году в 2015-м, когда пошла мода на такие простые html5-игры я пытался продать раннер, но тщетно. На fgl (сайт-аукцион для flash и html5) до продажи не дошло, а нагло рассылать предложение на почты сайтов мне не хватило настойчивости.
Bookvarenko
01.03.2018 10:38Вычитал в одном форуме про «метод прогрессивного джипега в разработке игр». Суть вкратце: на каждой итерации разработки игра должна быть полностью проходима и закончена. Метод вполне рабочий. Только нужно сразу иметь целостное видение игры перед началом разработки. Тогда всё идёт как по маслу.
Makasin
01.03.2018 13:21Звучит неплохо, но добавит сложностей. В готовый проект зачастую сложнее впихнуть какой-то элемент, чем реализовать его в процессе разработки. Ситуативно, конечно, но все же.
Bookvarenko
01.03.2018 17:24qsp.su/index.php?option=com_agora&task=topic&id=865&Itemid=57 вот, нашёл с помощью гугла многознающего.
zigrus
хочу что бы запуская игру я попадал в игровой процесс
а не пол часа лазил по меню настройки и обучалкам
помню еще на 386 компе что бы запустить игру
нужно было переписывать autoexec.bat и config.sys
подобрать драйвера для звука, мышки, keyrus…
и все это нужно было проделывать чуть ли не для каждой игры.
сейчас таких проблем нет. любую игру можно запустить практически на любом устройстве.
меню игры должно быть второстепенным. чем то дополнительным. откуда можно просто выбрать нужные настройки. а не ждать пока оно загрузится
ToshiruWang
Совет — не надо было их удалять после и не требовалось бы повторной настройки.
И она скажет что хочет DX11
Кассеты заменяются дискетами, дискеты — HDD. скорость загрузки уменьшается, если кто-то не понимает механизма работы (т.е. происхождения ожидания), то что он ищет здесь? Сейчас, к слову, тоже не всё быстро грузится (если не SSD/i7/Vega), хотя я уже и достаточно далёк от самих игр.
zigrus
Ну как обычно, суть не уловили, а второстепенные мысли стали критиковать.
Смысл был в том, что некоторые игроделы, уделяют сотворению меню слишком много внимания. Там и музыка, и графика, и анимация.
А что бы запустить игру нужно пройти целый квест.
ToshiruWang
Если брать «старые времена», то достаточно было запустить экзешник. Если требования выполнены (карта VGA, если игрушка для VGA, переменная окружения прописана один раз для звука), то всё запускается. Один раз надо запустить утилиту конфигурирования — указать что есть, если отличается от дефолта, но это до-PnPные времена, который и был сделан, тобы любая домохозяйка запускать могла.