User
Если у вас скопилось слишком много ассетов в Unity, а поиск нужного контента превращается в долгий и хаотичный процесс, значит, пора пересмотреть подход. Автор статьи делится своим опытом создания Asset Inventory — мощного инструмента, который решает проблему организации ассетов, позволяя искать не по пакетам, а по самим объектам. Как работает эта система, какие технологии использованы и какие возможности она открывает — читайте под катом.
Полгода назад меня повысили до ведущего Unity-разработчика, и тогда я почувствовал, что должен поднять уровень навыка написания кода. Мне надоело создавать прототипы, которые впечатляли клиентов и работодателей, в то время как через год кодовая база превращалась в адское месиво, изобилующее ошибками и горами технического долга.
Однако, куда бы я ни обращался и кого бы ни спрашивал, мнение было одним: я не должен гнаться за такими глупыми мечтами, Singleton — это всё, что мне нужно для создания приложений на Unity.
Мне однако этот ответ не понравился, и я надеюсь, что он не является окончательным. Поэтому я решил бросить себе вызов и сделать игру — не ради славы или денег, а чтобы исследовать саму природу того, как создавать игры. В надежде найти архитектурный паттерн, который сможет привести меня к чему-то большему, чем гора спагетти-кода.
Этот цикл статей о разработке серверного ПО совместимого с протоколом Minecraft: Java Edition.
В этой части я акцентирую внимание на основных вещах: типы данных, структура пакетов и как клиент получает информацию о сервере.
От переводчика
Привет, Хабр!
Я ненастоящий сварщик и перевод статьи дался мне тяжело, поэтому я назову его вольным — заранее очищу совесть, если где-то слишком сильно перефразировал оригинал. Буду рад указаниям на ошибки перевода, грамматики и т.п. в личку.
Перевод публикую с разрешения сайта Toptal, где выложен оригинал автора Eduardo Dias da Costa.
Обычно программисты знакомятся с профессией, начиная с Hello World. Затем ставят всё большие и большие цели и каждая новая задача приводит к важному уроку: чем больше проект, тем запутаннее код.
И в больших, и в маленьких командах никто не кодит так, как ему вздумается. Код должен быть поддерживаемым и расширяемым. Ведь компания, в которой ты работал, не обращается к тебе всякий раз, когда потребуется исправить баг или улучшить код. Да и ты вряд ли этого хочешь.
Поэтому существуют шаблоны проектирования; они — сборники правил для стандартизированного структурирования проекта, которые помогают разделить и организовать большую кодовую базу, и упростить работу с незнакомым кодом.
