mage

Загляни сюда.

А не задумывались над luabind?
Да, разбираться и компилировать немного нетривиально, но это того стоит. Потом пробрасывать классы и объекты в lua - сплошное удовольствие. Вот пример кода:
https://github.com/NeonMercury/time-killer/blob/ma...

Литературу я вряд ли посоветую, но опытом поделиться могу. Процесс создания игры следующий:
сначала создаётся документ с общим описанием игры, затем, в процессе бурного обсуждения документ обрастае деталями, подробностями, фичами и прочим. Получившийся документ называется ГДД (гейм дизайн документ). В нём должны подробно быть описаны все игровые режимы, Окна, возможности, переходы, состояния. Для создания какого-либо окна в удобном вам графическом редакторе создаётся фейк (просто картинка с желаемым результатом), затем художник разбирает фек на детали, дорабатывает их и передаёт геймдизайнеру, геймдиз в имеющейся тулзе создаёт гуи (если нужно) и отдаёт всё программисту, который складывает ресурсы в игру, прописывает в коде загрузку необходимых проектов, колбэки на кнопки и подобное.
Я сам сейчас занимаюсь созданием игры с кокосом, только я использую cocos2dx (кросс-платформенный вариант на C++).
Про гуи, левелам и анимациям. Для кокоса есть тулзы, я, например, использую CocoStudio. У неё есть модули для создание гуи, скелетной анимации и сцен. При этом тулза экспортирует проект как сцену в json формате + один или несколько атласов (которые сама собирает) и плисты к ним с описанием спрайтов. Всё что нужно для таких базовых вещей. А ещё можно в анимации вставлять частицы. Только вот немного глючит эта студия.
Что же касаетс создания конкретного левела в игре, то тут нужно продумать игровую механику и отталкиваться от неё. Если левел не удаётся создать используя существующие тулзы (а скорее всего так оно и будет), то следует описать логику геймплея: выделить основные объекты, описать взаимодействие их, определить какие из них и что конкретно должно меняться от левела к левелу и вынести загрузку их во внешний файл (можно использовать обычные плисты, которые легко парсятся в словари, а можно использовать скрипты, кокос2дх поддерживает луа, только я пока им не занимался). Это позволит разделить труд (один человек может делать скрипт для конкретного левела, другой - доделывать логику), легко изменять параметры и баллансировать левелы без пересборки билда и вообще - это общепринятая практика.

template< class RandomAccessIterator >
void sort( RandomAccessIterator first, RandomAccessIterator last )
{
    sort( first, last, std::less< std::iterator_traits<RandomAccessIterator>::value_type >() );
}

эм. вы что делаете SELECT rating FROM users WHERE userid = :id, потом делаете rating++, потом делаете UPDATE users SET rating=:rating WHERE userid=:id? Во-первых, вы можете просто делать UPDATE users SET rating=rating+1 WHERE userid=:userid. Во-вторых, можете выстроить очередь. При изменении рейтинга в очередь ложить действие (+ или -), :userid, потом обработчик очереди сам сделает + или — над рейтингом очереди, но тогда пользователь не увидит мгновенного изменения рейтинга. В-третьих можно рейтинги пользователей держать в кэше, делать +- в кэше, показывать из кэша, а кэш синхронизировать с базой несколько раз в день или по какому-нибудь событию.

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

Все у вас получится! Успехов ;)

>>корень репозитория должен быть корнем сайта и после коммита должен быть сразу доступен в браузере

Пожалуй, включу режим зануды и внесу некоторую ясность. Репозиторий — это не просто набор файлов и папок. Репозиторий subversion использует организованную особым образом файловую систему. Обычно файлы хранятся в БД, либо являются файлами определенного формата, так что корень репозитория не может быть корнем сайта.

Что касается использования файлов проекта по прямому назначению, нужно, во-первых, экспортировать рабочую копию(svn checkout). Это уже обычное дерево папок и файлов со скрытой поддиректорией .svn в каждом каталоге дерева. Такая локальная копия имеется у каждого участника проекта, который коммитит в центральный репозиторий. Но и эту копию нельзя использовать на продакшене, так как она содержит эти самые служебные поддиректории .svn. Для того чтобы от них избавиться, экспортируется чистая рабочая копия командой svn export. Вот теперь это ваш проект.

Сейчас как раз разрабатываю веб-проект с помощью svn, могу поделиться как у меня все устроено.
Есть VDS-ка, где крутится сервер svn. Есть две ветки репозитория — trunk и release. На локальном компе рабочая копия, по мере разработки коммичу все в trunk. Все скрипты тестирую на локалхосте. Девелоперская база данных общая, расположена на том же серваке что и svn.

Самый быстрый исполняемый код — это тот, который написан вменяемым программистом. Если у вас код выполняктся за O(nⁿ), хотя есть алгоритм, делающий тоже самое за O(n), вам никакой компилятор не поможет.

А так неплохие результаты выдают компилер студии и GCC. Ну и Intel C++, хотя его надо твикать, чтобы получившийся бинарник не тупил на AMDшных процах.

Как-то вот так.

По поводу оптимизаций — компилятор знает про выравнивания, конвеер и ещё кучу разных вещей, которые даже за счёт в нужном месте воткнутого NOP ускорят код в несколько раз.