Что из следующего, по вашему мнению, труднее?
- решение проблемы кодирования
- решение более серьезной проблемы с кодированием
Ага, я тоже.
Программирование - это решение проблем. Когда вы пытаетесь соответствовать требованиям будущего своего кода, вы эффективно решаете излишне более сложную и большую проблему.
Почему излишне сложнее? Потому что есть вероятность, что ваши предположения о будущем неверны!
Время историй!
Мне нравится создавать инструменты для разработчиков игр. Я люблю делать вещи, которые делают вещи. Из-за этого иногда я просто делаю инструменты без реальной нужды в них!
Все идет нормально. Но в середине разработки DeMagnete мы решили использовать какой-нибудь инструмент графического редактора, чтобы помочь разработчику игры настроить логику головоломки.
В то время я подумал: «Это здорово, потому что я уже создавал редактор графиков раньше! Давайте просто воспользуемся этим! ».
Аааа и получилось некачественно, как бутерброд из фастфуда.
Дело в том, что когда я начал создавать его без реального использования, я принял некоторые дизайнерские решения, которые укусили бы нас при использовании его в реальном проекте.
Плохие решения
- Пытался сделать все расширяемым
- Использовал непонятный графический интерфейс Unity API.
Плохие последствия
- Часть сильно расширяемой начинала действовать при попытке сделать простые вещи (и даже тогда она не была такой расширяемой, потому что в то время я не знал, что действительно выиграет от возможности настройки)
- Нет увеличения / уменьшения масштаба
- Трудно связать узлы, потому что слоты такие маленькие (нет API, чтобы это изменить)
- Сериализация была сложной, потому что нам нужно было синхронизировать нашу модель с моделью Unity API.
Переписываем решение
Пусть первый камень бросят те, кто никогда не переписывал реализацию решения!
Обладая знаниями о болевых точках первого API, а также точных потребностях, которые решит наш инструмент, мы, наконец, смогли найти более надежное решение.
За выходные я смог набросать новый инструмент графического редактора с нуля только потому, что на этот раз я знал, к чему стремлюсь. Благодаря этому API стало проще как в реализации, так и в использовании.
Хорошие решения
- Делайте API простым и самоуверенным
- Используйте стандартные инструменты графического интерфейса редактора и создайте собственный API для рисования графиков (это проще, чем кажется!)
Хорошие последствия
- Скрипты новых узлов суперкомпактны и выразительны.
- Возможна реализация увеличения / уменьшения масштаба !!!
- Легче подключать узлы, так как мы закодировали нашу функцию столкновения слот-мышь
- Сериализация была более надежной (как только мы выяснили некоторые начальные проблемы, ха-ха), поскольку нам не нужно было поддерживать синхронизацию двух состояний (представление и модель графика)
Хорошие дополнения
- Выберите GameObjects в иерархии, щелкая связанные с ними узлы.
- Пинг узлов при изменении выбора в иерархии
- Узлы могут иметь любой цвет RGB (раньше это должно было быть перечисление - безумие, правда?)
- Менять и анимировать цвет краев стало проще.
- Мы сделали «обрезанный край» для массового удаления краев, как это делает ShaderForge (довольно круто и полезно).
Что изменилось
Мы дважды решали одну и ту же задачу. Но вторая реализация была намного лучше и в целом лучше.
Единственное, что изменилось, - это то, что когда я впервые писал этот инструмент, у меня не было ни реальной необходимости, ни в прошлом.
Это один из шаблонов, которые я заметил в других инструментах / коде, которые я создал, но не имел реального варианта использования. И не было ни одного из этих инструментов, который я на самом деле использовал повторно без какого-либо переписывания!
Итак, это все! Сохраните свой код в настоящем!
** Ой! Ожидайте, что этот новый редактор графиков скоро будет доступен на BitStrap!