dollar

Надёжный способ понять, что причина именно в нехватке памяти - услышать, как шуршит жёсткий диск во время фризов (если файл подкачки не на SSD).

Вариант 1: запрет и модерация. То есть как только появляются доказательства кооперации вне игры - наказание. Игрокам дать возможность жаловаться на других игроков. Также можно прикрутить систему, в которой жалобы будут учитываться полуавтоматически. Пример, где так сделано: Project Winter

Вариант 2: запретить игрокам собираться вместе на уровне матчмейкинга. То есть нельзя пригласить друга, вместо этого тебе дадут случайного игрока. Плюс (по желанию) убрать чат и голос, чтобы нельзя было обменяться контактами, но случайные люди и так вряд ли будут звать в дискорд. Пример, где так сделано: Journey (2012)

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

Да, что-то с драйверами.

Или с переключением между картами. Возможно, у тебя две видеокарты - встроенная и дискретная, и система определённым образом настроена, чтобы переключаться между ними при запуске игр и т.д. Только это приходит в голову на "removed device".

Также попробуй убрать разгон. Пусть видяха работает чуть медленнее, зато надёжнее. И в целом проверь, не перегревается ли она, мало ли.

У Unity один из самых низких порогов вхождения. Поэтому писать скрипты для Unity может и школьник. И если ты два года интересуешься программированием и играми, то уже должен уметь многое, то есть знать Unity хотя бы на 70%.

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

Если же с программированием всё и так хорошо, то обрати внимание на другие интересные специальности. Это может быть что угодно, что просто интересно было бы изучить или пригодится в проработке каких-то игровых механик. Это может быть, например, художественное направление, психологическое, юридическое, экономическое, медицинское, - да какое угодно. Знания пригодятся как при создании механик, так и для понимания организации процесса создания игры.

Программист, который знает лишь программирование и умеет только кодить, - это далеко не самый хороший программист. У хорошего (в будущем) программиста при выпуске из школы должны быть хорошие оценки не только по информатике, алгебре и геометрии. Если предметная область (игра) на историческую тему, то пригодится история. Если там будет стратегическая карта Земли, то - география. Если там будет механика здоровья, частей тела, крови, то - биология. Я уж молчу про физику, которая будучи в игре очень поспособствует тому, чтобы игра стала хитом. А что касается ВУЗа, то (помимо общих знаний) совмещение программирования и глубоких знаний в другом направлении, сделает из тебя довольно редкого специалиста.

На стыке знаний рождается много интересных решений. Хотя по сути, при взгляде со стороны, ты будешь как бы просто делать игры, писать скрипты и т.д.

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

Да, возможно.

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

Может даже оказаться, если не договоритесь о цене, что ещё дешевле будет переписать и сервер, и клиент с нуля. Из незащищённого клиента будет не очень сложно выковырять полюбившиеся текстуры и модельки. Но такая разработка тоже стоит денег. Всё делать одному будет слишком долго. А кто говорил, что будет легко? Речь о том, что это возможно.

Если у тебя есть интерес к математике и ты любишь логически рассуждать, то основы программирования тебе дадутся легко. В любом императивном языке программирования используются конструкции "если-то-иначе" и "повторять-до-тех-пор", то есть используются условия, которые могут быть "истиной" или "ложью". Остаётся только изучить синтаксис самого языка: где-то пишут if условие then действие end, а где-то if (условие) { действие } и тому подобное. То есть различия только в написании. Вот тебе основы программирования в двух словах.

Что касается разработки именно игры, то есть понятие основного игрового цикла. С точки зрения программирования - это обычный цикл "повторять-до-тех-пор", просто он не заканчивается до самого конца игровой сессии. Этот цикл делит игру на так называемые "кадры" или "тики", из которых и состоит игра. Каждый кадр - это отдельное состояние игры, которое соответствует отдельной итерации основного цикла. Тебе нужно придумать, каким образом одно состояние сменяет другое, как осуществляется переход, какие вычисления при этом производятся. Такой "кадр" обычно не соответствует кадру на экране (другими словами ход игры не зависит от FPS), хотя это уже отдельная сложная тема.

1. Язык выбирай в зависимости от того, какой движок или платформу будешь использовать. Не оглядывайся на другие игры. Например, Unity и соответственно C#.
2. Курсы, учебники, ютуб-каналы - без разницы. В любом случае ты потратишь какое-то время, и его не получится сильно уменьшить. То есть это прямая конвертация времени в знания и навыки без сильных колебаний курса цены этой конвертации. В целом, время будет зависеть от твоего начального бэкграунда (т.е. что ты знаешь и умеешь уже сейчас).
3. В программировании (да и в других областях) сложную задачу принято разбивать на части (декомпозиция). Сначала нужно изучить понятие игрового цикла, и как время будет течь в игре (или как время в игре соотносится с реальным, учитывая паузы и сохранения). Затем решить, в каком порядке и что там будет выполняться более детально. Однако любая мелкая игровая система всё равно будет достаточно сложна, и её снова нужно разбивать на совсем уж простые. А простые - снова разбивать на элементарные. Поэтому от умения разбивать зависит, закончишь ли ты программу (игру) или нет.
4. Сетевая часть - обычно самая сложная (и самая глючная), потому что для каждой своя оптимизация. В двух словах, устройства обмениваются сообщениями по сети, и эти сообщения могут пересылаться с разной скоростью, а могут порой вообще теряться в никуда. Клиент-серверная модель предполагает, что есть некое главное устройство (например, ты арендовал сервер в дата-центре), к которому подключаются все остальные (т.н. клиенты). Но вот как будет реализовано взаимодействие, контроль ошибок, чтобы не глючило, вот это уже зависит от самой игры.