8 ms·

In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?

by anon4 13y ago

deluvas 13y ago
Can confirm. This is by far the most ideal option available.
- kelvin0 13y ago
  I used to work as a programmer in a game company shipping on consoles+PC. The first time we embedded a scripting language in our engine to be used by the level designer's they surprised the whole team with their new found 'toy'. This was great and lessened the burden on programmers. Fast forward to first milestone (everyone crunching) and the milestone was delayed ... The level designers (not being programmers) had introduced a new category of bugs. Compound that to that fact that this script language had a very very primitive debugger ... hell ...
  - namuol 13y ago
    I get the feeling that "crunching" is to blame for the bugs a lot more than the engine's newly-integrated scripting language.
    - kelvin0 13y ago
      I didn't imply the scripting engine was to blame. It's unchecked use and the lack of tools for debugging it were mostly to blame ... of course crunching amplified all these problems
  - sitkack 13y ago
    The affordances of debugging are almost more important than the language.
adamnemecek 13y ago
If nothing else, if you want to learn. If there was an article about building a hobby OS would you respond '''In what situation would "just use linux/freebsd/etc." not be the appropriate solution to this problem?'''?
- anonymoushn 13y ago
  If the article about building a hobby OS was on a blog about making actual useful software, and framed building an OS as a reasonable subproblem of making actual useful software, I would expect lots of people to reply like that.
  - adamnemecek 13y ago
    The blog is specifically about patterns used in game development not about game development per se. So it's about the journey, not about the destination.
- namuol 13y ago
  But the site isn't "Programming Language Patterns" -- it's "Game Programming Patterns".
  - adamnemecek 13y ago
    Correct and one of the patterns is embedding a language. Maybe lua/js does not fit your criteria for whatever reason so it might be a good idea to know how to roll your own language.
    - sitkack 13y ago
      More importantly, that you understand how the underlying language runtimes work and their call/data structure models. Most of us will still embed an existing system.
    - eropple 13y ago
      I am beyond very confident that the solution set containing embedding Python, JavaScript, AngelScript, and Lua covers just about everything in the problem set a game programmer reading that book is going to encounter. And if it doesn't, it's not going to be improved by rolling your own.
eropple 13y ago
Disappearing up your own backside to implement something like this is a time-honored indie game development tradition. (I should know, I've certainly killed enough projects by doing it.)
xjh 13y ago
Security. When you want to run untrusted modding code. It's hard to sandbox python or lua and block I/O and all system calls. 1 mistake and player computers are compromised. Even with JS in browser you can't just eval(), you need sandboxing like https://code.google.com/p/google-caja/ https://code.google.com/p/google-caja/ or https://github.com/jterrace/js.js/ https://github.com/jterrace/js.js/ (200 times slower than js).
ANTSANTS 13y ago
You saw them a lot in old games (the kind likely to be written in assembly), because not even C, let alone a general-purpose scripting language, was acceptable for performance reasons for quite some time, yet there has always been a need for greater abstraction and expressive power. Look at any Japanese RPG of the 80s and 90s, for instance, and there's probably a simple bytecode VM (or state machine, if you prefer) for scripts that move characters around during story sequences, one for displaying text in menus and dialogs, and so on. Look in an arcade shooter, and there's probably one for defining enemy movement patterns, etc. Tiny bytecode DSLs not only boosted expressive power for programmers, they also allowed non-programmers to script behavior. 6502 assembly might be out of reach for non-programmers, but `SETANIM PLAYER1 PLAYER_WALK_TICK; WAIT 20; SETANIM PLAYER1 PLAYER_WALK_TOCK; WAIT 20; LOOP;` is not. If you only have to remember a few simple rules to get the behavior you want, even learning to hand-assemble bytecode is not out of the question for a dedicated professional. Nowadays, you'd probably be better served by embedding a general-purpose dynamic language in most of these scenarios, but hand-rolled bytecode can still win in certain situations that need high performance and/or low latency. Imagine, for instance, one of those fancy "danmaku" shooters with hundreds or even thousands of bullets on screen moving in intricate patterns. You just might want a language more dynamically manipulable than C to script the behavior of those bullets, but using a dynamic language that furiously generates garbage and demands collection pauses for something that must happen 60 frames per second on so many objects is probably going to cause hitches eventually that will get your player killed (in the game, at least). You'll then be subject to a very harsh but valid criticism: "I played games like this on my PlayStation back in the day with no slowdown, this guy must be a crappy programmer if his 2D game stutters on my monster PC." Sure, it's great that you don't need to break out the optimized assembly to do a Breakout clone anymore, but at the same time, you should feel bad if a 1Mhz 6502 provides a considerably more reliable experience than your game on a modern x86. A certain popular 2D shooter series made by an ex-Taito arcade game programmer uses a bytecode DSL for its intricate bullet patterns for this reason. It was probably an easier decision to make when the series started in the late 90s, but today it lets the author be productive without adding wildly variable latency into the mix that would kill the gameplay. People should not forget that running smoothly even on poor hardware is a real feature. Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. If you make the only new games/apps/whatever that run well on these computers, you have a captive audience. At the same time, I think you could extract 99% of the performance benefits of the bytecode approach if your language had a well-defined heapless, stackless "tasklet/microthread" subset that centered around mutating existing objects and making certain limited kinds of allocations (allocating from a memory pool and manually "freeing" by marking the object as unused later). Knowing that a piece of code will never generate garbage and that a garbage collection cycle will never happen during its execution makes a huge difference.

In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?

by anon4 13y ago

In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?

deluvas 13y ago

Can confirm. This is by far the most ideal option available.

kelvin0 13y ago
I used to work as a programmer in a game company shipping on consoles+PC. The first time we embedded a scripting language in our engine to be used by the level designer's they surprised the whole team with their new found 'toy'. This was great and lessened the burden on programmers. Fast forward to first milestone (everyone crunching) and the milestone was delayed ... The level designers (not being programmers) had introduced a new category of bugs. Compound that to that fact that this script language had a very very primitive debugger ... hell ...
- namuol 13y ago
  I get the feeling that "crunching" is to blame for the bugs a lot more than the engine's newly-integrated scripting language.
  - kelvin0 13y ago
    I didn't imply the scripting engine was to blame. It's unchecked use and the lack of tools for debugging it were mostly to blame ... of course crunching amplified all these problems
- sitkack 13y ago
  The affordances of debugging are almost more important than the language.

adamnemecek 13y ago

If nothing else, if you want to learn. If there was an article about building a hobby OS would you respond '''In what situation would "just use linux/freebsd/etc." not be the appropriate solution to this problem?'''?

anonymoushn 13y ago
If the article about building a hobby OS was on a blog about making actual useful software, and framed building an OS as a reasonable subproblem of making actual useful software, I would expect lots of people to reply like that.
- adamnemecek 13y ago
  The blog is specifically about patterns used in game development not about game development per se. So it's about the journey, not about the destination.
namuol 13y ago
But the site isn't "Programming Language Patterns" -- it's "Game Programming Patterns".
- adamnemecek 13y ago
  Correct and one of the patterns is embedding a language. Maybe lua/js does not fit your criteria for whatever reason so it might be a good idea to know how to roll your own language.
  - sitkack 13y ago
    More importantly, that you understand how the underlying language runtimes work and their call/data structure models. Most of us will still embed an existing system.
  - eropple 13y ago
    I am beyond very confident that the solution set containing embedding Python, JavaScript, AngelScript, and Lua covers just about everything in the problem set a game programmer reading that book is going to encounter. And if it doesn't, it's not going to be improved by rolling your own.

eropple 13y ago

Disappearing up your own backside to implement something like this is a time-honored indie game development tradition. (I should know, I've certainly killed enough projects by doing it.)

xjh 13y ago

Security. When you want to run untrusted modding code. It's hard to sandbox python or lua and block I/O and all system calls. 1 mistake and player computers are compromised. Even with JS in browser you can't just eval(), you need sandboxing like https://code.google.com/p/google-caja/ https://code.google.com/p/google-caja/ or https://github.com/jterrace/js.js/ https://github.com/jterrace/js.js/ (200 times slower than js).

ANTSANTS 13y ago

You saw them a lot in old games (the kind likely to be written in assembly), because not even C, let alone a general-purpose scripting language, was acceptable for performance reasons for quite some time, yet there has always been a need for greater abstraction and expressive power. Look at any Japanese RPG of the 80s and 90s, for instance, and there's probably a simple bytecode VM (or state machine, if you prefer) for scripts that move characters around during story sequences, one for displaying text in menus and dialogs, and so on. Look in an arcade shooter, and there's probably one for defining enemy movement patterns, etc. Tiny bytecode DSLs not only boosted expressive power for programmers, they also allowed non-programmers to script behavior. 6502 assembly might be out of reach for non-programmers, but `SETANIM PLAYER1 PLAYER_WALK_TICK; WAIT 20; SETANIM PLAYER1 PLAYER_WALK_TOCK; WAIT 20; LOOP;` is not. If you only have to remember a few simple rules to get the behavior you want, even learning to hand-assemble bytecode is not out of the question for a dedicated professional. Nowadays, you'd probably be better served by embedding a general-purpose dynamic language in most of these scenarios, but hand-rolled bytecode can still win in certain situations that need high performance and/or low latency. Imagine, for instance, one of those fancy "danmaku" shooters with hundreds or even thousands of bullets on screen moving in intricate patterns. You just might want a language more dynamically manipulable than C to script the behavior of those bullets, but using a dynamic language that furiously generates garbage and demands collection pauses for something that must happen 60 frames per second on so many objects is probably going to cause hitches eventually that will get your player killed (in the game, at least). You'll then be subject to a very harsh but valid criticism: "I played games like this on my PlayStation back in the day with no slowdown, this guy must be a crappy programmer if his 2D game stutters on my monster PC." Sure, it's great that you don't need to break out the optimized assembly to do a Breakout clone anymore, but at the same time, you should feel bad if a 1Mhz 6502 provides a considerably more reliable experience than your game on a modern x86. A certain popular 2D shooter series made by an ex-Taito arcade game programmer uses a bytecode DSL for its intricate bullet patterns for this reason. It was probably an easier decision to make when the series started in the late 90s, but today it lets the author be productive without adding wildly variable latency into the mix that would kill the gameplay. People should not forget that running smoothly even on poor hardware is a real feature. Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. If you make the only new games/apps/whatever that run well on these computers, you have a captive audience. At the same time, I think you could extract 99% of the performance benefits of the bytecode approach if your language had a well-defined heapless, stackless "tasklet/microthread" subset that centered around mutating existing objects and making certain limited kinds of allocations (allocating from a memory pool and manually "freeing" by marking the object as unused later). Knowing that a piece of code will never generate garbage and that a garbage collection cycle will never happen during its execution makes a huge difference.