Scripting language for C game
I guess that's why they make ice cream in different flavors
I like Lua because it's small, simple, doesn't try to be everything to everyone, and is real easy to integrate. I have a few gripes about the syntax too, but it'll get you off the ground quickly if you want to add scripting to your C game, which is what this thread is all about. Besides, Lua's where all the cool kids hang out!
I like Lua because it's small, simple, doesn't try to be everything to everyone, and is real easy to integrate. I have a few gripes about the syntax too, but it'll get you off the ground quickly if you want to add scripting to your C game, which is what this thread is all about. Besides, Lua's where all the cool kids hang out!
unknown Wrote:I much prefer lua over python and ruby especially for this purpose, but overall as well. You might be confusing a language with the libraries it has, its important to make the distinction.
Though I think that the libraries it provides are important too, especially the ones that are built in. It might be fast and have a well written C API, but as a language it just seems mediocre to me.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
My general take on it is, if you want to write small amounts of code as scripts, or are desperate for security (eg. you intend to transmit user-written scripts across a network and run them on other players' machines) then Lua is a good choice.
If you want to write substantial portions of your application code in your scripting language, you want something that actually has useful language features, object-orientation, and a decent standard library. Python (particularly Stackless) and Ruby are both excellent choices for this use.
Also IM(NS)HO, if you're in the first camp, you should seriously consider being in the second!
If you want to write substantial portions of your application code in your scripting language, you want something that actually has useful language features, object-orientation, and a decent standard library. Python (particularly Stackless) and Ruby are both excellent choices for this use.
Also IM(NS)HO, if you're in the first camp, you should seriously consider being in the second!
TomorrowPlusX Wrote:Are you all happy with Lua as a language? I bought PIL a year or so ago and read through it ( and did some testing of my own ) and by the end I was thinking: "I wouldn't touch this language with a 10 foot clown pole".
Python & Ruby are beautiful languages. Lua may be practical, but it smells to me.
lua's so dang easy to embed, I can hold my nose regarding the syntax. plus the VM fits in a tiny little static library, so it feels much more managble than an entire python/ruby VM.
that said, I've never embedded python/ruby in C, just the other way around
I'm talking about Lua the language. The kind of meta understanding you need just to do polymorphism and OO programming in general is deeply offputting.
That being said, it's clearly very performant and has great embedding.
I don't care. I'm going to use SWIG to generate python bindings.
That being said, it's clearly very performant and has great embedding.
I don't care. I'm going to use SWIG to generate python bindings.
TomorrowPlusX Wrote:I'm talking about Lua the language. The kind of meta understanding you need just to do polymorphism and OO programming in general is deeply offputting.Well, but, we're talking about embedding a scripting language in C, not C++. Lua tends to present a more procedural way of doing things, like C. You, OTOH, if I may see it this way, deeply understand polymorphism and OO programming in general, and prefer C++ to begin with. It makes sense to me that you wouldn't like Lua from the beginning.
Which brings up another point of debate about scripting languages in general. If the application would allow for the use of a procedural language or an OO language, which would end-users prefer? My guess would be procedural, since that tends to be easier to digest upon first approach.
Lua adapts well to the OO model actually, I used embedding, object orientation and polymorphism extensively in N0x35C49E
Theres also another great thing about the "lightweightness" of it, you can really alter the basics of it if you need to, for example when I was trying to bridge lua, io and ruby together I found a very simple way to make a function call in a lua script fallback to the interpreter and then be tested to see if an io or ruby function of the same prototype existed.
Theres also another great thing about the "lightweightness" of it, you can really alter the basics of it if you need to, for example when I was trying to bridge lua, io and ruby together I found a very simple way to make a function call in a lua script fallback to the interpreter and then be tested to see if an io or ruby function of the same prototype existed.
Sir, e^iπ + 1 = 0, hence God exists; reply!
TomorrowPlusX raises the very good point that SWIG does a lot of heavy lifting for you when you want to mix Python or Ruby with C/C++, which is nice. Currently, SWIG doesn't do Lua... I developed a decent set of C++ template files that make it really easy to wrap C++ objects in Lua (I'm sure other people have done the same).
Also, I'm interested in how people do embedding... is your game "engine" made up of C/C++ objects wrapped inside of a scripting environment, or do you use scripting just to handle a few things (i.e. level loading & NPC AI) with most of the code living in compiled modules? On the few projects where I've done scripting, I use the latter approach.
Also, I'm interested in how people do embedding... is your game "engine" made up of C/C++ objects wrapped inside of a scripting environment, or do you use scripting just to handle a few things (i.e. level loading & NPC AI) with most of the code living in compiled modules? On the few projects where I've done scripting, I use the latter approach.
In my experience, SWIG never does anything for you but waste your time generating shit, or failing to generate anything at all...
I have a thin layer of ObjC at the top for windowing and events, then a thick layer of object-oriented scripting where the bulk of the game is, then a thin but heavy-lifting layer of C at the bottom for the bits that are too slow or too low-level to do in the scripting language.
I have a thin layer of ObjC at the top for windowing and events, then a thick layer of object-oriented scripting where the bulk of the game is, then a thin but heavy-lifting layer of C at the bottom for the bits that are too slow or too low-level to do in the scripting language.
I have to say, OneSadCookie is mostly right. Lua is more useful as a configuration language than for full game logic.
Personally, I've been using the IoLanguage, which while being a bit slower than Lua, probably surpasses it on every other front.
Also, there are other alternatives to Lua, besides Python, Ruby, or Io. Pike comes to mind, and I am sure there's a million and one other such projects out there.
Personally, I've been using the IoLanguage, which while being a bit slower than Lua, probably surpasses it on every other front.
Also, there are other alternatives to Lua, besides Python, Ruby, or Io. Pike comes to mind, and I am sure there's a million and one other such projects out there.
I've been thinkinga bout my current aspirations. I have been playing with embedding Lua in C, and have had quite a bit of success with drawing polygons, loading images, rendering them to the screen, taking keyboard commands, and the like.
My goal was to write the whole game in Lua, but now I think that it might not be the right way to go. I think it may be better to use Lua to inform the C engine of what is going on or what to do. For instance: loading levels should be in Lua, but iterating through the grid, culling out the non-visible tiles, and rendering the whole shebang is a better task for C.
To make the engine as flexible as possible would be a daunting task in itself. I should just make a game and use C/Lua wherever it fits instead of a grander idea.
My goal was to write the whole game in Lua, but now I think that it might not be the right way to go. I think it may be better to use Lua to inform the C engine of what is going on or what to do. For instance: loading levels should be in Lua, but iterating through the grid, culling out the non-visible tiles, and rendering the whole shebang is a better task for C.
To make the engine as flexible as possible would be a daunting task in itself. I should just make a game and use C/Lua wherever it fits instead of a grander idea.
bronxbomber92 Wrote:How do you embed python in Objective-C code?
The exact same way you embed it in C.
Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Skorche Wrote:The exact same way you embed it in C.
Which is how?
I tried this:
Code:
#include <Python.h>
int main(int argc, char *argv[])
{
PyMac_Initialize();
PyRun_SimpleString("from time import time,ctime\n"
"print 'Today is',ctime(time())\n");
Py_Finalize();
return 0;
}
Try Python/Python.h ?
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| Ruby for scripting my game engine... | djork | 13 | 7,852 |
Aug 20, 2006 06:48 PM Last Post: OneSadCookie |
|
| RGSS: Ruby Game Scripting System | Carlos Camacho | 5 | 7,860 |
Jul 31, 2005 06:26 PM Last Post: Carlos Camacho |
|

