"But there are no side effect free ways of changing the pixels on a screen or the sounds coming out of a speaker as those are precisely side effects."
No, those are precisely effects. They can only be side effects once you've defined how you're distinguishing side effects from effects generally.
A common way is labeling intended results "effects" and unintended results "side effects". By this definition, they're clearly effects not side effects, though this equally clearly isn't the usage in question.
Another way - common in Haskell - is to label effects that do not appear in a function's type signature "side effects". By this definition, it clearly depends on the implementation and there are "side effect free ways of changing pixels on the screen".
I don't think there is another useful definition to be had.
Without getting into a hugely semantic debate, I was using side effect imprecisely to mean the opposite of a pure function.
Many FP paradigms (including Haskell's) impose an overhead when doing operations that are not pure. In the case of a SMB clone a huge percentage of the work of the program may end up not being pure, therefore a large overhead may be imposed. Further, many of the advantages of FP paradigms (including Haskell's) are dependent on pure functions.
In the case of a SMB clone, a large percentage of the application may be intended to be impure, therefore the "worst case scenario" comment.
"Without getting into a hugely semantic debate, I was using side effect imprecisely to mean the opposite of a pure function."
That's the second sense I described. It's only meaningful if you're actually talking about a particular function. And you're still left with the question of the actual domain of the function. Semantics, but relevant semantics.
"Many FP paradigms (including Haskell's) impose an overhead when doing operations that are not pure. In the case of a SMB clone a huge percentage of the work of the program may end up not being pure, therefore a large overhead may be imposed. Further, many of the advantages of FP paradigms (including Haskell's) are dependent on pure functions."
That's somewhat true of FRP, basically false about Haskell IO generally, but either way if you can do it in PyGame someone can do it in Haskell - it's mostly a matter of working in a high level language, not a matter of functional-programming-imposed overhead.
I would recommend listening to what John Carmack had to say about implementing games in Haskell (and also Lisp, IIRC).
In FRP, you basically define your UI as a function to display pixels. Physics is a bit weirder, but that is handled by event streams over ticks and "stepping." Actually, the effect system doesn't really come into play, because you can define everything effect free.
I'm not a big FRP proponent though. In my own work [1], I believe that manipulating pixels and doing physics should be effects...even side effects that are at least explicit during run-time. Of course, to achieve this, I needed to do special things to achieve commutativity and idempotence, which is otherwise taken for granted in a pure functional program.
No, those are precisely effects. They can only be side effects once you've defined how you're distinguishing side effects from effects generally.
A common way is labeling intended results "effects" and unintended results "side effects". By this definition, they're clearly effects not side effects, though this equally clearly isn't the usage in question.
Another way - common in Haskell - is to label effects that do not appear in a function's type signature "side effects". By this definition, it clearly depends on the implementation and there are "side effect free ways of changing pixels on the screen".
I don't think there is another useful definition to be had.