Уже не помню откуда это, но когда я это осознал, качество работы и жизни в целом стало значительно лучше )) Нужно что бы работа была наполнена жизнью, а не жизнь работой.
Хранение параметров айтемов в SO это нормально. Даже если их будет гораздо больше 5000, нужно просто сделать удобный кастомный Editor для этого.
Но с эвентами реально просто дичь. С таким подходом до чистого кода как до луны. И что самое печальное, многие бегинеры могут последовать этому примеру и получить кашу в голове.
В данном случае нужен всего один статический евент с параметром и тогда была бы реально полезная статья.
Согласен. Я пришёл к выводу, что тут большую роль сыграли значения различных настроенных коэффициентов стратегий, которые не успели оптимально настроить. Также почти у всех есть не дописанные до конца отдельные модули их решений. Всё это + рандом вполне могли определить результаты.
Отвечу только по пункту 7. Остальное пусть лучше WeslomPo разжует ))
Как раз таки именно в больших проектах все это и имеет смысл, т.к. относительный объем этого инфраструктурного когда будет очень малым. А преимущества от вынесения бизнес логики в отдельные классы согласно паттерна MVC будут очень значительны.
Вообще, я руководствуюсь правилом — если это MonoBehaviour то это Вид и он максимально тупой.
Т.е. не использовать их для чего-то сложного. А выносить всю логику и т.д. в свои классы не наследуемые от MonoBehaviour и связывать с компонентами порожденным от MonoBehaviour через интерфейсы.
Но это все актуально только для более менее сложных проектов. Совсем простые игры проще, быстрее и в целом выгоднее делать не задумываясь обо всем этом, т.к. может получиться проектирование ради проектирования.
Стараться не использовать MonoBehaviour :).
Как бы это не было смешно, но насколько я знаю, это единственный верный путь, если нужно создать проект с более менее сложной архитектурой в Unity.
Проблемы не будет т.к. у них будут разные классы. Описание любого элемента можно будет легко получить только по его id. А при запросе к бд, если нужно получить данные для нескольких (или всех) элементов разных типов нужно будет использовать LEFT JOIN, а для какого-то конкретного типа INNER JOIN.
Баланс не нужен или костыль?))
А вообще не могу не согласиться с тем, что уже давно практически не делают ничего интересного и не казуального.
Если не затруднит, тоже очень бы хотелось получить продолжение в личку )
Намёк на продолжение очень радует)
Спасибо за рассказ! Очень здорово и легко читается.
Здорово! На одном дыхании… А когда стоит ожидать продолжение "Квантовое будущее"?
Очень здорово! Прочёл на одном дыхании, с нетерпением жду продолжения.
Нужно что бы работа была наполнена жизнью, а не жизнь работой.
Хранение параметров айтемов в SO это нормально. Даже если их будет гораздо больше 5000, нужно просто сделать удобный кастомный Editor для этого.
Но с эвентами реально просто дичь. С таким подходом до чистого кода как до луны. И что самое печальное, многие бегинеры могут последовать этому примеру и получить кашу в голове.
В данном случае нужен всего один статический евент с параметром и тогда была бы реально полезная статья.
Настроечных коэффициентов
Простите за описку с мобилы
Согласен. Я пришёл к выводу, что тут большую роль сыграли значения различных настроенных коэффициентов стратегий, которые не успели оптимально настроить. Также почти у всех есть не дописанные до конца отдельные модули их решений. Всё это + рандом вполне могли определить результаты.
Спасибо за статью! Действительно очень интересно. И даже в какой-то мере мотивирует к личному участию в следующем чемпионате))
Как раз таки именно в больших проектах все это и имеет смысл, т.к. относительный объем этого инфраструктурного когда будет очень малым. А преимущества от вынесения бизнес логики в отдельные классы согласно паттерна MVC будут очень значительны.
Т.е. не использовать их для чего-то сложного. А выносить всю логику и т.д. в свои классы не наследуемые от MonoBehaviour и связывать с компонентами порожденным от MonoBehaviour через интерфейсы.
Но это все актуально только для более менее сложных проектов. Совсем простые игры проще, быстрее и в целом выгоднее делать не задумываясь обо всем этом, т.к. может получиться проектирование ради проектирования.
Стараться не использовать MonoBehaviour :).
Как бы это не было смешно, но насколько я знаю, это единственный верный путь, если нужно создать проект с более менее сложной архитектурой в Unity.
Рекомендую этот канал всем кого заинтересовал UniRx. Там скоро должен появиться толковый тутор https://m.youtube.com/watch?v=kFoBvjwzbNA
Спасибо за статью! К сожалению, не могу просто плюсануть.