Hello everyone ! My name is Andrei and i'm 18 years old. I'm interested in game development and i started to read some books...now i read something about DX11 and its very interesting but in a section about game engines i heard about LUA scripting and heard that it's a good practice ... But why to use it if C++ can do the same thing?
I just wanna some opinions pro's or con. Thanks for help guys ;D
Why LUA Script ?
Lua is a scripting language and it is very common to do a lot of the programming in a scripted language. Most(if not all) commercial game engines provide some sort of scripting support. The reason people use scripting languages is that it helps cut down on development time. For example, you're working on an enemy's AI and it's not working quite right. If you coded it's logic in C++ you would have to recompile the code to test any changes. With a scripting language you just make the change and the new file is loaded into the system.
As you said, everything you can do in a scripting language you could do in C++, but anything that helps speed up production is a good thing, right?
Of course, there is a little overhead to run the scripting interpreter on top of your game but with today's systems you should see much of an impact.
As you said, everything you can do in a scripting language you could do in C++, but anything that helps speed up production is a good thing, right?
Of course, there is a little overhead to run the scripting interpreter on top of your game but with today's systems you should see much of an impact.
Also, on top of not having to recompile you can actually modify scripts while the game is running and see the result immediatly, it can also make it quite easy for non programmers (level designers for example) to add custom behaviour to the game without having to ask the programmer to add every tiny little feature.
In addition to the moddability and decreased turn-around time on modifications that has been mentioned, it also has to do with tooling and productivity.
You can leverage C++ in ways that yield a great deal of performance, but at the same time it has essentially no guardrails and pitfalls are not uncommon -- things like memory leaks, maintaining ownership of resources correctly, and the rabbit-hole of premature optimization. In truth, a large part of the game-specific elements don't need all the performance that C++ can offer you, and so it doesn't make sense to expose that part of the code to all the potential pitfalls. Instead, you can implement those parts of code in a language that is safer, more productive, and "efficient enough" -- and leave the core engine to more-experienced programmers using C++.
There still exists a certain inertia among game developers that "all code is performance-critical" and for a certain type of developer -- say, those pushing the limits of AAA console gaming, it's not entirely untrue. However, this notion that this is true of all games is something that dogs some in the industry, and far too many of those aspiring to be in it.
Objectively, yes, performance matters (you can measure it it, therefore you can rank it), and 300 frames per second is "better" than 270 frames per second -- but subjectively, no one's going to notice whether your game runs at "only" 80 or so frames per second. In the end, all that matters to the consumer is "does this run well enough on my hardware?" and the number of consumers you want to reach is defined by "what hardware can I make this thing run well on?"
You can leverage C++ in ways that yield a great deal of performance, but at the same time it has essentially no guardrails and pitfalls are not uncommon -- things like memory leaks, maintaining ownership of resources correctly, and the rabbit-hole of premature optimization. In truth, a large part of the game-specific elements don't need all the performance that C++ can offer you, and so it doesn't make sense to expose that part of the code to all the potential pitfalls. Instead, you can implement those parts of code in a language that is safer, more productive, and "efficient enough" -- and leave the core engine to more-experienced programmers using C++.
There still exists a certain inertia among game developers that "all code is performance-critical" and for a certain type of developer -- say, those pushing the limits of AAA console gaming, it's not entirely untrue. However, this notion that this is true of all games is something that dogs some in the industry, and far too many of those aspiring to be in it.
Objectively, yes, performance matters (you can measure it it, therefore you can rank it), and 300 frames per second is "better" than 270 frames per second -- but subjectively, no one's going to notice whether your game runs at "only" 80 or so frames per second. In the end, all that matters to the consumer is "does this run well enough on my hardware?" and the number of consumers you want to reach is defined by "what hardware can I make this thing run well on?"
Looks like the benefits have been covered pretty well:
So far I only see one disadvantage listed though: code written in a scripting language has a run-time overhead and may execute slower than lower level code. As already mentioned, this isn't a big problem the majority of the time, and the benefits above are usually well worth a slight hit to performance -- it is something to be aware of though, and depending on your needs means that you might not want to use scripting for everything.
Another disadvantage I wanted to list is that you need to spend a small amount of development time initially setting up your scripting language so that it works. In a great many cases the advantages listed above will outweigh this small investment in time and make it well worth the additional effort, but if you are creating a particularly small and simple game it might be worth considering.
Overall I personally think the inclusion and usage of a scripting language (Lua, Python, JavaScript, etc.) is well worth it for most projects above a certain (very simple) complexity, and is well worth considering. As a beginner who is just learning however, you might want to put it aside as something to look at more after you've spent more time learning your chosen lower-level language as well as programming in general.
- Faster/easier iteration when testing new ideas (because you don't need to recompile).
- Allows for non-programmers to take an increased role in development.
- Can protect the programmer from some mistakes that can occur in lower level programming languages.
- Can easily allow players to mod the game.
So far I only see one disadvantage listed though: code written in a scripting language has a run-time overhead and may execute slower than lower level code. As already mentioned, this isn't a big problem the majority of the time, and the benefits above are usually well worth a slight hit to performance -- it is something to be aware of though, and depending on your needs means that you might not want to use scripting for everything.
Another disadvantage I wanted to list is that you need to spend a small amount of development time initially setting up your scripting language so that it works. In a great many cases the advantages listed above will outweigh this small investment in time and make it well worth the additional effort, but if you are creating a particularly small and simple game it might be worth considering.
Overall I personally think the inclusion and usage of a scripting language (Lua, Python, JavaScript, etc.) is well worth it for most projects above a certain (very simple) complexity, and is well worth considering. As a beginner who is just learning however, you might want to put it aside as something to look at more after you've spent more time learning your chosen lower-level language as well as programming in general.
Yes, Lua may execute slower than C++ code, but that shouldn't be seen a reason not to use it. First, make it work. Then, if profiling shows it to be a bottleneck, you can optimize, which may include migrating some routines from Lua to C++. But honestly, JTippets's Goblinson Crusoe is written almost entirely in Lua. The C++ bit is an extrapolation of the Lua interpreter that comes with the Lua distribution.
There are other languages that can be used as scripting languages, such as Python and JavaScript. One thing I like especially about Lua, though, is that it works well for data description, which can be nice if you're into a more data-driven approach.
There are other languages that can be used as scripting languages, such as Python and JavaScript. One thing I like especially about Lua, though, is that it works well for data description, which can be nice if you're into a more data-driven approach.
lua is great... and lua is horrible...
lua is great as once it is setup and going, it is wonderful, you can modify your game as it plays, not having to recompile and get to the state that you were testing
lua is horrible because setting it up can drive you insane. Well, at least me. Oh, and the documentation isn't always that helpful, for instance, lua_pcall(L, NumArgs, numRet, 0) when I first started using it I had my numArgs being the number of arguments the function needed, the documentation didn't specify specifically that the function call was also an argument, so it was failing on me. The documentation wasn't wrong, it just wasn't helpful enough for an impatient tiered student as of myself find understand it how it was meant to be.
I would recomend that you look into luabind... It can be hard to set up due to the lack of examples to follow and it can be made even harder if you can get impatient.
but once you have it implimented it can be really useful, I am currently working on my own luabinding, yes, it is driving me nuts, but the sheer flexibility it offers is what keeps me going at it.
lua is great as once it is setup and going, it is wonderful, you can modify your game as it plays, not having to recompile and get to the state that you were testing
lua is horrible because setting it up can drive you insane. Well, at least me. Oh, and the documentation isn't always that helpful, for instance, lua_pcall(L, NumArgs, numRet, 0) when I first started using it I had my numArgs being the number of arguments the function needed, the documentation didn't specify specifically that the function call was also an argument, so it was failing on me. The documentation wasn't wrong, it just wasn't helpful enough for an impatient tiered student as of myself find understand it how it was meant to be.
I would recomend that you look into luabind... It can be hard to set up due to the lack of examples to follow and it can be made even harder if you can get impatient.
but once you have it implimented it can be really useful, I am currently working on my own luabinding, yes, it is driving me nuts, but the sheer flexibility it offers is what keeps me going at it.
now it's clear
Oh, and the documentation isn't always that helpful, for instance, lua_pcall(L, NumArgs, numRet, 0) when I first started using it I had my numArgs being the number of arguments the function needed, the documentation didn't specify specifically that the function call was also an argument, so it was failing on me. The documentation wasn't wrong, it just wasn't helpful enough for an impatient tiered student as of myself find understand it how it was meant to be.
Take no notice of this, Lua's documentation is excellent.
falconmick maybe you should read the documentation next time it clearly tells you the protocol as lua_pcall links to lua_call
As people are mentioning the speed of Lua compared to C and C++, if this does become a problem you can always you use the excellent and blazingly fast LuaJIT which supports quite a lot of platforms now with speed being the same or close to C code.
edit: I just can not let it go
The Language's name is Lua not LUA,
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
