Comments 36
Удачи!
Спасибо, она мне понадобится )
я тоже работаю инженером, но дома начинаю пилить игру) но у меня подход попроще. 2.5д, возможно пиксельная, по жанру как oxenfree
Ну, это кому что проще. Для меня 2D графика это кошмар и мучение - руки совсем не из того места. А вот для 3D могу хоть что-то похожее на правду собрать в Блендере.
а в чем кошмар и мучение? на 1 координату меньше, нет камеры как таковой, проще технические решения. Если вы про рисование, то примитивы можно сейчас генерировать.
Да, я именно про рисование. Да и личное предпочтение - все-таки 3D мне нравится больше, чем 2D, по крайней мере именно со стороны работы с графикой.
мне как человеку выросшему на играх с 80-х всё же кажется что для хорошего 3д, чтобы это смотрелось нормально - нужно моделировать и уметь это делать на приличном уровне. Иначе это будет выглядеть как игра PS1, из глаз кровь хлынет от такой графики. Посмотрите на игры Kingdom New Lands, The Final Station - простейшая графика, но мир просто отличнейший, в 3д такое вообще не реализовать, когда один пиксель может передать информации больше чем 100 моделей.
Так а я же не спорю ) мне 40 лет и я тоже вырос на 8-битках. Они прекрасны. Даже сейчас очень много крутых пиксельных игр, которые с уверенностью могу назвать шедевром с моей точки зрения. Но делать 2D игры самому пока не хочется. Ведь любую игру нужно делать интересной. Нужно уметь передать в одном пикселе тот самый мир. У меня это пока не получается...
Я вот с интересом фигачу ролеплей в DnD или не DnD стиле в современных LLM. Идея "можно идти куда угодно и делать что угодно" для меня до сих пор завораживающая )
А смотрел ли другие инструменты Godot , Love2d , Cocos2d ?
Да, смотрел (кроме Love2d, о таком даже не слышал), но поверхностно, т.е. только в виде каких-то обзоров и сравнений движков на Ютубе. Сам руками не трогал. Больше всего оттолкнуло малое количество обучающих материалов (по крайней мере на тот момент) и основной язык разработки. C# теперь навечно в моем сердечке ))
К слову, в Godot можно (и нужно) на C# писать.
тут дело не в языке , а в философии проектов...
Есть навороченные фреймворки с кучей состояний Тот же Юнити как пример.
Есть примитивные фреймоворки вроде Love2d , надо заморочится с некоторыми вещами сделать свои реализации.
Допустим нужен менджер сцен , в Love2d его нет , так же самое рендеринг нужно репку чесать как сделать...
В Юнити есть разные варианты из коробки.
Вопрос стоит в сложности задачи,отсюда и фреймворк выбирается. Из самых супер успешних проектов на Love2d Balatro к примеру.
Из статьи непонятно, это все таки хобби паралелльно с работой или ушли с основной работы?) Есть какие-то примеры игр, пусть даже мобильных? Как сейчас обстоят дела с лицензиями и роялти у Unity? Ну и последнее - у Unreal Engine вроде огромнейшее количество примеров, бесплатных ассетов, megascans от quixel, обучающих материалов на Ютубах, Udemi, да и в целом документация классная, а по описанию проблем, которые вы решали в Unitiy, все вроде как это уже реализовано "из коробки" в UE.
Это всё еще хобби, хотя где-то в глубине души тлеет огонек надежды, что когда-нибудь хобби превратится в основной источник дохода. К сожалению, даже если это и произойдет, то очень нескоро - зарплата на текущем месте работы слишком хороша и догнать ее на разработке игр просто так не получится).
Из опубликованных было 6 игр на яндексе, но сейчас все они сняты с публикации (и хорошо, за большую часть из них мне сейчас стыдно...) из-за низкого рейтинга. Пару из них я планирую в ближайшее время оживить.
По моему опыту ScriptableObject лучше не использовать для хранения прогресса и не изменять его в рантайме, а относиться к ним как к конфигам, статическим данным. Прогресс лучше хранить в другом месте, как вариант в PlayerPrefs. Так же в Unity вместо стандартного класса Task, лучше пользоваться пакетом UniTask, у них есть интеграция с движком и минимум аллокаций.
Если вам за 30, 40, 50, и у вас в голове зажегся тот самый “огонек” - не гасите его.
Если только у тебя есть бабки как минимум на дизайнера - можешь сам делать игры. Иначе никому не нужен джун в 30 лет, не говоря уже о 40-50 лет. Всем нужен 20-летний сеньор с 10-летним стажем. В случае с инди, "огонек" потухнет, когда придет рутина и осознание того, что твоя игра никому нахрен не сдался, а ты корпел над ним целый год. Чтобы твоя игра стала прибыльной, надо корпеть 5 лет над 5 играми и тогда ты может получишь доход в "огромные" 10-100 тыс баксов.
В корпоративном мире твой успех измеряется в KPI, ROI и выполненных спринтах.
В геймдеве тоже самое если работаешь на дядю.
Я давно понял, что главный навык - не знание конкретного фреймворка, а умение находить и усваивать информацию.
Работодатель явно так не думает.
В геймдеве (на моем уровне) успех - это момент, когда твой друг смеется от придуманной тобой глупой механики или когда ты сам получаешь удовольствие от геймплея, который создал. Это невероятно заряжает.
Видно что ты пороха не нюхал.
Геймдев - это когда сидишь с красными глазами в 3 часа ночи, пытаясь выявить и исправить баг, ибо завтра деплой. А он с*ка, проявляется только тогда, когда луна на фоне юпитера пролетает через марс!
Геймдев - это когда 90% времени ты тратишь не на проработку интересного геймплея, а на исправление ошибок, на патчи, на унылое заполнение json'ок и уровней, на креши на айпаде(потому что эпл пожадничал и поставил 3гб озу в девайс с ретина-дисплеем), на тестирование в 100500 разных андроид девайсов.
Геймдев - это нищие зарплаты и бесконечные кранчи. Пока твои коллеги ездят на машинах, ты ездишь на автобусе. Копишь на велик и радуешься, что экономишь деньги на автобус ездя на велике.
Геймдев - это когда ты полтора года делаешь свою игру мечты, а она продается в количестве 10 штук(друзья купили из жалости). Ибо рынок перегрет хорошими качественными играми.
Пробовали ли вы кардинально сменить фокус в зрелом возрасте?
Пробовал из геймдева в другую сферу вкатиться, ибо геймдев в РФ сейчас мертвый. Смотрел в сторону Golang(web), типа как самая популярная вакансия в РФ. Начал было учить и охренел от объема знаний, которые надо изучить, чтобы тебя взяли на работу. Ладно бы только язык выучить, но там помимо языка надо учить кучу фреймворков! Видел курсы на полтора года! WAT? В геймдев я пошел почитав книжку типа "C++ для чайников" и прекрасно вкатился... Поэтому решил пока не выкатываться из геймдева...
Позиция вполне понятна, но у нас с тобой принципиально разные цели. У тебя всё упирается в "найти работу с достойной оплатой" - у меня есть работа, она мне нравится, мне не нужна вторая. Я просто начал заниматься тем, чем давно хотел где-то на подкорке мозга, но в чем совершенно не разбираюсь.
По поводу багов в определенной фазе луны - ты даже не представляешь, сколько их было на моем почти 20-летнем пути. Поверь, такое бывает не только в геймдеве. Одни из самых веселых - это ошибки, возникающие только на продуктивных данных, доступа к которым у тебя нет и никогда не будет...
Не стоит так сгущать краски. Геймдев - он разный. Кто-то не вылезает из кранчей, а кто-то за 5 лет перерабатывал недели две. Кто-то вкалывает в стартапе за обещания, а кто-то работает с 9 до 6 за вполне рыночную зарплату.
Баги в ночь перед релизом есть в любой сфере, этим Вы на хабре вряд ли кого удивите. А в остальном - компании все разные, как и в любом IT.
Кажется вам просто не повезло, до 22 года в геймдеве было очень сытно и уютно последнее время)
Сейчас стало похуже, особенно в России, но кризис пройдет.
Спасибо большое за мотивирующую и добрую статью!
Было ли у вас чувство, начиная создавать игры, что вы делаете слишком мало и/или слишком просто? Если да, то как справлялись с этим и как выбирали масштабность первых игр?
Я тоже понемногу делаю игры и ловлю себя не только на желании сделать всё "идеально", имя опыт в смежной области, но и на мысли, что я делаю слишком простые вещи, хоть для новичка в новых для него технологиях, это не так.
Конечно, даже сейчас, спустя почти 2 года, каждый раз мне кажется, что я делаю недостаточно. Каждый раз мне кажется, что я делаю новую фичу слишком долго и можно сделать гораздо быстрее, но выё это решается опытом. У меня за плечами десятки, если не сотни начинаний что-то делать с нуля. И за счет всех этих начинаний я усвоил урок - ничто не получается быстро (если это не выигрышный лотерейный билет). Любая новая технология усваивается потом, кровью и объемом решенных задач. Так же усвоил, что нельзя придти и сходу сделать задачу "создать вселенную". Сначала простейшие задачи, только потом поэтапное усложнение.
По поводу "идеально". Моё ИМХО - идеальной должна быть игра со стороны конечного игрока. Он должен играть в нее с удовольствием. Что под капотом - это вопрос второй и гораздо менее приоритетный. Сейчас я всегда сначала прототипирую - при этом на код смотреть зачастую страшно. А вот если сделанная фича мне нравится, то уже тогда я начинаю делать рефакторинг.
Из интересного есть еще Bevy, Fyrox (это все Rust) но там нужно страдать (движки еще очень сырые). Я сам полностью на Rust перешел c многолетней интерпрайз Java, это прям другой мир (в плане подходя к разработке). Кстати тоже Blender, Substance 3D Painter (в стиме его все еще можно купить), RizomUV, Marmoset Toolbag, Unreal, Unity, Godot смотрел - в качестве хобби, но руки так и не дошли что то серьезное сделать. Кстати в Unreal интегрирован Quixel Megascans (эпики пару лет назад купили компанию) - это огромны набор бесплатных ассетов - сканов с реального мира (с их нанитами неплохо работает), плюс в Fab к Unreal ежемесячно выкладывают бесплатные ассеты, также на гитхабе рядом с сорцами анрила есть плагины к Blender для экспорта рига и объектов, правда не знаю работают ли они еще с новыми версиями аррила
лучше начать с 2д, 2д на самом деле проще, тайлики закешированные, на С++ действительно очень быстро достигается, тем более в сдл всё для этого есть, Юнити для этого монструозен, но всё в себе для этого имеет, далее, надо конкретно понять, а что дальше когда какой-то пазл будет архитектурно и визуально допилен и играбелен. Допустим это 3д, и тут к сожалению даже с движком путь большой, от математики и оптимизации до фильтров hdr с тенями(дефолт сцена в Юнити и анриале уже имеет шаблон, хорошо бы понять этот шаблон по-лучше) и анимациями и попутными механиками, я даже не знаю что посоветовать, могу только пожелать успехов, не забывайте о деревьях и о нелинейной обработке данных и распреденной памяти )
вообще могу посоветовать, но знаю что лучше набивать шишки самому, упор на физику и математику в купе с деревьями даст буст до механик, плюс можно будет смотреть в сторону рейтрейса
ну а так конечно пофиг есть движок впринципе наверно и без этого всего можно сделать игру, что-то в движке уже решено, например дерево и физика твёрдого тела, пуск луча и тп
можно начать с бильярда, пин-бола ), сложные сцены я вот смотрю Adorable Adventures ну и как бы понимаю в соло сложно )
О, у меня чего-то очень близкое недавно произошло. Я тоже с хорошим Job Title на хорошей зп, и тоже вдруг захотел игры пилить. Только учить другой язык мне стало лень, а на работе у меня только python и rust, поэтому я взял rust биндинги к godot. За два месяца запилил небольшой 2д пазл без графики и без звука, выложил на itch.io, получил около 100 игроков и десяток комментов с фидбеком. От комментов вдохновился, похоже у меня получается геймдизайн. Так что в свободное от работы время я теперь пытаюсь рисовать учиться. А точнее, дорисовывать за нейросетками. Может когда-то сделаю что-то стоящее стима.
Я - не разработчик игр и с Unity не знаком, но меня зацепил один момент в статье, где архитектура "сражается" с некрасивым, но работающим кодом.
Когда-то в начале своего профессионального пути сильно страдал от того, что голова была забита всякими представлениями о том, как должно быть хорошо (SOLID and etc.) и как можно сразу сделать хорошо (книжка банды четырех).
Каждый раз, когда я садился что-то сотворить новое в коде я городил монстра. Я тратил время, много времени на то, чтобы продумать всё и учесть, как могут развиваться требования в дальнейшем. Код, который получался, был сложным для большинства остальных его читателей, и он частенько был к тому же и избыточным, решал те задачи, которых и не было на самом деле.
В моём окружении часто витала красивая фраза "рефакторинг". Часто кто-то говорил "давайте порефакторим вот это" и иногда в результате этого садились писать рядом ещё одну новую версию того, как обрабатывается какая-то фича в продукте. Я примерно понимал, что значит рефакторинг, но не понимал, является ли это чем-то особым (это просто переписать код, или всё же есть какая-то особая церемония?).
Открытием стала книжка Фаулера про рефакторинг. Дико повезло, что не прошёл мимо неё. Увы, после её прочтения я узнал, что почти никто никогда не занимается честным рефакторингом, даже какое-то время воевал с этим (да и сейчас агитацию за это веду в своём комментарие :) ).
То, что узнал в книжке, я возвёл в некий абсолют, стал использовать непрерывно (да, я ещё и поклонник идей из XP и люблю пробовать идеи проверять в их экстремуме).
И я заметил, что в результате (а я проверял буквально постоянно и на разных проектах, и на пет-проектах, и на рабочем коде, и на katas), идеальная архитектура рождалась самая собой.
Буквально то, как я стал работать, выглядит так:
Есть текущий код (хороший или кривой - не важно)
Есть новое требование/задача
Если хочу, покрываю тестом текущий код (если боюсь его менять, если считаю его хрупким или мутным). По рабочему коду покрыть его тестами несложно, особенно если код понятный. Если код непонятный, то тест будет больше похож на тестирование чёрного ящика, если понятный - то я могу позволить себе более детальные тесты, либо могу позволить себе их не писать. В общем тут стараюсь действовать так: чем дешевле - тем я довольнее, ведь новые тесты - это такой же новый код, я им займусь в пункте 5
Я вкорячиваю новую реализацию минимальными усилиями. Буквально иногда через 100 место в цепочку функций могу спокойно прокинуть доп. флажочек, если так быстрее. Цель: лишь бы это заработало. Если так проще - могу сперва сделать минимальный рефакторинг кода, если это действительно дёшево.
Окунаюсь в рефакторинг. Тут я нахожусь до тех пор, пока не буду полностью удовлетворён, пока не почувствую, что больше не знаю, что тут сделать, либо знаю, что то, что осталось ну уж слишком дорогое и оставит меня на этом месте на час или больше. Возможный критерий останова тут - ощущение, что теперь тест на этот код написать тривиально.
Если хочу (если боюсь, что кто-то сломает написанный код) или того требует долг (обычный процесс разработки), покрываю тестом то, что я только что написал. Как писал выше, теперь это легко сделать.
Да, это звучит во многом похоже на TDD :) Но акцент на том, что ключевое - не тесты, ключевое - не рефакторинг даже, а результат: я не чувствую никаких преград взять и добавить любую новую фичу. Я всегда уверен, что как бы коряво я её не воткнул бы, сам код подскажет мне, а как фича должна в итоге выглядеть с т.зр. архитектуры и качество кода будет на высоте (и читаться будет, и тесты будут).
Кажется, осознанно в подавляющем числе случаев не пишу тесты сначала. Я чувствую, что они обычно сильно фокусируют меня на реализации, на том, как фича должна выглядеть в коде. А этого я в начале не знаю. Поэтому и не TDD.
Поразительно, но в рефакторинге появляются изначально совсем неочевидные (но при этом совершенно логичные) абстракции, которые сходу ты бы не стал предлагать при проектировании.
Сверх этого потом наложились и сплавились воедино другие знания (например, я также позаимствовал себе из Чистого кода Мартина идеи про минимальное возможное число параметров у функций и возводя в абсолют добиваюсь того, чтобы 90% функций не имели бы параметров, а ещё и чтобы 90% функций не имели бы сайдэффектов).
Подход, которым я пользуюсь, смело можно называть "рефакторинг ради рефакторинга" :) Ничуть не стыдно за это, поскольку я вижу, что если преодолеть эту психологическую стену "это ведь не нужно больше рефакторить" и довести до абсолюта, то начинаешь получать пользу. Структура кода адаптируется под то, что нужно в конкретных требованиях и он становится всё более и более выразительным.
Со временем тот новый код, который ты добавляешь становится всё менее и менее корявым (он просто напросто хорошо вкладывается в получаемый доменный язык). Внезапно то, что обычно называют сложной фичей оказывается простым упражнением, да и количество требуемого рефакторинга радикально снижается (ведь основное сделано ранее).
Интересное последствие (как у автора статьи, но наоборот):
К этому подходу я сильно привык. Перестал ощущать, что есть нерешаемые с точки зрения архитектуры задачки вне зависимости от объёма, но при этом архитектуру отвык проектировать. Я скорее стал наблюдать, как она рождается в ходе изменений. И как-то раз, сменив работу, ощутил, что мне просто напросто некомфортно и больно описывать какую-то гипотетическую архитектуру в каком-то документе (это требовалось во многих задачках на новом месте). Ощущение, что топчишься на месте, а не творишь. (Но это стало для меня ценным наблюдением, тоже извлёк для себя выводы и чуть иначе стал относиться к своему подходу).
Ну а если сделать вывод к статье, то думаю, что такой вот любительский геймдев - это отличный полигон для быстрого прототипирования в связке с последующим рефакторингом. Советую пробовать этот поход (и советую почитать Фаулера + потестировать его применять в абсолюте на каком либо петпроекте)
У меня примерно такая же ситуация, как у вас. Мне тоже 40, я 18 лет занимаюсь андроид-разработкой и давно интересуюсь геймдевом, год назад для сына начал записывать видеоуроки по разработке игр на движке Defold и это переросло в проект «Сделай игру с папой» - https://vkvideo.ru/@makegamewithfather
Автор, подскажи, есть ли семья и/или ипотека? Если да, то как решился и что получается сейчас зарабатывать? Я понимаю, что не смогу пойти на такой же шаг, потому что жена и ребенок кушать хотят и ипотеку надо гасить стабильно
Да, есть как семья, ипотека, так еще и автокредит ) Более того, ипотека с автокредитом кушают сильно больше жены и ребенка))
Я выше уже писал в комментариях, что не могу позволить себе бросить основную работу. Во-первых, она мне нравится, во-вторых, она приносит доход оооочень сильно выше среднего заработка по городу. На играх за последний год я заработал столько, что даже минимальной суммы вывода с Яндекса не набралось. Единственная привилегия, которая у меня есть - 24-часовой день. Зачастую его хватает чтобы и денег на работе заработать и с семьей немного побыть и геймдевом позаниматься пару-тройку часов. На сон, к сожалению, остается не так много, но приходится чем-то жертвовать.
В 40 лет в геймдев: от корпоративного архитектора к инди-разработчику