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

Comments

breakout

[neo8750]

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

Re:breakout

[AKAImBatman]

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.

Re:breakout

[Annymouse Cowherd]

Another great one is DHTML Lemmings

Actionscript

[Anonymous Coward]

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.

Re:Actionscript

[Achoi77]

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

[6Yankee]

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

[deniable]

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

[aliquis]

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

[SanityInAnarchy]

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.

Re:Actionscript

[Anonymous Coward]

With all due respect who the fuck cares what IE supports or not?

People that are interested in supporting 70.38% of all web browsers as of 2008 Q4, that's who. Anyone who ignores IE is a fool. Or a fanboy of their supported browser.

Re:Actionscript

[aliquis]

I'm not as much of a fanboy as I'm a hateboy of one single browser (or well, make that two, Safari is quite crappy to.)

java != javascript

[QuantumG]

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

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

Enjoy.

Re:java != javascript

[ChienAndalu]

Presses 'down' key on keyboard

Seeing page scrolling down

Is JavaScript Ready For Creating Quality Games? NO

Re:java != javascript

[QuantumG]

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

This is 100% pure javascript baby.

QuantumG

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

Re:java != javascript

[ChienAndalu]

Well, they probably are captured differently on every browser anyways.

Re:java != javascript

[Anonymous Coward]

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

[QuantumG]

That's a feature.

Re:java != javascript

[ruda]

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

Re:java != javascript

[Jamie's Nightmare]

Not exactly breathtaking. Tetris hasn't been cool since the original game boy. Why not interact with an Italian plumber instead?

Re:java != javascript

[sgbett]

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

Re:java != javascript

[QuantumG]

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

[Anonymous Coward]

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

Re:java != javascript

[0xygen]

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

Another great win for JavaScript.

Re:java != javascript

[AKAImBatman]

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

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

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

(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

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

Re:java != javascript

[sgbett]

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

Re:java != javascript

[QuantumG]

I like your version.

Re:java != javascript

[6Yankee]

Not a problem here - I'm a leftie :)

Re:java != javascript

[AKAImBatman]

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

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, though. That is a marvelous piece of game design right there. Very professional in every way.

Re:java != javascript

[Anonymous Coward]

This is cool, but demonstrates the browser issues. I was trying to play using the keyboard arrows and even though it worked, every time I hit the down arrow to drop the pieces, the whole page scrolls up a little bit. Very annoying when trying to play and have to constantly keep adjusting the scroll position.

Re:java != javascript

[Anonymous Coward]

Nice, but its very unresponsive with the music on. Music stopped when I hit the left button and wasnt able to move at all with the other keys.

Re:java != javascript

[kbrasee]

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.

WASD, have you heard of it?

There are Java games, so why not JScript?

[hairyfeet]

Since there are already games built on Java like Specforce 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?

[farnsworth]

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!).

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

[rav0]

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

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

[deniable]

Why use JScript and limit yourself to Windows?

Easier?

[Psychotria]

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?

[Xest]

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?

[Psychotria]

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?

[Psychotria]

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?

[Yvanhoe]

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?

[BenoitRen]

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?

[Xest]

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?

[Anonymous Coward]

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?

[soniCron88]

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

Re:Easier?

[SanityInAnarchy]

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.

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.

Re:Easier?

[yusing]

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

math game: optimal path in number matrix

[Anonymous Coward]

A small javascript game to waste time with.

http://fn.dy.fi/old/misc/matrix/index.pl

No.

[SharpFang]

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.

[Anonymous Coward]

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.

[SharpFang]

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.

[SanityInAnarchy]

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?

Re:No.

[SanityInAnarchy]

If something costs lots and lots of time and effort to create, it will take quite a bit of resources to run as well.

Are you sure you're a programmer? Because that is the most absurdly wrong thing you've said all day...

There are decades of research into sorting algorithms, for instance, and these are focused in reducing the amount of resources they take to run, for a given set of input. In the extreme example, people often rewrite things in assembly to make them go faster on a particular machine -- are you going to tell me that assembly is slower than C because it took more time to write? Or are you going to tell me the assembly would take less time to write?

At the other extreme, any idiot can build a "while(1){fork();}" -- which eats as many resources as you throw at it.

Re:No.

[SharpFang]

Are you trying to prove your point by suggesting purposely wrong solutions as examples?

Look, the best algorithms will have complexity of O(n). The five-minute solution would be "Send me the data pre-sorted, you have more CPU power on your side", of complexity of O(0).

People rewrite things in assembly if these things were way too slow for their purposes. Meaning they get faster, but still slow. A five-minute solution would be to remove the whole part which does it, and use precalculated data, or hiring a bunch of interns to do it by hand, a hundred times faster than the computer would.

Not only I'm a programmer, I'm a seasoned one. Not once I spent a week trying to optimize a part of the program until someone suggested "why not overhaul the database structure instead, and kill the monster you're struggling with, replacing it with one simple SQL query?" A large application, with admin interface, with segments in Java, Perl and PHP communicating over custom protocol, importing data with SOAP, extracting a couple of lines from enormous files the partner would provide - and wouldn't change because hundreds of others depend on them - replaced with one guy adding or removing a line in a 4KB text file once a month, after getting a call from that partner. Getting the app to -just- fit in the time frame instead of lagging behind the required speed by -O3 instead of optimizing an algorithm.

These are optimizations. Not reducing complexity by 20% or by half, but by 99%. Changing estimates from 2 manyears to one day. Young programmers dabble in the code thinking how to squeeze 2 more cycles from the critical section. Advanced programmers know a faster CPU costs less than the salary the younger programmers would get for the time they spend finding the two extra cycles.
Or replacing Javascript, even very, very well optimized with hundreds of people working years on making it faster, with C++.

Re:No.

[SharpFang]

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-down doubles. As for virtualization, try virtualizing a different architecture than your native, say running a virtual MIPS machine under an x86 system. See the impact. The virtualization you're talking about makes heavy use of hardware features. The JS VM does not.

I'm sure I've seen browser without SVG. Actually, I'm sure most of users use it. Are you going to put "Firefox 3.0.4 required" on the product you're selling?

Good luck accessing VBLANK interrupts in Javascript. Also, good luck getting 50FPS from anything more than a handful of pixels.

As soon as you start writing more advanced code, you start finding bugs in the libraries. Also, have you maybe noticed what is the performance impact of using, say, JQuery vs writing the code in JS by hand? Suddenly slow-down triples.

Re:No.

[cbrocious]

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

Re:No.

[SanityInAnarchy]

The five-minute solution would be "Send me the data pre-sorted, you have more CPU power on your side", of complexity of O(0).

In other words, I'm surprised it took you five minutes to figure out how to push the real work onto someone else. How does that still count as a "five-minute solution"?

A five-minute solution would be to remove the whole part which does it, and use precalculated data,

Again a non-solution in many cases. For years, games had pre-calculated shadows and lighting. Now, the lighting is mostly done in realtime, allowing it to change in response to moving light sources, as well as moving objects casting shadows.

In order to make that fast, certain parts of it are done in assembly, or even on the video card. Far more programmer time spent. Better results, for the same amount of CPU time.

or hiring a bunch of interns to do it by hand, a hundred times faster than the computer would.

How much do those interns cost? How much would it cost to instead hire one programmer and rent some power from, say, Amazon EC2?

Besides which, exactly what are you doing which is a hundred times faster for a human to do than a computer?

Not once I spent a week trying to optimize a part of the program until someone suggested "why not overhaul the database structure instead, and kill the monster you're struggling with, replacing it with one simple SQL query?"

Certainly, things like that happen. However, you've extrapolated it to claim that in all cases, more work equals more resources spent on the problem. I'm providing examples where, if the same solution is to be reached, more work may equal less resources spent.

Advanced programmers know a faster CPU costs less than the salary the younger programmers would get for the time they spend finding the two extra cycles.

I suppose that makes me an "advanced" programmer -- I use Ruby on Rails. If I can solve a problem in hours instead of days, it's worth the extra CPU and RAM I have to throw on it.

But that doesn't apply in all cases -- see, again, video games.

And it doesn't help your argument at all -- your examples say, "Work smarter, not harder." That is not the same thing as "If you work harder, your programs will run slower."

Or replacing Javascript, even very, very well optimized with hundreds of people working years on making it faster, with C++.

...thus spending at least as much time sandboxing the C++, possibly more.

Re:No.

[SanityInAnarchy]

VM = interpreter. No matter how much marketing people may want to convince you otherwise.

Sigh...

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 once a RISC CPU for which a virtual machine was written. By your logic, it was an interpreter. It also outperformed running the exact same code on the bare metal by a significant margin -- IIRC, it was twice as fast.

I'm sure I've seen browser without SVG. Actually, I'm sure most of users use it. Are you going to put "Firefox 3.0.4 required" on the product you're selling?

Better than putting "Random EXE required."

Good luck accessing VBLANK interrupts in Javascript.

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.

Also, good luck getting 50FPS from anything more than a handful of pixels.

Again, an API issue -- there is currently no OpenGL implementation in the browser. Still, I'll bet SVG can go reasonably fast, though perhaps not for 3D.

As soon as you start writing more advanced code, you start finding bugs in the libraries.

Which I can fix, given that they are open source.

Also, have you maybe noticed what is the performance impact of using, say, JQuery vs writing the code in JS by hand?

Given that I haven't yet had to optimize my Javascript -- it's fast enough -- no, I haven't noticed. But I would be curious to find out what the actual performance hit is, especially on the better Javascript VMs.

Re:No.

[SharpFang]

Dynamic lights written in assembly, vs static ones, same CPU time? Excuse me?
The OS sandboxes C++ well enough. And with "moving work to someone else", it's about modifying the whole system architecture, versus optimizing a single part.

Of course the "five-minute solutions" aren't always plausible. Of course sometimes hard work at optimization, months of efforts will yield a 5000% increase in efficiency. But we're talking about one specific case: Javascript engines in web browsers. The hard work at optimizing them doubled or tripled their speed. Switching the language of your would-be game from JS to, say, C++ would increase the speed about fifty times. Disagree with this specific case and don't seek exceptions to the rule which applies here.

Re:No.

[SharpFang]

"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 Microsoft to have it implemented in IE8 or IE9. Good luck.

It's exactly the lack of API that makes Javascript not plausible for making games. If it had an API to load 3D scenes, API to a physics engine, API to UDP sockets, it would work just fine. But it does not and even if at some time it will, currently Javascript is NOT ready for quality games, which was the original point. For lack of APIs, everything must be done by hand, pixel by pixel, polygon by polygon, and Javascript just doesn't have the speed to do it.

Javascript would be a great in-game scripting engine (though a hell to implement). Just like LUA or Python -inside- games. Not as the game platform though. WoW isn't written in LUA and Civ4 isn't written in Python for the same reason.

BTW, http://blog.creonfx.com/javascript/dojo-vs-jquery-vs-mootools-vs-prototype-performance-comparison
No "raw JS" in the graphs, but I assure you it would be the fastest of them all.

Re:No.

[SanityInAnarchy]

Heh, and that's what shows you're just a newbie.
I see. File a bug in bugzilla.mozilla.org

Now, did I say it had to be in a web browser?

And I thought I was the newbie... You do realize that Javascript can be -- is -- a general-purpose programming language, not only a browser scripting language?

If it had an API to load 3D scenes, API to a physics engine, API to UDP sockets, it would work just fine.

Which is my point -- though I would dispute that most games need UDP. In most cases, games seem to be re-implementing the wheel on top of UDP -- and that wheel ends up being at least SCTP, if not TCP itself. And in many cases, TCP honestly is not enough overhead to matter -- even HTTP might not be, which is why we're having this discussion anyway.

For lack of APIs, everything must be done by hand, pixel by pixel, polygon by polygon, and Javascript just doesn't have the speed to do it.

Sadly, even there, I'm not sure there is an API for the pixels -- though polygon by polygon would still be fast enough for some very interesting demos.

Javascript would be a great in-game scripting engine (though a hell to implement).

What would make it hell to implement? There are at least three open source Javascript engines that I can think of, off the top of my head, and more in the works. Are you saying none of them would be easy to embed?

Experience says otherwise -- for example, CouchDB embeds Javascript in an Erlang program.

BTW, [link]

That's three minor versions behind the current release of jquery -- how old are those benchmarks? I don't see Chrome in there, and Chrome is really what started the whole "My Javascript engine is faster than yours" game.

No "raw JS" in the graphs, but I assure you it would be the fastest of them all.

I would guess so, but I'm also not entirely sold -- after all, "raw javascript" is still essentially building your own library, which happens to be a thinner layer, for now. I would also guess that a sufficiently advanced VM might be able to make some guesses about code that might give the frameworked way an edge over the hand-rolled way.

I would also guess that this won't last forever -- eventually, either it won't matter (the speed difference will be worth the added flexibility, for the vast majority of cases), or browsers will start targeting specific frameworks.

Re:No.

[N1AK]

This entire thread came around from your original statement "If something costs lots and lots of time and effort to create, it will take quite a bit of resources to run as well.". It's outright wrong, and you deserved to get called on it.

Re:No.

[Anonymous Coward]

  I never said "if you work on optimizing it really hard, it will be slower".

I just said "if it required a lot of time and skill to create, it means it was big, and complex, because anything small and simple wouldn't require that much skill and time. And big requires much memory, complex requires much CPU time. Not "more than X", only "much". Dynamic lights, even written in assembly take enormous amount of CPU power. Quicksort will do the job a hundred times faster than bubblesort, but if you bothered to implement Quicksort here, it means you had reasons to, it means the data set is big enough that easier to write algorithms didn't perform well enough, that the system load made the extra effort necessary, and that it's still significant.

Time and effort are not REASON of things requiring extra resources. They are SIGN of them. If it's lightweight, you don't optimize it because you don't need to. If it required lots of time-and-effort-consuming optimization, then even after you optimized it, you started off with excessive load and reduced it to "something within limits".

And if you didn't optimize, but kept adding features, adding extra security checks, working on extra compatibility issues and such, then you did make it require more resources.

Meaning, if I see you working on something for a year now, I'm not saying you're making it heavier. I'm saying it's a damn heavy thing you're working on.

Re:No.

[SharpFang]

Now, did I say it had to be in a web browser?

And I thought I was the newbie... You do realize that Javascript can be -- is -- a general-purpose programming language, not only a browser scripting language?

You can control industrial machinery with PHP, write office applications in VRLM, and make ASCII art with SQL. Doesn't mean they are best for the job. JS adaptations are present in some programs other than browsers but hardly anyone takes them seriously. Look for job ads asking for perfect knowledge of Adobe Acrobat including Javascript. See if they prefer you knowing msh over C#. Besides, which of current -other than webbrowser- implementations of JS would you even start considering as a platform for a game? (note: platform for a game, not in-game scripting engine.)

For lack of APIs, everything must be done by hand, pixel by pixel, polygon by polygon, and Javascript just doesn't have the speed to do it.

Sadly, even there, I'm not sure there is an API for the pixels

Canvas.
But both Canvas and SVG are simply too slow and cumbersome to do anything serious in them. This may change in some nondescript future, but for now, nope. Yeah, someone wrote a wolfstein clone with Canvas. Meaning on a 2GHZ machine you're getting about the same performance as a corresponding program in C running on 486.

No matter how good the language by itself is, without API to perform given task, it's not suitable for that task. A bet why such a dirty and crude language as PHP is so successful? Myriads of APIs to everything in the world there is. It's not a good language but you can get things done in it, instead of messing around finding another 3rd party library that half-works with the data you need to interface with.

Javascript would be a great in-game scripting engine (though a hell to implement).

What would make it hell to implement? There are at least three open source Javascript engines that I can think of, off the top of my head, and more in the works. Are you saying none of them would be easy to embed?

Experience says otherwise -- for example, CouchDB embeds Javascript in an Erlang program.

The flexiblity of Javascript. Ability to extend, overwrite, modify system-provided objects. The little fun command eval() with its fun ability to be recursive. Asynchronous nature meaning all the synchronization issues. It's not getting a JS module to sit in the middle of your app that is a problem. It's writing the API between your app and JS, that takes into account all the tricky features of JS.

You created bird.prototype.fly = function(){...} and filled the sky of your game with birds.

and then some modder writes pig.prototype.fly = bird.prototype.fly;

In Javascript it's perfectly legal, and from then on all his pigs should be able to soar like eagles. But it's your job, as the game engine author, to assure that they will be able to - instead of crashing the game.

Once I've turned a DOM tree of a complicated HTML form into a cellular automaton collecting and analyzing the data that way - each element calls the children to provide results, creates new children if current value suggests it, hands its own and children's results serialized to the parent, and so on. The tree-like data structure is stored in 1:1 corresponding DOM tree.

At first I did it by extending Element.prototype, and it worked great in Firefox, but IE wouldn't have any of it. Then I overwrote document.CreateElement() with my version that applied the changes to every new instance before returning it. It worked in all browsers. A hack likely impossible in any other language, but it makes my head spin how the Mozilla guys made the engine to accept overwriting Element.prototype.check() so that clicking on a checkbox with class="submenu" creates a new submenu of choices.

That's three minor versions behind the curr

Yes. See Flash.

[naz404]

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.

Re:Yes. See Flash.

[Anonymous Coward]

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.

[shaka]

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

[Selanit]

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

[Selanit]

Ah, crap. I have been using too damn many forums. CURSE YOU, bbCODE!

Re:Meh

[Number14]

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

[Anonymous Coward]

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

Heres my try at a tile engine:
http://www.pc-gamers.com/webgamex/0.9

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

The keyword, however, is "quality"

[RLiegh]

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"

[oliderid]

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"

[h4rm0ny]

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"

[aliquis]

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"

[dreemernj]

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"

[aliquis]

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"

[foniksonik]

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"

[aliquis]

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"

[SanityInAnarchy]

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:The keyword, however, is "quality"

[Anonymous Coward]

Hey, for vector-graphics games, it's a real possibility. I made a clone of asteroids a few years ago, and with SVG it was plenty possible. (Only for browsers that support SVG, though...)

SVG Asteroids

Re:The keyword, however, is "quality"

[LunarCrisis]

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

Well, that settles it!

Re:The keyword, however, is "quality"

[dreemernj]

We already have what you are describing. MOV, AVI, MPG, WMV, they can all be embedded in all the major browsers right now.

One of the reasons flash is so popular amongst the folks embedding video in sites is that its become a platform for video thats extremely common on the web. It has a standard format.

Until the video tag spec has a viable video format to go with it, its meaningless. It just means we would use a video tag instead of embed/object/whatever to add the video to the site.

If FireFox and Opera choose OGG (Vorbis/Theora) and don't use other formats, I believe they'll have made the right choice. Until there is a standard, its just more of the sort of stuff we've been using for years.

Re:The keyword, however, is "quality"

[aliquis]

They can't be embedded in a standard way not using quicktime/wmp though can they?

Re:The keyword, however, is "quality"

[aliquis]

.. and h264 got better video quality and more peoples videos are probably already in h264 so why use theora? Except it's free... But that don't guarantee success in any way.

Re:The keyword, however, is "quality"

[dreemernj]

You use object and embed to embed all of them in the site. They all have to load external plugins because obviously no browser can play them all natively. The same would happen with the video tag, requiring lots of plugins, unless there's a standard.

Re:The keyword, however, is "quality"

[dreemernj]

It doesn't guarantee success but relying on a standard like h264 that has to be licensed will mean we're right back where we started. Not every browser will pay to license it, people will quickly realize its easier to just use a plugin, and we're back to flash.

I don't know how many open source options there are. I know Theora isn't the best codec that can be used, but if you are producing a standard, it just seems like a smarter idea to go with something that everyone basically has equal access to.

And considering how theora is the video format of wikipedia, and considering how many things already support it, it does make sense to adopt it and encourage/aide its development to get performance up to snuff.

Re:The keyword, however, is "quality"

[aliquis]

Browser no but won't most OSes have support for it? The free ones fail? What is more likely, Theora becoming a standard or people trying to get h264 for free (but can't they already? Can't VLC and mplayer play h264?)

I to believe a free format would be better, but if almost no-one use said free format and it's a definite fail that doesn't help. Such as trying to make a music store which only sell OGG although only just a few premium players play them.

I'd be ok with theora to, and a standard / getting rid of flash is more important than getting the most superior format (which will always be outdated some day anyway.)

Re:The keyword, however, is "quality"

[foniksonik]

I wasn't really talking about ads... my spelling was sub-par so it may have read that way, sorry.

What I meant was that in Flash you can take 2,3,4 videos which have been shot on a green screen and composite them. Even more significantly you can take vector graphics, text, etc. and composite them into the video using alpha and other blending modes. Flash also allows you to mask and clip video using other bitmaps and effects....

One application I created using this was a simulation of a multi-focus lens. I had one video stream which I then duplicated using a bitmap drawing area, and layered it 3 times with separate masks and each layer having a dynamic blur filter applied to it where each layer's blur amount was controlled via a single slider so that as you moved the slider left to right the foreground, midground and background of the video would each be affected by separate blurs, creating the illusion of a depth of field focus change.

This video was additionally larger than the viewable area, - somewhat panoramic so that you could use the mouse to pan left and right. Yes with video.

This is what I mean by using flash video.... I'm not talking about YouTube.

Don't run before you can walk.

[91degrees]

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

[El_Muerte_TDS]

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.

Re:short answer: yes

[Uzik2]

Audio is very difficult to do cross browser. Sound adds a LOT to a game.

Re:short answer: yes

[AKAImBatman]

The new "Audio" object in HTML 5 is an up and coming standard that should make such problems go away. But until that time, consider using a solution like SoundManager2:

http://www.schillmania.com/projects/soundmanager2/

Re:short answer: yes

[Uzik2]

Thanks, I hadn't seen that one :)
I had seen flash workarounds before but not that one.
It's still not perfect unfortunately. Flash is a serious security problem and it's not 100% available across all browsers and operating systems. My Ubuntu 64 bit OS is a perfect example.

Re:short answer: yes

[bcrowell]

Flash is a serious security problem and it's not 100% available across all browsers and operating systems. My Ubuntu 64 bit OS is a perfect example.

Flash runs fine on my 64-bit ubuntu box.

Anyway, the audio issue for JS is probably not going to go away for a long, long time. Right now, there is very little browser support for the html 5 audio tag. Support will be coming fairly soon in Epiphany and Firefox, but it will take years before most users of those browsers have switched over to versions that support it. Then there's the question of whether IE will ever support it, and if so, when. Add on to that the fact that there's no codec you can choose that is guaranteed to work. I think the day will be here very soon when you'll be able to make a JS game with audio and put it on a web page that says, "This game will work if you're running Safari, Chrome, or Firefox 3.x.y+." But as a mainstream option in the near future, I'm very skeptical. Currently, there does not seem to be any nonproprietary browser that will run on my linux box that supports the audio tag.

There's also the issue that although html 5 will have audio, video, and vector support, it won't necessarily be good enough to do all the things you could do in flash.

Long before html 5 audio becomes a widely supported option in browsers, I think it's likely that Gnash will have gotten good enough to be a usable replacement for Adobe's Flash player. There is also a surprisingly good OSS toolchain for developing flash, although you still have to be pretty hard core to try to develop a flash app without any proprietary software.

No, of course not!

[Lorens]

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

[Anonymous Coward]

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.

http://www.voximperium.com

Quality? Games?

[sweet_petunias_full_]

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.

Re:Quality? Games?

[sakdoctor]

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?

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

[Anonymous Coward]

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.

Re:Quality? Games?

[Psychotria]

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?

[discord5]

the way it used to in Web 1.0

This website is best viewed in Netscape Navigator 4.0

Re:Quality? Games?

[famebait]

Bananas? Oranges?

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

Re:Quality? Games?

[Anonymous Coward]

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

Re:Quality? Games?

[sweet_petunias_full_]

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 website is so dependent on javascript that, if not for advertisements, you would have trouble finding a link that took you elsewhere. Hyperlinks are no longer hyperlinks, as somebody else pointed out, now they're merely user interface elements and could lead to anything (a pdf, movie, an image blowup, etc.) unexpectedly.

Incidentally, I got past the dancing monkeys, the ads floating mid-page and all of that other junk you mention by disabling javascript on those sites, if not avoiding them entirely. Thus, as the web tries to become more javascript-based the eyecatching crappola is guaranteed to return and will be harder to avoid if javascript is required to do anything, or if sites enforce the need for a specific browser in order to do anything.

Yes, we have made some progress, but by and large the internet is a lot less vibrant, a lot less interesting, a lot more centralized and a lot more controlled and watched. It hasn't yet become less useful but this is simply because of its fantastic growth momentum. However, people seem to have forgotten why it experienced its fantastic growth in the first place, and it wasn't because we were lacking ways for corporations to track all of our decisions. It wasn't because people wanted to lose control over their page navigation or their ability to read certain information wherever it may be. It wasn't because people wanted to be turned into criminals by whatever industry had their business model threatened by the invention of the digital computer.

No, I could only be optimistic if the trend were becoming overall positive rather than overall negative, and it doesn't seem headed that way right now even if at present we still have a fairly useful web.

Blame CSS, HTML and IE

[Nicolas MONNET]

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

[spinkham]

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 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.

Define "ready"

[Kjella]

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"

[Anonymous Coward]

Yes, even the world's stupidest game is in JavaScript.

Proof if you dare:
http://www.philforhumanity.com/Worlds_Stupidest_Game.html

Re:Define "ready"

[ChienAndalu]

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?

[TheSpoom]

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?

[famebait]

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?

[TheSpoom]

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

[kvezach]

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.

[Psychotria]

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.

[Myen]

http://code.google.com/p/parchment/ does that, yes. Well, not quite - it's a Z-machine interpreter.

Re:Sure.

[Anonymous Coward]

No, he means Inform. Inform is what most interactive fiction has been written in for the past 15 years. It compiles down to z-code.

I hope it is

[Anonymous Coward]

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)
http://warofhonor.se

Re:Sure. Back up a few versions...

[JetScootr]

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.

Re:Easier? - Readers Digest Condensed version:

[OneSmartFellow]

Don't play bad games, just play the good games.

Hmm...

[Canazza]

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

[Jekler]

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

[Anonymous Coward]

Haven'tt you heard of jsMSX?

Emulators in JS are pretty intense.

Re:Interesting Turn Of Events

[inline_four]

I'd say the point of this discussion is not the quality of the games that can at all be achieved, but their method of delivery. Sure, none of these games is truly groundbreaking, but what's new is that instead of installing a program from a diskette or a CD written for a specific OS, I can simply click on a link and be playing it within seconds.

Furthermore, what's neat about JS, as opposed to Flash Actionscript, is its inherent open source nature. Think about it. A modern browser downloads JS source (as well as the source for enclosing DOM elements), just-in-time compiles it with native optimizations and then runs it at near-native speed. We definitely did not have this before.

yes, probably

[Anonymous Coward]

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

[ironicsky]

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.

Interesting

[Anonymous Coward]

http://www.fdirep.com/tstubbs Breakout games were pretty cool.. If you really want to make money open your eyes and your mind. The internet is still a very untapped market. Itâ(TM)s easier in life to be dismissive and not try than to even try at all. http://www.getthebar.com/Default.aspx?mrid=Wmld6lnsL2a0qBQ7GOHgeA==/

Unity 3D proves it is

[Johnny00]

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/

I'm working on such a project...

[k0vert]

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).

Re:I'm working on such a project...

[atomic-penguin]

I don't know how Slashdot views self promotion.

You must be new here.

what are you on about?

[Anonymous Coward]

I'm left-handed, you insensitive clod!

PseudoQuest!

[Xaroth]

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 host of non-JS related features.

As a caveat, it's just me creating it, so I haven't had time to polish it in IE - it's best viewed in Firefox 3 or Opera 9.6.

I also maintain a development blog of sorts in the forums (under "Status Updates"), for those that might be interested in such a thing.

Enjoy!

http://www.pseudoquest.com/

Why, should it?

[token0]

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

Why not stick with flash?

[merreborn]

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?

Re:Why not stick with flash?

[MrMunkey]

Another glaring problem (at least right now) with JavaScript is the lack of sound support. I wrote a little game 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.

Re:Why not stick with flash?

[Anonymous Coward]

Cell phone/embedded browsers rarely support flash.

Not to mention the major bandwidth required (relatively) to running from javascript+html+css. I can think of plenty of applications for this.

Re:Why not stick with flash?

[entmike]

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?

Probably the same reason that half of the stuff that you see on the web works. Because they "can".

Re:Why not stick with flash?

[merreborn]

Cell phone/embedded browsers rarely support flash.

A fair point, although most of them don't support all that much javascript either, especially if you aim for the lowest common denominator.

my JS game

[valentingalea]

Back in the day I did a small racing game all in DHTML.
I even added a highscore table - too bad it got hijacked by spammers:(

There are some pretty neat demos...

[Anonymous Coward]

TIE fighter space chase
Wireframe & filled z-buffering 3d engine
The toys page has more demos, and a link to some games too (try Robots).

Crysis

[Anonymous Coward]

I want to see Crysis written in JavaScript...

I like how

[sentientbrendan]

in chrome the javascript breakout game you linked runs too fast to humanly play.

Re:I like how

[iNaya]

It's also too fast to humanly play in Firefox.

UNITY 3D

[Pippilina]

Don't forget UNITY, the game dev environment complete with 3D graphics and Mono/NET framework.

You can use Javascript with it! It's awesome, and supports iPhone and Wii now.

www.unity3d.com

(dev platform is currently Mac but a windows version will be out mid 2009)

Some JavaScript games

[Pascarello]

Super Mario, Mario Kart, WolfenFlickr 3D, 3D Chess: http://www.nihilogic.dk/labs/javascript-games/
Spacius: http://scriptnode.com/lab/spacius/
Space Invaders: http://www.rebelideas.co.uk/games/invamars/

Yeah, but:

[Anonymous Coward]

JavaScript != Java != JScript.

All separate languages, but with the usual similarities you see between most languages.

I don't know much about JScript actually, i should look into it to see what differences there are.

Compare to the "bugs" in authentic Tetris games

[tepples]

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

But is it any more odd than what happens in authentic Tetris games if you rotate a T shaped piece into an occupied position? What about what happens if you lay down a piece and keep spinning it? Not only are these behaviors not considered bugs, they're actually required by The Tetris Company in authentic Tetris products published on or after 2001.

Not everyone has $700

[tepples]

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.

Because Atari 2600 takes fewer man-months

[tepples]

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.

Re:Because Atari 2600 takes fewer man-months

[Jekler]

Agreed, but the modern languages we're working with, like JavaScript and all C-style languages are working at a vastly higher level of abstraction than were available to work with for NES games. This should allow programmers to create far more complex systems with a lot less manpower to manage the complexity.

I'm just shocked at how little it seems like we've advanced. With modern resources we should be able to pump out SNES/Gensis quality games with roughly the same difficulty it took to produce an Atari 2600 game. That was supposed to be the draw of high-level abstractions. Admittedly, people are building general-purpose applications, business applications, and user interfaces with far greater effectiveness and complexity than those systems would have been capable of, but the bit-twiddling capability and real-time performance that games require seems to have lagged decades behind the rest of the functionality that JavaScript and ActionScript provide.

As an analogy, it seems like inventing a Go-Cart with a top speed of 10mph, going through 30 years of advancement and having cars with all the modern capabilities, climate control, raw horsepower, seating capacity, cargo capacity, anti-lock brakes, power steering, remote car starters and alarms... but the top speed still being 10mph.

Even the most barebones code, creating a simple pong game in JavaScript, the logic loop still runs at about the same speed as it did on an Atari 2600 but with much lower reliability with unpredictable and uncontrollable pauses. This is on a system literally thousands of times (if not tens of thousands) more powerful than an Atari 2600 was.

IE is still the supermajority browser

[tepples]

But SVG *is* XML-based

Which means jack droppings if the web browser on the supermajority of your audience's computers doesn't understand the semantics behind the DTD. Or were you thinking of translating SVG on the server side, in much the same way that a lot of web sites to turn random XML into XHTML?

Re:IE is still the supermajority browser

[h4rm0ny]

I think we're talking at cross-purposes. I'm pointing out that SVG, being XML-derived, is a natural fit with the HTML DOM and with environment Javascript already works in. There is little work in making Javascript be to SVG what Action Script is to FLASH. This is a major plus in SVG being used for much of the same stuff that FLASH is used for, streaming video being the exception.

Re:IE is still the supermajority browser

[tepples]

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.

Re:IE is still the supermajority browser

[h4rm0ny]

Okay, you are definitely not getting my point. I have said that manipulating SVG with Javascript is a very short step. Nothing you just said pertains to this.

Re:IE is still the supermajority browser

[tepples]

I have said that manipulating SVG with Javascript is a very short step.

And I have said that a much longer step of having SVG in the first place precedes your short step.

Re:IE is still the supermajority browser

[h4rm0ny]

Never disputed it. I was replying to someone who said that Javascript wasn't suited for use with SVG. Your replies seems to be in the vein of arguing with that. If you want the general thread about SVG implementation in browsers, I think it's that way:

||
\/

:)

No, of course it is not ready for creating games.

[Anonymous Coward]

Of course it is not ready for creating quality games.
It is barely usable to create web pages with basic client side scripting (mostly because of Microsoft's humiliatingly embarrassing, and truly shitty implementation, their broken DOM, useless CSS, non-existent SVG, missing Canvas, etc.)
Inconsistent browser implementations, implicitly declared variables, lack of strong typing, all make for a truly horrible language. Forget about trying to use it, unless you are absolutely forced to for some web app.

Programming can be less than 10 percent of a game

[tepples]

the modern languages we're working with, like JavaScript and all C-style languages are working at a vastly higher level of abstraction than were available to work with for NES games. This should allow programmers to create far more complex systems with a lot less manpower to manage the complexity.

True, abstractions can reduce programming to 10 percent of game development. But you still need manpower to draw graphics, lay out maps, compose the soundtrack, and test it all. Even something as simplistic as Super Mario Bros. 3 has a 128x4096 pixel graphic bank. And with the higher resolutions and color depths of newer monitors (compare the 1280x720 of modern platforms to the NES's 256x224 pixels), you have to spend even more effort in getting graphics to look good.

Another javascript browser game

[Anonymous Coward]

I've made an AJAX/CSS Sprite browser game as well :
WMD Tank Battle http://wmdtb.com
Multiplayer map conquest, with real time (but slow) missile-command stuff on the world map.

Re:pong

[audubon]

In your pong game, how long do you typically have to wait before the ball is served? (I've been about ten minutes so far...)

Re:pong

[audubon]

I get it now. This version of pong being "far superior," it simply refuses to play with a hack like me.

Re:pong

[AKAImBatman]

Press the space bar.

pure ajax rpg

[Anonymous Coward]

DomainOfHeroes.com uses all javascript/ajax. It is an RPG.