Color Escape или как я начал делать игры без программирования
Всем привет. Я тут у вас оказывается давно уже существую, и думаю что пора все же выйти из ридонли, и немного начать делиться. Начну издалека — я гуманитарий, который в качестве хобби иногда любит позалипать в инди-поделки и поделать что-нибудь. Началось это давно, но об этом в другой раз.
Самое главное что я понял — что я всё же не программист, а делать игры хочется. И ниже я поделюсь с вами первым результатом, которого мне удалось достичь с помощью Unity и визуального скриптинга Playmaker.
Предыстория
Идея аркады с непереводимым названием и механикой прохождения уровней с использованием цвета возникла у меня еще аж в 2013 году где-то — я тогда только освоил первый Construct и решил принять участие в каком-то джеме, сделав двадэ платформер с простейшими механиками ходьбы-стрельбы по цветным дверям.
Идея настолько мне зашла в плане механики, что я решил удариться в популярный тогда среди двадэшных игроделов пиксельарт, и освоив Construct2 уже на тот момент, я начал делать Color Escape 2 — сиквел придуманного мной шидевра.
На тот момент это был верх моего творческого начала в области геймдева — начиная от рисования и заканчивая сборкой механик и написанием саундтреков. Огромных 6 уровней этой умопомрачительной аркады, вдохновленной различными пиксельартовыми платформерами я таки смог осилить — получился бегающий мистер Шмордон Бримен с цветопушкой. Но Констракт2 и мои знания в нем на тот момент в итоге аннигилировали изза избытка накопившихся багов в ультралагающую 2D беготню.
И я оставил эту затею, предавшись другим непотребствам и утехам.
В итоге скользкая дорожка привела меня в Unity, где мое неумение кодить (и уже стойкое нежелание учиться делать это нормально) было компенсировано Playmaker-ом. Кто не знает, это такое визуальное программирование, аля блюпринты, только стейт-машины. И понабравшись, я решил вспомнить старую идею, и реализовать её — мне давно хотелось чего то простого, бродительного, олдскульного и без претензии на графонии. В общем хотелось самобытной адвенчуры, которую собственно и получилось сделать.
О чем игра?
Никакой затейливой предыстории — мир странного невидимого божка охватил колоровирус и игроку предстоит расчистить все проходы в этих странных архитектурных заведениях от всяких цветастых дверей.
Механика простая — бродим, ищем цвет, стреляем в цветовой замок, стреляем в врагов, и ищем выход. Иногда наступаем на джампер чтобы прыгнуть высоко, иногда заходим в телепорт, чтобы оказаться быстро где-то, иногда катаемся на платформе — просто потому что это миленько и удобненько. В качестве бонуса — собираем жизни, которые тратим, если падаем в бездну (тьма внизу) и лаву (тоже внизу, но приятно-красная). Иногда пользуемся дарами физики и дедушки Ньютона, перетаскивая коробки с места на место.
Цель — пройти уровень, чему будут мешать закрытые цветастые двери и враги.
Цветастые двери кстати есть 7 цветов, в то время как используемых цветов только три — классические RGB. Иногда нужно будет открыть и желтую, и белую дверь, и тут все по правилам смешения — нужно будет в соответствующие замки кинуть нужные цвета.
Как это вышло?
На все про всё у меня ушло ровно три недели. Ну три с половиной пускай.
Где-то после январских праздников, я застрял из-за налоговой в России на пару лишних недель, и дабы не повеситься и не спиться, я решил быстро сделать аркаду. Пайплайн разработки виделся сразу — сначала делаю все базовые механики, потом геометрию, потом уже собираю уровни, меню и озвучиваю.
Так и начал. С помощью плеймейкера все задуманные механики были реализованы, кроме одной.
Джампер оказалось реализовать почти невозможно, так как я использовал стандартный контроллер для движения игрока, а управлять его подпрыгиванием из Playmaker нельзя без ракования. Я же не хотел стрелять себе лишний раз в колено и выбрал менеджерский путь — купил скрипт джампера за 700 рублей на известном фриланс-сайте. Переделывать контроллер на кастомный ради джампера мне было честно лень, поэтому если баги и будут — это всё из-за одного единственного скрипта :D
Первым делом появились все двери и цветные замки. Ну и сами цвета. Откровением стала возможность проектировать всё на уровне объектов — в процессе удалось разобраться как можно внутри объекта контролировать его состояние в зависимости от того, с кем он столкнулся, и при этом контролировать объект столкновения. Проще говоря, каким то чудесным понятным образом очень ловко выстроилась с помощью этого плеймейкера вся механика.
Сложнее всего было с ИИ. Вот его делать еще нужно практиковаться. Пришлось поскачивать сторонних событий и действий из экосистемы плеймейкера, но они с лихвой покрыли потребности. В итоге придумалось три весьма простых аркадных противника, которых можно победить стреляя цветовыми сгустками.
Дальше наступила творческая пора — нужна была визуальная картинка уровней. Я знал сразу, что хочу делать абстракцию, но не понимал какую, пока не наткунлся на фильтр пикселизации для игровой камеры. Тут всё сразу встало на свои места. Этот фильтр позволял скрывать небрежность геометрии, придавая ей определенный абстрактный вид.
Собственно это и знаменовало мои мучения с левел-дизайном. Оказывается юнити 2019.1 не очень хорошо приспособлена для создания уровней, или я слишком сильно хотел все быстро. В общем то левел-дизайн занял примерно столько же времени, сколько и создание механик. Плюс ко всему отняла время калибровка механик, встроенных уже в уровень (господи храни префабы).
Тотальной ошибкой было оставить озвучку (имею ввиду SFX) на потом. Её нужно было делать вместе с созданием механик, а я её делал когда демо уровень уже был собран почти. Поэтому пришлось покорячиться, чтобы некоторые вещи обвесить звуками правильно и не запутаться.
Ну и в конце — сведение. Так я называю процесс описания логики открытия уровней и перехода между ними. Это особый математический изыск для меня как для гуманитария, работать с 0-based системой счисления, выводя на фронт значения с единицы. В общем эти пляски, и еще пляски с поломавшимся канвасом, заняли еще пару дней.
День ушел на озвучку демоуровня, который по сути есть туториал в игре, и всё. Задумка реализована, дальше можно просто клепать уровни из готовой геометрии и механик — при прохождении уровня, будет открываться новый в списке. Остается только сделать глобальное сохранение, чтобы при выходе из игры, прохождение сохранялось.
ОПРОБОВАТЬ
Ссылка на ИТЧ
(игра доступна для скачивания бесплатно если что. В ней готов один уровень — туториал)
Планы
Делается это все в качестве личного времяпрепровождения и демонстранции того, что 3Д игры можно делать без кода, поэтому в какой то момент может и забыться-забиться. Но я думаю, что штук 10 уровней я соберу для этой бродилки, и возможно выкину ее в стим. Еще у меня есть желание завести туториал-блог о плеймекере, на примере создания игры показывая (в качестве видео или текста) как работать с плеймекером — оказалось что в русегменте такого нет. Возможно потому что и не нужно)
Вопрос сыгравшим
Архитектура демоуровня состоит из трех «стилей» визуально:
— монументализм (большие просторные изолированные пространства, открытое небо)
— камерность (узко, закрыто со всех сторон, коридорность)
— опенспейс (платформы и пространство)
На ваш взгляд, основные уровни стоит делать придерживаясь какого из этих трех стилей? Само собой, цвета уровней будут не серые и белые всегда).
- 08 февраля 2022, 18:36
- 014
Всё шло неплохо, пока я не дошёл до джамперов. Возможно их код не учитывает FPS. Но меня они закидывали слишком высоко.
Монументализм мне понравился, озвучка прикольная и в целом атмосфера в игре имеется.
Хотелось бы чтобы персонаж двигался побыстрее, довольно скучно было ходить собирать цвета для белой двери.
да, про скорость мне уже все сказали)) видимо я на своем ноуте привык ко всему не быстрому) спасибо.
Про джампер занятно - это единственный скрипт в игре, написанный именно кодом и не мной, и он как раз учитывает FPS)
Насчет монументализма - советую слегка почерпать вдохновения из https://gamin.me/games/naissancee
А так, прикольно. Удачи!
спасибо)
Unreal Tournment '99 - тоже хороший источник вдохновения.
Знакомый ник, да ты, похоже, с сайта xgm! Помню, как в детстве лепили на том сайте карты к Warcraft 3 :D
именно! Я даже если постараюсь найду твои карты у себя сейчас =D
да, это я, и теперь развлекаю себя юнити, иногда задумываясь, а не перенести ли карту из вара в самостоятельную поделку, пока борода не поседела еще
Лучше найди в профиле более свежие мои игры. :D Карту я вроде выкладывал только одну последнюю долгостройную, а остальные умерли вместе с жёстким диском.
Твои я, к сожалению, уже не помню, возможно, они были мультиплеерные, а у меня тогда был интернет через 2.5G тормозной и по 5 рублей за мегабайт, и я в такие не мог сыграть.
Удачи с движками! Если карта была годной, то почему нет. А я наоборот задумываюсь снова поделать немного карт к чему-нибудь, так как в моддинге можно сразу делать суть, не тратя время на фундамент.
Кстати, тут лайк ставится мечом, а не сердечком.
я сделал одну единственную карту, которая собственно и просится перенестись в юнити - зомби в деревне))
Игры посмотрю на досуге)
Насчет моддинга согласен - изза наличия контента там как то проще геймплей и историю выложить, нежели с движками, когда приходится сначала попотеть над фундаментом. С другой стороны, с движками больше свободы в этом плане для фантазии.
Выглядит интересно.
Удачи в разработке! =)
хм. насчет жизней интересно. должно было увеличиться.
а откидывать - эт я перенял из платформеров каких то старых))
спасибо, комменты по делу)
Пробежался ещё раз:
привидения да, должны через стену проходить, это факт (фича выросшая из бага)
насчет попал-не попал - тут да, оказывается игроки спешат вперед и не смотрят попали или нет. Судя по всему надо как то более явно отмечать попадание, через наложение фильтра на экран или вроде того. Или вообще материал менять замку.
Пока ничто не может заменить программирование
так про замену никто и не говорил) просто я решил для себя что программирование мне нет необходимости учить (уже или пока) для решения задуманных задач. А если учесть что стейт-машина и события в ней это просто визуальная обертка для кода который работает по принципу "инпут-действие-аутпут", то тут как то и язык особо не поворачивается сравнивать код и его визуальное решение. Это одновременно и одно и тоже, и два разных феномена.
Ну в общем то и зря) Тут разница только в форме, а так все это - программирование, и я бы не стал противопоставлять: эвенты, ноды и скрипты. Мне после констракта 2-3, совсем не зашла нодовая система (пробовал и плеймейкер и болт). Простой скрипт в Visual Studio больше похож на то как программируется логика в констракте, да и просто кажется удобней.
тут солидарен, я вообще после триггеров в редакторе Wc3 болезенно к любоей альтернативной системе построения логики относился)) констракт поначалу тоже боль вызывал, но потом как то свыкся. А нодовую систему пробовал несколько раз вообще освоить, и каждый раз получал провал. Сейчас более менее соориентировался, но появлися новый барьер - который возник как раз изза того, что это все тоже программирование - некоторые сущности мало понятны в событиях и иногда не понимаешь чем они могут быть полезны и как они работают)
Привет ! Я пробовал unity3d, с программированием я знаком достаточно хорошо (у меня и движок свой есть написанный на c++ directx 9) и в арсенале знание других движков - phaser, немного game maker studio и вот godot. На phaser есть несколько завершенных игр. На своем движке их очень много (по-моему уже более 20 штук), на godot 3.4 делаю первую (пока что), игру, которая продолжает идеи предыдущего проекта на своем движке. Возможно если разрешат использовать наработки по игре - поучаствую с ней в конкурсе.
Насчет твоей игры. Мне unity3d сам по себе не нравится как движок. Слишком он громоздкий и игры на нем тяжелые - требования у них высокие. Если есть из чего выбирать - а выбирать есть из чего, то unity3d для меня движок который я вряд ли буду серьезно использовал. Немного изучал его, но дальше и глубже не стал.
Тем более он не с открытым кодом, как, например godot. game maker studio например более легкий движок как в плане создаваемых игр, так и для работы с ним. Но тоже с закрытым кодом.
И вот я добрался до godot 3.4.2.stable.
Делать игру без программирования в godot тоже можно. Но насколько понял эта система не самая удобная. Программировать на gd скрипт там удобнее. Там есть и поддержка c# тоже. Но пока нет необходимости (не пробовал).
Если с программированием совсем швах, то создание игры на blue-принтах, т. е. визуальным программированием - это конечно то еще извращение (как я считаю), ни в коей мере не пытаюсь обидеть, просто когда ты напрямую пишешь код - свободы гораздо больше.
А так ты зависишь от движка, от реализации визуального функционала. Слишком много зависимостей. Тяжело в таком случае сделать игру, которую хочешь. Если только такую - какая получится.
Изучить программирование, понятное дело, сложно человеку, который не понимает сути того, как там все устроено и работает. Не дано. Что поделаешь.
Поэтому не представляю себе, как я бы делал игры, не умея программировать )))
У тебя получилась (как мне показалось) чем-то похожее на DeBlob (может слышал про такую игру ?) только там надо красить не двери, а целые здания.
Поэтому что сказать ? Нужно убежать от идеи делать игры таким образом и все-таки попробовать делать игру методом программирования.
Начинать нужно с основ, с азов - и постепенно. У меня на сайте есть уроки по godot, если вдруг интересно - можешь ознакомиться. Это уроки которые я делал сам для себя изучая godot 3.4 ну и может кому-то еще пригодятся.
визуальная новелла на godot 3.4
Т. е. пошагово можно понять как делать игру. Причем не самую сложную - визуальную новеллу с элементами других жанров.
Я godot освоил практически за несколько дней.
Конечно тут всегда есть барьеры - нет времени, нет желания, страшно изучать что-то новое, не умею, не смогу, не получится и т. п.
Но если их преодолеешь - думаю все получится.
Game maker studio не советую изучать. Не потому что он плох. Как раз наоборот - это более старый движок - времен еще когда вообще движков не было, а потому и функционал там более богатый.
godot относительно молодой движок.
Но godot отличается от unity3d и game maker studio тем, что он имеет открытый исходный код. Его можно собрать из c++ исходников (делал сам по официальной документации). Не будет ограничений по времени использования (не кончится лицензия на движок), да и вообще функционал более удобный (как по мне) и игру можно делать сразу на несколько платформ - я делал сразу для Win, Linux, браузерную (html5), Android. Можно еще на XBox (UWP) и даже на Switch.
Работа с движком мне понравилась, сложности конечно были, но потом все как-то утряслось. Сейчас я работаю в нём почти как в своем движке )))
Так что мой совет: попробуй godot 3.4 Конечно начинать лучше не с 3d, я сам еще в 3d на godot не пробовал делать игры. Только делал несколько простейших примеров и видел 3d игру по официальному туториалу - tps demo.
Другого совета дать не могу, т. к. не представляю как можно делать игру без программирования ;) ТЯжКО НАВЕРНОЕ ;) Просто не пробовал )))
много букв. Спасибо за потраченное на написание время)
все прочел и честно скажу - к годоту присматривался когда искал на чем можно делать трехмерные игры но без программирования. В итоге он меня не покорил.
Юнити да, имеет ряд своих недостатков, и многие из них это в первую очередь личная криворукость. Даже на блюпринтах можно наговнокодить багов, и я этот путь прошел на старте, в попытках строить сложные системы. Конкретно с этой игрой механики оказались простыми и масштабируемыми - в итоге говнокода не вышло, блюпринты все логичные и быстро редактируемые, и при этом вся игра вышла в первом билде на 50 мб. Ну, я честно говоря глубоко доволен открытыми возможностями. Хотя и не утверждаю что что-то "серьезное" одними только блюпринтами возможно сделать.
А для двадэ игр я активно юзал констракт2, и мне его возможностей хватало для любой задумки, начиная от гиперкежа, заканчивая какими-то математическими конструкциями и всякими там локальными сохранениями. Крайне прост в освоении оказался для человека которыйуже не хочет ввязываться в программирование.
Просто не надо бояться как выражаются: говнокодить. Хотя вообще не люблю это слово. Что оно вообще означает ? Написать код с багами ? Но баги это не говнокод - это просто упущение некоторых логических действий. Кривой и некрасивый код ? Тоже нет. Главное чтобы он работал без багов. Код который кажется "плохим" ?
На мой взгляд не существует плохого кода. Есть просто субъективное мнение о его работе. Лично я никогда не писал ни единой строчки чего-то подобного. Просто не надо бояться делать ошибок. Ошибки делают все. Главное уметь их исправить, а не считать себя недо-программистом и при этом не пытаться развиваться.
Не. Тут проблема немного в другом. Уровни абстракции на котором происходит визуальное программирование и обычное немного различаются. Ну то есть я к примеру благодаря визуальным связям могу прослеживать условную логику. Когда же я читаю код - я не могу читать его как интерпретатор - и от этого теряю нить условной логики. Дальше начинается уже вопрос утечек памяти, многопоточности, использование корутин, конструкторов, ссылок на объекты и тд. Для меня все это темный лес который становится чистым полем когда я юзаю тот же плеймейкер. Я заглядывал в скрипты действий которые юзает плеймейкер и честно говоря там все весьма просто написано(в меру моего понимания) но при этом это все имеет визуальную понятную мне лично оболочку, не требующую писать код с нуля)
Когда же я читаю код - я не могу читать его как интерпретатор - и от этого теряю нить условной логики.
---
Ну это ты брат хватил. Никто и не может читать код как интерпретатор. Мы же не роботы )))
Все гораздо проще, чем ты думаешь. Мы программисты тоже не можем читать код как интерпретаторы. Да и зачем ? Обычно если код чужой - дампишь переменные и вникаешь какие значения там должны быть.
Чтобы работать как интерпретатор - ни времени ни ума не хватит )))
Все гораздо проще. Если чужой код - изучить как дампятся переменные.
Если свой - я вообще изначально пишу задачу словами. И только уже потом пошагово превращаю их в код.
Только так и никак не иначе. По сути словами я пишу как раз те самые абстрактные блю-принты )))
Хотя, конечно, спору нет, уровень квалификации и опыт определяет успешного программиста от начинающего или полного нуба. И все-таки никакой магии тут нет. И интерпретаторами вряд ли кто-то работает )))
Нет никакой возможности и тем более желания понимать большие куски кода. Важно знать лишь что на входе и что должно быть на выходе. Остальное зачем вообще ? ))) Вот такие дела.
Так что на мой взгляд ты просто все усложняешь. На самом деле все гораздо проще, чем кажется. И чистое программирование - проще, чем блю-принты. Тем более в конечном счете блю-принты все равно порождают какой-то код.
И вот как раз ты и делаешь как я написал: знаешь что должно быть на входе, и что примерно должно быть на выходе.
Не пытаясь при этом вникать в работу отдельных строк кода и операторов.
Тут нужна определенная сноровка. Но если начинать с простых примеров где все абсолютно и ясно - и постепенно усложнять логику, сверяясь чтобы результат на входе соответствовал ожидаемому на выходе, то все получится.
Вообщем я думаю ты понял (надеюсь), о чем я.
Программирование = Алгоритмы + структуры данных
Алгоритм = Вход > Некая цепочка действий с данными > Выход
Блю-принты = некий генерируемый код (т. е. Программирование).
Структуры данных = контейнеры для хранения данных - т. е. переменные различного уровня сложности и вложенности от простейших, то комплексных.
Я сравнивал годот и юнити, и тут есть один значительный минус у годота - у годота те же самые ресурсы загружаются почему-то намного дольше, хз с чем это связано, но на итче много игр годота, и чем больше ресурсов, тем загрузка дольше на старом железе. Но с другой стороны юнитовские проекты грузят мгновенно, хотя потом иногда подлагивают подгружая некоторые ресурсы, но лично я готов на небольшие микрофризы вначале игры первое время (когда появляется новые ресурсы), чем на долгую загрузку, хотя может это дело вкуса.
PS Например ресурсы этой игры загружаются нехило долго на моём старом ноуте, но возможно на SSD это не заметят, https://nonomiyo.itch.io/monstruous для единственного уровня, когда в юнити эти же ресурсы загрузились бы намного быстрее. Возможно я и не прав, и не у всех старые ноуты теперь xD , но эти долгие загрузки вымораживают на годоте.
PPS Хотя пиксельные игры загружаются достаточно быстро на годоте.
У godot ресурсы упакованы и вероятно при распаковке время на это тратится. Но надо делать игры с поэтапной загрузкой, а не грузить все за один раз. Наверное в каких-то более крупных проектах да - это проблема. Я с этим еще не сталкивался.
Насчет unity 3d - попробуй поиграть в Subnautica и сам увидишь как долго она грузится. Хотя gta 5 намного быстрее. ))) Тут не движок виноват на самом деле, а количество ресурсов которые пытаются загрузить и все разом. В gta 5 просто есть еще фоновая подгрузка. Поэтому тут все зависит не от движка, а от того как ты реализовал загрузку ресурсов в своей игре.
Тут я согласен, но подобная игра слишком большая в формате качества текстур и вообще количество контента. Но просто та же игра monstruous , невероятно короткая и маленькая, но загрузка умудряется занимать где-то 5-10% всего гемплея. Хотя игра конечно годная, но загрузка просто жесть.
Сам я планирую маленькие игры делать, ибо моих сил не хватит на большие, так что думаю никогда не дойду до уровня Сабнавтики.
Согласен, хотя я не так сильно в этом шарю, чтобы самому сделать распределение загрузки. Я пользуюсь автоматическими возможностями по умолчанию, ибо не особо хорош в программировании.
Не представляю как маленькая и короткая игра может грузиться долго. Как-нибудь гляну. А вообще я кроме Subnautica, ну и может еще пары-тройки игр, особо не замечал долгой загрузки. У тебя, какие игры долго грузятся ? Вообще все или какие-то конкретно ?
Я полагаю тут виновата сама реализация загрузки ресурсов игры, а движок может быть вообще какой угодно.
Загрузка файлов это не такая уж сложная операция, чтобы там что-то намудрить. Уж скорее я могу подумать, что hdd тормозит или еще что. Я и на старых ноутах и на новых ни с чем подобным не сталкивался.
Может что-то с системой у тебя. hdd не должен так лагать. Это ненормально.