3 ms·

> How many AAA games ship with a fully dynamic language like JS? Every single game that lets you use Lua to write game logic? AIUI, every Elder Scrolls game si

> How many AAA games ship with a fully dynamic language like JS? Every single game that lets you use Lua to write game logic? AIUI, every Elder Scrolls game since Morrowind? The Crash Bandicoot games? The Jax and Daxter games? (The Jax and Daxter games use http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp and the Crash Bandicoot games use its predecessor.) > At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox? Every single game that permits custom levels that can include scripted elements fits this bill. See, though, this is a strawman. Almost every competently designed website is just like a AAA game in that all of the code that that site runs and all of the assets that it loads were explicitly selected by the dev team and tested by its QA team. Moreover, any user-supplied data is carefully handled and constrained so that processing of said data is low-impact and non-disruptive; just like in a AAA game. I also note that you're refusing to engage with folks who call you out on the fact that your argument that "Having to handle a wide array of obscure image formats and potentially invalid XML makes page renders and reflows slow!" is bunk.

angersock 11y ago
I've engaged specifically on the image formats--consider both GIF and XBM, for example, or WebM or whatever else. Do those show up frequently in games? Nope. Games have other things, like DDS and whatnot, but those are actually kind of designed for their use case (storing mipmaps, cubemaps, etc.), and game engine developers have the luxury of saying "We use this blessed format and anything else runs through our tools pipeline first to become this blessed format". Web browsers have no such luck. The XML/HTML stuff I mentioned elsewhere is still the same: it's not just simple missing character stuff, it's dealing with old pages that are semantically (not syntactically) malformed and still rendering them properly. See also quirks mode. By contrast, game engines have level and script formats that they support, with simpler document models, and they get to deprecate things whenever it suits the developers. As for scripting, just look at some docs for the Morrowing stuff you bring up: http://www.quicenter.com/morrowind/files/Morrowind_Scripting_for_Dummies_8.pdf http://www.quicenter.com/morrowind/files/Morrowind_Scripting.... That's hardly on the same class of utility as Javascript--it's basically a procedural wrapper for stepping through basic scripted sequences. And that's fine--it's built to do that and only that. Every single game that permits custom levels that can include scripted elements fits this bill. "Scripted elements" is very, very different from, say, loading an arbitrary IDE into the browser: http://repl.it/languages http://repl.it/languages On the average, most game scripting languages don't support running Ruby, Python, or Erlang interpreters.
- banachtarski 11y ago
  Do you actually think it'd be hard to put GIF and XBM support in a commercial engine? I really wish you would stop commenting, and I also really wish I could ignore you, but given your last of experience, I'd appreciate it if you stopped talking out of your depth. I'm not sure your last point makes sense to me. I can't run Ruby, Python, or Erlang in a web browser either.
  - angersock 11y ago
    but given your last of experience s/last/lack So, other than the annoyance of actual handling animating the GIF, I don't think that adding the image formats to a commercial engine would be that hard. Hell, I'd just link in FreeImage and be done with it. The point, though, is that a web browser pretty much has to support that, whereas a game engine doesn't. For any particular feature X that a browser has and an engine doesn't, sure, you could absolutely add that feature to the engine. Or just embed Awesomium and have a browser in your engine. Doing so, though, is more of "anything you can do we can do" argument instead of the issue at hand of "browsers are required to be more complicated than engines". To explain my last point: both Python and Ruby there are available in interactive REPLs inside the browser, implemented in JS: http://www.repl.it/languages/Ruby http://www.repl.it/languages/Ruby http://www.repl.it/languages/Python3 http://www.repl.it/languages/Python3 Erlang has also been implemented in Javscript: http://svahne.github.io/browserl/ http://svahne.github.io/browserl/ The thing we keep disagreeing on is the basic premise that browsers are more complex than engines because they do more stuff, albeit less efficiently. Game engines, especially commercial ones like Unity or Source or whatever, are very nifty feats of engineering. I'm not disputing that. However, they aren't specified, they aren't standards conformant, they don't really have legacy stuff they have to put up with, they don't have security concerns in the same way browsers do, etc. If you want to keep claiming that engines are more complicated than browsers, that's fine, but realize that that's a position far from settled. You have yet to, for example, answer any of the points about how much more complicated the operating and compliance environment of a browser codebase is.
    - disusered 11y ago

angersock 11y ago

I've engaged specifically on the image formats--consider both GIF and XBM, for example, or WebM or whatever else. Do those show up frequently in games? Nope. Games have other things, like DDS and whatnot, but those are actually kind of designed for their use case (storing mipmaps, cubemaps, etc.), and game engine developers have the luxury of saying "We use this blessed format and anything else runs through our tools pipeline first to become this blessed format". Web browsers have no such luck. The XML/HTML stuff I mentioned elsewhere is still the same: it's not just simple missing character stuff, it's dealing with old pages that are semantically (not syntactically) malformed and still rendering them properly. See also quirks mode. By contrast, game engines have level and script formats that they support, with simpler document models, and they get to deprecate things whenever it suits the developers. As for scripting, just look at some docs for the Morrowing stuff you bring up: http://www.quicenter.com/morrowind/files/Morrowind_Scripting_for_Dummies_8.pdf http://www.quicenter.com/morrowind/files/Morrowind_Scripting.... That's hardly on the same class of utility as Javascript--it's basically a procedural wrapper for stepping through basic scripted sequences. And that's fine--it's built to do that and only that. Every single game that permits custom levels that can include scripted elements fits this bill. "Scripted elements" is very, very different from, say, loading an arbitrary IDE into the browser: http://repl.it/languages http://repl.it/languages On the average, most game scripting languages don't support running Ruby, Python, or Erlang interpreters.

banachtarski 11y ago
Do you actually think it'd be hard to put GIF and XBM support in a commercial engine? I really wish you would stop commenting, and I also really wish I could ignore you, but given your last of experience, I'd appreciate it if you stopped talking out of your depth. I'm not sure your last point makes sense to me. I can't run Ruby, Python, or Erlang in a web browser either.
- angersock 11y ago
  but given your last of experience s/last/lack So, other than the annoyance of actual handling animating the GIF, I don't think that adding the image formats to a commercial engine would be that hard. Hell, I'd just link in FreeImage and be done with it. The point, though, is that a web browser pretty much has to support that, whereas a game engine doesn't. For any particular feature X that a browser has and an engine doesn't, sure, you could absolutely add that feature to the engine. Or just embed Awesomium and have a browser in your engine. Doing so, though, is more of "anything you can do we can do" argument instead of the issue at hand of "browsers are required to be more complicated than engines". To explain my last point: both Python and Ruby there are available in interactive REPLs inside the browser, implemented in JS: http://www.repl.it/languages/Ruby http://www.repl.it/languages/Ruby http://www.repl.it/languages/Python3 http://www.repl.it/languages/Python3 Erlang has also been implemented in Javscript: http://svahne.github.io/browserl/ http://svahne.github.io/browserl/ The thing we keep disagreeing on is the basic premise that browsers are more complex than engines because they do more stuff, albeit less efficiently. Game engines, especially commercial ones like Unity or Source or whatever, are very nifty feats of engineering. I'm not disputing that. However, they aren't specified, they aren't standards conformant, they don't really have legacy stuff they have to put up with, they don't have security concerns in the same way browsers do, etc. If you want to keep claiming that engines are more complicated than browsers, that's fine, but realize that that's a position far from settled. You have yet to, for example, answer any of the points about how much more complicated the operating and compliance environment of a browser codebase is.
  - disusered 11y ago