AVR Freaks

Presumably if you simply set a breakpoint after the call to uartSendArray() then equally it completes OK even with that following code present?

As it's a synchronous routine I cannot see any way in which the code that follows it could possibly affect its operation.

BTW I cannot help noticing that tiny104 is a 1K micro. This couldn't be that the code image has simply grown too big could it and that removing that following code brings it back into size range?

As Jim says, the flash "consumption" is not equal to the size of the hex file. Hex files are encoded, are record-oriented with record type tags, record lengths, destination addresses and checksums taking up space in the file that will never actually end up in the flash memory. The actual flash contents are binhex-encoded so that one byte of actual flash memory contents takes up two bytes in the hex file. So hex file is more than double the size of the actual flash consumption. How much more depends largely on how "fragmented" the hex file is - i.e. how small the records are. The extreme degeneration (never seen this in real life) would be one hex record for each byte of flash. This case would have 12 bytes in the hex file for each byte of actual flash contents, i.e. 12 times the size. For more on the hex file format, look no further than to the Wikipedia article on the subject.

All that aside, for the flash consumption the memory report at the end of the build is the final word - and you have:

Program Memory Usage : 492 bytes   48.0 % Full

No problems there.

As has been noted above, you are not so good when it comes to RAM consumption. I have not checked the details here (not on Windows with Studio available for a simulation) but your peak RAM consumption could well be more than 32 bytes. You have not shown a complete program, so we do not know the details of how DFPlayerSendCommand() is called but lets assume it is called directly from main.
Sketchy, guesstimative, breakdown:

Statically allocated:                       2 bytes (From the build memory report)

Startup code calls main():                  2 bytes (return address pushed on stack)

main() calls FPlayerSendCommand()
  i)  Used registers must be saved by
      pushing them onto the stack           ? bytes
  ii) Call                                  2 bytes (return address pushed onto the stack)
  
Local array in FPlayerSendCommand()        10 bytes (uint8_t tempCommand[10])

Local array in FPlayerSendCommand()        10 bytes (uint8_t tempMessage[10])

FPlayerSendCommand() calls UARTSendArray()
  i)  Used registers must be saved by
      pushing them onto the stack           ? bytes
  ii) Call                                  2 bytes (return address pushed onto the stack)

UARTSendArray() calls UARTSendByte()
  i)  Used registers must be saved by
      pushing them onto the stack           ?
  ii) Call                                  2 bytes (return address pushed onto the stack)

  GUESSTIMATE TOTAL                        30 bytes plus the '?' unknowns for register preservation

I might very well have missed out on something so it might be worse than the above sketch.

You are overflowing your RAM.

With 32 bytes of RAM, at least the below techniques must be considered:

• You must be as absolutely conservative with RAM usage (i.e. variables) as at all possible.
• In general consider using global variable rather than passing parameters to functions. This will reduce RAM footprint in many situations, but not in all.
• Re-use/re-purpose global variables. (Example: You are allocating two arrays of 10 uint8_t's. Since they are not used at the same time, replace them with one such array, used for both things. Whether to allocate it as a local variable or as a global "depends on things".)

You have chosen a microcontroller that is extremely challenged with respect to available RAM. These things are normally intended for very simple applications, e.g. basic regulator stuff trying to keep a parameter (think temperature) within bounds of an upper and a lower limit. Or a simple parameter reader-and-sender (reads temperature, sends on UART). That kind of stuff..

Doing a game control with string handling and messaging and checksumming using a tiny104 could well be a case of "wrong AVR model chosen". It at least requires very good knowledge of what the compiler does: how it generates code, how it allocates space for variables etc. Very good knowledge. This is what will help you with decisions like "allocate this thing as a local or a global?".

There are AVRs that have e.g. 256 bytes of RAM. Consider moving to such a model.

That is still a very, very small amount of RAM!!

Why are you deliberately making things difficult for yourself.

Surely, it would be far easier to start with a chip with plenty of RAM to get your system working in the first place, and then think about optimising it once it is actually working.

Concentrate first on getting your system working - not on fancy tricks to minimise RAM usage!

As the old saying goes, "premature optimisation is a root of all kinds of evils!"

To be honest you shouldn't be hitting this RAM limit now. If you follow a sensible design strategy then during the specification stage you will have done peripheral/pin, time and memory budgets and during the latter you will have a pretty strong idea of both total flash and RAM usage. Then you make the final chip choice. Then you write the detailed specification. Finally you start to design prototype electronics and start code implementation. This way you shouldn't get any nasty surprises at the point of implementation. 

is there any kind of checker that makes sure I won't overflow at runtime?

Yes:

https://github.com/ezharkov/ezstack

... although it has limitations.

like having no documentation - and not even any comments in the source code ?

Among others.  It was written from our very own @ezharkov, who has made it available without much support.  Bummer, but it has been a useful to me and others.

If I may, I would like to get back to the original post

Hey, whatever, man.  You asked the question.

and is there any kind of checker that makes sure I won't overflow at runtime?

Well, the original question was, 

That question has been answered some time ago - we are now well into follow-on questions!

Maybe time for a new thread ... ?