@17
You don't want to embed Python. That's a very special sort of hell where you reimplement all of py2exe or whatever else, assuming that you want it distributed on client machines. If it's just going to run on a server that's probably fine though. be careful of the threading concerns, if threads matter to you, and be aware that it's not possible to sandbox it for all the same reasons you can't sandbox normal Python.
Lua is actually a very featurefull language, with exactly two things I don't like about it: undefined variables return nil instead of an error, and arrays are 1-based. It's got everything else up to and including the Python-style operator overloading. The only downside is that the standard library is tiny, but there's enough modules out there that you can just plug a bunch of things in no problem if you need them, and Luajit is about as fast as C.
I don't understand why you need cryptic file names, if you can just tell the engine what file the script is in. If you can't and you really need that, you can just open the user's normal editor to the file. Or, instead, offer an interface where you do like:
attach_evt_handler(object, "on_collide", collision_function)
My weird tentative plan for my MMO thing is to do level building in Python, having it spit out a bunch of json, and then having users do scripts with multiline strings.
I wouldn't worry about cryptic file names. You're never going to get a nice level editor. Nice level editors are the kind of thing where you need an entire person on it full time. You want the minimum that works. There's a reason that a lot of games around here use weird text-based command languages. In the case of scripting you're going to find that it's much more important of a question "what can be scripted", not "how do I install the scripts". Scripting in general, game or otherwise, will eat the entire codebase if you let it.
But in general "nice level editor" isn't the problem in front of you to circle back to my main point. The problem in front of you is "a level exists and I can play it". Don't plan your game around what you want the Ui for builders to be. Players are who matter first. In business speak we call this being customer focused, and it's kind of annoying in your job interview when you have to come up with stories in which you put the customer first, but I've found that for small personal projects it's the only way, even if you consider yourself the customer. Obviously your backend tooling and things need to be good enough to let you make gameplay and levels happen, but you can always build a nicer UI later. So why handle it now? A nice UI but no working game is just a fancy way to fail, kind of. I mean yeah you could push it through, but you'll probably find out that because you did it that way around you can't support a bunch of capabilities you didn't know you wanted when you started and things like that. it backs you into a corner but, in programming, backed into a corner is kind of synonymous with throw it out and start over.
My BlogTwitter: @ajhicks1992