Ну и кто тебе мешает применить в draw_game_object в serialize_game_object виртуальное наследование от game_object? Далее наследуешься новым классом super_game_object от этих двух и пишешь соответствующий код в Manager.
По сути, для тебя главное — точно определиться с деревом наследования game_object. Если это возможно (т.е. если структура жесткая), то Visitor прокатит просто замечательно, поверь опыту ^_~
Если же твоя структура обязана быть гибкой (by design, что называется), то есть и второй вариант. Делай функции по количеству вариантов действий (т.е. draw(), save()/load() и .т.п.), причем в базовом game_object делай пустые реализации этих функций. А в производных классах пиши реализации выборочно, в зависимости от возможностей конкретного объекта. Это даст тебе следующее: каждый объект game_object будет "как бы" реализовывать всё, но реально — только то, что ты переписал в наследнике. Тогда ты сможешь в менеджере перебирать всю очередь с вызовом, допустим, с draw(), не заботясь о том, какой из объектов обработает вызов, а какой — нет.
