Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Is JavaScript Ready For Creating Quality Games?

Soulskill posted more than 5 years ago | from the pac-man-thinks-so dept.


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?"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


breakout (1)

neo8750 (566137) | more than 5 years ago | (#26142767)

I always thought the break out games written in java script were good quality games and they been around for years...

Re:breakout (2, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#26146285)

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 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 [dnsalias.com] 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 [wikipedia.org] 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 [livemeeting.com] 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.

Actionscript (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26142773)

Since Flash's Actionscript and Javascript are basically identical, almost anything that can be done in one can be done in the other. The real limitation is DOM, which sucks compared to Flash.

The keyword, however, is "quality" (2, Insightful)

RLiegh (247921) | more than 5 years ago | (#26142939)

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.

Re:The keyword, however, is "quality" (4, Insightful)

oliderid (710055) | more than 5 years ago | (#26143151)

Javascript can't. The biggest problem imho is animation and vectors. You can't really use formats like SVG which is poorly supported by most browsers (if not all). So if you plan a 100% javascript+html+css, you have to stick to bitmap sprites and even there, there are some issues (slow, browser compatibility, etc.).

Re:The keyword, however, is "quality" (2, Interesting)

h4rm0ny (722443) | more than 5 years ago | (#26143869)

But SVG *is* XML-based and can be manipulated as a DOM. We're really 2/3rds of the way there in terms of manipulating it with Javascript. And if we get that, all we have to do is prise streaming video away from FLASH, and we're from FLASH at last!

Re:The keyword, however, is "quality" (4, Insightful)

aliquis (678370) | more than 5 years ago | (#26144115)

Safari, Opera and Firefox already have support for embedded videos thru HTML 5. So we're already there.

All I want for christmas is YouTube, DAP- and game-reviewing sites to start using it instead of flash. Probably won't happen until Microsoft has managed to drag their balls out of their ass and manage to pull IE8 out at the same time (and way ..)

If only atleast Google had some balls big enough to say "oh well, YouTube requires a decent browser!", or they could just check with JavaScript if the browser is new enough to have HTML5 video support and fall back on Flash if it's not.

Re:The keyword, however, is "quality" (2, Interesting)

dreemernj (859414) | more than 5 years ago | (#26144505)

Widespread use of the video tag probably won't become too common until there is a specific codec or group of codecs that are specified to go with it.

The tag spec just says it'll load a video, but doesn't specify what kind of video. Safari does quicktime and installed codecs. Firefox and Opera I believe do OGG Vorbis/Theora. If IE added it I would guess they'd do WMV.

The video tag is not done yet. So its not going to get much use.

Re:The keyword, however, is "quality" (2, Interesting)

aliquis (678370) | more than 5 years ago | (#26145349)

I assumed all of them would support whatever codecs you had installed? If Firefox and Opera don't that suck.

I see no problem with using mixed video codecs for the videos as long as every browser support the codecs you have installed. My Quicktime can probably play most stuff anyway, and obviously my VLC/mplayer classic would to if I had ran Windows, or mplayer in BSD or whatever.

Re:The keyword, however, is "quality" (1)

foniksonik (573572) | more than 5 years ago | (#26145917)

Embedded video isn't enough to supplant Flash's video compositing capabilities.... HTML 5 won't let you do a video mix, manipulate the video during playback, add hostpots of interactivity to the video or anything else to do with video other than play it, pause it, ff and rw.

Flash can not be beat by any current technology in this respect (for online distribution) and Silverlight which is the closest is still years behind.

Re:The keyword, however, is "quality" (1)

aliquis (678370) | more than 5 years ago | (#26147529)

I don't want to do anything of that anyway so .. If they really want to add ads I guess they can still add them into the actual video file, or make clickable layers with CSS and javascript and so on.

In fact I don't give a shit about ads and clickable areas in videos, I just want to watch videos.

Re:The keyword, however, is "quality" (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26148583)

I don't know, I think it would still be useful to use SVG. If your users have a choice between downloading your crappy little game, and downloading Firefox, I think Firefox would be the easier pill to swallow.

Then again, I'm thinking like a paranoid admin. I have no idea what typical users would do.

Re:Actionscript (2, Informative)

Achoi77 (669484) | more than 5 years ago | (#26143045)

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

Re:Actionscript (1)

aliquis (678370) | more than 5 years ago | (#26144137)

With all due respect who the fuck cares what IE supports or not? Start using it anyway and eventually people will move away from the inferior product which most people use. If you never give them a reason why would they switch?

"Firefox and Opera has better standards support!"
"But all pages I want to visit already works in IE! So why should I switch?"

Re:Actionscript (1)

6Yankee (597075) | more than 5 years ago | (#26143567)

Yep, it's the DOM access that's been the limiting factor on all my Javascript game experiments - that and function calls. Forced me to get more disciplined about holding onto references rather than looking things up every time, and learn that sometimes inline code is, well, maybe not *better*, but the only way to do the job acceptably.

Re:Actionscript (1)

deniable (76198) | more than 5 years ago | (#26143721)

Basically identical, except one tries to be strongly typed. Trust me, swapping between JS and AS3 isn't as easy as it sounds. That's just the language, the run-time environments are nowhere near identical.

Re:Actionscript (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26148659)

They are not even close to being identical. The syntax is very similar, in the way that JavaScript syntax is similar to C -- but the languages are quite different.

For example: AS is statically-typed, JS isn't. JS is prototypal inheritance, and I assume AS isn't (how could it be that and statically-typed?)

Despite some of the recent efforts to turn javascript into some kind of actionscript, by adding class keywords and the like, they really aren't that similar. While I haven't used actionscript, from what I understand, I'd much rather use Javascript, as a language -- the main difference is that actionscript is running in Flash, which has a lot of attractive properties for game developers.

java != javascript (3, Informative)

QuantumG (50515) | more than 5 years ago | (#26142775)

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

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


Re:java != javascript (2, Insightful)

ChienAndalu (1293930) | more than 5 years ago | (#26143229)

Presses 'down' key on keyboard

Seeing page scrolling down

Is JavaScript Ready For Creating Quality Games? NO

Re:java != javascript (1)

QuantumG (50515) | more than 5 years ago | (#26143295)

The keys are A-D to move, S to rotate, hold X to drop.

This is 100% pure javascript baby.


Think yourself fucking lucky that I even implemented the arrow keys. I sure as hell don't remember doing it.

Re:java != javascript (1)

sgbett (739519) | more than 5 years ago | (#26143953)

why would you build a tetris game that *doesn't* use the cursor keys !?

Re:java != javascript (3, Insightful)

QuantumG (50515) | more than 5 years ago | (#26143963)

Because, for some ungodly reason, everyone still uses keyboards that put the cursor keys on the same side as the mouse. Surfing the web is all about the freakin' mouse.. so making a web game that requires you to take your hand off the mouse is a bit silly.

Re:java != javascript (0)

Anonymous Coward | more than 5 years ago | (#26144019)

in terms of ergonomics, *any* application that encourages its users to take their hand off the mouse is a good application.

Re:java != javascript (1)

sgbett (739519) | more than 5 years ago | (#26144247)

I accept your point. I hadnt considered it because my cursor keys were about 1" from my trackpad!

what are you on about? (1, Funny)

Anonymous Coward | more than 5 years ago | (#26149175)

I'm left-handed, you insensitive clod!

Re:java != javascript (0)

Anonymous Coward | more than 5 years ago | (#26143411)

there's a bug in the game. the pieces rotate even when they don't have room to. they "override" existing blocks.

Re:java != javascript (1)

ruda (128152) | more than 5 years ago | (#26143705)

Javascript is also Turing compliant so anything (computable) is possible, even peace on earth.

Re:java != javascript (1)

0xygen (595606) | more than 5 years ago | (#26144043)

Notice what happens if you rotate an L shaped piece into an already occupied position?

Another great win for JavaScript.

Re:java != javascript (3, Informative)

AKAImBatman (238306) | more than 5 years ago | (#26144149)


Needs work. Here's my version, complete with an adapter for Internet Exploder:

http://java.dnsalias.com/tetris/ie [dnsalias.com]

(Mine is based on the NES version rather than the more modern Tetris versions, so use UP to rotate, DOWN to make it drop faster, LEFT/RIGHT to reposition the piece. If you use IE, click outside the block-drop area to make sure that it has proper focus as I have not finished the adapter.)

While not as pretty, there's also an online multiplayer version written in Javascript here:

http://www.wiicade.com/gameDetail.aspx?gameID=1063 [wiicade.com]

That one is not mine, though the programmer did use my network technology. ;-)

Re:java != javascript (1)

QuantumG (50515) | more than 5 years ago | (#26144253)

I like your version.

Re:java != javascript (1)

AKAImBatman (238306) | more than 5 years ago | (#26144457)

You're too kind. :-)

You can see some videos of a PacMan game I was working on as well as the evolution of the Tetris game here: http://www.youtube.com/profile?user=thewiirocks&view=videos [youtube.com]

I used to have a very pretty Space Invaders game written in 100% DHTML, but I never released it where anyone could see it. If you're curious, shoot me an email sometime and I'll point you to it. While it had sound effects and music, the underlying code was not nearly as good as I could have done. (It was written before I had a really good feel for how bad of an idea innerHTML was.)

Neither of us is as good as the Space Invaders clone in TFA [rebelideas.co.uk], though. That is a marvelous piece of game design right there. Very professional in every way.

There are Java games, so why not JScript? (1)

hairyfeet (841228) | more than 5 years ago | (#26142839)

Since there are already games built on Java like Specforce [wikipedia.org] I don't see why somebody wouldn't use JScript to build a game. And yes, I know there is a big difference between Java and JScript, I am simply pointing out that when Java came out I very seriously doubt the designers of Java would have envisioned someone making a couple of FPS out of their creation.

Re:There are Java games, so why not JScript? (3, Informative)

farnsworth (558449) | more than 5 years ago | (#26142887)

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 [wikipedia.org] 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!).

Re:There are Java games, so why not JScript? (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#26142973)

JScript is Micro$oft's bastardized version of JavaScript, FYI.

Re:There are Java games, so why not JScript? (1)

rav0 (983195) | more than 5 years ago | (#26143471)

Like you say, Java is different to Javascript. Note that Javascript is different again.

Easier? (4, Insightful)

Psychotria (953670) | more than 5 years ago | (#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? (3, Interesting)

Xest (935314) | more than 5 years ago | (#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:Easier? (2, Interesting)

Psychotria (953670) | more than 5 years ago | (#26142961)

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 would improve the situation? Wouldn't it make the situation worse?

Re:Easier? (2, Interesting)

Xest (935314) | more than 5 years ago | (#26143825)

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 100 more crap games to be made, but with it they bring 1 good game and again, that's what we want- more good games.

We've seen this happen before with mobile phone games, with flash games and to an extent we're seeing it now with XBox 360 community games and to a point we're seeing it with the Wii, where many games make use of the new control scheme but most are crap, however it's made worth it by the few that are good.

The problem is if you don't have an easy to use platform for creating games in the first place you wont even get most the crap games, let alone the good ones.

There are exceptions to every rule certainly, someone will always go that extra mile and slug their arse off to make a game on an obscure gaming platform (I'd argue Tribal Trouble did this somewhat with the Java platform) but that in itself will lead to creation of easy to use libraries. Some of Popcap's games and games like Fantastic Contraption (There's always going to be bad developers and bad games, this will always be a problem.

Easier to use libraries wont even increase the amount of good games in relation to the amount of bad games.

What it will do though is open the door for a few good developers/innovators that will produce good stuff. I'm not so fussed about quantity, like you I want quality, but they go hand in hand with this sort of thing to an extent, that to have any quality titles you need some amount of quantity, that is, for every 100 crap titles, you might find 1 good one, but it's that 1 good one I'll bother with and the others that I'll ignore. If we only have a 1 in 100 chance of a Javascript game being good and we only have 20 Javascript games out there then there isn't the greatest of chances that any of them will be any good.

I've noticed the same with XNA community games on the XBox 360, there is so much crap on there, but amongst it all there are a couple of gems and to me, they make it all worthwhile.

We can't ever expect every game for a specific technology to be good, no matter what we do this will never happen, but we certainly can start opening up more platforms to game developers and over time things will improve. We've seen this happen before with Flash games and Mobile phone games, we're seeing it happen now with XNA community games on the 360. For all the flash crap there is out there, we eventually end up with excellent games like Fantastic contraption (fantasticcontraption.com) are a testament to the good games that can exist once the tools are available (although in Popcap's case, they made a lot of the tools).

I've recently even seen some games made on the likes of XNA by people who weren't previously programmers, this in no way means they're incapable of making a good game, some of their ideas are great and the ease of XNA (or even other engines, such as Torque Game Builder) have allowed them to realise those ideas. It's the ease of use of the tools that made these, previously non-programmers, produce better games than the guy who can write a full blown engine + game on top of raw Javascript.

In a way, I'm not even sure that production of massive amount of crap is even a bad thing, after all most this crap is produced by teens experimenting with the tools and these teens maybe your John Carmack's of tommorrow, making sure the tools are available again in this case is surely only a good thing.

I think the fundamental point I'm getting at is this- bad games, released free don't actually hurt anyone, there's no downside to having lots of bad games out there, but there are upsides- such as allowing people to learn to make better games.

Re:Easier? (1)

Psychotria (953670) | more than 5 years ago | (#26142965)

Xest, I actually agree with you mostly by the way. I just don't agree that "easiness" or "availability" is a great metric.

Re:Easier? (1)

BenoitRen (998927) | more than 5 years ago | (#26143369)

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.

Re:Easier? (1)

Yvanhoe (564877) | more than 5 years ago | (#26143337)

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 (non-massive) multi-player online games.

Re:Easier? (0)

Anonymous Coward | more than 5 years ago | (#26146735)

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.

Those would be the same people who would go ahead and *reimplement those same tools extremely poorly*. It's still better!

A great example is any sort of random number generation ;)

Re:Easier? (1)

soniCron88 (870042) | more than 5 years ago | (#26149321)

I don't know about you, but I'm pretty sure modern games are much better than those written with punch cards...

Re:Easier? (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26149417)

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 could simply write sufficiently obfuscated and overly complex code to hide their incompetence -- for example, ObjectWrapper [thedailywtf.com].

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.

And you don't imagine you'll get 10% of those that are worthwhile?

Remember: 90% of everything is crap. That also means: If you stop staring at the crap for a second, you might see the 10% that's actually good.

All I have to say is... (-1)

Anonymous Coward | more than 5 years ago | (#26142899)


No. (1, Insightful)

SharpFang (651121) | more than 5 years ago | (#26142909)

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 sandboxed, meaning it can't run natively at full speed, every operation must be scrutinized security-wise. The rendering uses non-native extensions that lack in efficiency too. It's event-based meaning you shouldn't run a loop at full speed (or the user gets a requester "this page is running slow, should I stop the script?"), you need to create clock events to trigger each iteration. And you get a HUGE pile of compatibility issues.

Of course, if you create a faster computer, the Nature will create programmers writing the usual in slower programming languages.

Re:No. (0)

Anonymous Coward | more than 5 years ago | (#26143427)

I don't think you really understand how Javascript works in a browser.

If you're having to scrutinise every operation, then you've already failed.

Re:No. (1)

SharpFang (651121) | more than 5 years ago | (#26144793)

In Firefox, which is in fact written mostly in Javascript (or at least most of the user interfaces is) and which uses a superset of functions available to webpages for that, including "dangerous" functions like file I/O, it does the work of providing the user with Javascript by restricting/limiting/crippling/sandboxing the very same engine it freely uses for purpose of creating the UI.

Quite a few of Firefox security holes were based exactly on shortcomings of this sandboxing, access to "system-only" methods leaking into userspace.

I don't know how exactly this duality (sandboxing vs full feature set) is achieved internally, but I know it costed lots and lots of time and effort to create. And only five-minute solutions can take next-to-none resources. If something costs lots and lots of time and effort to create, it will take quite a bit of resources to run as well.

Re:No. (1)

SanityInAnarchy (655584) | more than 5 years ago | (#26149499)

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 without too much of a performance hit. Exhibit A: Virtualization. Exhibit B: Unix permissions.

The rendering uses non-native extensions that lack in efficiency too.

Please be more specific. I'm sure I've seen SVG be hardware accelerated in a browser.

It's event-based meaning you shouldn't run a loop at full speed

Nor should you in any other game, really...

you need to create clock events to trigger each iteration.

Which, in an FPS, we call "Vertical Sync".

And you get a HUGE pile of compatibility issues.

RTFA -- this is one thing libraries help a lot with.

Of course, if you create a faster computer, the Nature will create programmers writing the usual in slower programming languages.

Was it ever usual to be able to open up a browser, navigate to a page, and suddenly be playing a game?

Yes. See Flash. (3, Insightful)

naz404 (1282810) | more than 5 years ago | (#26142925)

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.

Re:Yes. See Flash. (0)

Anonymous Coward | more than 5 years ago | (#26143763)

Erm...i think JavaScript is based in ECMA's standard aswell as AS, *not* the other way round.

AS 3.0 resembles java because it's based (as is the next version of JS) in the new ECMA specification which adds among other things Java like inheritance with classes, as oposed to the prototype based inheritance that has been the tradition in these languages (and, IMHO, better than classes).

Re:Yes. See Flash. (1)

shaka (13165) | more than 5 years ago | (#26143943)

Erm...i think JavaScript is based in ECMA's standard aswell as AS, *not* the other way round.

GP is right, ECMAScript was standardised based on JavaScript and JScript. JavaScript was developed by Brendan Eich at Netscape, who later submitted it to ECMA for standardization. Brendan is still a driving force behind the language and the specification as he is now CTO at Mozilla and the maintainer of Mozilla's JavaScript engine.

Meh (0, Flamebait)

Selanit (192811) | more than 5 years ago | (#26142933)

It's definitely ready for card games, and probably some 2D tile-based type games. You know, like, say, [url=http://www.spiderwebsoftware.com/exile3/winexile3.html]Exile III[/url]. That was an excellent game, due mostly to its interesting writing and vast scope, because the graphics sure weren't carrying the day. You could probably put together a web-based version of that without too much trouble.

But nobody's going to be rewriting World of Warcraft for JS in the foreseeable future.

Re:Meh (1)

Number14 (168707) | more than 5 years ago | (#26142955)

I am, in fact, writing a 2d tile based game, similar to Exile or the early Ultimas, in JS. So far, so good. I may wind up screaming and giving up, but for now I think it's going to be doable.

Re:Meh (0)

Anonymous Coward | more than 5 years ago | (#26143557)

Oh comeone we can do much *much* better than that.

Heres my try at a tile engine:

3d, drag-drop (buggy) and shinies! :)

Don't run before you can walk. (1)

91degrees (207121) | more than 5 years ago | (#26143029)

You don't just build an ambitious game. You build up to it. Start with something simple. Increase complexity. Find the problems a few at a time rather than all at once.

short answer: yes (4, Insightful)

El_Muerte_TDS (592157) | more than 5 years ago | (#26143037)

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.

No, of course not! (2, Funny)

Lorens (597774) | more than 5 years ago | (#26143043)

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!

There are a few now (0)

Anonymous Coward | more than 5 years ago | (#26143147)

There are a couple out there now. Vox Imperium is one I play pretty regularly. Its not all that great, but hey? Its Civish and doesn't require any plugins. All Ajax. Just don't use Lynx.


Quality? Games? (5, Insightful)

sweet_petunias_full_ (1091547) | more than 5 years ago | (#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.

Blame CSS, HTML and IE (4, Interesting)

Nicolas MONNET (4727) | more than 5 years ago | (#26143223)

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.

Re:Blame CSS, HTML and IE (1)

spinkham (56603) | more than 5 years ago | (#26144537)

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:Quality? Games? (2, Insightful)

sakdoctor (1087155) | more than 5 years ago | (#26143239)

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?

Re:Quality? Games? (2, Insightful)

Anonymous Coward | more than 5 years ago | (#26143251)

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 composition going on.

That said, if you are requiring canvas xor png32, you already have reasonably high requirements on what browsers can be used. You won't be worrying about IE6 flaws.

Re:Quality? Games? (1)

Psychotria (953670) | more than 5 years ago | (#26143507)

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? For what? Collision detection? I'm not even sure I would have used xor 10 years ago for (as you put it) "image composition". XOR with a mask, yeah. Not sure that is exclusive to PNG though... actually I am sure it's not. PNG is a file format, not a display format or anything that remotely resembles the image in RAM. It doesn't resemble what your web browser does either (except in the most absract way I guess).

See what I mean? There are so many things wrong about your comment. And the biggest thing I think is that you're talking about browsers and how they handle data. The sooner you forget about browsers and elevating the people who write markup language to the status of programmers the better. Yes you can make games. Yes you can make pretty blinking lights.

Re:Quality? Games? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26144159)

I believe he meant "[...] if you are requiring canvas or, alternatively, png32 [...]". but was lazy and wanted to be cute.

Re:Quality? Games? (0)

Anonymous Coward | more than 5 years ago | (#26143467)

Slashdot (and others, but Slashdot has become the worst offender for me) has been become almost unusable because of all the JavaScript rubbish which is now there.

I get loads of script timeout errors, even on a 1GHz machine for the front page - it's a joke. My usual machine is a 500MHz laptop, it has no chance for what should be just a stupid bloody website.

Trying out Seamonkey 2.0 is better than 1.13, but it's still not perfect.

I think people should sort it's use out on webpages before they try doing *anything* else with it.

And it invariably kills tabbing.

Define "ready" (5, Interesting)

Kjella (173770) | more than 5 years ago | (#26143383)

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.

Re:Define "ready" (1)

ChienAndalu (1293930) | more than 5 years ago | (#26148357)

Even large (most) of Rollercoaster Tycoon was built in assembler. I just wouldn't call it a weird language choice, assembler is pretty fast and "predictable", unlike the common javascript implementations.

Why? (2, Informative)

TheSpoom (715771) | more than 5 years ago | (#26143497)

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?

Re:Why? (1)

famebait (450028) | more than 5 years ago | (#26144105)

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.

Re:Why? (1)

TheSpoom (715771) | more than 5 years ago | (#26148361)

"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

Sure. (1)

kvezach (1199717) | more than 5 years ago | (#26143545)

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.

Re:Sure. (1)

Psychotria (953670) | more than 5 years ago | (#26143671)

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.

Re:Sure. Back up a few versions... (1)

JetScootr (319545) | more than 5 years ago | (#26143745)

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.

I hope it is (0)

Anonymous Coward | more than 5 years ago | (#26143589)

I hope it is as I'm writing a Risk/Diplomacy type of game where the client is in pure js. It works, but is somewhat slow in IE 7 and does not work i IE 6.
There is no special IE version. The problem is getting nice grafiks, not the js language.

The Beta version can be found here (in Swedish)

Hmm... (2, Informative)

Canazza (1428553) | more than 5 years ago | (#26144493)

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.

Interesting Turn Of Events (3, Insightful)

Jekler (626699) | more than 5 years ago | (#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.

Re:Interesting Turn Of Events (1, Interesting)

Anonymous Coward | more than 5 years ago | (#26145903)

Haven'tt you heard of jsMSX [googlepages.com]?

Emulators in JS are pretty intense.

yes, probably (0)

Anonymous Coward | more than 5 years ago | (#26144731)

could you pick your nose with a monkey wrench?
yes, probably.

is it a good idea? might there be a better way?
almost certainly.

I would say yes (1)

ironicsky (569792) | more than 5 years ago | (#26144987)

A friend of mine was bored at work and wrote a Mario Brothers side scroller in Javscript, which included simple a simply but accurate physics of when Mario jumps and falls, just like in the console version. He also wrote a multiplayer animated version of Monopoly in Javascript with the help of a back-end php script for connectivity.

The biggest hurdle in programming fun things in javascript is the browser the user is using(speed of execution issues) and the processing capabilities of their computer.

Unity 3D proves it is (1)

Johnny00 (213878) | more than 5 years ago | (#26147983)

Check out Unity 3D, a multi-platform 3D IDE focused on letting you use 1 of 3 languages (Javascript, C# or a Python variant) to do all the scripting of your game objects. It's extremely awesome and fun work and I've seen some great games created with it. It makes it all the better that they can run on Mac and Windows, on the desktop or via the browser. Sad for Linux folks who can't play their games yet though. http://www.unity3d.com/ [unity3d.com]

I'm working on such a project... (1)

k0vert (1323411) | more than 5 years ago | (#26148513)

I'm working on a game that will be purely HTML+CSS+JavaScript (PHP backend). It will be similar to Uplink and will include multiplayer. If you are interested in seeing a video just search for "uplink inspired multiplayer" (I don't know how Slashdot views self promotion).

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account