>Хотя некоторая трава, на вкус, слишком яркой стала
Цветовую палитру брал с имперской травы :-) Поэтому визуально цветовая гамма эльфийской травы в игре смотрится гармонично с окружением. А в целом, цвета могут казаться слишком яркими на фоне тёмных в видео. Рекомендую, посмотреть в самой игре, если у вас есть такая возможность.
Прежде чем ответить на ваши вопросы, проговорю один момент: если смотреть строго с позиции исправления технических ошибок, то большая часть изменений в моде попадают под категорию вкусовых улучшений. Например, чёрные текстуры, маленькие юниты и отсутствие освещения на 3d объектах в тёмное время суток - это тоже своего вкусовые улучшения, т.к. в логах игры нет никаких ошибок (текстовых строчек помеченных как [EE]). Т.е. технически игра отрисовала всё корректно - ошибок нет.
Поэтому: что считать полезным улучшением, а что вкусовым - это очень дискуссионный вопрос, и у каждого человека может быть своё видение.
Поясню почему были внесены мной изменения, которые вызвали у вас вопросы.
>чем обосновывается смена цвета травы?
Красный цвет забирал на себя много зрительного внимания при игре. Плюс обилие красного цвета в кадре (особенно на вечерней сцене) лично у меня вызывал жуткий зрительный дискомфорт при игре.
>Или убирание огня с юнитов демонов за появившиеся камни?
Значительно активная анимация забирала внимание от юнита, который должен быть центральным объектом в сцене. Другими словами, по задумке юнит должен владеть зрительным вниманием игрока, а волей-неволей глаза всё-равно фокусируются на огоньки под ногами. Я их убрал и сцена стала казаться пустой. Я добавил 3d объект в сцену и огни слева и справа на заднем плане.
>Или статическая камера вместо динамической?
Честно признаюсь, что в главном меню меня подташнивает от кругового движения камеры. Словно я надел VR-шлем и сел на аттракцион. В столицах убрал потому, что там, как я предполагаю, есть баг. Как я понял, по задумке должно было быть так: в начале "обзорная камера панорамы столицы с медленной скоростью", а затем "камера с более быстрой скоростью движется от объекта к объекту столицы". Но баг заключается в том, что проигрывание камеры не сбрасывается при выходе из экрана столицы, а воспроизведение продолжается на том моменте, когда ты закрыл окно столицы. И каждый раз открывая экран столицы у тебя там постоянно какая-то движуха, зрительно не формируется образ столицы, как целостный предмет. Плюс ты открываешь, например, окно магазина, а на заднем плане у тебя карусель. Зрительные ощущения на любителя.
>Или окно навыков -- у юнитов выглядит красивше с изображением (неужели фон нельзя было оставить?)
Фон пришлось убрать, т.к. новое положение элементов окна закрывали бы персонажа. Я одно время работал дизайнером и в общем, так делать не очень хорошо. По крайней мере, в такой ситуации. Представьте, что кто-то вас фотографирует, а какой-то человек решил пробежать и в итоге часть вашего тела закрыта.
>или у лидеров в оригинале больше направлений развития?
Всё верно, вариативность направлений пришлось поубавить, т.к. место под навыки стало значительно меньше. Плюс было желание сделать, чтобы у древа навыков юнита и лидера было какое-то общее ядро. И в моде ядро такое: у юнитов одна полоса с навыками без возможности вариации. А у лидеров та же полоса, но есть ещё две параллельные, на которые можно переключать в некоторых местах.
>Было бы неплохо, если бы каждое такое изменение можно было включать отдельно
К сожалению, игра не предоставляет такой возможности. Но лицензия мода позволяет делать ответвления (fork). Поэтому вы можете сделать форк мода и в своей версии удалить не понравившиеся вам фичи или добавить свои.
Судя по вашим формулировкам и вопросам, вы привыкли оперировать категориями. Мышление категориями - это полезный инструмент, сам им пользуюсь довольно часто, но к сожалению, у него есть недостаток: категории - это очень относительное понятие. И чертить границы категорий можно как угодно в зависимости от ситуации и задачи. Поясню на примере:
Представьте себе руководителя проекта (РП). Он привык работать с проектами, срок которых от полугода до 2-х лет. Исходя из его опыта, у такого человека вычерчивается допустим следующие категории размеров проектов: маленький (6 - месяцев), средний (12 месяцев), крупный (24 месяца). Теперь представьте себе руководителя разработки. Он привык работать не с проектами, а фичами. Сделать фичу в продукте - это проект для руководителя разработки. Исходя из его опыта, у такого человека категории размеров его проектов (сделать фичу) отличаются от аналогичных категорий РП. Для него маленький проект - 1 месяц, средний - 3 месяца, крупный - 6 месяцев.
Поэтому ваш первый вопрос не понятен, если вы не указываете объект с позиции которого будет даваться определение.
По второму вопросу, если кратко, то сложность в том, что типизация - не работает. Каждая задача уникальна и со своим контекстом. Да, можно группировать проекты в условно "типовые", чтобы например, определить стек технологий. Но из своего опыта скажу, что даже типовые задачи делаются по-разному. Например, типовая задача мониторинга в одном проекте, может быть реализована, совершенно по-другому в другом проекте. Другая реализация -> следовательно, другие трудозатраты и оценка.
Спасибо за ваш развёрнутый комментарий. С интересом почитал.
Могу только его дополнить тем, что модель работы, которую вы описываете в промышленности в ИТ называется Водопад. Она широко была популярна где-то до начала 2000-х годов. И сейчас считается неэффективной, т.к. в ИТ сейчас чертежи деталей могут меняться каждый месяц, оборудование на котором вытачиваются детали (пишут код) тоже постоянно меняется и оборудование очень сложное, в котором сотни тысяч, а в некоторых и миллионы маленьких деталей разработанных огромным количеством, зачастую, никак не связанных друг с другом людей.
Другими словами, сейчас на производстве в ИТ нет ничего фиксированного, всё может поменяться буквально через месяц-два, а бывает и чаще. И в такой среде традиционные способы оказываются мало эффективны, т.к. они рассчитаны на статическую среду, когда изменения происходят неспешно и измеряются годами, а не месяцами или неделями, как это сейчас происходит в ИТ.
С статистической точки зрения, вы абсолютно правы. Поэтому математически, демонстрация всего одного примера не может служить прочным доказательством того, что на множестве других задач он будет выполняться тоже.
С другой стороны, я не могу приложить в статью все примеры из своей практики. Статья и так получилась объёмная. И новые примеры раздули бы её ещё больше. Скажу только то, что за 4 года использования этой методикой оценки - она давала очень хороший результат. И за это время я сдал все свои проекты в срок.
Цель моей статьи: донести идею и свой опыт решения проблемы с точной оценкой задач. А применять ли эту методику на практике или нет - решать уже вам.
Действительно, в проектах оценка может проводиться в несколько этапов: - есть первоначальная оценка, когда заказчик хочет просто узнать сколько будет стоить. В этом случае, вкладываться в детальную оценку и составлять подробную дорожную карту нет смысла. Заказчик просто приценивается, поэтому и количество трудозатрат должно быть соответствующим. - есть оценка фичи, когда уже есть заказ от заказчика, есть требования и нужно сделать оценку, чтобы сообщить заказчику, когда ориентировочно получит свою фичу. Здесь можно оценку сделать уже более детальную, чем в первый раз. - есть оценка конкретной задачи, когда уже фича в работе. Вот здесь как раз и нужно прям детально фиксировать и разбивать задачу на подзадачи, которые представляют собой маршрут её решения.
Поэтому считаю, что трудозатраты по оценке должны быть соразмерными с этапом проекта. Другими словами, детализация дорожной карты зависит от того насколько близко она к началу реальных работ.
Честно признаюсь, что использование contract coverage не встречал ни на одном проекте из которых мне доводилось работать. Но опыт работы на этих проектах показал, что все понимают важность использования автоматизированных средств контроля качества, но по приоритету такие активности очень часто стоят в конце списка, и они долго пылятся в бэклоге. Судя по вашему комментарию, на вашем проекте иная ситуация и очень рад, что у вас на проекте есть ресурсы для внедрения таких инструментов и поддержки их.
Широко использовал во многих проектах аннотацию `@Sql`. Но я столкнулись с проблемой при использовании такого решения: сложно поддерживать sql запросы, которые кодируются текстом. Для себя я выявил следующие недостатки такого подхода: - сложно переиспользовать sql запросы - сложно кастомизировать sql запросы с помощью параметров - при частом изменении схемы править приходится большое количество sql запросов - не очевиден порядок выполнения sql запросов - необходимо в insert sql запросе обязательно указывать все not null значения, что в итоге приводит к не пониманию, а какие именно значения нужны для теста - как бы странно не звучало, не все проекты написаны на Spring Framework
Я искал решение, которое бы могло покрыть все описанные выше недостатки, но к сожалению не нашёл. Поэтому написал DbChange. Изначально в нём была возможность только задать changeset (через Java классы). Но потом я подумал, что у решения предлагаемого Spring Framework тоже есть плюсы и кому-то это может быть полезным. И потом уже добавил поддержку statements и sqlQueryFiles.
Я намерено в статье не ссылался на Spring Framework, т.к. библиотека не позиционируется как альтернатива его аннотации `@Sql`. Хотя вы верно отметили, что часть функций схожа. Вы можете использовать любую из них или обе сразу. Это ваш выбор. Но в любом случае, спасибо, что обратили на это внимание. На мой взгляд, важно предоставить разработчику набор инструментов, чтобы он уже сам выбрал подходящий для решаемых задач.
Rogue Lords тоже стоит в wishlist'е. А вот ArtStation, к сожалению, у меня не открылся. Видимо нужен впн...
Попробуйте, возможно, ваше мнение изменится.
Я в пятых героев тоже наиграл не мало часов. Но Герои и Disciples хоть и близкие по жанру игры, но по механикам игры довольно разные.
Кампанию можно проходить с модом. Я сейчас так и делаю :-)
Приятной вам игры. Если будет возможность, поделитесь своими впечатлениями после игры.
>Хотя некоторая трава, на вкус, слишком яркой стала
Цветовую палитру брал с имперской травы :-) Поэтому визуально цветовая гамма эльфийской травы в игре смотрится гармонично с окружением. А в целом, цвета могут казаться слишком яркими на фоне тёмных в видео. Рекомендую, посмотреть в самой игре, если у вас есть такая возможность.
Спасибо за ваш комментарий. С интересом почитал.
Iratus у меня в желаемом в Steam, но поиграть руки пока не дошли. А про Легенды Эйзенвальда вообще не слышал. Спасибо за рекомендацию.
Прежде чем ответить на ваши вопросы, проговорю один момент: если смотреть строго с позиции исправления технических ошибок, то большая часть изменений в моде попадают под категорию вкусовых улучшений. Например, чёрные текстуры, маленькие юниты и отсутствие освещения на 3d объектах в тёмное время суток - это тоже своего вкусовые улучшения, т.к. в логах игры нет никаких ошибок (текстовых строчек помеченных как [EE]). Т.е. технически игра отрисовала всё корректно - ошибок нет.
Поэтому: что считать полезным улучшением, а что вкусовым - это очень дискуссионный вопрос, и у каждого человека может быть своё видение.
Поясню почему были внесены мной изменения, которые вызвали у вас вопросы.
>чем обосновывается смена цвета травы?
Красный цвет забирал на себя много зрительного внимания при игре. Плюс обилие красного цвета в кадре (особенно на вечерней сцене) лично у меня вызывал жуткий зрительный дискомфорт при игре.
>Или убирание огня с юнитов демонов за появившиеся камни?
Значительно активная анимация забирала внимание от юнита, который должен быть центральным объектом в сцене. Другими словами, по задумке юнит должен владеть зрительным вниманием игрока, а волей-неволей глаза всё-равно фокусируются на огоньки под ногами. Я их убрал и сцена стала казаться пустой. Я добавил 3d объект в сцену и огни слева и справа на заднем плане.
>Или статическая камера вместо динамической?
Честно признаюсь, что в главном меню меня подташнивает от кругового движения камеры. Словно я надел VR-шлем и сел на аттракцион. В столицах убрал потому, что там, как я предполагаю, есть баг. Как я понял, по задумке должно было быть так: в начале "обзорная камера панорамы столицы с медленной скоростью", а затем "камера с более быстрой скоростью движется от объекта к объекту столицы". Но баг заключается в том, что проигрывание камеры не сбрасывается при выходе из экрана столицы, а воспроизведение продолжается на том моменте, когда ты закрыл окно столицы. И каждый раз открывая экран столицы у тебя там постоянно какая-то движуха, зрительно не формируется образ столицы, как целостный предмет. Плюс ты открываешь, например, окно магазина, а на заднем плане у тебя карусель. Зрительные ощущения на любителя.
>Или окно навыков -- у юнитов выглядит красивше с изображением (неужели фон нельзя было оставить?)
Фон пришлось убрать, т.к. новое положение элементов окна закрывали бы персонажа. Я одно время работал дизайнером и в общем, так делать не очень хорошо. По крайней мере, в такой ситуации. Представьте, что кто-то вас фотографирует, а какой-то человек решил пробежать и в итоге часть вашего тела закрыта.
>или у лидеров в оригинале больше направлений развития?
Всё верно, вариативность направлений пришлось поубавить, т.к. место под навыки стало значительно меньше. Плюс было желание сделать, чтобы у древа навыков юнита и лидера было какое-то общее ядро. И в моде ядро такое: у юнитов одна полоса с навыками без возможности вариации. А у лидеров та же полоса, но есть ещё две параллельные, на которые можно переключать в некоторых местах.
>Было бы неплохо, если бы каждое такое изменение можно было включать отдельно
К сожалению, игра не предоставляет такой возможности. Но лицензия мода позволяет делать ответвления (fork). Поэтому вы можете сделать форк мода и в своей версии удалить не понравившиеся вам фичи или добавить свои.
Судя по вашим формулировкам и вопросам, вы привыкли оперировать категориями. Мышление категориями - это полезный инструмент, сам им пользуюсь довольно часто, но к сожалению, у него есть недостаток: категории - это очень относительное понятие. И чертить границы категорий можно как угодно в зависимости от ситуации и задачи. Поясню на примере:
Представьте себе руководителя проекта (РП). Он привык работать с проектами, срок которых от полугода до 2-х лет. Исходя из его опыта, у такого человека вычерчивается допустим следующие категории размеров проектов: маленький (6 - месяцев), средний (12 месяцев), крупный (24 месяца). Теперь представьте себе руководителя разработки. Он привык работать не с проектами, а фичами. Сделать фичу в продукте - это проект для руководителя разработки. Исходя из его опыта, у такого человека категории размеров его проектов (сделать фичу) отличаются от аналогичных категорий РП. Для него маленький проект - 1 месяц, средний - 3 месяца, крупный - 6 месяцев.
Поэтому ваш первый вопрос не понятен, если вы не указываете объект с позиции которого будет даваться определение.
По второму вопросу, если кратко, то сложность в том, что типизация - не работает. Каждая задача уникальна и со своим контекстом. Да, можно группировать проекты в условно "типовые", чтобы например, определить стек технологий. Но из своего опыта скажу, что даже типовые задачи делаются по-разному. Например, типовая задача мониторинга в одном проекте, может быть реализована, совершенно по-другому в другом проекте. Другая реализация -> следовательно, другие трудозатраты и оценка.
Спасибо за ваш развёрнутый комментарий. С интересом почитал.
Могу только его дополнить тем, что модель работы, которую вы описываете в промышленности в ИТ называется Водопад. Она широко была популярна где-то до начала 2000-х годов. И сейчас считается неэффективной, т.к. в ИТ сейчас чертежи деталей могут меняться каждый месяц, оборудование на котором вытачиваются детали (пишут код) тоже постоянно меняется и оборудование очень сложное, в котором сотни тысяч, а в некоторых и миллионы маленьких деталей разработанных огромным количеством, зачастую, никак не связанных друг с другом людей.
Другими словами, сейчас на производстве в ИТ нет ничего фиксированного, всё может поменяться буквально через месяц-два, а бывает и чаще. И в такой среде традиционные способы оказываются мало эффективны, т.к. они рассчитаны на статическую среду, когда изменения происходят неспешно и измеряются годами, а не месяцами или неделями, как это сейчас происходит в ИТ.
С статистической точки зрения, вы абсолютно правы. Поэтому математически, демонстрация всего одного примера не может служить прочным доказательством того, что на множестве других задач он будет выполняться тоже.
С другой стороны, я не могу приложить в статью все примеры из своей практики. Статья и так получилась объёмная. И новые примеры раздули бы её ещё больше. Скажу только то, что за 4 года использования этой методикой оценки - она давала очень хороший результат. И за это время я сдал все свои проекты в срок.
Цель моей статьи: донести идею и свой опыт решения проблемы с точной оценкой задач. А применять ли эту методику на практике или нет - решать уже вам.
Про пи и e, к сожалению, не слышал. Слышал про формулу длины дуги, её частный вывод, как раз и использовал в статье.
Спасибо, что поделились своей историей.
К сожалению, не понял вашего вопроса. Поясните, пожалуйста.
Вы подсветили хороший сценарий.
Действительно, в проектах оценка может проводиться в несколько этапов:
- есть первоначальная оценка, когда заказчик хочет просто узнать сколько будет стоить. В этом случае, вкладываться в детальную оценку и составлять подробную дорожную карту нет смысла. Заказчик просто приценивается, поэтому и количество трудозатрат должно быть соответствующим.
- есть оценка фичи, когда уже есть заказ от заказчика, есть требования и нужно сделать оценку, чтобы сообщить заказчику, когда ориентировочно получит свою фичу. Здесь можно оценку сделать уже более детальную, чем в первый раз.
- есть оценка конкретной задачи, когда уже фича в работе. Вот здесь как раз и нужно прям детально фиксировать и разбивать задачу на подзадачи, которые представляют собой маршрут её решения.
Поэтому считаю, что трудозатраты по оценке должны быть соразмерными с этапом проекта. Другими словами, детализация дорожной карты зависит от того насколько близко она к началу реальных работ.
Честно признаюсь, что использование contract coverage не встречал ни на одном проекте из которых мне доводилось работать. Но опыт работы на этих проектах показал, что все понимают важность использования автоматизированных средств контроля качества, но по приоритету такие активности очень часто стоят в конце списка, и они долго пылятся в бэклоге. Судя по вашему комментарию, на вашем проекте иная ситуация и очень рад, что у вас на проекте есть ресурсы для внедрения таких инструментов и поддержки их.
Спасибо за статью! Примеры в официальной документации похоже давно устарели. Приятно найти актуальное на текущий день руководство.
Широко использовал во многих проектах аннотацию `@Sql`. Но я столкнулись с проблемой при использовании такого решения: сложно поддерживать sql запросы, которые кодируются текстом. Для себя я выявил следующие недостатки такого подхода:
- сложно переиспользовать sql запросы
- сложно кастомизировать sql запросы с помощью параметров
- при частом изменении схемы править приходится большое количество sql запросов
- не очевиден порядок выполнения sql запросов
- необходимо в insert sql запросе обязательно указывать все not null значения, что в итоге приводит к не пониманию, а какие именно значения нужны для теста
- как бы странно не звучало, не все проекты написаны на Spring Framework
Я искал решение, которое бы могло покрыть все описанные выше недостатки, но к сожалению не нашёл. Поэтому написал DbChange. Изначально в нём была возможность только задать changeset (через Java классы). Но потом я подумал, что у решения предлагаемого Spring Framework тоже есть плюсы и кому-то это может быть полезным. И потом уже добавил поддержку statements и sqlQueryFiles.
Я намерено в статье не ссылался на Spring Framework, т.к. библиотека не позиционируется как альтернатива его аннотации `@Sql`. Хотя вы верно отметили, что часть функций схожа. Вы можете использовать любую из них или обе сразу. Это ваш выбор. Но в любом случае, спасибо, что обратили на это внимание. На мой взгляд, важно предоставить разработчику набор инструментов, чтобы он уже сам выбрал подходящий для решаемых задач.
Согласен, скачивание из Maven Central, гораздо удобнее и привычнее для Java разработчика.
Спасибо за ваш комментарий. Дополню статью об использовании TestInfo.
Спасибо за ваше мнение. Согласен, взглядов много и мой всего лишь один из многих.