Надо же. А я как будто внимательно всё вокруг осматривал когда регистрировался) Виноват.
Что ж, таких как я было большинство, судя по всему. Хорошо хоть меня знания английского не подвели)
Я не совсем представляю как это устроенно именно у вас, но в моём случае было бы примерно так. Характеристики юнита указаны в префабе юнита. Окно покупки может получить доступ к префабу для того чтобы выдернуть эту информацию оттуда — должно ведь оно потом каким-то образом вызвать Instantiate этого юнита?
Вроде бы можно изменять скорость воспроизведения анимации через параметры компонента Animator (:
Но у нас часть «анимации» производится из кода, как раз чтобы можно было гибко менять параметры анимации — скорость замаха, время отдыха после удара…
Я код кастомных инспекторов пишу в том же файле, в котором находится сам класс, для удобства. И да — в случае использования этой директивы код можно оставлять где угодно.
Огромное спасибо, обязательно всё это учту!
Не думаю, что буду серьёзно менять имеющуюся архитектуру в текущем проекте, но переписать что-то для последующих очень вероятно (:
Тут как раз возникает проблема невозможности редактирования public-полей и констант ScriptableObject без открывания кода. То есть такие классы смогут обрабатывать свою логику и хранить какие-то данные, что удобно — но гейм-дизайнер не сможет их настраивать из редактора Unity.
Можно было бы использовать ScriptableObject для тех объектов, настройкой которых гейм-дизайнер занимать не будет — но тогда у нас будут две практически одинаковые сущности (SO и синглтоны), которые нужно будет поддерживать отдельно — я принял решение упростить эту систему. Может быть, есть решение оптимальнее, но я пока что его не придумал (:
Чаще всего — да. Но помимо этого нередко бывают новые фичи, которые можно покрыть используя исключительно имеющиеся методы в API — у нас достаточно типизированная вёрстка (хоть и не всегда, конечно), чтоб можно было использовать общие методы вида «Нажать закрывающую кнопку в облаке» или «Нажать кнопку 'Продолжить' в диалоге». Часто этого бывает достаточно :)
Пример: мы для наших тестов пишем библиотеку, построенную вокруг слегка изменённого принципа PageObject — поэтому если в новой задачке появляется какой-то простой функционал на уже существующей странице (или на похожей странице), то инженеру достаточно написать новый метод в тесте этой страницы вида (это не наш код, это пример)
Научить ребят базовому синтаксису PHP и поиску существующих методов — не такая сложная задача.
Понятно что в этом случае новые кнопки, новые странички иболее сложная логика могут стать для инженера сложностью — но тут либо они могут уже сами начинать совершенствоваться, либо (если сроки поджимают, например) отдать написание этого теста более опытным специалистам.
«Постарайтесь записывать интересные кейсы в вики» — тоже регламент, просто совсем не строгий.
Не обязательно иметь их в каком-то официально записанном виде — главное чтобы все участвующие в процессе были в курсе.
А семинары, лекции и прочие беседы позволят даже устные договорённости доносить до всех заинтересованных :)
Вот если бы в интернете было какое-нибудь общедоступное и более-менее универсальное решение, то нам бы не пришлось разрабатывать вышеописаный велосипед с моторчиком (:
Спасибо, теперь понял (: На самом деле, не натыкались на такую идею в процессе поиска решения — возможно, в противном случае всё могло пойти по-другому.
В принципе, большая часть трудов ушла именно на разработку системы сбора/хранения/использования статистики и распределения тестов по потокам — она ведь нигде и никак не реализована. А уж что использовать, чтобы запускать полученные потоки, уже дело отдельное — и это не такая большая работа, чтоб не написать это самому со 100% соответствиям потребностям системы.
У нас уже использовалась билдовая система Ant (как я понимаю, Waf как раз его аналог), и его функционала вполне хватало — зачем использовать что-то дополнительно?
Задачей всё-таки было ускорить прохождение тестов, не вылезая из имеющейся инфраструктуры. Возможно, другие инструменты могли бы улучшить результат, но перекраивать имеющуюся мощную систему контроля качества только ради пускалки в наших планах не было
Что ж, таких как я было большинство, судя по всему. Хорошо хоть меня знания английского не подвели)
Но у нас часть «анимации» производится из кода, как раз чтобы можно было гибко менять параметры анимации — скорость замаха, время отдыха после удара…
Не думаю, что буду серьёзно менять имеющуюся архитектуру в текущем проекте, но переписать что-то для последующих очень вероятно (:
Можно было бы использовать ScriptableObject для тех объектов, настройкой которых гейм-дизайнер занимать не будет — но тогда у нас будут две практически одинаковые сущности (SO и синглтоны), которые нужно будет поддерживать отдельно — я принял решение упростить эту систему. Может быть, есть решение оптимальнее, но я пока что его не придумал (:
Научить ребят базовому синтаксису PHP и поиску существующих методов — не такая сложная задача.
Понятно что в этом случае новые кнопки, новые странички иболее сложная логика могут стать для инженера сложностью — но тут либо они могут уже сами начинать совершенствоваться, либо (если сроки поджимают, например) отдать написание этого теста более опытным специалистам.
Не обязательно иметь их в каком-то официально записанном виде — главное чтобы все участвующие в процессе были в курсе.
А семинары, лекции и прочие беседы позволят даже устные договорённости доносить до всех заинтересованных :)
В принципе, большая часть трудов ушла именно на разработку системы сбора/хранения/использования статистики и распределения тестов по потокам — она ведь нигде и никак не реализована. А уж что использовать, чтобы запускать полученные потоки, уже дело отдельное — и это не такая большая работа, чтоб не написать это самому со 100% соответствиям потребностям системы.
Утилитка написана на PHP (: