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

Я пиарюсь

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

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

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

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

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

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

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

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

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

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

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

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

Для такого случая лучше использовать DateTime и TimeSpan вместе с шаблонами форматирования:

using System;
using UnityEngine;

public class TimerTest : MonoBehaviour
{
    public float timer = 90;

    private DateTime timerEnd;

    private void Start()
    {
        timerEnd = DateTime.Now.AddSeconds(timer);
    }

    private void Update()
    {
        TimeSpan delta = timerEnd - DateTime.Now;
        Debug.Log(delta.Minutes.ToString("00") + ":" + delta.Seconds.ToString("00"));
        if (delta.TotalSeconds <= 0)
        {
            Debug.Log("The END");
        }
    }
}

Важно помнить, что при таком способе не будет учитываться Time.timeScale, если он вам нужен, то можете аналогичным образом вместо DateTime сохранять float со временем, но тогда минуты придётся вычислять самостоятельно. Плюсовать deltaTime в апдейте не советую. Теоретически ещё можно использовать Timer, но я слышал, что он работает не на всех платформах.

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

Просто берёте и назначаете:

var request = new UnityWebRequest();
request.timeout = 10;

Может быть у вас версия юнити старая, где таймаута ещё нет?

Подозреваю, что прежде всего проблема в огромных размерах игрового мира, ваш радар еле-еле в экран влезает, юнити на таком масштабе плохо работает. Во-вторых имеет смысл в настройках Rigidbody поменять Collision Detection на Continuous или Continuous Dynamic, но учтите, что MeshCollider с такими настройками работать не умеет, так что его придётся заменить на сборный коллайдер из боксов и капсул. На худой конец можете триггеры заменить на ручной вызов Rigidbody.SweepTestAll, возможно, результат будет лучше.

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

Первая строчка в гугле

On a desktop computer (Mac OS or Windows) the location of the files can be obtained with the following code:
path = Application.dataPath + "/StreamingAssets";
On iOS, use:
path = Application.dataPath + "/Raw";
On Android, use:

path = "jar:file://" + Application.dataPath + "!/assets/";

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

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

Вам надо выключать не модуль, а саму систему частиц. Модуль нужно выключать, если вы собираетесь руками спавнить частицы с помощью ParticleSystem.Emit. В вашем случае лучше дёргать Play, Pause и Stop в нужное время.