Lua: Creating a scripting engine to handle sprite actions

[link_jr97]

I don't know if anyone else here has ever thought of doing this for their game BUT.
I know I have. If you look at the way alot of blizzard's newer games work you'll see that the maps are all stored in one file. And all the sprite commands and dialogue are also stored in those map files. When the game launches the map it converts those commands in the map to commands that have been hardcoded into the game and then it calls upon the necessary algorithms etc to handle those commands when they are recquired.

Perhaps a simpler kind of engine could be used in a hobbyist 2d game.
I'm not looking at the coding aspect of this as much as I am at the 'logic' behind the code. The 'concept' if you will.

How convinent would it be to store all the sprite commands for a specific map, in a map?
I think it would be convinient only if you had a good map editor that could edit those commands easily.
Another thing I've been looking at is map compression.
If I were to store my tiledata in hex instead of just regular numbers it might save up SOME space in the long run. This would only be convenient if the numbers went past 100 and the maps were large.
I also got an idea for compressing the scripts for a map.
Each routine will have it's own number in the array as well as a routine name.
Each routine parameter will also have it's own number, unless it's numerical of course.
This would probably work great. Tell me what you all think? Your input is appreciated.

[Skorche]

As far as scripting goes, use a scripting language that already exists and bend it to your will like lua or ruby. As far as compression goes, nothing beats the simplicity of zlib, and it will probably get you better compression than what you're describing.

[link_jr97]

Really? Never heard of zlib. How do I use it?
Would it be possible for you to provide me with a link or something?

[Skorche]

You should already have it. Open up /usr/include/zlib.h, scroll down until you get to gzopen(), gzread() etc. They work pretty much like the stdio file functions except that they work on gzip (.gz) files. So zlib doesn't actually compress the files, but helps you work with them.

[wadesworld]

If you're looking to integrate a scripting language, the perfect choice is Lua. It's extremely lightweight, designed for embedding, actively developed, and used in a ton of applications. You can either call Lua scripts from your app, or you can expose C code to Lua so that users can call functions in your app.

Full details at: http://www.lua.org

(Note, when reading documentation, read the the online Lua book, not the Lua manual - the manual's syntax is confusing)

Wade

[ravuya]

Lua's great. There's an OK, but obviously Windows-specific (as are most tutorials there) tutorial (http://www.gamedev.net/reference/programming/features/lua/) on using it on GDNet.

[link_jr97]

thanks, I think I might look into that. Even though I'm not using C coding for my projects.

[ravuya]

That's ok, I think there are Lua hooks for most languages out there.

[IronWallaby]

World of Warcraft itself uses Lua, interestingly. As do a great many games nowadays... Lua is just a very well-built language, simple and elegant.

As for gzip stuff, type "man gzip" into a terminal for more information.

And, in fact, storing your tiledata in binary, rather than ASCII hex or decimal, would save you gobs and gobs of space (we're looking at, 7 bits instead of 16 for small numbers, and the savings are still there as you go up).

[DoG]

Lua is definitely a good choice for gaming. It has a long, and successful, history of being used in games. Binding it to C is a piece of cake, binding to C++ is a little more difficult, but mostly works, too. If you go with a Lua/C++ combination, try and steer clear of luabind, go with toLua++ instead.