Подобные проблемы часто поддаются красивому решению при помощи паттерна Visitor.

1) надо сделать классы-наследники от game_object — draw_game_object, serialize_game_object и т.п. с соответствующими методами draw(), save()/load() и т.п. Менеджер должен об конкретных наследниках знать.
2) game_object должен обладать следующим интерфейсом:

...
public:
virtual void accept(Manager* mgr);
...

3) менеджер должен обладать следующим интерфейсом:

... 
public:
void process(draw_game_object* object);
void process(serialize_game_object* object);
// и т.п.
...

4) функцию accept() каждый наследник реализует как

...
mgr->process(this);
...

Передавая таким образом this как указатель на конкретного наследника
5) а в функциях process(...) менеджер может творить всё что угодно, ориентируясь на известные ему интерфейсы наследников game_object'a

Достоинства метода:
— никаких кастов, всё строится на таблице виртуальных функций
— легко расширяемо
— нет условных конструкций
— саму конструкцию process/accept можно вынести и спрятать очень далеко