Я читаю одну замечательную книгу, Game Coding Complete , и эта книга настоятельно рекомендует использовать подход MVC (Model-View-Controller) с тремя ключевыми слоями:
- Уровень игровых приложений
- Игровая логика
- Просмотр игры
Для меня такой подход выглядит излишним для мобильной компьютерной игры.
Каково ваше мнение, пожалуйста? Стоит ли реализовывать эту архитектуру, даже если она добавляет дополнительную связь, необходимую между модулями? Может ли этот дизайн потреблять столько ресурсов процессора, что в итоге результат будет значительно медленнее, чем если бы он не был реализован?
architecture
Bunkai.Satori
источник
источник
Ответы:
Я немного поддерживаю использование структуры MVC даже для простой мобильной игры. Если ничего другого, то это помогает решить проблему, от которой страдают разработчики, которые не укусили ее достаточно раз: отделить код дисплея от логики игры.
Я также скажу, однако, чтобы иметь в виду, что MVC, как и все шаблоны проектирования, существует, чтобы сделать вашу жизнь проще . Это означает, что если в любой момент времени соблюдение каких-либо правил относительно того, что вы должны или не должны делать при использовании MVC, усложняет вашу жизнь, игнорируйте это . Произойдет одно из двух: 1) вас укусят позже, и вы поймете, почему, если вы сделаете это иначе, на самом деле ваша жизнь в конечном итоге упростилась, или 2) никаких последствий.
Компьютерное программирование по своей природе получает много последователей правил, которые ценят приверженность элегантному принципу, а не совершают что-либо, и им нравится выдвигать свою систему ценностей; не позволяйте им сделать вас одним из них. Самое важное, что может случиться с вашей игрой, - это ее доставка .
источник
Проекты времени компиляции не потребляют мощность процессора, если у вас нет невероятно ужасного компилятора. Объектно-ориентированный язык или подход не отличаются по характеристикам производительности от процедурного. Вы не будете вызывать никаких дополнительных затрат на использование MVC. Модульность существует во время компиляции, а не во время выполнения, когда код встроен и оптимизирован, это не будет иметь никакого значения вообще.
Многие современные игры фактически запускают модели и представления в отдельных потоках и получают большую производительность на большинстве платформ.
В конечном счете, MVC - это хороший дизайн, который позволяет вам повысить уровень обслуживания и уменьшить количество ошибок и т. Д. Бесплатно . Там нет причин, чтобы не использовать его. Это все равно что спросить, почему вы должны использовать
forцикл вместо рукописныхgotos. Если вы не задумываетесь о превосходном дизайне, он, несомненно, лучше, чем ничего.Редактировать: проекты во время компиляции не потребляют мощность процессора. Проекты времени выполнения, такие как наследование, очевидно, делают.
источник
Почти всегда существует компромисс между ясностью кода и техническими требованиями (скорость, память и т. Д.) Программы. Объектно-ориентированные языки имеют дополнительные издержки по сравнению с процедурными языками, но было показано, что они имеют много преимуществ по сравнению с процедурными языками, особенно в долгосрочном обслуживании кода (ошибок и т. Д.), А также часто в скорости разработки.
Исходя из этого, я предлагаю, чтобы MVC стоил реализации ради вас как программиста игры . Ваш код будет лучше следовать объектно-ориентированным принципам, особенно инкапсуляции , и вам, скорее всего, будет гораздо легче его поддерживать (исправлять ошибки или добавлять новые функции).
С другой стороны, убедитесь, что вы действительно закончили игру и не тратите так много времени на работу над «движком», что это никогда не будет сделано.
Для получения дополнительной информации, пожалуйста, прочитайте вопрос "Почему MVC & TDD больше не используются в игровой архитектуре?" и мой действительно длинный ответ.
источник
a++будет точно такой же, как иa++в C (гдеaтип примитива и т. Д. И т. Д.). Но рассмотрим простой класс C ++ с виртуальной функцией, которая что-то делает, эта виртуальная функция несет большие издержки по сравнению с простой функцией C, даже если внутренний код идентичен. Объектно-ориентированные языки имеют накладные расходы . Извините за явное высказывание "скорость". Если дополнительное выделение памяти и тому подобное не приводят к более медленной программе, то вы абсолютно правы.