
Сообщение от
DeadlyInnerSenseNew
Спасибо за ответ.
Хотелось бы, чтобы учитывалось и следующее.
1. Приоритетная задача в виде балансировки это хорошо, но прошло уже 4 полных недели, а из изменений по сетам была только оперативная правка могущества через костыль.
2. Я сам разработчик лид уровня и понимаю, как функционируют команды. Само собой, что и на правки и на тестирование нужно время. Но ведь есть несколько типов задач по приоритетности и сложности. Вот пример.
а) Таск А - исправить ошибку на сете, благодаря которой дается 45 статов вместо 90, в описании 90. Это маленький баг либо описания либо одного числа. Он правится любым разработчиком, даже стажёром, на него не требуется много времени разработки, детального анализа и даже детальной проверки.
б) Таск Б - изменить баланс сета - 1-2 недели разработки. Тестировщики обкатывают сет, выдают рекомендации, что и как не работает. Какое-то время занимают правки. Это 1-2 недели работы, максимум 3, если что-то случилось странное.
в) Таск В - изменение характеристики умений (Атака по площади против прямой атаки по площади) - скорее всего потребует больше времени, возможно больше месяца.
Очевидно, что таски А и Б можно было бы сделать, если бы этим занимались. Возможно - ими и занимаются, но хотят выкатить всю пачку изменений разом. Понимаю, но даже если бы вы делали это по частям львиная доля негатива бы ушла.
3. К сожалению, мы уже получили некачественный опыт с могуществом и сетами в первую неделю. И было прямое ощущение, что их хотели выпустить просто, чтобы выпустить. Сроки поджимали или по какой-то другой политической причине. Просто проблемы, которые повылезали были очеивдны спустя 1-2 дня активной игры, а значит тестирование о них вполне могло знать, чтобы этот качественный опыт нам обеспечить. Почему это попало на боевые сервера - остаётся загадкой.
Передайте, пожалуйста, разработке и менеджементу (скорее даже менеджменту), чтобы позволяли делать хотя бы небольшие правки по актуальному обновлению свежего контента, коими были сеты и оперативно их выкатывать. Это важно для снижения негатива в сторону команды разработки.