Даниил Басманов

Я пиарюсь

Наиболее популярная схема деления это:

1. Прототипирование
   
2. Пре-продакшн
   
3. Продакшн
   
4. Закрытый бета-тест
   
5. Soft launch
   
6. Релиз
   

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

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

Продакшн это этап, во время которого выполняется основная работа. К этому моменту вы уже чётко знаете что, сколько и как вы делаете. В этой фазе уже нельзя менять планы, все эксперименты надо было делать раньше. Конечно, может получиться и так, что несмотря на все усилия спустя месяцы и годы игра не складывается, в таких случаях процесс разработки откатывают на шаг-два назад. Например, так было с Prey, Overwatch и Rainbow Six Siege.

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

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

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

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

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

Это low poly, просто в определённой стилистике, термин "low poly" сам по себе означает только маленькое количество полигонов. Например, на картинках ниже изображены низкополигональные деревья, но выглядят они по-разному, потому что созданы в разном стиле.
Точно также и "pixel art" означает только то, что при рисовании уделяется большее внимание индивидуальным пикселям, а стилей рисования много, взять хотя бы Sword & Sworcery и Fez. Если вам понравились модельки в определённой стилистике, то вам нужно просто обратиться к автору и заказать их у него, либо найти художника, который сделает вам такие же. Нет никакого единого стиля низкополигональных космических кораблей, который можно нагуглить, в лучшем случае можно зацепиться за название какой-то популярной игры, например "модельки как в майнкрафте".

Вам нужно почитать про алгоритмы поиска пути, начать можете с википедии. Для общего случая навигации по графу обычно используют алгоритм A*. Для трёхмерных миров удобнее использовать navigation mesh, для работы с ними есть хорошая библиотека Recast.

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

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

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

Напишите им письмо, SDK доступен в индивидуальном порядке. Ближайшее, что есть из альтернативы это NVIDIA Material Definition Language.

У вас где-то в проекте лежит скрипт с названием Camera, из-за пересечения имён и получается такая ошибка. Почитайте внимательно консоль, у вас должно быть такое сообщение:

Script 'Camera' has the same name as built-in Unity component.
AddComponent and GetComponent will not work with this script.
UnityEditor.DockArea:OnGUI()

Используйте Rigidbody2D.rotation.

Если двигать физический объект через трансформ, то можно огрести глюки симуляции и лишние пересчёты физики. Двигайте лучше через Rigidbody.position или Rigidbody.MovePosition.
Самостоятельно физические объекты двигаются только под действием сил, в вашем случае без циклов не обойтись.

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

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

Скрипт не будет общим, у каждого инстанцированного префаба будет свой экземпляр класса. А проблема у вас в скрипте, вы считаете одинаковое расстояние для всех объектов:

pointDistans = GameObject.Find("point").GetComponent<Transform>();
...
distans = Vector3.Distance (pointDistans.position, camer.position);

По всей видимости, вам нужно поменять строчку в апдейте:

distans = Vector3.Distance (transform.position, camer.position);