This was the approach I tried in the very first version of Ren'Py, and one that I abandoned quite early. It basically makes it impossible to save and load the game, as most programming languages provide no facility for jumping back into the middle of a function. One can work around this by providing designated save points, but that's less than ideal.
Instead, you want to represent the game script as data, which is used to control some form of virtual machine. (Using the term quite liberally... bytecode seems to me to be massive overkill for this purpose.) By turning the control flow of the game into data that is manipulated by the engine, we can save the current control position, along with the game state, and fairly easily implement loading and saving.
As to language choice, I would choose a high-level language like Java or a VHLL like Python over a low-level language like C. Many of the higher-level languages have C-based libraries that handle the expensive graphics operations, and the remaining control stuff really isn't that important speed-wise.
(Indeed, it's generally worth spending some time being clever and trying to minimize the number of pixels that are blit to the screen. In my tests of Ren'Py, that's where most of the time is spent.)
Finally, one thing I've come to realize is how much harder coming up with a good script is, as compared to writing the game engine.
