Павел

Это не резюме, это набор слов, ничем Вас не выделяет из общей массы и даже делает низовым в списке общей массы.

1. Такой кучи тегов даже у меня нет)) Если Вы знаете названия технологий, не говорит о том, что Вы знаете сами технологии. С Вашим опытом никто не поверит, что Вы имели реальный опыт со всем этим, а не просто hello world написали. Выберите те, в которых по Вашему мнению Вы лучше всего разбираетесь.

2.

Отличное знание WinForms, ASP.NET, LINQ и WPF. Паттерны: MVVM, MVP, Repository, IoC.

Для третьекурсника звучит самонадеяно. При такой формулировке на техническом собеседовании будут проверять "отличное" знание и я почти уверен, что Вы его провалите. Лучше сказать что-то подобие: имел опыт работы с, для реализации использовал технологии, имею <начальные> навыки работы с и т.д.

3.

Занимался исправлением мелких багов, написанием небольших SQL-запросов и unit-тестов, решал небольшие задачи.

Этим занимаются все разработчики, даже мидлы с сеньорами. Из Вашей фразы не понятно, какого уровня проект, какой стек, какие конкретно задачи Вы решали, как успешно Вы их решали. Работодателю нужно понимать Ваш реальный опыт и Ваши реальные возможности, а не нечто эфемерное "решал небольшие задачи".

4.

Если вспомнить css и html

Вот такое никогда не пишите. Лучше соврать или преувеличить, или даже написать "Отличное знание", но не так как Вы здесь сформулировали.

5. Не нужно оставлять ссылки на каждый проект в репозитории. Либо один, самый интересный на Ваш взгялд, либо одна ссылка на сам репозиторий. Работодатель пойдет туда только, если Вы заинтересуете его, не раньше. И ему пары файлов хватит оценить ваш уровень. Он не будет делать ревью всех Ваших проектов.

6. Опыта одного проекта мало. Где опенсерс проекты, где участия в хакатонах, где амбиции стартапов, посещение конференций? Работодатель хочет понимать как Вы заинтересованы развиваться, какие у Вас планы для дальнейшего роста. Он берет вас нулевым не из альтруистических побуждений, а с надеждой, что Вы быстро вырастите и вернете ему прибылью затраченное на Вас время. Из Вашего резюме видно только одно: я студент - дайте работу. А почему Вам, за какие такие заслуги и что с этого будет иметь работодатель - не понятно.

7. Я посмотрел Ваш код. Я бы не хотел, чтобы так писали у меня в проекте, начиная от именований и заканчивая некоторой логикой. Вас надо очень осторожно подпускать к реальным задачам и контролить, что Вы там напишете, просто чувствуется маленький опыт и до "отличных знаний" там далеко.

В общем, вывод. Пока у Вас за плечами нет списка реальных проектов, чтобы Вас пригласили, надо себя выпячивать, хвастаться достижениями, демонстрировать амбиции, свою уникальность. Нужно убеждать работодателя, что Вы именно тот, кто ему нужен. В резюме этого нет. Когда у Вас будет пяток законченных проектов, будет наоборот, работодатель будет за Вами бегать и убеждать, что Вам у него будет лучше всего. И на hh студентов практикантов не ищут, поэтому только Вы должны делать отклики на вакансии, обязательно с сопроводительным письмом, в котором парой фраз Вы сможете заинтересовать работодателя.

Стандарт C++ предписывает статическое расположение для глобальных и статических переменных. Это означает целую массу побочных эффектов для генерации использующего переменную кода.

Для примера можно взять твою функцию swap и посмотреть на то, как компилятор будет генерировать код даже с учетом оптимизации.


Не обязательно быть специалистом в ассемблере чтобы увидеть прямую разницу в сгенерированном коде.
На самом деле, если t объявить именно как глобальную переменную, то сгенерированный код станет немного легче, но он все равно будет объемнее и тяжелее кода с локальной переменной. Уже просто потому что глобальная переменная находится в глобальной памяти, а запросы из процессора в ОЗУ - сравнительно долгая операция.

да, будет очень интересно почитать.

Найти другую работу

Замыкания! Информации куча.
Вот к примеру

"Прям качественные игрули" разрабатываются годами, и тратить драгоценное время ещё и на написание туториалов никому не интересно. Если хотите побольше узнать про процесс разработки, то можете почитать блоги разработчиков, вот вам несколько для начала:
https://rust.facepunch.com/blog/
https://www.factorio.com/blog/
the-witness.net/news/category/development
https://www.reddit.com/r/devblogs/

Для успешного использования кватернионов понимание их внутренней структуры не обязательно, нужно просто разобраться как работают конструкторы и оператор умножения. Математический смысл кватерниона к разработке игр имеет мало отношения.

Про шейдеры есть хороший сайт The Book of Shaders, там немного другой стандарт чем в юнити, но всё переносимо с минимальными изменениями. В шейдерах основная сложность не математике, а в понимании функционального программирования и параллелизма, большинство вещей всё равно делается на простом сложении да умножении.

Если же всё-таки хотите подтянуть математику, то найдите где-нибудь "сборник задач по математике для поступающих в вузы", есть много книг с похожим названием. Интегралы можете сразу пропускать, а вот синусы и косинусы можете порешать. Ещё можете поиграть с Wolfram Alpha и интерактивными рисовалками графиков. Этого должно быть более чем достаточно, в геймдеве дело редко заходит дальше сложения векторов.

какими навыками я должен обладать

Уметь все это разделить на мелкие компоненты. Так чтобы в связи представляли твой конечный результат. Большая цель она выглядит непонятной, не ясно как к ней подступиться. Поэтому попробуй разбить это на небольшие кусочки. И соединяй их постепенно. Для каждого кусочка тебе понадобятся определенные знания, уже будешь знать конкретно какие, и появятся конкретные вопросы, появятся вопросы, сможешь находить решения и идти дальше. Задавай вопросы, находи решения, делай и по новой.
Если кажется это слишком простым, попробуй это сделать и уже сможешь выложить это как вопрос, например: "Правильно ли я декомпозировал мою идею на подзадачи?"
Тогда тебе уже смогут поправить и подсказать более детально.

0. Написание дизайн-документа. Если не можете точно и детально написать, что из себя представляет игра, какие механики используются, сеттинг и т.п., то к разработке приступать не рекомендуется.
1. Пре-альфа/Прототип. Этап, на котором набивается "скелет" игры, с минимумом контента. На нём можно успешно закончить, если понимаете, что не можете реализовать те или иные идеи диздока или игра не соответствует вашим ожиданиям.
В UE4 - этап, состоящий из написания кода на 90% (даже если вы разрабатываете на блюпринтах - рано или поздно захочется уехать на чистый код, тем более что оттуда можно делать интерфейсы для них для удобства тестирования и гуманитариев).
2. Альфа. Играбельно-багованое нечто, в котором реализованы все основные механики. На этом этапе обычно основной упор в разработке на базовый баланс, заполнение контентом и БАГИ. Тут по-полной используются все возможности: от моделей и анимации до активной работы с дебаггером и логами.
3. Бета. Весь геймплей в наличии, контент готов на 95%. Баги - наше всё.
4. Релиз. Момент рождения продукта.
5. Пост-релиз. БАГИ, недовольные пользователи, призывы к бунтам. Возможно захочется делать допконтент.
Про мобильную разработку: преимущества ue4: полный контроль над кодом, лучший редактор во Вселенной, вариативная производительность и бОльшие технические возможности, недостатки: больший порог вхождения, дольше и сложнее разработка, нет поддержки "из коробки" многих удобных фич типа AdMob и ачивок на платформе.

Гипотрохоида
https://ru.wikipedia.org/wiki/Гипотрохоида
Гипоциклоида
https://ru.wikipedia.org/wiki/Гипоциклоида

+ 'элемент случайности +- от координат

>За последние три месяца мне удалось освоить Python
не удалось

>Разобрался с гит
не разобрались

>линуксом на уровне пользователя
не разобрались

>Lua
не разобрались

Для начала приземлитесь. За 3 месяца вы ни в чём из этого разобраться на хорошем уровне не могли.

>Где писать игры для портфолио
Это делать не обязательно. Это, конечно, плюс, но не такой существенный чтобы прямо быть обязательным.

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

Определитесь чем конкретно хотите заниматься: физика, графика, логика, сеть, утилиты, etc и делайте что-то именно в этой области (демки, например).

А так, чтобы попась в геймдев достаточно просто навыков программирования и хорошей теоретической базы (графы, математика), демки не обязательны.

Вам правильно пишут: без callstack невозможно узнать, где именно ошибка вылезла, может даже не в этом методе, может где-то внутри GeneratePairGame, может randomLevel = null. Нужно логировать Exception, заверните тело кейса внутрь try-catch

case 2:
	try
	{
		GeneratePairGame(randomLevel);
		...
		break;
	}
	catch(Exception ex)
	{
		Debug.Log(ex);
	}

Тогда будет точно видно где и что произошло.

Вопрос (особенно, с его авторской орфографией, намекающей на то, что вы - "троечник") звучит так, будто вы ищете себе оправдание, чтобы забивать на институтские предметы, которые кажутся вам ненужными, или уже решили на них забивать, но ищете моральную поддержку у "старших товарищей".

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

Ничего личного против вас не имею - просто оно вот так почти всегда работает. Если с вами этого не случится - чудесно. Но вероятность, что отличный узкий специалист по Java выйдет из человека, который считает смежные предметы ненужными - стремится к нулю. Не потому что они вам понадобятся непосредственно (хотя я не очень представляю, как можно заниматься оптимизацией кода без понимания принципов работы ЭВМ), а из-за модели поведения.

Можно, но изменения не будут сохраняться в сборке, только в редакторе. Если хотите, чтобы сохранялись, тогда надо сериализовать ScriptableObject и писать куда-нибудь на диск. Когда я последний раз смотрел, изменения ресурсных файлов существовали только во время жизни приложения. За исключением необходимости сериализации хранить настройки в ScriptableObject очень удобно, особенно если надо что-то посмотреть или подправить в редакторе.

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

Скорее всего, вы его положили в папку Editor, поэтому он туда и попал.

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

Если ещё не читали, то прочтите статью Линейная алгебра для разработчиков игр, ещё могу посоветовать этот доклад с GDC. Для лучшего понимания трёхмерной графики очень полезно научиться моделить примитивные вещи в трёхмерном редакторе, а ещё лучше попробовать процедурно сгенерировать какую-нибудь сферу или кубик.

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