Hello, A friend and I have been researching & developing MMO server technology for around 4 years now. We started with an Asheron's Call emulator (ACE if any of you remember it), and then decided to work on technology for our own game. Since then we've written, scratched, and rewritten countless server architectures, always looking at how to make things better. We've finally decided on a server architecture (more-or-less, I'm sure it'll still change in the future). It's based loosely on Scott Bilas's Fubi concept: http://www.drizzle.com/~scottb/gdc/. However, we've changed and extended his concept quite a bit to support the following features: - Minimal context switching and near elimination (and possible complete elimination in the future) of lock contentions. This should allow impressive performance as context switching and lock contention are - IPCs as well as RPCs. - Scripting (and IPCs and RPCs for all scripted code). Althought it's not totally complete, everything is coming together quite nicely. The framework is basically done. We just need to add network code for RPC functionality and some fiber code for IPC functionality. The groundwork is laid out for tight integration of a scripting language. However, neither one of us are experienced in designing and implementing a custom scripting language. This is where you come in. We're looking for someone who is very talented in this area to help us out. If you've wanted to work on a MMO project but have been turned off by unexperienced teams with unrealistic expectations, this is your chance to join a team that fits your abilities. Either reply here or send me an email at mykillk@gmail.com Michael Koehmstedt

Oops I didn't finish a sentence =]. I meant to say lock contention and context switching are two of the biggest factors in degrading server performance.

I would recomend using an existing scripting solution rather than rolling your own. There are good scripting solutions for just about every problem already made, and they are certainly more stable than a new, proprietary language. Also, if you use an existing solution you can leverge people who are already familiar with it rather than hoping to find someone interested enough to learn an entirely new language.

On a bit of a side note:

My personal belief is that scripting is for gameplay elements such as object interactions, plot development and things of this nature. When it comes to implementing new gameplay systems such things are better left to code. DLLs will provide the ability add/alter core systems. This is how HL & HL2 mods are done.

To put it briefly: Script content, not code.

I'd agree with Ravyne on both the points made. An existing language is tried and true - tested, modified, etc etc. A language like Lua that is extendable and easily embedded in your program might be the way to go. Of course, it really depends on your needs. But you can't beat years of testing and countless shipped products that have used it very well.

Also, I agree that content should be outside the source code as Ravyne said as well. Since you'll want every ounce of horsepower you have to make your system fast, as much as possible should be in code. Even though bytecode in Lua is very fast, it won't be as fast as running things through your compiled code.

Now there are some compile on the fly scripting solutions (I think with .NET), but I have no experience with that. Might be something you're after though. Dunno.

-Catch

Ditto. Why waste time implementing your own, when there are usable, tried and tested solutions out there?

Well, I took everybody's advice and decided to use Simkin as my scripting language.

http://www.simkin.co.uk/

I find it's integration inside of XML documents very interesting indeed.