This warrants another post.
You also do not want to hard-code functions that perform actions per se. Your script system should be closely connected to the engine so that it can manipulate objects at will - again based on IDs.
Your system should be message based. Instead of the system always querying for information you need to get to the point that the systems can communicate back and forth. If an object needs attention then the object should be sent a message through the message system.
This changes the whole paradigm of games programming because once you get this working you can now create demos and testbeds for the game by simply writing a script. Instead of this:
You have this:
So now when you do the multiplayer, you just look at the incoming message and send it to the system and it will do what you want. For scripts you simply interpret the script and then relay the correct message and the action is performed.
It's a lot like Win32 programming and the systems for it. Hopefully not as messy or slow, but you get my drift.
Notice the sheer genius of the MSG structure in Windows. This one structure is applicable to all windows objects and every object relies on it. This is what you need for your game. That way you can use one function to send messages and based on the message, the parameters will have diff meanings.
In Windows to repaint a window you can either call your Paint function or you can send a message to a window provided you have its handle. But Windows does not specifically call the Paint function for that object. It sends a message and the object(s)responds to it. This allows any implementation of the WM_PAINT message and allows any function name to be used. Much the same for bashyourheadoff(). If you hard-code it, you will code yourself into a corner.
What does Windows do? It calls your WndProc() and the MSG is a parameter. You then act on the message and the Windows SDK tells you what that message is pertaining to and so you code your implementation of it.
Get a message system up and running soon after your resource system. And when you design your resource system and all systems keep in mind the underlying message-based structure. There is more to talk about concerning documents and views, the document being the game data, and the view being the render. If you implement this right, switching cameras is a simple matter of switching views.