Привет! Хотелось бы поделиться своими впечатлениями о проведении одного из самых популярных технических соревнований в России.

Объединение AR и VR в одну компетенцию

Самой первой заметной проблемой является объединение никак особо друг с другом не связанные компетенции AR и VR. Для тех, кто не знает, VR – разработка приложений для шлемов виртуальной реальности. AR – разработка приложений для мобильных платформ, в которых ты наводишь камеру на реальный мир и на него проецируются какие-то объекты. Разные движки, разные SDK, разные подходы к интерфейсу, разный гейм-дизайн, разный код. Тот, кто работает с VR обычно работает только с ним, а AR только с AR. С таким же успехом можно было в несколько раз сократить число компетенции. Например объединить:

• Всё, что связано с Unity: разработка игр, AR/VR и т.д.

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

• Всё, что связано с кулинарией: хлебопечение, кондитерское дело, поварское дело и т.д.

• Всё, что связано с робототехникой: Летающая робототехника, мобильная робототехника и т.д.

Площадки могут сами определять локальную документацию компетенции

То-есть площадка может менять оборудование в архитектурном листе, как угодно. Менять правила и так далее. Что-то с этим сделать нельзя, так как “документы уже утверждены и печати стоят”. Из-за этого возникает несколько следующих проблем.

На площадке почему-то запретили контроль версий

В целом, идея таких компетенций как разработка игр, AR/VR и т.д. является работа в команде. Главным инструментом коллаборации является контроль версий, и это важнейший навык в любой настоящей работе программиста. В требованиях к команде на первом месте стоит “умение работать с контролем версий”. В инфраструктурном листе также присутствует Git.

Однако, когда мы приехали на площадку, оказалось, что Git “нужен только для скачивания SDK”. Зачем для этого Git я не понял. Обычное использование Git запретили, из-за того, что “нельзя публиковать проекты в интернете”. Так проекты же в приватных репозиториях создаются… Да там и историю коммитов и изменений отследить можно. Проекты делаются один день так что зайти в репозиторий из дома тоже не получится.

Передача данных участников организуется через в флешку “в прошлом году также было”. Кооперироваться через флешку в Unity или других движках невозможно. Из-за этого получается деление обязанностей без особых вариантов: один программист и один 3D-дизайнер. Между собой они никак не взаимодействуют. Так и какой смысл в этом тогда? Может тогда просто на две компетенции разделить: на 3D-моделирование и, собственно, AR/VR? А то так получается, что кто-то просто кого-то задерживает.

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

Участников вынуждают использовать определённое ПО. Что это за ПО, заранее не известно

Посмотрев инфраструктурный лист на официальном сайте WorldSkills, мы готовились со своим, удобным нам ПО. Для VR мы хотели использовать Godot, а для AR – Unity + Easy AR.

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

1. На сайте WorldSkills в инфраструктурном листе указан движок Unity и слово “или аналог”. В локальной документации слово “или аналог” пропало, осталось только Unity и Unreal Engine. Мы, полагаясь на официальные документы, готовились выступать на Godot Engine (открытое и бесплатное ПО). В итоге, когда приехали на соревнования, оказалось, что можно использовать только Unity или Unreal. Unreal для этого дела не очень подходит, поэтому на нём и так никто не участвует. А у Unity есть огромное число проблем, которые делают разработку в соревновательных условиях настоящим мучением. Почему нас вынуждают работать только на определённом движке, который ещё и является коммерческим? Организаторы объяснили это тем, что “все должны быть в одинаковых условиях”. Но ведь у вас движка уже два: Unity и Unreal, это уже можно считать за “неравные условия”, хотя я так не считаю. Почему нельзя использовать другой движок, который в отличии от этих, является бесплатным и более удобным?

2. На сайте WorldSkills НЕ указано, с какими AR плагинами для движков должны работать участники. На локальной площадке в инфраструктурном листе появилась строчка “Vuforia” и всех заставили работать именно на ней. Почему? Лично я не вижу ни одной причины, почему именно она. По удобству лучше Easy AR, там не нужно зачем-то каждый раз заходить в браузер и загружать туда суда свои метки. А что делать интересно тем, кто работает на Unreal Engine и других движках? Самому писать фреймворк с нуля? + Vuforia является максимально коммерческой платформой и берёт деньги с разработчиков за всё подряд.

3. На сайте WorldSkills НЕ указано, с какими VR плагинами нужно работать. Когда приехали, сказали работать можно только со Steam VR Plugin. Причём, шлемы-то были Oculus. Вместо того чтобы сразу использовать их SDK, пришлось смириться с ненужной прослойкой Steam VR, которая не только просто была не нужна, но ещё и нестабильно работала. А ведь 50% людей всегда работало с Oculus Integration, или вообще ч чем-то другим. А что с UE, тоже свой писать?

Организаторы площадки сказали, что они сами определяют инфраструктурный лист и кто на чём работает. То-есть, официальная документация “для организаторов площадки, а не для участников”.

В принципе для тех, кто реально хорошо разбирается это не проблема. Так что мы за день вспомнили и Unity, и Vuforia, и Steam VR. Но для кого-то это может стать очень критично. Мы, например, по сути, потеряли всю подготовку.

Постоянные проблемы с оборудованием

Т.к. участники могут работать только на Unity, только с определёнными SDK возникают проблемы с оборудованием. По этим пунктам понятно, почему мы не хотели работать с Unity:

1) VR/Unity/Visual Studio могут просто не работать. Так некоторых участников задерживают часами, а то и больше.

2) Постоянные вылеты Unity, которые удваиваются с использованием Vuforia. Так, у нас Unity пару раз вылетела просто на тесте. Пустой проект встречает тебя тремя ошибками в консоли. Нажатие на окно выбора цвета на нашем ПК вызывало три подряд таких окна:

Только путь был другой. Хорошо, что хоть пару раз нажав на “Cancel”, ошибки уходили. Проект был если что на тот момент пустой, только с установленным SDK Vuforia.

               3) Так как, опять же, площадки сами утверждают инфраструктурные листы, у участников были ПК с медленными дисками. А медленные диски + Unity = постоянные ожидания, которые отнимают огромное число времени. Создание и запуск пустого проекта – 5 минут. Каждый перезапуск с вылетом столько же.

               Вылеты не останавливают время, ведь “других тоже не ждали”. А так как его очень мало, это превращается в лотерею, у кого программа будет работать стабильнее. А если ты ещё и не сохранишь вовремя…

Попытка применять правила классической олимпиады к современному направлению

1)     Слишком мало времени на выполнение заданий. Всего три часа на разработку полноценного приложения, и ты это ещё и в одиночку должен делать.

2)     Запрет пользоваться интернетом и необходимость сдавать телефоны во время выполнения задания. Чтобы воспользоваться интернетом, необходимо поднять руку и подозвать эксперта другой команды. В интернете можно только заходить на сайт Vuforia для загрузки баз и искать референсы, текстуру и музыку. Нельзя пользоваться никакими другими сайтами, к примеру: форумы unity, документация C# и т.д.

А ведь, по сути, AR/VR/Game разработка — это знание основ и умение пользоваться поисковиком. По идее, тебе должны просто давать задание, и ты должен найти способ его решить. Тогда, соревнования приносит тебе новые знания и даёт какой-то опыт в нестандартных проблемах, решения для которых ты собираешь по кусочку. На WorldSkills же ничего этого нет и смысл соревнования теряется. Никто не собирается выучивать все методы и баги SteamVR.

Час отведён на написание бесполезной документации

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

Как могла бы выглядеть полезная документация? Описание проекта и, допустим, диаграмма классов.

Что участников вынуждают писать?

• Диаграмма экранов и переходов между ними. Интересно, что они подразумевали под этим. 50% говорит, что это просто названия экранов и стрелочки перехода между ними, а остальные, что это наброски того, как будет выглядеть интерфейс приложения. В итоге выбор судий склонился в сторону того, что это всё-таки наброски интерфейса приложения, что в общем-то на “диаграмму экранов” совсем не похоже.

• Архитектура работы приложения. Что это такое тоже никто не знает. Пришли к выводу, что просто блок-схема действие пользователя.

• Системные требования приложения. Интересно, откуда мы заранее можем узнать требования ещё не готового приложения? Или какой смысл писать кол-во оперативной памяти для AR приложения на Android 7+? Что требовать судьи тоже не знали.

• Бесполезные наброски объектов приложения. Тут даже комментировать нечего.

Да и вообще, с каких пор 3D-Дизайнер и программист должны писать эти бумажки?

Полная некомпетентность 50% жюри

“Эксперты” могут выдвигаться от каждой команды. И часто это просто учителя информатики, которые ничего не понимают в компетенции. Естественно все будут максимально защищать свою команду. Присутствует множество субъективных критериев, в итоге эксперты должны сами придумывать систему оценки, а в таком случае она вряд ли окажется справедливой. Дебаты могут растянутся на часы (а участники в это время стоят и ждут в коридоре). В итоге получаются какие-то скандалы и обвинения экспертов других команд в несправедливой оценке (а может ли вообще такая оценка быть справедливой?). Несколько человек пытаются ещё как-то адекватно оценивать, кто-то боится занизить или завысить оценку и везде просто ставит что-то среднее. Из-за некомпетентности жюри принимаются несправедливые решения.

Странные требования в самом задании

Вот здесь есть тестовое задание, которое во много раз сложнее того, которое на отборочных этапах, однако критерии похожие: Юниоры 14-16 – Google Диск

3D:

“Должны быть пронумерованы основные динамические элементы приложения” – никто не знает, что они имели ввиду.

“Должны быть реализованы качественные спецэффекты на основе систем частиц” – Довольно субъективно. И зачем обязательно добавлять системы частиц там, где они не нужны?

“Должен быть проработан качественный UI/UX приложения” – субъективность.

Программирование:

“Должен корректно использоваться функционал игрового движка” – опять никто не знает, что же это значит.

“Должны использоваться современные паттерны разработки и паттерны ООП” – использование паттернов там, где не надо (а задание там простое) – само по себе является анти-паттерном и так делать нельзя.

“если используется код, то он должен быть легко читаемым и содержать комментарии (не менее 80% блоков)” – излишнее комментирование кода – анти-паттерн. Хороший код не требует описания, чтобы убедиться в этом можно открыть любой opensource проект, никаких 80% откомментированных блоков там не будет. Приходится писать бесполезные комментарии просто чтобы были.

“Оптимизация”:

“Количество треугольников не должно превышать 20 тысяч” – поставил две модели дерева, сделанные в блендере, и уже ушёл далеко за лимит.

“Настроены отражения - расставлены Reflection Probes” –мы же на мобильные платформы делаем… Разве это – “оптимизация”?

“правильно настроен Occlusion Culling” – а “неправильно” – это как?

“Реализована асинхронная загрузка уровня” – то-есть, вместо LoadScene() нужно обязательно использовать LoadSceneAsync()? Тот, кто знает критерий, просто добавляет одно слово и получает балл.

“Количество вызовов отрисовки не должно быть больше 500, настроен и применен GPU-instancing” – GPU-instancing? Мы опять же на мобильную платформу делаем. А про “количество вызовов отрисовки” – может это к разработчикам движка?

“FPS не должен падать ниже 60” – а если я запущу на ПК 20-летней давности со встроенной видеокартой? А если на самом современном топовом ПК?

Несправедливая система оценки

1)     Критерии оценки не всегда соответствуют заданию. Например, в VR части нет блока “Оптимизация” (лучше бы его на самом деле не было), но при этом в критериях есть то, что в нём содержится. Также в критериях есть блок “Постпроцессинг”, о котором в задании вообще нет никакого упоминания

2)     Куча странных критериев:

“Топология моделей не содержит многоугольники” – почему?

“Не видны обратные стороны полигонов” – а если у меня есть модель дерева, у которой должны быть видны обе стороны листьев?

“развертка сделана вручную” – развертку дефолтного куба тоже обязательно вручную делать?

“присутствуют PBR текстуры” – Как же мы без них то жили… Ведь ползунок Metallic и Roughness в движках давно, наверное, отменили.

“Хотя бы один элемент имеет анимацию” – сделаем анимацию куба где-нибудь на границе мира, куда никто не пойдет.

“реализован набор анимации для одного объекта – 3 и более”, интересно для каких моделей в простых заданиях нужно три анимации.

“кол-во треугольников в кадре не превышает 20к” – поставил два дерева и уже лимит.

“Присутствуют простые хорошо детализированные модели” – кажется, кто-то говорил про ограничение по числу треугольников?

“Использование Occlusion Portals” – в проекте с действием на открытой местности?

“Не должно быть просадок меньше 60” – на ПК 20-летней давности почему-то у всех 1 fps.

“Использование асинхронной загрузки уровней” – зачем?

“UI делает приложение уникальным”, “Адекватность разрешения проб” – никто не знает, что это значит.

“Проект запускается и работает в виртуальной реальности” – подходит к пустому проекту.

“Анимация выглядит хорошо”, “хорошо реализованная анимация”, “идеально проработанная анимация”, “Модели имеют хорошую визуальную составляющую”, “Модели идеально проработаны”, “UI красиво реализован”, “Качественный, безупречно продуманный и интуитивно понятный UX проекта”, “Идеально проработанные спецэффекты”, “красивые спецэффекты”, “логичные названия” – отличные темы для начала бесконечных дебатов среди “экспертов”.

3)     Некоторые критерии программирования являются анти-паттернами:

“Прокомментировано более 80% блоков кода” – хороший код не требует комментариев. Излишние комментирование – анти-паттерн.

“НАЛИЧИЕ ОТСТУПОВ – 0,1 БАЛЛ” – без комментариев.

“отсутствие неиспользуемых событий и действий в сценарных блоках” – в каком-то смысле анти-паттерн. Нельзя писать какие-то полезные методы для удобства использования.

“реализован по крайней мере один паттерн проектирования” – использование паттернов там, где они не нужны, является анти-паттерном. Единственный применимый паттерн в некоторых заданиях – синглтон, который является самым спорным паттерном и не очень хорошей практикой. А его при этом почему-то ещё и не засчитывали.

“использование асинхронных механизмов, встроенных в движок” – а если это не нужно? А не в Unity? Тоже анти-паттерн?

“Использование GPU-Instancing” – во всех материалах ставить галочку. А это точно хорошая практика для мобильных платформ? И зачем?

И всё это – только самые заметные.

Что же следует из такой системы оценки? Из небольших примеров - не засчитывается паттерн Синглтон.

А из серьезного:

Побеждают не талантливые ученики, которые достигли успехов в своём деле, а те, у кого есть таблица оценки

Первые места занимают участники, которые участвовали когда-то раньше и у которых есть листы оценки. Им даже не нужно реализовывать задание. Просто можно пройтись и выполнить простые критерии, про которые те, кто участвуют в первый раз не знают. А те, кто пытается реально сделать задание его выполнят, но у них не останется времени на угадывание, чего же всё-таки имели ввиду авторы задания под определёнными формулировками.

Получается нет смысла делать что-то интересное, искать новые пути решения, ведь ты всё равно проиграешь тем, кот использует:

Стратегия победы

Из этого получается идеальная стратегия победы за 20 минут одним участником для любого задания. Причём чем основное задание сложнее, тем лучше она работает.

1)     Заходим в блендер и копируем 10 раз дефолтный куб. Сохраняем. Повторяем столько раз, сколько нужно моделей. Для каждой делаем развертку, проводим триангуляцию, закрашиваем любым цветом. Получаем “качественную модель”, без многоугольников, без вывернутых нормалей, без оборотных сторон многоугольников, 90% полигонов участвуют в формообразовании. Кластеры покрывают 75% UV тайла, нет зазоров, перетягиваний. Развертка сделана вручную. Элементы текстурированы, есть PBR текстуры, все модели есть в соответствии с заданием. Модели соответствуют стилистике. Модели идеально проработаны и имеют много мелких деталей. Кол-во треугольников не превышает 20к.

За 5 минут мы получаем идеально выполненную часть 3D-моделлера. Если пытаться нормально выполнять задания такого результата достичь невозможно.

2)     Создаём проект в юнити, добавляем SDK. Создаём сцену с названием “Main Menu”. На ней добавляем кнопку “Играть”, добавляем одну строку кода LoadSceneAsync() с переходом на сцену “Game”. На сцене Game кидаем в центр все модели, закидываем абсолютно любые PBR текстуры. Добавляем на объект Rigidbody. Ставим Reflections Probe, запекаем Light Map. Настраиваем Occlusion Culling. Используем Importance Volume. На материалах ставим галочку  GPU-Instancing. Добавляем какой-нибудь Post Processing.

За 10 минут получаем проект, которые полностью удовлетворяет всем критериям системы оценки.

3)     Создаём скрипт, добавляем на любой объект.

В 18 строк мы получаем все баллы за часть с программированием: код, откомментированный более чем на 80%, с использованием паттернов ООП. 

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

Нельзя подать апелляцию

Так как решения принимаются “независимыми экспертами”, они не подлежат оспариванию, какими бы несправедливыми они не были. Так, нам, например, не засчитали паттерн синглтон, потому что “ну это так себе паттерн”, а по заданию никакой другой использовать смысла не было. Преимущество получает команда, у которой эксперт более продвинут в определённой области и может менять правила под себя.

Другие странности

После выдачи задания есть 15 минут на вопросы у своего руководителя – а он за это время может полностью рассказать суть решения задачи и помочь с чем угодно. Какой смысл тогда забирать интернет?

Что в итоге?

Те, кто уже участвовали и у кого есть таблицы оценки заняли первые места, просто пройдясь по критериям, даже без реализации основного функционала. Те, которые просто хорошо сделали задание – не прошли.

А как нужно?

Как пример хорошей организации соревнования подобного типа могу привести НТО (Национальную технологическую олимпиаду):

• На решение практической задачи 24 часа, причём 4 человека в команде = 96 человеко-часов.

• Работа в команде при помощи контроля версий.

• Участники сами решают, как распределять задачи и что делать.

• Нет никаких ограничений выбора ПО, главное, чтобы была бесплатная версия.

• Уникальные, интересные задачи без готовых решений – нет смысла отключать интернет.

• Можно пользоваться готовыми решениями, но за это снижают баллы.

• Спокойна общая психологическая обстановка, нет обратного отсчёта времени, который постоянно у тебя на виду.

• Справедливая система оценки, которая показывает общее состояние проекта.

• Независимые эксперты - профессионалы в своём деле.

• Также личный этап представляет классические олимпиады по информатике и математике, которые проверят необходимые для технических компетенций базовые знания.