Python bindings, anyone?

[Eternl Knight]

I agree with hybrid. The features that make Java a good beginning language (garbage collection, lack of pointers, etc) - also make it incredibly hard to optimise to speeds necessary for game engine development. Hell, the "memory management gotchas" (dependant on which JVM you used) caused us enough hassle when optimising a finiancial services application (something my 'day-job' involved me in about a year and a half back).

I reckon the simulator hybrid mentioned would positively fly if coded in say C++.

Personally, I am looking at Squirrel VM as a scripting language for my game. Most the flexibility & coroutine support of Lua with the nice class / module / generator features of Python.

--EK

[pinballwizard]

Personally, I am looking at Squirrel VM as a scripting language for my game. Most the flexibility & coroutine support of Lua with the nice class / module / generator features of Python.

--EK

As much as I love Python, I recently investigated the difficulty of cross-platform deployment of Python. Ideally I want to distribute a single executable file with data embedded, or possibly a single executable file with a single archive data file.

Achieving this with Python, in a cross-platform way, is rather complicated; you have to install the Python DLL's; Python cannot be statically compiled into your application without messing up the module loading; how to statically compile/bundle extension modules is not clear; Python is huge.

I recently looked at Lua (for which Irrlicht also has bindings ), and so far I like what I see. Coroutine support, static compilation of everything into one executable (though trying to get lua and luasocket statically compiled together was a very frustrating experience for my first experience with Lua), and apparently there's single-executable file deployment support, in varying stages of usableness (srlua, LAR lua archives, srlua with zip files, etc).

EK, you mentioned looking into Squirrel. Since you have experience with Python, Lua, and Squirrel... what's your verdict so far? I'm almost completely sold on Lua at this point, mainly because it is small and easy to embed, with libraries, into a single C program, which greatly eases deployment. (I looked into Java+Jython+Java WebStart as another option, but as you say, Java also has issues.)

[Eternl Knight]

Well, if I was basing my decision on language features & supporting libraries - I would go with Lua. It is relatively easy to embed, has alot of third party libraries one can use, and will get the job done with a minimum of fuss. If you are planning on using the "import" feature for loading DLL's extensively - I would recommend you stick with Lua.

However, I prefer Squirrel for three reasons.

Firstly, I like the syntax. Having class support "built-in" to the language is a big plus for me, and the use of generators is also very cool. I dislike Python's enforced "indent = block" syntax (for beginner coders, sure it's a nice way of enforcing "readable" code, but I've been coding for ten years now - I know what I'm doing!).

Secondly, it is incredibly easy to embed your own classes into the script using 'SQPlus' (which is used by almost all developers on the Squirrel mailing list). This is a big win for me as I like to expose as much of my internal classes & functions as possible when prototyping. Minor tweakage is all that is needed to have independent agents running their own AI threads (actually, Squirrel co-routines) with enough control to still get the rendering and physics code done in time for a frame refresh

Last but not least, there is a Squirrel debugger provided for free (found on the same site as SQPlus). When integrated into your "world editor" - this makes it very easy to find out what went wrong in your scripts.

You might also like to consider that Niko uses Squirrel in IrrEdit. This didn't influence me at all, but it was the impetus for me to check Squirrel out for myself (which I am grateful for).

--EK

[pinballwizard]

My interest is to write my entire game in script language: All my game data structures, entities, AI, persistence, map loading, collision response, networking, etc will be done in script. My scripts will call Irrlicht for rendering and ODE (or something else) for physics, ensuring total separation of game logic, graphics back end, and physics back end.

From what it sounds like, Squirrel isn't quite the right fit for this; it sounds like Squirrel is for adding small scripting to an existing C++ codebase for hybrid development. Is this right?

For me, I don't want hybrid development: I want to do pure script development. I want to stop worrying about C++ and memory management and pointers and segfaults, and concentrate on writing my game, so I want to write my game in a fast, easy, safe scripting environment.

Also, it looks like there is not a complete Irrlicht API binding for Squirrel - is this right?

Anyway, we all have different needs... to each his own!

[Eternl Knight]

I'm not sure I understand your position, pinball. Irrlicht is a C++ library (as is ODE) - so whether you are using Lua, Python, Squirrel, or Prolog - you will be interfacing with a C++.

Squirrel does not care about pointers (at least not in the same way C++ does). Squirrel is basically "Lua with enhancements". The only things it is lacking is (a) op-code level debugging (which you don't want) and (b) 'automatic garbage collection' (it uses ref-counting until you manually instigate a garbage collection cycle - much better for real-time applications).

Irrlicht does not currently have a full Squirrel interface, no. But I know there are at least two developers besides myself & Niko working on it. With IrrEdit using Squirrel - I bet you pounds to peanuts that the Squirrel interface becomes as close to an official scripting langauge for Irrlicht as you can get

But as you said, each to their own needs. I personally don't mind coding in C++. I'm into scripting for runtime modifications and "game logic".

--EK

[pinballwizard]

I'm not sure I understand your position, pinball. Irrlicht is a C++ library (as is ODE) - so whether you are using Lua, Python, Squirrel, or Prolog - you will be interfacing with a C++.

All I meant was that I want to stop doing my own coding in C++, and start doing my own coding purely in a typeless, interpreted, memory-safe script language.

So a big concern for me is (a) having a complete script-to-backend-C++-library interface for the libraries I am using (i.e. script-to-Irrlicht and script-to-ODE), and (b) having the script language be powerful/expressive enough, with enough libraries, so that I don't need to drop back into coding C++ (e.g. does Squirrel have networking support, or do I have to write that in C++ and hook it into Squirrel?)

As for Lua, it has networking support (luasocket), it has full a Irrlicht API binding, and there was a Lua-ODE binding someone claimed to have made (can't find it for download though). So Lua comes very close to letting me do 100% of my coding in Lua. Of course I'm interfacing to C++ code on the back end, but the point is that the back-ends and the interfaces already exist for Lua.

Irrlicht does not currently have a full Squirrel interface, no. But I know there are at least two developers besides myself & Niko working on it. With IrrEdit using Squirrel - I bet you pounds to peanuts that the Squirrel interface becomes as close to an official scripting langauge for Irrlicht as you can get

Now that would be a great factor in Squirrel's favor For full-blown game development, though, there's still the question of existing interfaces to libraries like ODE or networking.

But as you said, each to their own needs. I personally don't mind coding in C++. I'm into scripting for runtime modifications and "game logic".

After I started significantly coding in Python, I realized how much of my time was wasted in C++ worrying about and tracking down memory bugs. Python allowed me to think at a higher level and get things done faster with fewer errors. I don't want to go back to raw C++ if I can avoid it (I already get enough C++ practice debugging Irrlicht library code!)

[sRc]

Irrlicht does not currently have a full Squirrel interface, no. But I know there are at least two developers besides myself & Niko working on it. With IrrEdit using Squirrel - I bet you pounds to peanuts that the Squirrel interface becomes as close to an official scripting langauge for Irrlicht as you can get

wheres my ninja smilie? ah yes

[zenaku]

...and there was a Lua-ODE binding someone claimed to have made (can't find it for download though)

http://www.uploading.com/files/DN7M3OMX ... 1.zip.html

It's a basic tolua++ wrapper to ode, similar to irrlua. I hacked it out a couple weekends ago but never had a chance to really play with it. It is a raw wrapper and has not been 'luafied' yet, so it is probably not very usable at the moment. I dunno if it works, let me know

irrlua and odelua are going to become a part of a new project I started on sourceforge called the LuaGameSDK. It will be a month or two before I have anything up on the LuaGameSDK site, so I thought I'd share odelua now.

[pinballwizard]

Thanks for the odelua code - I'll play with it this weekend.

Your project about a LuaGameSDK sounds interesting. It sounds kind of like what I'm aiming for - do game development in Lua with other supporting libraries.

What exactly belongs in a GameSDK anyway? We have:
- Graphics - Irrlicht
- Physics - ODE
- Scripting - Lua
- Sound
- Input
- AI
- Networking
- Performance monitoring / debugging tools (timing classes, variable watching, number of triangles/state changes/textures, Nebula-device-like interactive shell)
- World structure (scene graph, portals/cells)
- Game object model (Entities/Component Model/Adaptive-Object-Architecture)
- Visual tools (modeling, level editing, lightmapping)
- Back end tools (asset conversion pathways, import/export)
- Deployment tools (compile or package into single EXE, virtual filesystem, installer, cross-platform support)

That's most of the things I can think of that complete game development needs. Anything else I left out? What audience are you aiming for with LuaGameSDK? E.g. usable by artists with little programming experience, like Blender, or as a library of code to be called by a programmer, like a higher-level programming API?

[zenaku]

Thanks for the odelua code - I'll play with it this weekend.

Your project about a LuaGameSDK sounds interesting. It sounds kind of like what I'm aiming for - do game development in Lua with other supporting libraries.

What exactly belongs in a GameSDK anyway? We have:
- Graphics - Irrlicht
- Physics - ODE
- Scripting - Lua
- Sound
- Input
- AI
- Networking
- Performance monitoring / debugging tools (timing classes, variable watching, number of triangles/state changes/textures, Nebula-device-like interactive shell)
- World structure (scene graph, portals/cells)
- Game object model (Entities/Component Model/Adaptive-Object-Architecture)
- Visual tools (modeling, level editing, lightmapping)
- Back end tools (asset conversion pathways, import/export)
- Deployment tools (compile or package into single EXE, virtual filesystem, installer, cross-platform support)

That's most of the things I can think of that complete game development needs. Anything else I left out? What audience are you aiming for with LuaGameSDK? E.g. usable by artists with little programming experience, like Blender, or as a library of code to be called by a programmer, like a higher-level programming API?

You have all the stuff I'm aiming for. Basically, there are a lot of lua modules already out there. It's just that they are all source distributions, or they depend on different lua versions, etc. The game sdk is going to be a binary distribution of those lua modules, prebuilt so they work together.

The primary audience would be developers. Initially there would not be any premade game logic like other game sdks, but I would like to get some good examples working


Most game engines that use lua for scripting are C++ and all the game core is also C++. For example there would be a CPlayer class in C++ that you would access in Lua. Using the LuaGameSDK, you would create the CPlayer class in Lua, not C++, so there is some added flexibility at the cost of the engine being a little slower than a straight Lua binding to a C++ game core.

The modules I'm initially aiming for are:

irrlua
odelua
luasocket
wxLua
openAL or audiere, I'm not sure here, or about joysticks...

[evo]

Irrlicht does not currently have a full Squirrel interface, no. But I know there are at least two developers besides myself & Niko working on it. With IrrEdit using Squirrel - I bet you pounds to peanuts that the Squirrel interface becomes as close to an official scripting langauge for Irrlicht as you can get

wheres my ninja smilie? ah yes

How is your progress with Squirrel, Anaconda? With any luck i'll publish the first version of my Squirrel wrapper tomorrow.

I agree with E.K. that Squirrel may become the 'official' scripting language for Irrlicht. It is very fast and versatile, also a friendly license. Only problem is the nonexistent documentation.

[Eternl Knight]

hehe, I knew you guys would pop up in this thread

I have to agree that the biggest thing Squirrel lacks is documentation. For pinball's purposes - it also lacks a stand-alone interpreter. However, this is not a "problem" in my mind so much as a feature. Both Lua & Squirrel were designed as "embedded" scripting languages, unlike say Python & Java. The stand-alone interpreter for Lua was primarily an example of how one would use Lua with all "internal" libraries registered that has taken on a life of it's own

--EK

[pinballwizard]

Using the LuaGameSDK, you would create the CPlayer class in Lua, not C++

That's what I like to hear C++ back-end for heavy-lifting, Lua scripting for all game-domain stuff. That makes it possible to develop and distribute games purely in Lua without needing to recompile the back-end C++ code for different games. I think is neat from a program-architectural perspective - kind of like Blender, where games are developed with logic bricks and Python, but without needing to modify the Blender C++ engine code.It also allows artists - who might be comfortable with scripting but not with compiling engine code - to make games more easily.

[sRc]

How is your progress with Squirrel, Anaconda? With any luck i'll publish the first version of my Squirrel wrapper tomorrow.

I agree with E.K. that Squirrel may become the 'official' scripting language for Irrlicht. It is very fast and versatile, also a friendly license. Only problem is the nonexistent documentation.

actually ive been too busy with other stuff since my post on there to work on it much again :/ bought a new car been working on getting it (and myself) licenced and stuff before i start my new job

im only at the very beginning of the wrapper, im still in my experiments with it. im planning on setting it up so that certain functions can be enabled and disabled within scripting, so for example i can do my experimenting all in script then later build certain functions into the program and disable them, so that end users dont have access to some of the core functions that could cause them to crash the game and stuff. was gonna try working on it some more today

the nonexistant documentation is very much a problem!

[evo]

New car, new job (congrats.), plenty to keep yourself busy.

Sounds like you want to overload Squirrel functions by C functions.

I want to keep things very simple for now. Only make some irrlicht functions available to Squirrel. I'am pretty sure I can post it this sunday. It's too late/am too tired now. Here is part of the header file:

Code: Select all

	// functions bound to Squirrel+
	bool		setCurrentNode(const u32 node);					// following functions from ISceneNode
	int			getCurrentNode();

	vector3		getPosition();
	vector3		getRotation();
	vector3		getScale();

	bool		setPosition(vector3 *value);
	bool		setRotation(vector3 *value);
	bool		setScale   (vector3 *value);

	vector3		getCameraPosition();
	vector3		getCameraRotation();

	bool		setFrameLoop(const s32 begin, const s32 end);	// from IAnimatedMeshSceneNode
	bool		setFrameType(const u32 type);
	s32			getFrameNr();