dollar

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

Есть, конечно, нюансы чисто игровые, но они сильно разнятся и зависят от игры. В шутерах одни слабые места, в стратегиях реального времени - другие. Про пошаговые молчу, там проблем практически нет, но если это типа ММО или игры с матч мэйкингом, то нюансы касаются нагрузки на сервер и т.д.

P.S. Где вопрос про список ресурсов? Не смог найти.

По Unity, помимо документации, основной обучающий ресурс - learn.unity.com
Для комфортного обучения есть платный вариант.

Сделайте хитбокс.
Надеюсь, очевидно, что это такое (википедия).

Инди покупают готовые ассеты в сторе.

Unity. И это движок, а не "фреймворк".
Еще можно Unreal Engine.
Больше ничего не стоит использовать.

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

Начать лучше на Unity.
Как это сделать, лучше узнать из документации и обучающих материалов.

И если вы подумываете заработать на этом, то знать движок будет не достаточно. Но ведь главное - начать, не так ли? Если вы приверженец такой логики, то начните с Unity, а дальше, как пойдет.

Скорее для самоутверждения.

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

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

Большинство такой документации, особенно хорошей, находится под NDA. Так что вряд ли вам кто-то даст нормальные ссылки. Про курочку Рябу даже не смотрите.

А что касается структуры, то четких правил нет. Есть очень много подходов к составлению ГДД (геймдизайн документ), и у каждой компании (а иногда у каждой отдельной игры) они свои. В каждой структуре есть свои плюсы и минусы.

Задача ГДД - дать наиболее полное и точное представление об игре или фиче исполнителям. От этого и отталкивайтесь. А чем и как при этом вы пользовались, своей головой, или самодельной ИНС, или еще чем - не так важно.

Кстати, документация разная бывает. К примеру: вижн, концепт, ГДД, ТЗ, арт библия, рекомендации локализаторам, и многое другое, да даже регламент оформления программного кода. Это всё документация. И везде свои тонкости.

Нужно использовать программирование.

Соответственно, можно начать изучать Unity. Там же будет вам и аналитика, и монетизация, и многое другое из коробки.

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

Каждая игра в праве выбирать какие-то отдельные возможности Steam для создания серверов, либо обходиться без них.

Таким образом, это не одна технология, а комплекс технологий (либо одна сложная, как вам нравится).

Не нужно дублировать вопрос, удаляя при этом старый. Это прямое нарушение правил (п.4.1), где четко сказано:

категорически запрещается дублирование вопроса с целью повторного привлечения к нему внимания

К тому же, кто-то в момент удаления мог ещё писать развернутый ответ. А может до сих пор пишет, думая, что старый вопрос ещё жив. Бедняга. Ведь его труды пропадут сразу же после нажатия на кнопку "Отправить".

По теме вопроса: можете создавать объекты в другой системе отсчета, и двигать саму систему. Это родительский пустой объект.

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

Unity больше подойдет для всего, что имеет богатую 3d-графику и анимации. В целом, порог вхождения чисто по программированию туда и туда примерно одинаковый.

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

Перспективнее? По какому основанию? Я бы смотрел по уровню удовлетворенности. А это значит, что перспективнее там, где вам самим больше нравится и в чем вы больше разбираетесь, к чему лежит душа.

VR и AR - мы все следим за это сферой, но пока что там ловить особо нечего. Резкого взлёта, как у айфонов в свое время, не наблюдается. Может быть, вы будете первым, кто придумает что-то реально крутое, и весь рынок VR/AR пойдёт за вами.

За качество игры отвечает геймдизайнер.

Что касается чисто внешнего вида, то есть UI, UX - это отдельное направление, под которое в среднем и выше проекте желательно иметь отдельного специалиста. Есть также арт-директор (арт-лид), который может отвечать за стиль. Но в целом они все всё рано взаимодействуют с геймдизайнером.

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

Можно делать игру даже без операционной системы и языка программирования. А что? Теоретически такое возможно. Просто пишете сразу в машинных кодах процессора. Кое-как создаете загрузочную флешку - и вуаля, клиентская игра без ОС, без блекджека и без всего.

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

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

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

Я вижу два основных пути для вас:
1) Углубиться в программирование и математику. Для этого лучше технический ВУЗ. Можно даже отучиться два первых курса и уйти, чтобы перейти ко второму варианту. Но можно и защититься, к примеру, в сфере машинного обучения, это было бы полезно (для игр в том числе).
2) Выбрать то направление, в котором вы вообще не разбираетесь. Например, экономику, психологию, юриспруденцию. Для поступления, как правило, нужно знать школьные предметы типа математики и биологии, с которыми у вас по идее (если вы хорошо учитесь) всё должно быть хорошо. Тогда вы сразу станете разнопрофильным специалистом, это ценится в геймдеве, сможете быть классным геймдизайнером или продюсером. Если в одиночку делать игры, то тем более важно охватить все сферы.

Параллельно с этим можно самостоятельно интересоваться геймдевом вообще. Это специфическая сфера, и у нас в РФ нет профильного образования. К тому же в этой сфере всё так быстро меняется, что сложно сделать программу обучения, которая не устареет к выпуску из ВУЗа, с нашей-то системой образования. Есть различные короткие курсы, обычно платные, правда там готовят узких специалистов. За рубежом можете учиться, там есть высшее в области геймдева. Ну и в Москве есть профильное образование при вышке, но оно идёт как второе высшее, то есть сначала в обычном ВУЗе отучиться нужно, да и вообще накопить бэкграунд в игровой сфере.

Достаточно ли умения писать документы для игр

Главный скилл геймдизайнера - это, безусловно, умение составлять документацию и работать с экселем.

Не уверен, что вы действительно умеете писать документацию. В целом, это проверяется легко: если вы составили ГДД по фиче, и ни у одного члена команды (хотя бы 10 человек, включая начальство) не возникло умных вопросов, то вы крутой геймдизайнер. К слову, документация разная бывает, и даже конкретно диздоки разнятся по структуре и оформлению, хотя это вы наверняка и так знаете.

Все остальные навыки полезны, но не обязательны. К примеру, если игра про гонки, а вы водитель со стажем, то этот навык будет вам в плюс. Аналогично любой другой навык или профессия. Бухгалтер? Социолог? Политолог? Всё пригодится. В конкретном игровом проекте что-то может быть важнее.

Программирование тоже идёт плюсом, как и любой другой навык. Конкретно от программирования важно системное мышление, но не только. Геймдизайнер иногда может, особенно в малых командах, брать на себя роль программиста:

• Делать прототипы некоторых фич
  
• Писать макросы в экселе для своих нужд
  
• Писать тулзы для конфигурационных файлов
  

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

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