Well, I mean, I have a fairly concrete vision for what this thing is, so in that sense it's sort of a one man show. Perhaps volunteering will be more fruitful once the groundwork has been laid? A lot of effort is going to end up having to go into defining and implementing scripting commands, which is maybe a better floor to get in at than the ground floor.

Re: Hungarian, I think you have it backwards -- it's very important when you have different concepts that are represented similarly (see Joel). Though in practice it's actually very useful to use everywhere, as it forces you to be very precise about what you're talking about -- surprisingly, initial crypticness is hugely preferable to vagueness. But this is probably a discussion for email, if you're actually interested.

Re: Coroutines, okay, so imagine a section of script for an adventure game. It might look sort of like this:

as(Guybrush)
{
  say("I'm Guybrush Threepwood, mighty pirate!")
  walk([200, 124])
  anim(animChokehold)
  WussPirate.anim(animBeingChoked)
  waitfor(evAnimFinished)
  say("So don't you fuckin' fuck with me, motherfucker!")
}

You can't write code this way in C# or Java, because this is merely one simple thread of logic that has to go on. While Guybrush is walking, other animations can be playing, the player might hit F5 to bring up a save-game dialogue, he might hit ESC to skip this cutscene, you've got to draw the screen 60 times per second, maybe you're ticking down a timer to interrupt this scene with another cutscene, whatever. The game world should still be alive while Guybrush is walking, and other scripts should be running. If "walk" is a function call that only returns when Guybrush is done walking, in a non-multithreaded environment, we're fucked. However, A) shared-state threading is something that is incredibly dangerous and that you absolutely do not want to make designers suffer through, and B) you can't start threads for every little object running scripts in your game; there could be hundreds or thousands doing piddly little jobs, and the overhead would be enormous.

What many games do is punt; they say, "here's a function that gets called sixty times per second; keep track of your intermediate state yourself." So you have to build a state machine where, after you finish walking, you set some bit, and then the next part executes. It's hard to understand and harder to change without breaking. For adventure games this is particularly ridiculous, but I believe it's a tremendous waste of effort in a lot of other situations, too.

So instead you say, I know exactly when I want to wait for something to happen; that is the point at which I want to stop running this script and start running the next script. When that thing happens, we can wake this script back up at our leisure and let it do its next chunk of work. This way, you keep context switches down to an absolute minimum, you can run umpteen million scripts, all written in a natural style.

Doesn't that sound nice? I think it sounds pretty nice. Thus far, using these ideas in practice (with Hax0r and Alien Zit 2000 being sort of trial runs at the engine, using Stackless Python instead of rolling my own interpreter as I'm doing now), it's been pretty nice. So, that's where that angle's coming from; it's a fundamental part of my scripting model.

...

SHH IT'S A SECRET DON'T TALK SO MUCH ABOUT IT GOSH