Игры: Кто ответственен за дисплей?

Я думаю, если процессор аннотаций тогда определенно использовать Java 6 версии API. Это тот, который будет поддержан в будущем. API Java 5 все еще находился в неофициальном пространстве имен com.sun.xyz.

Я думаю, что в ближайшем будущем мы увидим гораздо больше применений API процессора аннотаций. Например, Hibernate разрабатывает процессор для новой функции статической метамодели, связанной с запросом JPA 2. Они также разрабатывают процессор для проверки аннотаций проверки компонентов. Так что обработка аннотаций здесь, чтобы остаться.

Интеграция инструментов в норме. Последние версии основных IDE содержат опции для настройки процессоров аннотаций и их интеграции в процесс сборки. Инструменты построения основного потока также поддерживают обработку аннотаций, где maven все еще может вызвать некоторое горе.

При тестировании я нахожу большую проблему. Все тесты являются косвенными и каким-либо образом проверяют конечный результат обработки аннотаций. Я не могу писать простые единичные тесты, которые просто утверждают простые методы, работающие с TypeMirrors или другими классами, основанными на отражениях. Проблема в том, что невозможно создать экземпляр классов этого типа вне цикла компиляции процессоров. Я не думаю, что Sun имел в виду проверяемость при разработке API.

java.rmi.server.UnicastRemoteObject используется для экспорта удаленного объекта с протоколом удаленного метода Java (JRMP) и получения заглушки, которая взаимодействует с удаленным объектом.

Для следующих конструкторов и статических методов exportObject получена заглушка для экспортируемого удаленного объекта...

Там вы должны следовать Javadoc

Этот вопрос по-прежнему часто возникает в разработке игры, поскольку различные студии и группы начинают на новых движках.

Короткий ответ заключается в том, что это зависит от того, насколько сложными будут ваши игровые объекты. Для простых сущностей это не имеет значения.

Когда вы попадаете в гораздо более сложные сущности, вы должны переосмыслить свой подход. В общем, вы хотите противостоять желанию иметь убер, которая итерирует над каждой сущностью и вызывает некоторую функцию обновления/рендеринга. Это совсем не масштабируется, если только каждое обновление, рендеринг или какая-либо иерархия не совпадают. Что прекрасно для игры, как геометрия войны, но не для ничего сложнее, чем это.

То, что вы хотите сделать, это дать наиболее общей коллекции сущностей извлечь специфическое для использования обход. Например, если требуется визуализировать сцену, необходимо выбрать способ извлечения всех визуализируемых объектов из коллекции объектов и последующего визуализации всех объектов в произвольном порядке. То же самое касается физики, столкновений, ИИ и т. д.

Некоторые полезные ссылки:

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/ http://research.scee.net/files/presentations/gcapaustralia09/Pitfalls_of_Object_Oriented_Programming_GCAP_09.pdf

я настоятельно рекомендую оба;первый переходит в обоснование проектирования для построения игровых объектов из компонентов, то есть компонента рендеринга, физического компонента, компонента ИИ. Второй переходит в характеристики производительности различных подходов игровых сущностей.

MVC не обязательно подходит для игр. MVC был разработан для традиционных графических интерфейсов, которые обычно обновляются нечасто на основе дискретных событий, в то время как игры больше похожи на симуляторы, в которых происходит постоянное обновление, и презентация должна отражать это мгновенно.

Тем не менее, нет причин для того, чтобы все еще стремиться отделить состояние от презентации. Сущности не должны уметь рисовать себя как таковые - это означало бы, что они знают об операциях рендеринга, что ненужно - но должна быть возможность спросить их, как они выглядят в данный момент времени, а затем использовать эту информацию для рендеринга сцены. Например, 2D сущность должна быть способна вернуть свой текущий кадр анимации. Или же 3D сущность должна иметь возможность вернуть 3d сетку, положение и ориентацию. Здесь не требуется переключатель, если у вас есть общие представления, которые вы можете вернуть к рендереру. Сущности с сильно отличающимися алгоритмами рендеринга могут на этом этапе возвращать довольно разные объекты.

Обычно я решаю эту проблему с помощью наследования .

Например, над проектом, над которым я работаю, я использую Test-Driven Development для написания игровой логики с ручным тестированием рендеринга. Пример ниже на C # показывает приблизительную идею.

class GameObjecet {
    // Logic, nicely unit tested.
}

class DrawableGameObject : GameObject {
    // Drawing logic - manual testing
}

Как правило, это лучшее решение, которое я считаю. Это позволяет тестировать код, не загромождая логику игры презентационным кодом, таким как рисование, загрузка модели и т. Д.