Slashdot Mirror
Is JavaScript Ready For Creating Quality Games?
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?"
javascript is more like scheme with a C syntax (the one and only syntax, all hail!)
http://www.quantumg.net/tetris.php
Enjoy.
How we know is more important than what we know.
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.
I very seriously doubt the designers of Java would have envisioned someone making a couple of FPS out of their creation.
Java was originally designed to be a multi-media platform for televisions. It's 2d and 3d APIs are, although simple, pretty good. Actual functionality was bolted on later (see ya Vector!).
There aint no pancake so thin it doesn't have two sides.
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 is based on ECMAScript which is in turn based on JavaScript, 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.
http://www.object404.com
I'll be the first to admit that my knowledge of flash-based games is quite limited; but just because java script can do most of what flash can do doesn't mean that it's ready to do quality games.
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!
I assumed the problem with using javascript was the inability to manipulate images at the bit level with relative ease. People have made some successful projects using the canvas object to handle their 'blitting,' but do all browsers even support it (shifting eyes at IE)?
Another (rather unrelated) issue would be the lack of a mature way to communicate between server and client - cheaply that is. If someone is going to make their own browser based graphic mud, that means they are going to have to write their own comet app. Not a lot of ppl are willing to write their own server. You can't really control how you want your game to do socked based communication.
But the main issue is the lack of ability to be able to program close enough to the 'metal.' That means no native support to take advantage of things like the video card for 3D, or sound card or what have you. Nor the fact that you can't simply plug in a gamepad controller and just playing your javascript game (at least, not without doing some config work on your gamepad prior).
Most games are (relatively) graphic intensive, and the people that code them want to have the freedom to be able to access the power of the computer that is running them. With different browsers having different javascript engines, you're going to end up with very inconsistent results when playing a game on IE compared to FF compared to Safari compared to Chrome. *shrug* I don't know, it just seems too much of a pain to take into account all those factors when trying to come up with consistent gaming experiences, at least with flash or java you can (somewhat) expect to have a common platform to develop on, considering the trouble people are having with cross-browser compatability when simply making web pages. (just being snarky) :-P
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.
You can't send a takedown notice to an already printed newspaper.
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.
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.
Live today, because you never know what tomorrow brings
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?
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
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 outcome is a result of the game logic and not someone's poking around.
Think about a high-score table for example, I could easilly modify whatever variable holds my score and then end the game with a massive score.
Javascript games will be a novelty, no more, I don't see it becoming anything mainstream (definitly not rivialing Flash or Java) mainly because anything sensitive will be wide open to hacks and work arounds.
It pays to be obvious, especially if you have a reputation for being subtle.
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.
Like this? 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. 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 net. (If you don't mind my saying so.) The reason for its superiority is simple: 95% of people who write a game don't understand what makes games interesting.
In the case of Pong, nearly all variations are too slow and the AI consists of stupidly following the ball. Well, that's not very fun. The ball should bounce fairly quickly and the AI should respond like a human. How do you make AI respond like a human, though? Simple: It should not act robotic and it should make mistakes.
The AI for Pong stops moving the paddle when the ball is traveling in the opposite direction. This helps remove the "robot" feel of the opponent. Next, the computer is limited to the same rate of movement as the player. This gives the player a chance to sneak one by the computer. (Since the ball is faster than the paddle.) Finally, the AI has a bit of jitter in its algorithm. Rather than moving with the ball, it computes where the ball is expected to be. A random amount of jitter is then added to the computation so that the computer has the possibility of "misjudging" where the ball will actually arrive. By adjusting the jitter, the game can be made to play on easy, normal, or hard. (Use the options menu to set the difficulty. Though for some reason, the menu doesn't work on Chrome. So just be aware of that issue.)
Another game that is rarely done right is Tetris. Take the Jetris game in the "GameJS" link. It's a nice tech demo, but it's a sub-par game. And not because the game is of the "classic" Tetris variety. (My own Tetris game was of the same variety.) It at least gets the coloring right in that each piece is a specific color. (Though adhering to the Tetris standards for coloring would have been an improvement.) That's a good first step. The bigger issue is that the piece selection does not have a very good distribution of pieces. I regularly get three or four of the same piece in a row. That should never happen in a good Tetris game. Programmers need to take steps to ensure that the player will never get more than two of the same piece in a row. The Tetris "Bag" algorithm is a good solution to this that makes the game more fun. Another good trick is to ensure that pieces always arrive in the default rotation.
Anyway, the point of my rant is that the technology is rarely the problem. A good game programmer can make a fun game out of nearly any technology. An inexperienced game programmer with no understanding of what is "fun" can make any technology look like the problem.
Javascript + Nintendo DSi = DSiCade
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)?
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 great one is DHTML Lemmings
There is little work in making Javascript be to SVG what Action Script is to FLASH.
There's still a lot of work. The SWF player is installed on PCs before people buy them, unlike the SVG player. SWF supports audio; SVG does not, and no web browser that I'm aware of supports SMIL.