Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×

Is JavaScript Ready For Creating Quality Games? 165

kumpetan writes "After seeing so many games built with JavaScript, and considering the applications it powers and the use of Ajax, it seems like web developers are now in the game development pot. It is getting easier and more popular with libraries like jQuery, MooTools, Prototype, etc. There are even libraries like Game JS, GameQuery or JavaScript GameLib, specifically for this purpose. So, will we start to see more ambitious game projects arise using these tools?"
This discussion has been archived. No new comments can be posted.

Is JavaScript Ready For Creating Quality Games?

Comments Filter:
  • I always thought the break out games written in java script were good quality games and they been around for years...
    • Re: (Score:3, Interesting)

      by AKAImBatman ( 238306 ) *

      Like this [internet.com]? Breakout is a fairly simple game that requires only minimal animation. That makes it relatively easy to program. That doesn't mean it can't be done better. The breakout example I linked to it pretty choppy once you slow it down to a reasonable speed.

      I wrote a DHTML version of Pong a while back that is far superior. Here's a link. [dnsalias.com] The underlying architecture was very primitive when I wrote it, not having features like the Canvas tag available. And yet it is one of the better Pong variations on the

    • Re: (Score:3, Interesting)

      Another great one is DHTML Lemmings [elizium.nu]

  • java != javascript (Score:4, Informative)

    by QuantumG ( 50515 ) * <qg@biodome.org> on Wednesday December 17, 2008 @04:06AM (#26142775) Homepage Journal

    javascript is more like scheme with a C syntax (the one and only syntax, all hail!)

    http://www.quantumg.net/tetris.php [quantumg.net]

    Enjoy.

  • Comment removed based on user account deletion
  • Easier? (Score:5, Insightful)

    by Psychotria ( 953670 ) on Wednesday December 17, 2008 @04:25AM (#26142859)

    It is getting easier and more popular with libraries like jQuery, MooTools, Prototype, etc

    What does "easiness" (of programming) have to do with the end quality of the game? It could probably be argued that "easiness" (fancy API's etc) actually reduce the quality of games by giving tools to people who do not know how to wield them properly. This is obviously not true for all games; there are simple games that can be adequately programmed in lots of languages. Addictive, puzzle-like, entertaining games. Then there are other games that push the envelope of what is possible. Pushing the envelope does not make a good game though so I digress.

    To cut a long story short I don't think the availability of libraries etc to do the grunt work of games will improves things. In fact, I think it may result in an influx of poorly programmed/poorly thought-out games written by people who know enough to program a web page or move a LOGO turtle. It may of course be great for prototyping.

    Note to QuantumG: Exclude your tetris implementation from the above comments. Nice work.

    • Re:Easier? (Score:4, Interesting)

      by Xest ( 935314 ) on Wednesday December 17, 2008 @04:40AM (#26142921)

      It's because most game developers wont want to pratt about for weeks trying to get the core Javascript stuff done, they'll want to write games.

      The availability of these libraries mean they can do that.

      There's the argument that developers always used to have to write their own driver layer and such in the DOS days and then build a graphics engine on top of that so it's not like game developers didn't used to have this barrier and yet still did well. The problem with that argument is back then, everyone had to do that, nowadays people could just go build something with Flash or just do a non-web game with XNA or something instead.

      The importance of good and easy to use libraries means Javascript has a more level playing field with other technologies that currently attract game developers.

      Messing around developing the underlying APIs, framework and such detracts from the important part of developing games- developing the game itself. The more time that can be spent actually developing games, the more potential there is for the games to be better because more time can be spent on the actual gameplay.

      • Re: (Score:3, Interesting)

        by Psychotria ( 953670 )
        Well, I agree with most of what you say. However, judging by the quality of several recent games that I presume were written in C++ using frameworks that I assume were also written using C, C++ or (parts) ASM, I can't assert that I believe that the framework being available to JS developers would have improved the situation. The guys doing stuff in c/c++/asm are not doing everything themselves... they use lots of libraries. What makes you think that the same libraries being made available to JS programmers
        • Re: (Score:3, Interesting)

          by Xest ( 935314 )

          I don't think we'll ever eliminate bad games on some specific platform no matter how easy we make it to make games for that platform.

          What we will see is an overall increase in games, and with that an increase in good games. It may be that we only get 1 good game for every 100 crap games, but I don't see that as a problem because people will play the good games and ignore the crap ones- as long as there are more good ones out there than that's what we want. Easy to use libraries allow for that, they allow 10

      • Xest, I actually agree with you mostly by the way. I just don't agree that "easiness" or "availability" is a great metric.
      • While that's a good argument, those libraries are often complex, and not optimised for what you want to do. Function calling in JavaScript is more expensive than in other languages as well.

    • by Yvanhoe ( 564877 )
      A good game designer need one less person in the team : the javascript specialist. It gives both good and bad designers occasions to create games.

      I think the most obvious ease brought by AJAX and browsers is not cited : it makes multi-player games and online content easier to do, it abstracts completely the network protocols. Now, serving a thousand AJAX request is not the same as serving a thousand UDP socket connections (the former uses more resources) but I think that this could create a new niche of
    • I don't know about you, but I'm pretty sure modern games are much better than those written with punch cards...
    • What does "easiness" (of programming) have to do with the end quality of the game?

      It's not so much "easiness" as "speed", which is crucial.

      If you have two programmers instead of four, your game is cheaper to make.

      If you have four programmers, and your competitor also has four, if you choose something "easier", you'll get to market faster than them.

      It could probably be argued that "easiness" (fancy API's etc) actually reduce the quality of games by giving tools to people who do not know how to wield them properly.

      Anyone can find a way to abuse any tool. I would argue that the cleaner and easier the language, the more readable the code, and the easier it is to find out who those people are.

      Contrast this with something like, say, Java or C, and someone co

    • by yusing ( 216625 )

      "What does "easiness" (of programming) have to do with the end quality of the game?"

      Not a programmer?

      If you have to spend weeks doing the basic, grunty underlying stuff (with assembler, let's say), that's less time you have to spend on quality interface, graphics, sound, innovation, vision, finesse.

      GREAT languages let you do a lot with a little.

  • No. (Score:2, Insightful)

    by SharpFang ( 651121 )

    Matter of performance, not language capabilities.
    Writing games in JS is rather easy, rather pleasant, rather fast. It's a nice language for the programmer, due to very flexible structure (override built-in methods? yay!) and has some great development tools (Firebug), and it's a nice language for the user, because everyone has a web browser, no installation required.

    It's not nice for the machine. First, it's an interpreter. Second, due to this very extreme flexibility it won't ever be very efficient. It's s

    • First, it's an interpreter.

      Actually, it's just-in-time compiled and run in a VM, on modern browsers.

      A language cannot, by itself, be interpreted or compiled -- that's a property of the implementation. It is, in fact, possible to have interpreted C.

      Second, due to this very extreme flexibility it won't ever be very efficient.

      Take a look at some of the recent work done on Javascript engines, particularly in Chrome. I wouldn't be surprised if it got at least as fast as Python or Java.

      It's sandboxed, meaning it can't run natively at full speed, every operation must be scrutinized security-wise.

      Actually, no. I'm fairly sure modern implementations don't do this, and I know for a fact that it's possible to sandbox something w

      • VM = interpreter. No matter how much marketing people may want to convince you otherwise. If it's not native code, it's not run by native CPU, but by a virtual machine, it means it's interpreted.

        Guess why people don't write quality games in Python and Java.

        UNIX is an OS, running on bare hardware. It introduces a serious performance impact over running the app on bare hardware, a'la DOS. Javascript is embedded inside a browser which acts as OS for it. OS inside OS. Extra abstraction layers. Suddenly the slow

        • "VM = interpreter. No matter how much marketing people may want to convince you otherwise. If it's not native code, it's not run by native CPU, but by a virtual machine, it means it's interpreted." Nonsense. A just-in-time compiler compiles the bytecode to native code at runtime. Claiming this is "not native code" is BS.
        • VM = interpreter. No matter how much marketing people may want to convince you otherwise.

          Sigh... [wikipedia.org]

          If it's not native code, it's not run by native CPU

          And what do you think happens to your C source? It's not native code, it's a bunch of ASCII.

          It then produces native code -- just like a VM does. The only difference is when this happens.

          Guess why people don't write quality games in Python and Java.

          Because they don't know better?

          Most games do, in fact, implement some sort of scripting language to implement AI, game logic, etc. The smarter ones use an existing language, rather than rolling their own. WoW uses Lua. Civ4 uses Python.

          As for virtualization, try virtualizing a different architecture than your native, say running a virtual MIPS machine under an x86 system.

          I'll have to find you a citation later, but from what I understand, there was onc

          • "That's not a flaw of Javascript, it is a lack of an API. I see no reason why a vblank couldn't trigger a Javascript event."

            Heh, and that's what shows you're just a newbie.

            I see. File a bug in bugzilla.mozilla.org "Javascript needs a vblank trigger". If it isn't RESOLVED WONTFIX in first week, it will stay unresolved for the next eternity and some. The reason is not because it can't be done, it's because nobody will do it. You're confusing theory with reality. Try getting this feature in Explorer, talk with

  • Yes. See Flash. (Score:3, Insightful)

    by naz404 ( 1282810 ) on Wednesday December 17, 2008 @04:42AM (#26142925) Homepage

    it seems like web developers are now in the game development pot

    Flash was the realm of web designers/web developers and is now one of the most widespread game development platforms.

    Moreover, Flash's scripting language, Actionscript [wikipedia.org] is based on ECMAScript [wikipedia.org] which is in turn based on JavaScript [wikipedia.org], so Flash game developers have in fact been creating games in Javascript for some time now.

    Flash Actionscript = JavaScript (although Actionscript 3.0 now resembles Java more)

    So yes, Javascript is not just ready, but has in fact been one of the de facto languages for creating quality (fun and addicting!) (Flash) games in the past few years.

  • short answer: yes (Score:5, Insightful)

    by El_Muerte_TDS ( 592157 ) on Wednesday December 17, 2008 @05:07AM (#26143037) Homepage

    There is no reason why you can't use JavaScript as the script engine for your game engine. Just like you could use lua or python.

    If the question is if JavaScript + WebBrowser is ready for games? Yes, has been for quite some time. With improving javascript interpreter speed and better webbrowser functionality (i.e. "canvas") element you can even create graphic intensive games. But javascript based sudoku, tetris, sokoban, etc. games have been possible for over 10 years.

  • As you say it's getting easier and more popular, and bandwidth is getting better, but I can't for the life of me see why people already writing browser games would try to use that to write *better* browser games... can you? You'd better ask slashdot!

  • Quality? Games? (Score:5, Insightful)

    by sweet_petunias_full_ ( 1091547 ) on Wednesday December 17, 2008 @05:36AM (#26143165)

    How about we start with some quality... webpages?

    You know, the type that worked reliably with just about any browser, the way it used to in Web 1.0 before web standards became a marketshare battleground?

    Lately, websites have become picky about which browser you use for just this reason. The AJAX monster they're trying to get everyone to use is just too unwieldy and expensive to maintain in terms of programmer time if they actually have to support all of the browser versions. The outstanding bug count is too much even for some of the big players in this space, I dare say.

    I'm sorry, but I'm just not that optimistic that games will be very well supported across browser versions to think that it will result in "quality". Instead I have a sneaky suspicion that someone will try to use some slick game that works on a couple of browsers to pull marketshare over to its cloud, but all the while dictating to people which browser they must waste their time upgrading in order to participate in the hypefest. Then, a few browser versions later, the game won't work anymore.

    • by Nicolas MONNET ( 4727 ) <nicoaltiva@gm a i l.com> on Wednesday December 17, 2008 @05:53AM (#26143223) Journal

      HTML+CSS (current versions) is inadequate for most of what it's used for (user interfaces), as opposed to what it's meant for (documents). Add to the mix the monster that is IE, and you need javascript to make it bearable.

      • by spinkham ( 56603 )

        Specifically, IE 6 needs to die. IE 7 is tolerable but annoying, but IE 6 is really holding the web back.

        Push up the web [pushuptheweb.com] has a nifty little mostly unobtrusive widget you can put on your web page to gently encourage your users to upgrade. The web designer in me likes the idea, but the security person in me doesn't want to train people to click on "upgrade your browser popups. Still, it's an interesting idea.

    • Re: (Score:3, Insightful)

      by sakdoctor ( 1087155 )

      You must have been on different internet tubes from me.
      For me "Web 1.0" was riddled with badly written copy/paste JavaScript, IE only sites, punchable monkeys, doubleclick cookies, dancing hamster gifs and pop-ups that you couldn't block.

      How can the vast progress we've made not make you optimistic?

      • It depends where you draw the Web 1.0 line. Once the browser wars were in full swing, then of course sites ended up written for IE. Before that, the web was designed to be a collaborative research tool and deep linking was not only allowed by the "content owners" but expected. You were supposed to surf from site to site following your interests. Now each website is supposed to be its own little fiefdom where jumping offsite is discouraged. Rather than linking to the vast resources offsite, the typical

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      Part of the reason people use libraries like Dojo, Mootools, etc is because they solve a lot of the cross browser woes. I've been developing in dojo for over 2 years now and I rarely have browser compatibility problems, except with older IE which I'm lucky not to support.

      I do think certain goals would be idiotic to even attempt outside of the Canvas element, and if you are working in the DOM, you most likely would like transparent PNG support because most games that aren't text based have some form of image

      • Are we talking about the same thing? The subject title is "Is JavaScript Ready For Creating Quality Games?" Now, I concede, that the subject or the summary doesn't really contradict what you're saying but what annoys me is you're assuming that it's talking about stupid web-based games (I may be wrong. I am just assuming from your comments on xor and png and browsers and stuff...)

        Assuming for a second I am misunderstanding. I think that web-based games are about 20 years behind the current technology. XOR? F

    • the way it used to in Web 1.0

      This website is best viewed in Netscape Navigator 4.0

    • Bananas? Oranges?

      How about we start with some quality... apples?

  • Define "ready" (Score:5, Interesting)

    by Kjella ( 173770 ) on Wednesday December 17, 2008 @06:38AM (#26143383) Homepage

    Q: Is JavaScript Ready For Creating Quality Games?

    A: No, but it's happening anyway.

    People build quality games out of the wierdest languages, for example Transport Tycoon Deluxe was built in assembler around 1995. I have no doubt you can write quality games in javascript. I don't think it's the easiest or best way, but it's not really my concern. If they cna make it happen, more power to them.

  • Why? (Score:3, Informative)

    by TheSpoom ( 715771 ) * <slashdot&uberm00,net> on Wednesday December 17, 2008 @07:06AM (#26143497) Homepage Journal

    Hasn't anyone heard of "the right tool for the right job"?

    Sure, you might be able to force JavaScript into displaying graphics and sound with some crazy tricks or frameworks, but why bother when you can do the same thing much easier and with many fewer browser or speed issues in Flash?

    • Have you checked which language flash is scripted with these days?

      With the new javscript revision, the main difference will be the graphics library.
      That is admittedly important, but canvas+dom will enable quite a few nice things.

      • "Will" being the key word there. And of course it's scripted quite a lot with Javascript, since Javascript is primarily a scripting language :^P

    • but why bother when you can do the same thing much easier and with many fewer browser or speed issues in Flash?

      Because not every budding game developer owns a copy of Flash CS3, nor (I presume) is TheSpoom ready to donate thousands of copies of Adobe software. To write JavaScript, you don't need anything more than the Notepad that came on your existing PC.

  • It shouldn't be that difficult to make a JavaScript version of ADVENT ("Colossal Cave Adventure"). An Inform source to JS compiler... that might be harder, but not impossible.
    • I think you mean Infocom. But what you're talking about is not far from the truth. Zork et al ran (run) on a virtual machine not unlike Java (the Z-machine). This was an amazing advantage back in the day. Infocom "merely" had to port their z-machine to run on different machines and their games would work. If an architecture had a z-machine implementation Infocom could release their title across multiple platforms.
    • and use the FORTRAN source to port to JS. Sure, it's like crayons and a big chief tablet, but IIRC that's what Colossal Cave was first coded in. I know I ran across a FTN version in 1979.
  • Hmm... (Score:2, Informative)

    by Canazza ( 1428553 )
    The main problem - as far as I can see - with Javascript based programming is that by using a plugin, such as Firebug - one can effectivly go into Debug mode, set breakpoints, changing variables and all sorts of stuff in the client-side Javascript, opening up a whole world of possibilities for hacking, so unless you want to handle changing score, state or whatever server-side (which would require a rather good server to handle that) you're going to be left with a game where you can never be sure that the ou
  • by Jekler ( 626699 ) on Wednesday December 17, 2008 @10:08AM (#26144541)
    I find it interesting that we're still figuring out how to implement games on a 32/64-bit 2+ gigahertz computer that barely rival games we previously implemented on an 8-bit 2 megahertz platform (NES). I would have imagined that even in a worst case scenario, emulation of an NES system in JavaScript would be trivial just by throwing more processor cycles at it, but the games people are creating in ActionScript and JavaScript are closer to Atari 2600 games than anything else. The games that are more complex tax a modern computer as much as the latest 3D games.
    • but the games people are creating in ActionScript and JavaScript are closer to Atari 2600 games than [NES games]

      Video games in the Atari 2600 era were often developed entirely by one person. NES games might have had a team of three to twenty people.

  • I'm always happy to see stories like this go by, because it gives me a chance to shamelessly plug my own webgame. ;)

    In this case, PseudoQuest is a great example of some of the crazy stuff one can do when combining existing libraries (Prototype, Scriptaculous) with custom code.

    Interesting bits relevant to the JS portion of this article include: realtime PvP combat, a spiffy windowing system, drag/drop quickbar, in-game chat, easy-to-use player housing customization interface (drag/drop), and - of course - a

  • In related stories:
    Is bash ready for creating quality databases?
    Are homing pigeons ready for creating quality mobile phone networks?
    Is brainfuck ready for creating anything (quality)?
  • by merreborn ( 853723 ) on Wednesday December 17, 2008 @04:43PM (#26150557) Journal

    Even as a huge fan of AJAX web applications and javascript libraries, I don't understand why'd you'd pick javscript over flash for developing anything any more complex than tetris.

    Anything javascript can do, flash can do better and faster. And the number of flash-capable browsers out there is almost as high as the number of javascript-capable browsers. Flash gives you far, far better image handling capabilities, and more.

    Other than the "haha, I did X on a platform that isn't really meant for it" factor, why would any serious game developer choose the javascript-in-a-browser platform?

    • Another glaring problem (at least right now) with JavaScript is the lack of sound support. I wrote a little game [primateapplications.com] in JavaScript, but I had to resort to Flash to handle the sounds. It was a fun experience, since it was the first game I've ever written. I was also trying to push my limits in JavaScript at the time, so that probably added to the intrigue of it all.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Working...