Анимированный эффект щита космического корабля в Unity3D

Понял.

есть гарантия отсутствия креша

Это главное.

Анимированный эффект щита космического корабля в Unity3D

Спасибо! Очень полезная и занимательная статья.
Кстати, что в шейдерах с возможным делением на ноль?
Например, здесь:

float hitIntensity = (1 - t0) * ((1 / (d0)) - 1) +
					(1 - t1) * ((1 / (d1)) - 1) +
					(1 - t2) * ((1 / (d2)) - 1);

Мобильная 3D игра на Unity3D менее чем за 90 часов

1) velocity лучше руками не трогать вообще, т.к. это ломает физику объекта. Используйте .AddForce(x, y, z, ForceMode.Force);

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

2) все вычисления физики надо делать в FixedUpdate(), а не Update(). Он для того и предназначен, что не зависит от мощности железа игрока.

Да, тут согласен с Вами.

Ещё из коварного вспомнилось, что для произвольного перемещения/вращения rigidibody необходимо использовать методы MovePosition/MoveRotation (или параметры position/rotation) самого rigidbody, а не трансформа.

Мобильная 3D игра на Unity3D менее чем за 90 часов

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

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

Мобильная 3D игра на Unity3D менее чем за 90 часов

del

Мобильная 3D игра на Unity3D менее чем за 90 часов

Спасибо, именно это я и имел ввиду, когда писал:

Много опасных «а вдруг» при дальнейшей разработке проекта

По поводу

void Update() {
    rb.velocity = new Vector3 (speed, 0f,0f);
}

Тут в каждом кадре устанавливается скорость движения rigidbody, а не выполняется перемещение объекта на определённую величину. То есть от фпс тут будет зависеть то, как часто будет устанавливаться скорость (как часто вызывается Update()), но никак не скорость передвижения объекта. Поэтому умножать на Time.deltaTime в данном случае не нужно.

Но Вы правильно сделали, что упомянули и разъяснили принцип работы Time.deltaTime, ведь это, наверное, самая распространённая ошибка начинающего Unity-разработчика.

Мобильная 3D игра на Unity3D менее чем за 90 часов

Думаю, Ваша статья совместно с нашими комментариями, дадут начинающему разработчику понятие того, что нужно учиться делать правильно. И при этом не отпугнут его от увлекательной стези геймдева, а это главное.

Мобильная 3D игра на Unity3D менее чем за 90 часов

Почему внутри метода

void changeDirection() {
      if (isMovingRight) {
         isMovingRight = false;
      } else {
         isMovingRight = true;
      }
}

пять строчек вместо одной:

void changeDirection() {
      isMovingRight = !isMovingRight;
}

InvokeRepeating ("SpawnPlatform", 1f, 0.2f);

Странное решение. Разве Вас не смущает то, что платформы будут генериться вне зависимости от положения игрока? Много опасных «а вдруг» при дальнейшей разработке проекта:

• а вдруг игрок пройдёт первые десять платформ быстрее, чем за секунду
• а вдруг игрок будет стоять на месте, а платформы всё генерятся и генерятся
• а вдруг скорость игрока будет больше одной платформы за 0.2 секунды

Я понимаю, что целью статьи было немного другое, но с такими вещами аккуратнее надо быть в статьях, которые мотивируют/обучают начинающих разработчиков :)

Реализация быстрых 2D-теней в Unity с помощью 1D shadow mapping

Тут дело скорее не в сравнении «что лучше: 2д или 3д?», а в целесообразности разработки и выпуска 2д-игры с низким фпс (и, соответственно, потери аудитории/прибыли) вследствие туманных перспектив её дальнейшей доработки до 3д.

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

Уж поверьте, тени для игр — головная боль. Особенно для мобильных устройств. И тут практически всегда приходится изощряться изо всех сил, придумывать обходные пути, чтобы получить картинку приемлемого качества с минимально необходимым фпс.

P. S. Да, мне нравятся 2д-игры. Как в качестве развлечения, так и при их разработке :)

Реализация быстрых 2D-теней в Unity с помощью 1D shadow mapping

Спасибо за перевод!

Не так давно сам мучался с подобной задачей. Есть игровое поле, состоящее из ~80 кубов, выстроенных в 2д-сетку. Кубы могут исчезать и выпадать сверху, заполняя пустые места. Для каждого куба нужно отрисовывать тень от направленного источника света, находящегося слева вверху (то есть, все тени параллельны между собой, направлены вправо-вниз).
Главными проблемами были:

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

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