4 ms·

Makes me wondering with all those WoW-Addons which are Lua, it certainly can't be _that_ bad..

by buster 15y ago

forrestthewoods 15y ago
Sure it can. When I play WoW years ago there were addons that could take up over a gig of ram. The mods that were item database related could often obliterate performance. I had a beefy PC at the time and there were still a few popular mods I couldn't run. The perceived advantage of something like Lua is that it's easy to write, allows for fast iteration, and designers/artists can use it. The issue is that designers/artists really shouldn't be using it. To write fast code it requires a programmer and if you have a programmer why not just do it in C++ where it will be several times faster? A common game development pattern is to write the bulk of gameplay code in a scripting language and at the 11th hour in a desperate panic start moving as much of it as possible to C++ until you fit in 360/PS3 memory and are fast enough.
- rikthevik 15y ago
  I think there's something to be said for the ease of patching with a scripting language, though. If you need to update a quest, just ship a few new lua files and it's done - seems much easier than messing with a binary.
- slowpoke 15y ago
  To write fast code it requires a programmer and if you have a programmer why not just do it in C++ where it will be several times faster? Why should I as a programmer not profit from extremely fast design/implement/test/fix/repeat iterations? I'm not saying scripting/high level languages like Lua, Python or Ruby should always be preferred. But it's equally wrong to assert that C-oid languages are always the superior choice. It's much more a question of knowing when to use what and why, which in my opinion makes an important part of being a good programmer.
  - to3m 15y ago
    I've never seen the effort involved in making a nice quick-feedback REPL-style affair pay off. Perhaps for certain types of game it would be worth it, and perhaps amortized over a long enough period the result would become value for money. My experience has been that making a script system work that way, and work reliably, and provide a nice interface, just takes up more time than you end up saving. Anyway, all the programmers I've known would want good debugging facilities as well, like the ones you get in Visual Studio/ProDG/Code Warrior/Xcode/gdb/etc. - oops, only kidding about gdb! This thing really needs a GUI. This all just expands the time-suck further. That's not to say it can't be made to work, of course! People can do anything, if they set their mind to it hard enough, and if they wait for long enough, maybe it will even become value for money.
    - Derbasti 15y ago
      Let me tell you about one project I have been working on. It was a large embedded device, with lots of highly optimized code in C and ASM on Sharks and Blackfins. The problem was, every time you changed the code, you also had to push it on the device via FTP, then power down the device to reset it's memory, then reboot it with the new binary and reconnect your FTP and debugging host. Some of that could be automated, some not. However, we also had a scripting interface. Update a script, tell the software to restart, done. Easy.
      - MichaelEGR 15y ago
        Nice.. I too was working with embedded C++ dev w/ a Blackfin & Sharc combo and yes the standard build cycle was kind of lame. I attended a Blackfin course that just happened to be located at Analog Devices HQ. In the 4 days that I was there I got an OSC (Open Sound Control) library w/ message parsing and Lua support up and running hooked up to desktop GUI audio control apps built with a framework I've created in Java. I continued to try and get things going with the OSC message parsing to Sharc communication for DSP control (Ambisonics mostly), but then Android steam rolled me.. I already had a real time app dev runtime / framework in Java for J2SE that immediately started porting to also run on Android. A modern SoC and Android w/ my framework on the desktop and on the device for 3rd party app dev is now driving my future audio hardware dev efforts. First though I get to do a general release of the software dev framework as a product which never really would have happened without Android showing up. Things changed a lot recently! Anyway, good idea with the scripting / Blackfin deal though as that can pay off big.
- malkia 15y ago
  Surely you profiled to see that it was the interpreted language causing the slowdown?
- malkia 15y ago
  Being a PC game, they might have easy solution waiting for them - LuaJIT. Now Mike Pall is saying that the garbage collector is still the old lua one, so in your case (item database) it might not give much speedup. Then again it might!

Makes me wondering with all those WoW-Addons which are Lua, it certainly can't be _that_ bad..

by buster 15y ago

Makes me wondering with all those WoW-Addons which are Lua, it certainly can't be _that_ bad..

Sure it can. When I play WoW years ago there were addons that could take up over a gig of ram. The mods that were item database related could often obliterate performance. I had a beefy PC at the time and there were still a few popular mods I couldn't run. The perceived advantage of something like Lua is that it's easy to write, allows for fast iteration, and designers/artists can use it. The issue is that designers/artists really shouldn't be using it. To write fast code it requires a programmer and if you have a programmer why not just do it in C++ where it will be several times faster? A common game development pattern is to write the bulk of gameplay code in a scripting language and at the 11th hour in a desperate panic start moving as much of it as possible to C++ until you fit in 360/PS3 memory and are fast enough.

rikthevik 15y ago
I think there's something to be said for the ease of patching with a scripting language, though. If you need to update a quest, just ship a few new lua files and it's done - seems much easier than messing with a binary.
slowpoke 15y ago
To write fast code it requires a programmer and if you have a programmer why not just do it in C++ where it will be several times faster? Why should I as a programmer not profit from extremely fast design/implement/test/fix/repeat iterations? I'm not saying scripting/high level languages like Lua, Python or Ruby should always be preferred. But it's equally wrong to assert that C-oid languages are always the superior choice. It's much more a question of knowing when to use what and why, which in my opinion makes an important part of being a good programmer.
- to3m 15y ago
  I've never seen the effort involved in making a nice quick-feedback REPL-style affair pay off. Perhaps for certain types of game it would be worth it, and perhaps amortized over a long enough period the result would become value for money. My experience has been that making a script system work that way, and work reliably, and provide a nice interface, just takes up more time than you end up saving. Anyway, all the programmers I've known would want good debugging facilities as well, like the ones you get in Visual Studio/ProDG/Code Warrior/Xcode/gdb/etc. - oops, only kidding about gdb! This thing really needs a GUI. This all just expands the time-suck further. That's not to say it can't be made to work, of course! People can do anything, if they set their mind to it hard enough, and if they wait for long enough, maybe it will even become value for money.
  - Derbasti 15y ago
    Let me tell you about one project I have been working on. It was a large embedded device, with lots of highly optimized code in C and ASM on Sharks and Blackfins. The problem was, every time you changed the code, you also had to push it on the device via FTP, then power down the device to reset it's memory, then reboot it with the new binary and reconnect your FTP and debugging host. Some of that could be automated, some not. However, we also had a scripting interface. Update a script, tell the software to restart, done. Easy.
    - MichaelEGR 15y ago
      Nice.. I too was working with embedded C++ dev w/ a Blackfin & Sharc combo and yes the standard build cycle was kind of lame. I attended a Blackfin course that just happened to be located at Analog Devices HQ. In the 4 days that I was there I got an OSC (Open Sound Control) library w/ message parsing and Lua support up and running hooked up to desktop GUI audio control apps built with a framework I've created in Java. I continued to try and get things going with the OSC message parsing to Sharc communication for DSP control (Ambisonics mostly), but then Android steam rolled me.. I already had a real time app dev runtime / framework in Java for J2SE that immediately started porting to also run on Android. A modern SoC and Android w/ my framework on the desktop and on the device for 3rd party app dev is now driving my future audio hardware dev efforts. First though I get to do a general release of the software dev framework as a product which never really would have happened without Android showing up. Things changed a lot recently! Anyway, good idea with the scripting / Blackfin deal though as that can pay off big.
malkia 15y ago
Surely you profiled to see that it was the interpreted language causing the slowdown?
malkia 15y ago
Being a PC game, they might have easy solution waiting for them - LuaJIT. Now Mike Pall is saying that the garbage collector is still the old lua one, so in your case (item database) it might not give much speedup. Then again it might!