14 ms·

With an interpreter you sort of get an automatic sandbox because your badly implemented user language is handled by a buch of switch-case or if-else statements.

by delinka 15y ago

With an interpreter you sort of get an automatic sandbox because your badly implemented user language is handled by a buch of switch-case or if-else statements. Not literally, but the 'user language' is entirely limited within the interpreter and doesn't mingle with the real game code unless you code up that specific interface. Enter compiled code. Now we have the opportunity to run unknown binary code right within the game's address space. Bad News in many ways. To get the Happy Medium (compile code within the game engine, load and run the resulting executable safely) requires implementing operating system concepts. It's a Big Job. This leads my thoughts on a slight tangent: why isn't there a Super Awesome Open Source Game Engine that's the heart of all 3D games? SAOSGE could even provide the extensibility framework (compiling, loading), ready for you to expose parts of your games to player programmers.

nostrademons 15y ago
If you control the compiler and the language is memory-safe, you get the same guarantees with JIT-compilation that you do with interpretation. All execution runs within the memory boundaries specifically allocated by the runtime system, and any other interaction with the machine must go through the runtime libraries, where you can perform any checks you want.
- prodigal_erik 15y ago
  I don't see this kind of sandboxing as likely to help. Whether your scripting language is compiled or interpreted, if any accessible portion of your system is written in a memory-unsafe language like C, that is where crackers will find the most damaging exploits. E.g., http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit http://stackoverflow.com/questions/381171/help-me-understand... which attacks a native XML toolset (some "data binding" IE feature I don't understand) without breaking any javascript rules.
krakensden 15y ago
> why isn't there a Super Awesome Open Source Game Engine that's the heart of all 3D games? Unreal is the closest thing, but there's still lots of new/strange/innovative stuff going on in rendering, which means that lots of bits are hard to reuse. Rage, for instance, has a pretty nifty virtual-memory for textures scheme, which no one else has really done.
- teamonkey 15y ago
  Also, licencing costs. Why pay a rival company money when you can create your own engine in-house? Unreal has various licencing agreements, from (probably) 8 figures for an unlimited license down to 99$ + 25% of any revenue above $50k per title (and anywhere in between). In particular I'm thinking of Criterion's Renderware engine. Originally funded by Canon it was very popular. Then Criterion was sold to EA and everyone dropped it.
  - jacques_chester 15y ago
    > Also, licencing costs. Why pay a rival company money when you can create your own engine in-house? Because developing a AAA engine from scratch is a multi-million dollar enterprise at this point. You actually need to develop your system faster than the leading edge so you can catch up. That's an expensive ask. Most companies arrive, after 2-5 years, with something that was as good as UDK or idTech n was ... years ago. Paying the $500,000 or x% of revenues is often the fastest, cheapest way to get your game out.

by delinka 15y ago

nostrademons 15y ago

If you control the compiler and the language is memory-safe, you get the same guarantees with JIT-compilation that you do with interpretation. All execution runs within the memory boundaries specifically allocated by the runtime system, and any other interaction with the machine must go through the runtime libraries, where you can perform any checks you want.

prodigal_erik 15y ago
I don't see this kind of sandboxing as likely to help. Whether your scripting language is compiled or interpreted, if any accessible portion of your system is written in a memory-unsafe language like C, that is where crackers will find the most damaging exploits. E.g., http://stackoverflow.com/questions/381171/help-me-understand-this-javascript-exploit http://stackoverflow.com/questions/381171/help-me-understand... which attacks a native XML toolset (some "data binding" IE feature I don't understand) without breaking any javascript rules.

krakensden 15y ago

> why isn't there a Super Awesome Open Source Game Engine that's the heart of all 3D games? Unreal is the closest thing, but there's still lots of new/strange/innovative stuff going on in rendering, which means that lots of bits are hard to reuse. Rage, for instance, has a pretty nifty virtual-memory for textures scheme, which no one else has really done.

teamonkey 15y ago
Also, licencing costs. Why pay a rival company money when you can create your own engine in-house? Unreal has various licencing agreements, from (probably) 8 figures for an unlimited license down to 99$ + 25% of any revenue above $50k per title (and anywhere in between). In particular I'm thinking of Criterion's Renderware engine. Originally funded by Canon it was very popular. Then Criterion was sold to EA and everyone dropped it.
- jacques_chester 15y ago
  > Also, licencing costs. Why pay a rival company money when you can create your own engine in-house? Because developing a AAA engine from scratch is a multi-million dollar enterprise at this point. You actually need to develop your system faster than the leading edge so you can catch up. That's an expensive ask. Most companies arrive, after 2-5 years, with something that was as good as UDK or idTech n was ... years ago. Paying the $500,000 or x% of revenues is often the fastest, cheapest way to get your game out.