Игра C++, дизайн класса и обязанности
Сериализация является процессом записи представления экземпляра объекта к потоку (или к последовательности байтов). Посмотрите то, что Sun заявляет об этом: http://java.sun.com/developer/technicalArticles/Programming/serialization/
3 ответа
Что касается создания глобального класса, я бы использовал синглтон, а затем просто вызвал Game :: GetInstance (), который вернул бы указатель на глобальный класс.
Что касается частиц, то, как я всегда работал с играми, было создание класса, который управляет всеми объектами. В основном цикле моих игр я бы назвал эту функцию классов UpdateObjects, которая будет просматривать список сохраненных в ней элементов и вызывать каждую из этих функций Update. То же самое с Render and Collision.
Раньше я возился с игровым дизайном, но не могу претендовать на звание эксперта.
Для глобального доступа к объекту я бы предложил использовать синглтон
для движущихся объектов я бы предложил сделать все родительским классом, который понимает расположение экрана и имеет метод обновления. Каждый раз, когда создается новый объект, добавляйте его к вектору, содержащему все объекты, один раз за кадр, вы проходите через вектор и запускаете обновление для всех объектов.
Объект, представляющий мою игру library is currently global (I know globals are usually bad) because many objects may rely on it here and there for things like loading their art or music. What's the best way to go about pulling that object out of global scope, without having to pass fifty parameters to everything that would otherwise use it directly?
I agree with the aforementioned singleton solution.
Next question: As we all know, Mega Man shoots lots of little white projectiles. Currently, the Player object is responsible for the Projectile objects he fires, updating their position and such (literally, calling the Projectile::Update() method once for each shot, inside the Player :: Update () метод).
Существует принцип гибкой разработки для создания кода, называемый «принцип единой ответственности». Согласно ему "НИКОГДА НЕ ДОЛЖНО БЫТЬ БОЛЬШЕ ОДНОЙ ПРИЧИНЫ ДЛЯ КЛАСС, КОТОРЫЙ МОЖНО ИЗМЕНИТЬ. "Итак, я думаю, я бы начал с разделения обязанностей класса Player на отдельные классы: например, один для позиционирования, а другой для стрельбы.
См. Пример и многое другое по этому вопросу SRP