Бекенд на Java чи геймдев з C++ та UE. Яку спеціальність обрати?

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Вітаю.

Останні кілька місяців мене мучить одне важливе як особисто для мене так і для будь-якого програміста питання: «Який напрямок та мову вибрати?»

Взагалі, по факту, самі напрямки та мови я вже вибрав, їх два:
1) Бекенд на Java
2) Gamedev на C++ та Unreal Engine

Обидва напрямки дуже подобаються. Однак якщо виникає питання «А яке все-таки вибрати?», то тут виникає непроста ситуація:

Мій мозок каже: «Чувак, бери однозначно ’Бекенд на Java’, там і вакансій по більше, і перспектив для старту більше, вчити менше і швидше, та й Java нині затребуваний і дуже популярний. А геймдев — це величезні незвідані джунглі, з купою складних незрозумілих термінів і технологій. Unreal Engine ти навчатимеш дуже довго і нудно, постійно спотикаючись по 10 разів за тему. А якщо згадати що там ще й С++ використовується, то взагалі навіть не думай про це»
«Але ж він тобі подобається (UE і C++)», тихенько шепоче душа.

І ось кого краще послухатись? Тому що рівень знання мов ± однаковий (однаково мізерний, і не достатній навіть щоб повноцінно назвати себе Джуном).

Заздалегідь дякую всім хто відгукнеться))

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

👍ПодобаєтьсяСподобалось2
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Я заробляю автоматизацією (Java/JS) але у якості хоббі з 2019 року роблю ігри на Unreal Engine (є опубліковані у Гугл плеймаркеті та у Steam -> google: ’Big Byz Wars’). Важаю що для грошей краще бути бекендером, а у вільній час щось творчо робити на будь-якому game engine (UE, Unity, Godot, Defold, LibGDX etc.).
Для того щоб трохи знялися рожеві окулярии стосовно геймдева — рекомендую почитати книжку Джейсона Шраєра: «Натисни Reset...».
Геймдев це: відносно низька з/п, кранчі/овертайми по кілька місяців поспіль, несподіванні скорочення, навіть коли гра вдало продається та купа іншого.
І це на прикладі західних ААА-студій.
На наших теренах, рідко проскакують вакансії від N-ix для студії Supermassive Games («Men of Medan»), але там потрібен вже мідл+.
Переважна кількість вітчизняних геймдев вакансий це Unity + мобільно-донатні помийки.

А чому б не попробувати і те й те? Не думаю, що воно буде заважати, а може й допомогти. Ну а так ще поміняєш 10 разів. При навчанні головне мотивація, треба щоб процес приносив задоволення, з-під палки не дуже працює. На це треба орієнтуватися. По-друге, 90% часу ти шукаєш та фіксиш, чому не працює код. Чим більше досвіду буде з різними мовами, тим краще як на мене. Як трохи навчишься — то вже сам зрозумієш, що тобі треба.

Насправді краще вибирати те, що більш подобається.
Але у другому випадку рекоменлую спочатку прокачати С++ скіли окремо, а потім переходити до геймдеву.

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

а на Go багато роботи для джунів?

Всего вакансий в 3 раза меньше, чем на Java, и в 2 раза чем на C++, jobs.dou.ua
В целом там много свитчеров, которых можно считать джунами плюс/минус.

а можно на примере C++20 конкретно рассказать, что именно является «настройками к курятнику»?

Конечно можно, например C++ коротины являются надстройкой к курятнику. Почему? Потому, что посмотрите на реализацию коротинов в Lua, или в js, и в C++. Не говоря уже, как в Go сделано, где строгая статическая типизация, если что. А задачи выполняются одни и те же. И в итоге выходит, что если надо что-то писать на C++, то целесообразнее сделать низкоуровневый API на чистом C, и каркас логики на Go или скрипте.

так и что не так с корутинами то?

Слишком большой оверхед. Что в сочетании с отсутствием полноценных замыканий с прозрачным доступом к контексту вызова делает эти коротины бесполезными. В Lua практически весь код можно написать на коротинах, в C++ подобный подход будет сопоставим написанию кода на брейнфаке.

А можно ну хоть какой-то конкретики, а не общих фраз, которые вызывают подозрение в том, что вы нахватались по верхам и плохо разбираетесь в теме?
В чем именно большой оверхед? И вообще зачем весь код писать на корутинах?

Корутины в плюсах это генератор машины состояний. Есть огромное число задач, где такой механизм существенно упрощает написание и сопровождение кода.
Есть масса реальных примеров. Например, библиотека asyncio, которая позволяет писать асинхронных код в стиле аналогичной библиотеки в Python
github.com/netcan/asyncio
Там есть вполне себе конкретные замеры производительности, где плюсовая либа работает не хуже libuv. При этом код по выразительности ничем не отличается от асинхронного кода на JS или Python.
В чем подвох то?

В чем именно большой оверхед? И вообще зачем весь код писать на корутинах?

Затем, что параллельное программирование подразумевает постоянный обмен данными между разными цепочками выполнения. И этот обмен должен быть удобен в любой точке без потери контекста исполнения. На коротинах очень удобно писать например анимации, где алгоритм каждого актора часто прерывается, и возобновляется вновь с сохранением контекста исполнения, именно поэтому Lua используется для скриптования игр. На коротинах ещё удобно например писать любые итераторы. Чтоб не быть голословным, вот пример, как легко реализуется итератор для перебора чисел Фибоначчи:

function fibonacci(n)
  return coroutine.wrap(function()
    local a, b = 0, 1
    for i = 1, n do
      coroutine.yield(i, a)
      a, b = b, a+b
    end
  end)
end

for i, v in fibonacci(10) do
  print(i, v)
end
Здесь функция fibonacci возвращает итератор на основе замыкания. Замыкание берёт из контекста исполнения n — количество чисел, и возвращает порядковый номер и соответствующее число Фибоначчи. Вы можете всё то же самое написать на C++ с коротиной и лямбда-функцией, и сравнить код. Чтоб наглядно было видно, в чём оверхед.

Тут лямбда в принципе высосана из пальца (скорее всего какие-то забубоны конкретно Lua). Просто возвращаешь генератор и все
gist.github.com/...​b29d08be83616d250b84dd4d3

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

Так и генератор высосан из пальца, можно всё сократить до простого цикла. Дело как раз в примере использования. Кроме того. В коротинах вообще-то можно обмениваться данными разных типов, то есть один yield возвращает один тип, дальше второй yield возвращает другой тип, и в разном количестве. В C++ такой вариант не предусмотрен, строгая типизация мешает. Ок, в скриптах допустим можно это условно списать на возможности динамической типизации, а в Go — строгая статическая, и через каналы можно передавать всё что угодно, и как угодно. Ну и работа с контекстом исполнения там ровно такая же, как в Lua и в js. То есть, замыкание из примера выше будет выглядеть один-в-один. Таким образом, коротина может работать не только с переданными данными, но и с текущим состоянием из точки инициализации. Наверное вы догадываетесь, насколько это облегчает написание параллельного кода.

Так что там с примером использования?
Я переписал код с fibonacci() и должен был увидеть какой-то страшный оверхед. Где он?

зы. В плюсах через yield точно так же можно возвращать все, что угодно, используя std::any.

Где он?

generator<pair<int, int>> — вот оверхед, совершенно ненужная писанина. К тому же вы пропустили замыкание в связи с ненадобностью. Так и возможности параллельного программирования отсекаются ровно с тем же успехом. Удобство использования коротин и замыканий — это ключевой аспект.

В плюсах через yield точно так же можно возвращать все, что угодно, используя std::any

Как вы считаете, std::any — это вообще что, оверхед, костыль, или вершина передовой программистской мысли, которую нужно срочно внедрять во все остальные языки, чтобы они подтянулись до уровня изящности C++?

Лучше бы порассуждали через какую жопу к Go прикрутили дженерики и какой оверхед там получается.

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

в отличии от пятиэтажной белеберды в случае ошибок в темплейтах C++

Вы несколько отстали от жизни
en.wikipedia.org/wiki/Concepts_(C

В целом необходимость дженериков некоторыми сильно переоценена.

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

Вы несколько отстали от жизни

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

вступать в дебаты в области языков со статической типизацией

Так речь насчёт дженериков в Go, ну а Go — в отличие от С++ язык со строгой статической типизацией. Потому что C++ с нестрогой статической типизацией. При наличии там кучи бредовых операндов типа reinterpret_cast, наряду с простым приведением.

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

Зепки будуть майже на одному рівні, а потім на щось інше зіскочити досить проблематично. Якщо вже зібрався в айті, то краще займатися тим що цікаво на хорошому рівні. Хороший джавіст буде заробляти, ніж посередній С++ дев і навпаки.

Спершу прочитай це, а тоді й вирішуй. Та й, чесно кажучи, важко уявити, як можна бути впевненим у тому, що тобі подобаються джава, UE і плюси, якщо

рівень знання мов ± однаковий (однаково мізерний, і не достатній навіть щоб повноцінно назвати себе Джуном).

Що заважає обрати С++ негеймдев і у вільний час колупатись в УЕ? Якщо знаєш С++ на хорошому рівні то в майбутньому відкривається купа напрямів і зможеш світчитись туди-сюди. Сам почав недавно розбиратись з анрілом, якщо хочеш робити ігри самому то С++ там 1% від усієї роботи.

steep learning curve

відкривається купа напрямів і зможеш світчитись туди-сюди.

ніт,
хіба джуном

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

Я поки дивлюсь відеотуторіали (в ютубі повно відео ue5 for beginners) і намагаюсь повторити за ними. Далі планую створювати власну гру і по ходу розбиратись з тим чим цікавить. Про книги не знаю, як на мене їх варто шукати коли хочеш розібратись з чимось конкретним, типу нетворк кодом

Я би сказав більше Сі, на не С++. Все-таки С++ знати на хорошему рівні можна тільки якщо ти розробник компілятора, мова дуже складна, з великою купою нюансів. З іншого боку, С++ майже ніяк не повпливав на інші мови, усе унікальне (система шаблонів, zero-overhead ООП, ...) так й лишилося там. А от Сі дасть знання архітекрути, база, яка буде крізь дуже корисна.

Я б підходив би зі сторони що цікавіше — програмування чи геймдев? Якщо написання бекенду приноситиме задоволення і людина цим горить — то чом б і ні. А якщо все таки не однакова область в якій працювати і хочеться саме робити ігри — то тоді краще йти туди, аби не сидіти і не думати якби прикольно зараз було писати гру а не цей черговий мікросервіс :)

Я в твоїй ситуації колись вибрав бекенд як спеціалізацію, а геймдев залишився як хоббі.
П.С. ти цілком можеш підібрати собі жанр, де можна написати бекенд гри на Java.

Все нижче описане є субєктивною думкою одного геймдев програміста.
Не хочу бути тою токсичною людиною, але якшо в тебе постає таке питання, то тобі не у геймдев.
Варто розуміти, шо геймдев лише здається простим і веселим, де люди грають в ігри на консолях цілими днями. На практиці, ти будеш пиляти клон клонів донатних помойок, карнавальними монетизаціями. Все це разом з трохи нижчою зп ніж у «звичайних» програмістів і кучою кранчів. Таке переживають і знаходять сили рухатись вперід лише люди з геймдевом головного мозку.
Також варто відзначити, шо попасти в IT через геймдев тяжкіше чим іншим способом. Джава може стати гарним транзитом, способом навчтись програмуванню загалом, отримати рік — два навичок і фінансовою подушкою, а потім вже можна перейти в те шо по душі

Все нижче описане є субєктивною думкою одного геймдев програміста.
Не хочу бути тою токсичною людиною, але якшо в тебе постає таке питання, то тобі не у геймдев.
Варто розуміти, шо геймдев лише здається простим і веселим, де люди грають в ігри на консолях цілими днями. На практиці, ти будеш пиляти клон клонів донатних помойок, карнавальними монетизаціями. Все це разом з трохи нижчою зп ніж у «звичайних» програмістів і кучою кранчів. Таке переживають і знаходять сили рухатись вперід лише люди з геймдевом головного мозку.
Також варто відзначити, шо попасти в IT через геймдев тяжкіше чим іншим способом. Джава може стати гарним транзитом, способом навчтись програмуванню загалом, отримати рік — два навичок і фінансовою подушкою, а потім вже можна перейти в те шо по душі

IMHO що завгодно краще Java

Ну тоді треба дивитись інші критерії:

* Я хочу швидше знайти роботу: Java чи геймдев? — Java
* Я творча людина: Java чи геймдев? — геймдев (мабуть сама творча професія впринципі, особиста думка)
* Я хочу більше заробляти грошей: Java чи геймдев? — Java

І так далі, те що вже написав, то чисто особиста думка та мій досвід.

Я обрав геймдев, бо я супер творча людина, мені подобається і програмувати, і ще шось чи анімувати, чи ідеї накідувати і т д... Чи наприклад музику писати під ігри. Можна сказати шо це все майже є скрізь, але я скажу шо геймдев в цьому плані більш особливий ніж розробка додатків, або сайтів...

Підписатись на коментарі