27 Mar, 2009, Kline wrote in the 1st comment:
Votes: 0
I know a few folks here have successfully embedded Lua or another scripting language in their game; care to share any pointers? I've read the stuff on Gammon's site about Lua, but I'm not entirely sure that's the best way to do things? I'm just looking for a replacement to mobprogs, and not really biased to any flavor of language as I know very little of any of them :).

So…Any reason to use one over another, past personal preferences? Is one easier to implement, tips/guides on how to not go "horribly wrong" with doing so?
27 Mar, 2009, elanthis wrote in the 2nd comment:
Votes: 0
Lua is the easiest to implement and the most likely to suite your needs. Its coroutines support makes it very, very easy to develop mobprog-like functionality. There is an insane amount of information online about using Lua, especially for games as the gaming industry is a huge consumer of Lua. Lua is also very small and fast, which makes it easy to just distribute with your MUD code (no need to force people to install 50 dependencies to build the thing) and its speed is more than adequate for just about any need outside of heavy number crunching or truly massive data processing (beyond a MUD's needs, to say the least). it has an active and helpful community, a growing library of third-party addons, and a definite future with active development.

I have over the years embedded Python, Lua, Ruby, JavaScript, Scheme, and not one or two or three but four different home-grown scripting engines, and I can say without a doubt that using anything besides Lua is just a waste of time. Whatever advantages other languages may have, not a one of them surpasses Lua for use as an embedded scripting engine. That is the primary thing Lua was designed for, while all those other languages were designed to be stand-alone programming environments first and embedded languages second (or in the case of JavaScript runtimes, they were designed to be embedded into very specific applications and not game servers). Any of those other languages will work, but it is harder to do so and you lose out on many advantages of the Lua API.

For mobprobs, for example, you can start each prog as a coroutine for each mob. When any kind of "blocking event" occurs (such as telling the mob to perform some command, or just wait) you can have the coroutine yield (and unlike most other runtimes, you can do this easily from within a C function) and then resume it when the blocking event completes/triggers. Doing that in other languages requires either copious amounts of callback functions or requires doing a lot of low-level trickery. Lua just makes it freaking easy.
27 Mar, 2009, Scandum wrote in the 3rd comment:
Votes: 0
Any snippets or open source (preferably public domain) codebases out there to look at? If not maybe someone ought to release a Lua powered Socketmud.
27 Mar, 2009, Idealiad wrote in the 4th comment:
Votes: 0
Locketmud?
27 Mar, 2009, elanthis wrote in the 5th comment:
Votes: 0
It takes all of 15 seconds to find a number of MUD-related Lua articles on Google. Not that you really need them to be MUD-related – integrating Lua into a MUD is really no different at all than integrating it into any other game engine (and there are bazillions of articles online about that), which in turn is really no different than integrating it into any other application (hobajillion articles, easily).

That said, there are at least two MUDs written entirely in Lua (with a small bit of C server glue – Lua's upstream codebase is ANSI C only, so it doesn't ship with socket routines in its core library), and any number of others that use Lua. Aardwolf is one I believe you are fond of which uses Lua for its mobprobs.

Make no mistake, integrating Lua into a codebase is far from simple, and requires a great deal of technical know-how and time. It is definitely easier than integrating any of the other scripting engines out there, though, and Lua's design makes doing mobprog-style stuff much more straight-forward compared to the others which all require a lot of hacks due to the limitations of their C coroutine APIs.
27 Mar, 2009, JohnnyStarr wrote in the 6th comment:
Votes: 0
Wow, LUA looks pretty sweet!

I am building a custom code base in Ruby and have thought about what to use for scripting, being that Ruby is already a scripting language.

Do you think its worth the time and effort to use LUA?

Will i have to design some sort of custom interface?

Also, i'd like to add that isn't scripts for rooms and mobs and stuff kind of a bad way to go? What i would like to do is build a stable web front end to add all mobProg type features into the OLC so that non code savy builders can just log on to the website and start building. I may be wrong but (IMOO) taking the time to implement the site will probably save hours for the builders as well as avoid potential crashes because of porely written code.
27 Mar, 2009, David Haley wrote in the 7th comment:
Votes: 0
If you're already in Ruby, it's all but pointless to use Lua for the scripting. The main point of using scripting is to add easily dynamic, lightweight code to an otherwise somewhat static, heavyweight system (e.g. C++). If your main system is already dynamic, there's not much point tacking on another dynamic system. Now, there might be reasons to use Lua as the language for the whole system, but that's another question entirely…

staryavsky said:
Also, i'd like to add that isn't scripts for rooms and mobs and stuff kind of a bad way to go?

Well, personally I think that using scripts for rooms/mobs/etc. to add interactivity is the way to go. I'm not sure what the relevance to the web front end is though.

(BTW, Lua's not an acronym, so it's just "Lua", not LUA)
27 Mar, 2009, Grimble wrote in the 8th comment:
Votes: 0
elanthis said:
Lua just makes it freaking easy.

Second. You'll spend most of your time developing and exposing the API your scripts will will use to interact with the MUD engine. I suggest using SWIG to help you out with some of that. As a working example for illustrative purposes only (let's not debate any design), here's one of my scripts…


– character will mimic actions of others

function main()
local self = core.self()
local event = core.tCmd()

while true do
event:wait(true, 0)
– only mimic users to prevent a feedback loop with another mimic
if event.mActor:is_user() == true then
self:wait(3)
self:parse(event.mTxt)
end
end
end

"core" is essentially a namespace for the engine API and datatypes. The script is attached to a mobile and runs forever (while the mobile lives). It blocks on a command event from a player, waits a bit, and then executes the same command itself.
27 Mar, 2009, Lyanic wrote in the 9th comment:
Votes: 0
I've also been debating something similar to Kline for a sub-project I'm working on. However, I'd already narrowed my decision down to Ruby or Lua. The project in question would involve integrating one of those two languages into a C++ based system for quickly adding light-weight, but dynamic functionality. Does anyone have any specifics on a comparison between the two (elanthis, perhaps)? Specifically, what are the pros and cons between the two for the stages/aspects of initial integration, usage (the actual scripting/writability), readability, performance and maintenance?
27 Mar, 2009, David Haley wrote in the 10th comment:
Votes: 0
The question "which is more readable" is going to be very subjective, as is the question "which is easier to write with". There are objective questions, like "which has a larger standard library", for which Ruby wins, or, "which has the simpler structure", for which Lua wins. (Lua is a very "clean" language that implements a very small core set; Ruby does a lot more and so is less simple in that respect.) What is easier to maintain is more a question of in which one will your code be better, because once your language is sufficiently sane (i.e. allows function calls, data structures, etc.) maintainability is mostly a factor of your own code, not the language.

Lua is a clear performance winner, there is data for this all over the place.

Lua integration is extremely easy IMO, and FWIW it was designed for integration and extension. Ruby was not; it was designed to be a top-level interpreter. Now, I don't have personal experience embedding Ruby so I can't speak authoritatively to this point, however just glancing over the API docs makes me feel that Ruby embedding is more complex than Lua embedding.
27 Mar, 2009, Lyanic wrote in the 11th comment:
Votes: 0
David Haley said:
The question "which is more readable" is going to be very subjective, as is the question "which is easier to write with".

I realize they're subjective, but I'm only asking for opinions of people who have experience with Ruby and Lua in this context. I don't expect cold, hard facts for anything I inquired about.

David Haley said:
What is easier to maintain is more a question of in which one will your code be better, because once your language is sufficiently sane (i.e. allows function calls, data structures, etc.) maintainability is mostly a factor of your own code, not the language.

Sorry, perhaps I poorly phrased what I was trying to ask with respect to that. I'm not asking about the maintainability of the scripts written in the language after it's integrated. I was asking about maintainability more in relation to the integration - such as if there is extra work involved with modifying the interface at a later point to be able to use additional libraries, or with keeping up with changes in standards as new versions of the language are released.

Other than that, thanks for the input. So far, it seems Lua is winning out. I'd like to get opinions from a few more people, but the only downside I'm seeing is that I know far less about Lua than Ruby. That can be remedied by a few google searches, though.
27 Mar, 2009, David Haley wrote in the 12th comment:
Votes: 0
Well, if you're just after opinions, I find Lua to be more readable as it has fewer symbols, and I really dislike how important line endings are to Ruby. I like the simplicity of Lua's syntax; more simplicity means fewer surprises. I don't have a particularly strong opinion as to which is more "writeable", although Ruby has syntactic sugar for a lot of stuff that is convenient in some cases.

As for maintainability, I can't speak too much to that aspect as far as Ruby is concerned. In Lua, since the C API is so simple, it's very easy to add new stuff. The Lua authors are careful about making changes to the C API, so things tend to break infrequently, but obviously large version changes (e.g. 4 to 5) cause a lot of fuss. This is probably true for any language, not just Lua vs. Ruby.

I'm not sure what you're asking w.r.t. additional libraries. If they're Lua libraries, there's basically nothing to do as far as the C side is concerned. If they're C libraries that have no Lua binding, you have work to do to expose it to Lua. But both of these are also true of any language.
27 Mar, 2009, Davion wrote in the 13th comment:
Votes: 0
elanthis said:
I have over the years embedded Python, Lua, Ruby, JavaScript, Scheme, and not one or two or three but four different home-grown scripting engines, and I can say without a doubt that using anything besides Lua is just a waste of time.


Out of curiosity, did you use the Python C API to embed it or did you try out boost::python? I've done Spider Monkey some Lua but I found boot::python the easiest by far to expose the codebase to the scripting engine, YMMV though…
28 Mar, 2009, Tyche wrote in the 14th comment:
Votes: 0
If you are looking for an example of a ruby embedded server, see aetas.
30 Mar, 2009, elanthis wrote in the 15th comment:
Votes: 0
Ruby is a fantastic language, although Perl's influence on it is a little too string at times for me. Ruby was in fact the very first language I embedded in AweMUD years and years and years ago. It wasn't bad, but Lua was definitely far easier.

Davion said:
Out of curiosity, did you use the Python C API to embed it or did you try out boost::python?


No, I've not yet used boost::python. If we're going to talk about binding generators, though, Lua has some absolutely fantastic ones as well. And of course pretty much all languages have Swig support.
30 Mar, 2009, Vassi wrote in the 16th comment:
Votes: 0
I've been dying to play with LUA.

.NET has only had one attempt (that I've found) at integrating LUA and it has its fair share of leaks and problems that make it unsuitable for an application that needs to run over extended periods of time (a MUD).

As someone (elanthis?) said, Python (and others) work fine but they are meant to be more than just an embedded script language. It takes a lot of work to make Python 'safe' to expose to admins without giving a clever Python programmer the keys to not only the MUD, but the machine it's running on.

Edit: Looks like the LuaInterface binding has been updated this month, maybe I'll give it another try. It would probably still be nicer if it was implemented with the DLR, but I'll take what I can get.
30 Mar, 2009, David Haley wrote in the 17th comment:
Votes: 0
(It's 'Lua', not 'LUA'.)
Vassi said:
As someone (elanthis?) said, Python (and others) work fine but they are meant to be more than just an embedded script language

:sad:

Vassi said:
It takes a lot of work to make Python 'safe' to expose to admins without giving a clever Python programmer the keys to not only the MUD, but the machine it's running on.

You need to do similar work in Lua and sandbox the script environment appropriately. However you do have absolute and total control over what a script can see, and you can do so relatively easily.
30 Mar, 2009, elanthis wrote in the 18th comment:
Votes: 0
Vassi, if you're on .NET, you have a lot of options available to you besides Lua that are probably even easier to integrate. :) I wouldn't be surprised if there's an entire Lua-like reimplementation on .NET.
David Haley said:
You need to do similar work in Lua and sandbox the script environment appropriately. However you do have absolute and total control over what a script can see, and you can do so relatively easily.


Making Lua safe is VERY easy. Just don't import the IO or sys libraries, and Lua is automatically 100% locked down. There is no need for sandboxing and the like at all, unless you plan on exposing admin-only functions to Lua scripts. Even then, it's as easy as giving the "admin approved" scripts a different environment than the builder-supplied scripts, and only putting the admin functions into the admin environment.

So very easy, compared to other languages.
30 Mar, 2009, Vassi wrote in the 19th comment:
Votes: 0
elanthis said:
Vassi, if you're on .NET, you have a lot of options available to you besides Lua that are probably even easier to integrate. :) I wouldn't be surprised if there's an entire Lua-like reimplementation on .NET.


I would be surprised, and if your google-fu proves superior to mine I would love a link. =\

Right now the 'love' of dynamic languages is all about making new dynamic languages that harness the CLR, rather than embeddable languages that your code can harness for dynamic input.

Quote
You need to do similar work in Lua and sandbox the script environment appropriately. However you do have absolute and total control over what a script can see, and you can do so relatively easily.


Yeah, that doesn't compare to having to check official documentation to see what .NET security rights system methods use, and then making sure IronPython doesn't have those rights. Of course, to limit them at all (without limiting your host app) you have to isolate IPy in a separate app-domain and then you have to create separate objects that use .NET's MarshalByReference interface in order to push objects into Python's sandbox. It helps if these objects are on a different assembly (dll) so you can further limit the security of that assembly.

This still does not prevent people from calling any damn .NET assembly\system class they please, but it does prevent them from executing the 'naughty stuff' without generating an exception.

Edit: I am fully aware that C# and VB.NET have run-time compilation, people love to throw this one at me, but 1) it creates a memory overhead in script-like usage because you're essentially generating a DLL every time you re-compile a file. 2) You still have full access to the CLR classes unless you follow the above appdomain trickery. 3) You now need to teach your users the quirks and syntax of a 'real' language.
30 Mar, 2009, elanthis wrote in the 20th comment:
Votes: 0
Sounds like a fun project for you to tackle then, Vassi. I look forward to seeing Lua.NET in the near future. ;)

EDIT note added: The whole of Lua – in C, including comments and white space and such – is only 16kloc. One of the largest files is just luaconf.h which is essentially just a crapload of macros for portability and configuration. Lua could be reimplemented in a higher-level language with significantly less code, and you could probably make the parser cleaner while you're at it.
Random Picks
0.0/82