Ambushed Raccoon
Весьма распространенная практика.
Продуктовая компания+мобильный геймдев.
Зависит от жанра игры, если игра одиночная, то для нее постоянно надо добавлять контент, ибо пользователи его "выжигают" и покидают игру.
Это самый ад ибо тогда кранчи тянутся из спринта в спринт.
Спасибо большое за привлечение внимания к данной теме.
Выскажу свое мнение. В большинстве случаев главная причина и проблема овертаймов в том, что они не оплачиваются. Это влечет за собой то, что менеджмент не видит в этом никакой проблемы. Зачем решать проблему овертаймов, если компания от этого имеет прибыль, а менеджер имеет свои плюсики и баллы от начальства, тк его подопечные более результативны. Обратил внимание, как в статье, так и в жизни, в большинстве случаев кранчи вам будут оправдывать люди, не принимающие в них непосредственное участие. Да, те самые плохие менеджеры. Да и довольно сложно представить себе овертаймящего менеджера, что он/она будет делать? Митинги до глубокой ночи? Из последних сил заполнять капасити матрицы? Рассылать письма об успехах на передовых по субботам? Я так не думаю.
И, да, отдельное спасибо работникам, которые готовы овертаймить за спасибо, даже тем, кто находится на довольны высоких позициях. Какая бы там лапша на ушах у вас не висела: общее дело, командный дух, сегодня овертаймишь, а через неделю мы все будем отдыхать, в общем нужное подчеркнуть.
Увы, но пример вообще ни к месту. И таких мест по коду не "достаточно много", а одно - это функция IEnumerator Climbing(), где подряд делается три этапа перемещения, которые можно вынести в отдельный метод и это пойдёт только на пользу. Но меня смутило, что это происходит в рамка корутины и я не стал с этим разбираться. Я бы не стал резко реагировать, но ведь вы не могли оставить конкретно меня и мои навыки без своих оценочных суждения.
"Нормальные кодеры так не делают" - оскорбление чересчур очевидное.
Их 8.
Видимо мне надо было написать "я мог бы сделать это циклом, но мне не кажется такой код более читаемым, особенно в рамках статьи". Вы бы сами почитали и посчитали сначала. 20 строк тут не будет, потому что перебирается только 8 чисел. т.к. у параллелепипеда 8 углов. Если бы их было 20 то это было бы совсем другая ситуация. И да. Вот так код будет выглядеть, если его написать циклом:
for (int i = 0; i < 8; i++)
{
int coefX = (i & (1 << 0)) == 0 ? 1 : -1;
int coefY = (i & (1 << 1)) == 0 ? 1 : -1;
int coefZ = (i & (1 << 2)) == 0 ? 1 : -1;
points[0] = gameObject.transform.TransformPoint(new Vector3(center.x + xSize / 2 * coefX, center.y + ySize / 2 * coefY, center.z + zSize / 2 * coefZ));
}
Да выбор в пользу 8-ми строк был сделан осознанно.
Вы правы. Я не обратил на него внимания. Но думаю, что данный материал будет интересен не только в рамках разработки на Unity. Логика будет работать и для других движков. Unity идеально подходит для быстрого создания POC-а.
Сейчас попробую найти подходящий пример использования и добавлю.
Доброго времени суток! Нашёл баг в решении. Хочу поделится правильным решением. Ошибка в методе private void ShakeRotateCameraInternal(...).
Должен выглядеть следующим образом:
private void ShakeRotateCameraInternal(Vector2 direction, float angleDeg, float degVelocity)
{
_degVelocity = degVelocity;
direction = direction.normalized;
direction *= Mathf.Tan(angleDeg * Mathf.Deg2Rad);
Vector3 resDirection = ((Vector3)direction + Vector3.forward).normalized;
_targetRotation = Quaternion.FromToRotation(Vector3.forward, resDirection);
}
Прошу прощение за кривой формат кода.
По сути вместо transform.forward нужно использовать Vector3.forward, потому что именно таким будет направление взгляда локальное.
Для меня проблема в том, что Вы рубите с плеча. Что значит трясти ствол и не трясти камеру? Подскакивает прицел, который всегда по центру, значит подскакивает и сама камера, ведь так? Помимо этого, отдача, как и скорострельность, безумно важные понятия с точки зрения геймдизайна и баланса. Чем мощнее оружие, тем больше у него будет отдача и ударное вращение после выстрела. Урон от выстрела больше, значит и больше расплата за него.
По поводу "разработчиков". Ну вы так или иначе сказали это с издёвкой. Это как в статье на тему медицины написать "доктор". Подобное пренебрежение тут неуместно.
Чаще всего вот такие очень редкие случаи свидетельствуют о том, что баг репорт составлен не совсем корректно. То есть произошла какая-то ошибка, не связанная с данным тестовым сценарием. И данный сценарий он будет мешать разработчику найти реальную проблему, ибо над ним всё время будет висеть то, что надо подпрыгнуть 23 раза и тд. И это действительно большая проблема. И бывают такие ситуации, что что-то на этапе тетстирования не учтено Вы решаете, что это редко и чёрт с ним, отдаёте пользователям, а потом данный баг воспроизводится у каждого 3-го юзера.
Бывают редкие баги, которые возникают в очень редких случаях и если их исправлять то надо внести много изменений и скорее всего выгоднее такой баг не исправлять, а оставить всё как есть.
В общем, такие вот очень редкие и дико непонятные баги бывают, но чаще всего они даже и не связаны с предоставленным тестовым сценарием.
Ну и возникновение ошибки при частых повторениях чего-либо свидетельствует о том, что логика слабо заточена под частые вызовы, такая проблема была с моей предыдущей реализацией тряски камеры и бывает, что она у тестировщика воспроизвелась на 23-й раз, просто к 23-му разу он стал это делать гораздо чаще. Либо же ещё, если Вы выделяете какие-то ресурсы на каждый прыжок, но чистите их некорректно, у вас может произойти утечка памяти, и там будут уже обращения к запрещённым областям и тд.
Извиняюсь за сумбур, постарался покрыть как можно больше ситуаций.
Да, что-то я тут на эмоциях рубанул с плеча. Неправильно это. Думаю, все зависит от всего, от менеджмента, от разделения менеджеров и разработчиков(куа и тд.) от политики компании и прочее, от самих людей, естественно. Но, так или иначе, в большинстве случаев тот, кто говорит, что овертаймы неизбежны и тд. Тот сам не особо то и в курсе, что это такое и насколько это может быть трудно и вредно.