bfDeveloper

Два месяца назад исследовал этот вопрос. Задача стояла так: найти кроссплатформенный игровой движок, желательно, но не принципиально С++, для написания любых игр под Android, IOS, и по возможности остальные системы типа blackberry.
Сначала хотелосб Unity3D. Для 2d текущая версия unity мне показалась совершенно неприспособленной. Вроде обещали в ближайшей версии допилить. Но стоит учитывать, что некоторые необходимые для мобильника фичи типа texture batching весьма странно реализованы и только в pro версии. Смотрел CoronaSDK, показалась неплохой штукой, но писать всё на Lua лично мне не хочется. Это индивидуальные тараканы, вам может подойдёт. Ещё неплох Cocos2d-x. Это C++ порт Cocos2d, который тоже неплох, много чего умеет. Сейчас мне кажется лучшим вариантом среди готовых фреймвёрков. Все эти движки пугали как чёрный ящик, ограничивающий возможности списком своих фич. Особенно это касается unity3D, залезть в Cocos2d не проблема.
Остановился в конце концов на неиспользовании готового. Взял C++, SDL2, пошаманил с Open GL и получил самописное чудо. Основное достоинство — полное понимание внутренностей, нет вопросов, как что-то сделать, никаких проблем с производительностью. Очень круто то, что этот же код работает на десктопе и можно тестить любые разрешения, просто меняя размер окна. Ну и запускается без деплоя на устройство, что ускоряет разработку. За чуть более чем месяц появился сам движок и почти есть игра на нём. Недостатки подхода очевидны — за каждой фичей типа сети, json, xml, шрифтов, форматов картинок и физики надо искать и осваивать отдельную либу. Так же надёжность не проверена. Ну и свой велосипед никак не упрощает вхождение новых людей в команду. На данный момент игра не завершена, но пока не жалею, что выбран такой путь. Подумайте, возможно тоже захотите своё велосипед.

У вас описано одно из лучших решений: M классов по N методов. Дублирования легко избежать, реализовав всё по 1 разу, а в остальных методах просто вызывать уже реализованные. Ваша задача для ООП стиля гуглится по фразе «множественный полиморфизм». Кажется, у Меерса предлагалось решение в виде map<key, function>, в которую просто записываются указатели на функции так, как вам уже предлагали выше.

Есть ещё одно интересное соображение по трёхмерному решению, навеянное методом Хука-Дживса.
Пусть мы нашли одну точку нашего графика (например, рассмотрев сечение x = const и применив в нём метод Пиявского). Назовём эту точку опорной. Если предположить, что мы ищем одну непрерывную кривую, то можно утверждать, что рядом с найденной точкой есть другие, принадлежащие этой кривой. Возьмём некоторый шаг h и посчитаем значение функции F(x, y) в нескольких точках на расстоянии h от первой. Выберем точку со значением максимально близким к 0 за следующую опорную и повторим действия. Таким образом мы как бы пройдёмся по дну оврага (если брать модуль F) или просто по склону, сохраняя высоту.
Если хорошо подумать над тем как искать следующую точку, то можно сообразить как от начальной точки пройти сразу по двум направлениям (она же не обязательно будет на границе, и описанный выше метод найдёт кривую только по одну сторону от точки).
Получив массив точек, мы можем применить метод градиентного спуска для каждой из них для получения более точного результата. Так как точки уже близки к кривой, практически исключается возможность скатывания в локальные минимумы.
Вообще в методах глобальной оптимизации принято сначала локализовывать точки минимума, а потом запускать методы локальной оптимизации в найденных областях. Здесь это тоже неплохо работает.