Header в header'е и можно ли делать игру на одних Header'ах?

Игру можно делать на одних библиотеках. Написать кучу библиотек, в каждой свое.
И потом вызывать все функции из подключенных библиотек.

Игру можно сделать в одном основном файле. Ничего в него не включать, написать спагеттикодом.

Писать программы вообще можно тремя символами, просто

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++.+++++++++++++++++++++++++++++.+++++++..+++.-------------------------------------------------------------------------------.+++++++++++++++++++++++++++++++++++++++++++++++++++++++.++++++++++++++++++++++++.+++.------.--------.-------------------------------------------------------------------.-----------------------.

Что я только что прочитал? Вы кажется не понимаете, зачем нужны хедеры, там должно быть определения всего что вы используете, а реализация в *.cpp. Распространённая практика - для классов использовать .h с определением и .cpp файл с реализацией, имя файлов совпадает с именем класса, в .h нужно использовать #pragma once или костыль include guard. Напрмер:
Color.h:

#pragma once

// или так
// #ifndef COLOR_H
// #define COLOR_H

class Color {
public:
  Color(unsigned char red, unsigned char green, unsigned char blue);
private:
  unsigned char red, green, blue
};

// #endif

Color.cpp:

#include "Color.h"

Color::Color(unsigned char red, unsigned char green, unsigned char blue)
  : red(red), green(green), blue(blue)
{
}

Из правила есть одно исключение - шаблоны, обычно их пихают в хедер с расширением .hpp, чтоб было видно, что это шаблоны, cpp для шаблонов сделать не получится.
Можно конечно весь код писать в хедерах, но тогда при малейшем изменении перекомпиливается весь проект.

Такой механизм называется «одна единица компиляции» и вполне имеет право на жизнь: на одном процессоре время полной сборки будет наименьшим, потому так распространяют некоторые библиотеки (SqLite, Google Test). Правда,
игра — обычно масштабный проект, и чем больше будет кода, тем дольше нужно компилировать, чтобы проверить изменения.

Потому код обычно разбрасывают по единицам компиляции (*.cpp) в соответствии с его внутренней логикой, и к каждой единице (кроме точки входа) приписывают хедер (*.h), который показывает, что эта единица делает. Повторяю, только описывает, что делает — весь код в CPP. И в большинстве случаев самый длинный этап сборки — линковка (особенно с оптимизацией по ходу линковки aka LTO).

Единственное, что в 80% случаев не получается закинуть в CPP — это шаблоны.

Чтобы один хедер не подключался несколько раз — есть include guard. Правда, если вы не продумали зависимость между хедерами, может попасться циклическое включение — это вредно, но лишь потому, что программа может не скомпилироваться.

Чтобы не было циклических включений, для сохранения скорее всего потребуются два хедера: один отвечает за собственно процедуру сохранения и подключается к одному-единственному модулю — системе меню. Второй — за какие-то общие функции, которые позволяют сохраняться в абстрактный поток плиточному фону, снаряду, монстру… Называется как-нибудь SaveUtils.h и подключается повсюду.

(Примечание. И SqLite, и Google Test разрабатывались по традиционной схеме, с проектом из кучи CPP. SqLite собирается в один большой *.c автоматикой, и я даже качал традиционный код — на 5-метровом файле некоторые версии Embarcadero вылетали с нехваткой памяти. В Google Test есть файл all.cpp или что-то подобное, в котором #include остальных CPP — пользователь подключает в проект all.cpp, и библиотека отнимает минимум его времени.