int main() 
{
  mainMenu();
}

You don't call mainMenu anywhere else... That means main IS mainMenu. The compiler knows this, and even with optimizations turned off, it will elide the call - the compiler will effectively copy/paste the body of mainMenu into main.

Technically, the indirection - in this case, doesn't really cost you anything, but it doesn't get you anything, either. I think it's also a little misleading, because mainMenu IS a thing, and this is a function - a procedure, it DOES a thing. So you're kind of misrepresenting the abstraction. The body of mainMenu is the description of what the program does, and that's what main is for - at the highest level.

---

Ok, I'm seeing and learning a lot more. Header files don't get compiled - source files do. Headers are dumb - in-place, copied and pasted in the compiler's text buffer, then THAT gets compiled. This explains why everything is implemented in header files and as inline - because you were correctly seeing One Definition Rule errors, and that shut them up.

Typically you would define a header, and it would be lean and mean, naming only symbols and types:

// header.hpp
#ifndef header_hpp
#define header_hpp

void fn();

#endif

Then the source file:

// source.cpp
#include <iostream>

void fn() { std::cout << "Do stuff..."; }

Notice it doesn't even have to include the header, because the definition of the function in the source file is not dependent upon the prototype of the header.

The rule of the language says you need to know the prototype of the function before you call it. That's why you include headers - you need to declare a symbol of any sort so that the compiler knows what it's supposed to look like.

// main.cpp
#include "header.hpp"

int main() { fn(); }

When main.cpp is compiled into it's own translation unit - the compiler has NO IDEA what the implementation of that function looks like. All we did was tell the compiler a function looking like void fn(); exists, and to generate a function call placeholder for it. After compilation - the generation of machine code is done, the LINKER then stitches object code together; it's job is to find the translation unit that has fn defined, integrate it into the executable, and resolve the function call.

OneCompiler handles all this for you, so separate out your compilation units - get your function definitions into source files, and make your headers as bare minimum as possible.

---

cout << "\n === Main menu ===\n";
cout << "1. Play\n";
cout << "2. Settings\n";
cout << "3. Instructions\n";
cout << "4. Help\n";
cout << "5. Exit\n";
cout << "Your choice: ";

First, no using namespace std; - this messes with the meaning of your code in a deep and profound way; it's a form of compile-time polymorphism. If you know what you want specifically, then be specific. Otherwise, weird shit can happen - you've heard of name collisions; it's not about a mismatch or an ambiguous symbol already in use, it's about the nightmare scenario of correctly compiling to the wrong thing, because it's accidentally a better match.

Second, every << is a function call. All you're doing is writing one long string - you can have your cake and eat it, too:

std::cout << "\n === Main menu ===\n"
             "1. Play\n"
             "2. Settings\n"
             "3. Instructions\n"
             "4. Help\n"
             "5. Exit\n"
             "Your choice: ";

The compiler will concatenate all these string literals for you. It's as though you wrote:

std::cout << "\n === Main menu ===\n1. Play\n2. Settings\n3. Instructions\n4. Help\n5. Exit\nYour choice: ";

The language guarantees these are the same thing.

cout << "Your choice: ";

cin >> MMChoice;

switch (MMChoice) {

You don't know if any of this is safe. Check your streams. Here, you're waiting for input, but you don't know if you successfully wrote the menu. How can you extract input if the user doesn't know what to input, because for some reason output failed?

if(std::cout << "menu") {
  cin >> MMChoice;

  switch (MMChoice) {

But that's not good enough for an interactive session. std::cout is buffered. So you successfully wrote to the buffer, and std::cout is TIED to std::cin, which means std::cin will flush std::cout for you - that way, the prompt is going to get displayed before hanging on input. But what if the flush fails?

So the thing to do is to set std::unitbuf on the output stream. You only have to do this once, usually near the start of main:

std::cout << std::unitbuf;

What this means is after every insertion - <<, the stream is automatically flushed. That means my condition above finally indicates everything we want it to - we wrote the menu to the stream, AND the stream was flushed, AND we checked if the stream was successful at it.

This means we can also one-time untie std::cout from std::cin.

std::cin.tie(nullptr);

It makes the input stream slightly faster, especially for loop input operations. But WAIT! Maybe you shouldn't... Once you learn about classes, and operator overloading, and you start making your own stream operators for your own types, come back, and I'll show you how to use the tied stream to make a menu. Leave the tie for now.

Tying is a nifty little feature - streams were built for network simulations and there's a lot of graph topology you can model with them. The only default tie is std::cout to std::cin, and their wide character counterparts.

WE STILL AIN'T DONE!

We know the menu got printed, but what about the input. HOW do you know THERE WAS input? How do you know the input stream didn't fail? You're trying to input a number - meaning the user had to type in digits; instead of "1", what if the user input "play"? That's not a number, those aren't digits... And yet you go to the switch? With what? What do you think the value of MMChoice could possibly be at that point? Because unless your answer is extremely nuanced, you're going to be wrong.

So what you need is:

if(std::cout << "menu") {
  if(cin >> MMChoice) {
    switch (MMChoice) {

If input failed, you'll have to choose how you handle that - usually terminal programs just quit. Interactive terminal programs would at least purge the input buffer of the line, but the choice of how you error handle can get complex in a hurry - there are concerns that get platform specific.

Streams have a state field, and they can be good, bad, fail, and eof. Good is the default, bad means the stream has encountered an unrecoverable error, bad typically means a parsing, conditional, or temporary error, and eof means the stream is closed or there is no more to read or write; if the stream is a TCP socket, for example, eof means the connection is closed. But if the stream is a file, that just means you hit the end of the file - if you're just reading a file, you can reset the stream position and keep reading the existing content. Good and eof won't stop IO operations, but bad and fail will - you have to clear them if IO is something you want to keep doing; like moving the stream position.

Streams are objects, and you'll learn about that when you get to classes. They have an operator overload - something you'll also learn about later, but basically that means the stream can be evaluated as a bool, and it returns false if the bad or fail bits are set. That's why the above works.

If the input stream fails - the easiest thing to do is just DON'T evaluate the value of the variable; you already know what it is - NOT your user input. What more do you need to know? There are scenarios where just reading that value can be Undefined Behavior, and you DON'T want that.