31–40 of 73 posts
Earlier quoted context omitted.
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 i…
I get the feeling that "crunching" is to blame for the bugs a lot more than the engine's newly-integrated scripting language.
Earlier quoted context omitted.
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.
Hi, I wrote that chapter. I also wrote the AI system for Hatsworth. There is absolutely no way we would have embedded Lua on a DS! What we did do was write a tiny little bytecode VM as described in the chapter. The level editor I wrote[1] let designers author behavior using a little UI. It then compiled that to bytecode. It worked like a charm if I may say so. Unlike a full-featured language VM, we didn't have to dea…
In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?
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) f…
Don't forget low-end mobile devices.
Earlier quoted context omitted.
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.
Hi, I wrote that chapter. I also wrote the AI system for Hatsworth. There is absolutely no way we would have embedded Lua on a DS! What we did do was write a tiny little bytecode VM as described in the chapter. The level editor I wrote[1] let designers author behavior using a little UI. It then compiled that to bytecode. It worked like a charm if I may say so. Unlike a full-featured language VM, we didn't have to dea…
(That said, no-GC AngelScript uses under a megabyte of RAM on ARM; before I switched to libgdx and decided that I could do without supporting the Galaxy Nexus I'd spent a lot of time examining it. It certainly might be tight on the DS, but on any modern system, I think you're probably cool.)
Earlier quoted context omitted.
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) f…
> Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. Don't forget low-end mobile devices.
Earlier quoted context omitted.
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) f…
> Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. Don't forget low-end mobile devices.
I sorta doubt there are many games targeting these devices (and, more particularly, the people who still use these devices in 2014) in the first place, but even fewer which are pushing their headroom so hard that, if they decide they need what amounts to a scripting language, they can't fit one in off-the-rack.
In what situation would "just embed python/lua/js/etc." not be the appropriate solution to this problem?
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) f…
Oh hey, I think you just described asm.js
Earlier quoted context omitted.
> Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. Don't forget low-end mobile devices.
Eh, angry birds runs on Lua. Your point was?
Earlier quoted context omitted.
> Even in 2014, I'm sure there are plenty of people out there still using Pentium 4s and Windows XP. Don't forget low-end mobile devices.
Eh, angry birds runs on Lua. Your point was?