[Gardon]

I've been debating whether to use a scripting language like lua for my rpg, or to use my own custom made scripting system.

Using my own scripting system would be the best way for me to make the game, however, I was unsure if lua or any other scripting language had greater speed when it came to actual gameplay.

speed comes first, and if lua is optimized (or whatever you might call it), then I would most definitely go with that.

Any help would be appreciated. Thank you,

-g-man

[Ninkazu]

LUA is the most optimized and minimalistic of scripted languages out there.
Given computational benchmarks, compared to C, LUA was 30x slower, while Python was 200~x slower. Java with its JIT magic was 7x slower.
A very large amount of professional games out there use LUA. See: WoW, Crysis, Ragnarok Online
For more see
http://en.wikipedia.org/wiki/Lua_(programming_language)#Games

With a clever assortment of custom API calls into your engine, you can make LUA work to your advantage and efficiency.

Believe me when I say that LUA is extremely easy to work with and learn, and is a much better alternative to a phoned-in solution most would likely dream up during their 20 minutes of design time allocated to the scripting engine. Upon poorly thought out design, you get incomplete and inefficient implementations even after a large amount of effort.

You want to make a game, yes? Learn to use tools that exist to your advantage. If you want to learn about writing your own interpreter/compiler/assembler, take a class, read a book, or make that your prime goal of a particular project.

After years in software, I really have learned that the #1 desired trait of any software engineer is to be able to deliver. Produce. Ship. You can find you've made a huge mistake in hiring the brilliant guy who can't get shit done over the recent college grad that's completed 10 large personal projects with a GPA of 2.9.

I'll reiterate. Games are probably the largest undertaking of any software developer and often involve a formidable amount of specialized technologies. If your goal is to learn rather than create, concentrate on a single area and make that your project rather than trying to single-handedly outdo Chrono Trigger.[url][/url]

[Mattias Gustavsson]

I think that it is important to first ask yourself WHY you need a scripting language.

If you're just a lone dev, and you're not planning to have other people create mods for your game, you don't really need a scripting language at all. All it will do is slow you down. You're better off with a couple of simple text-based data file formats, which you make dynamically reloadable.

One reason to use scripts, is if you have non-programmers who will be making the game specific scripting. In that case, general purpose scripting languages like LUA is no good - it's too complicated and not specific enough to your game, so you're better off making your own (SIMPLE!) scripting language, with the exact functionality you need and nothing more.

If the people making the game specific scripts for your game are programmers, they will prefer working in the normal IDE, and this will generate the fastest code too.

I guess integrating a general purpose script language such as lua can be fun, but it doesn't really give you an advantage, an I'd say you're better off just working on the game.
_________________
www.mattiasgustavsson.com - My blog
www.rivtind.com - My Fantasy world and isometric RPG engine
www.pixieuniversity.com - Software 2D Game Engine

[Ninkazu]

I wholeheartedly disagree. Throwing away scripting makes content generation a nightmare. You end up having a large amount of bloat in your engine to support new formats of data, and cutscene-type events and event simple dialog can turn out to be a huge pain to write. You essentially still have to write a semi-scripting language.

A simple scripting language as you say can easily be emulated in LUA, however in LUA you have access to far better resource management and expression evaluation (say you have some previous event requiring something else to happen and you need the same amount of gold rings as party members).

LUA IS simple. It takes about 10 lines of code to load it all up, and 1 more to launch a script.

The time to learn LUA would be less than a third it would be to write up and debug a "simple" scripting language.

[Jinroh]

Personally I like the Mad Libs Style Scripting that Jim Adams proposes and implements in Jim Adam's Programming Role Playing Games With DirectX.

I made a variant of it with BASIC Syntax and what not I just haven't gotten to actually stick the class in my engine yet.
_________________
Mao Mao Games
The wolf and his mate howl, taking solace in the silver moon. Pressing ever foreward to see what the future holds.

[Mattias Gustavsson]

[valderman]

[DeveloperX]

wow this is turning into quite the little tit-for-tat argument. :P

As a programmer who uses several languages, let me toss in my $0.02.

I am against hard-coding game data / logic into the game. Using scripting is so much better. However this approach only applies if you are writing your game in a compiled language.

I myself have all but quit using compiled languages for my game projects, and now I use what is considered to be a scripting language, though I think of it as just a really easy to use, and easy to learn programming language with which anything is possible. (Ruby if you're wondering.)

I have used LUA, and have used TCL, and I have used Python, all in the context of using it for scripting, as well as using it to write the whole game.

My personal experience has been that it depends on the overall goal that you are aiming for.

If you are trying to make a reusable engine, then build into that engine a way to script it using whatever language you want.

If you are just trying to make a game such as for a contest or just for the hell of it, then do not bother with adding a scripting layer to your game, just write the game in the scripting language to begin with.

Recompiling a project over and over to tweak any game data that has been hardcoded is STUPID. 100% utterly stupid!

The only time that hard coding the game data is not stupid is when the language that you are using is not compiled, hence its an instantly easily changed data.

Worried about someone seeing your code? Buy a commercial obfuscater that makes your code unreadable by 9/10 of the people who would try to mess with it. (Just don't forget to keep a backup of the readable code on hand for later changes if needed)

My final thing to say is. C++ while powerful is a terrible language to write games in. Period. Its great to write game engines with, and its great for writing apps that must be fast as hell. Just do yourself a favor and don't try to write a game in C++ its not worth it.
_________________
Principal Software Architect
Rambling Indie Games, LLC

See my professional portfolio

[RedSlash]

[Gardon]

I think C++ is essential in writing games. I'm only a casual programmer, but I think the speed is necessary compared to something like Basic or straight up script programming (perhaps in ruby). Plus it gives me something to work on and design since I can't make artwork for shit. I guess I like keeping busy with the code :)

[Mattias Gustavsson]

In my experience, most people who recommend the use of extensive scripting, are people who either haven't been through the whole process of making games, or people who have not worked on all parts of a game, even if they are often experienced programmers. I'm not saying this applies to those who have posted in this thread (I don't know what games you've worked on, so I wouldn't know), but it's a general observation.

Scripting is one of those things that seem like a neat concept, and looks like it could save a lot of time (it's particularly easy to get this impression early on in development).

Again, in my experience, it's often the case that scripting is more problem than it's worth. Custom made, very precise script systems can be worth their weight in gold. General purpose scripts though, is what I recommend against, as I've seen it tried and failed over and over again. I even worked on one big, AAA title where scripting went so out of control that the project was dropped altogether - it was considered to be so much work to put it right that it wasn't worth doing. In this case, the LUA scripts had kept growing and growing, doing more and more things, and never working quite right....

I'm not trying to convince those here that have their minds set on the usefulness of scripting - I'm merely sharing my negative experiences with it, in the hope that some people reading this might take a bit of time to think through, one more time, what they hope to achieve by adding script support, and whether general purpose scripting is really the solution to this.

Saying "just use LUA, it's the best and fits every game" is not good advice, in my opinion.

[Nodtveidt]

Without getting into yet another language war here...my opinion is that you use the tool for the job. Lua seems to be a good general purpose tool but it's not suited for every project and seems to be rather ho-hum for games (though better than most prebuilt dialects). C++ is for people who want to distance themselves from the lower levels of computing, and want the ease of objects. But the only thing "fast" about C++ is the speed of development compared to low-level procedural languages...and that only applies if you're a C++ expert. C++ compilers tend to introduce way too much overhead (which creates performance bottlenecks), and the dialect itself is a bloody mess, especially if you come from the *logical* world of procedural programming (anything you do in C++ can be done in C...if you know how). In the end though, it all boils down to what YOU think is best for your project.
_________________
If you play a Microsoft CD backwards you can hear demonic voices. The scary part is that if you play it forwards it installs Windows. - wallace

[valderman]

[RedSlash]

A note about C++ and speed: the "fast" part of C++ is more to do with the skill of the programmer, than it is of the language itself. A novice programmer will likely produce a slower, more buggier and memory-leak riddled program when programming in C++ but will produce a decently performing program with lesser bugs and in shorter time using a higher leveled, managed language like Java and C#. For C++, you'd have to push your knowledge to the limit and be an expert skilled C++ programmer with years of experience if you want the speed advantage that is worth your development time.

As for scripting, scripting is very useful when you want to allow people to extend the functionality of your game. Whether Gardon needs scripting or not, if he chooses to use it, it is probably better to use LUA than to write his own unless he just wants to do it for fun or requires something that LUA cannot provide. There's really no reason to reinvent the wheel. As for LUA alternatives, anyone have experience with NekoVM?

[Hajo]

In my former project H-World, at least in the design stage, I wanted to keep my engine closed source and scripting was meant to provide the extensibility and adaptability that game and mod makers will need.

Speed or ease of development were not the drivers of choosing a scripting approach, but the separation of closed and open parts was.

Lua worked fine there. I liked the way it integrated with C/C++, and it seemed to be sufficiently performant.

I just tell this to show that some projects chose scripting for reasons that have not been pointed out in this thread yet, and for some projects they may be valid. In my case it turned out to be a moot point though, since H-World now is open source, so there is no "closed" part anymore, and my new project Sonnheim is also open source - with open engines the need for scripting is lower, I think. But I also moved from C++ to Java, since in my experience development is quicker with Java, and Java programs are more robust, overall Java has less ways to make mistakes than C++ has (at least for me).