Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Diablo in JavaScript

mitallast.github.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Diablo in JavaScript

#101

Post by unwind »

MichaelGG wrote: post #55
overgard wrote: post #23

Not a commentary on this project per se, but I can't help but think when I see "X in javascript" voted up that the implicit frame is: "isn't it impressive what you can do in javascript now?" But if you flip that statement on its head, the equivalent is "The web has finally caught up with what we could do on a 1997 desktop!"

I've had this sentiment from 1996 on. I worked for a company creating Internet materials for use in classrooms (Internet-on-CD, books, etc.). I remember seeing a "frog dissection" thing on a website and everyone seemed to impressed with it. Why? You'd click a gif, it'd run a CGI and deliver a new image. Just what you could do with actual clients, just slower, more limited, and lower resolution. There's something neat…

This has been stated a million times, and I'm not even a "web developer" like the majority here seems to be, by my take is this: not needing a client is the win.

There's a huge amount of value, as perceived by "users" of the services/applications/games, in not having to care about and install a specific client for each service/application/game.

That's why it's noteworthy when something that used to require a heavliy specialized client, such as a game, no longer does for delivering the same experience.

Re: Diablo in JavaScript

#105

Post by MrScruff »

jQueryIsAwesome wrote: post #99
MrScruff wrote: post #95

Earlier quoted context omitted.

That argument works for anything, as long as you can convince the browser vendors to implement support for it and provide it as an api. So I would argue that's much closer to the definition of cherry picking an example.

So I guess I can't talk about the DOM; many functions are just an API for it; and canvas is just an API for drawing accelerated by the CPU; so... Javascript is nothing and nothing can be blamed on it?

I'm just saying that the provision of video streaming as a web api is not a particularly technically interesting development. It's just a gradual beefing up of the browser as a thin client. And until support for the features are widespread, it's not really a commercially interesting development either.

I would class many of the other things you mention as incremental improvements of the rendering engine as a universal runtime. It's great that it's happening but it's not technically that exciting to me to see reimplementations of 16 year old games since we've had the flash runtime in the interim anyway.

Re: Diablo in JavaScript

#106

Post by runn1ng »

moron4hire wrote: post #56

This is neat, but it's not really that big of a leap. Here is a thing I wrote in 2002, as I was just starting to learn to program. It's a little broken now because the character image didn't get archived, but you get the idea. A lot more was possible, I just didn't quite have the chops before I got distracted by my next project http://www.oocities.org/webspynner_99/games/RPG/rpg.html The fact that browsers are still…

I see a green blob and a blue blob.

What should do with it? :)

Re: Diablo in JavaScript

#108

Post by thevdude »

coldtea wrote: post #83
kalleboo wrote: post #78

Earlier quoted context omitted.

The desktop equivalent, CU-SeeMe, was working in 1994.

I tried it circa 1998. I wouldn't call it "working" even then. Not to mention it needed installation (Javascript just needs people to go to a specific page), and the speed, lag and buffering was horrible at the time.

> speed, lag and buffering was horrible at the time

That has nothing to do with the software and everything to do with the network, no?

Re: Diablo in JavaScript

#109

Post by coldtea »

thevdude wrote: post #108
coldtea wrote: post #83

Earlier quoted context omitted.

I tried it circa 1998. I wouldn't call it "working" even then. Not to mention it needed installation (Javascript just needs people to go to a specific page), and the speed, lag and buffering was horrible at the time.

> speed, lag and buffering was horrible at the time That has nothing to do with the software and everything to do with the network, no?

Of course not.

Even on the same network, different conference apps have different characteristics. It depends on the compression and coded they use, how they handle changes in network performance, etc.

Plus the GUI and UX of that app was simply horrible.

Re: Diablo in JavaScript

#110

Post by rplnt »

shadowmint wrote: post #57
d0m wrote: post #20

Earlier quoted context omitted.

It's possible to point that out without being a total jerk.

The problem with this demo isn't that it's pretty alpha (and to be fair, it is, you can move, and attack, that's about it). The problem is that it uses stolen assets from another game. That is 100% not ok, even for a tech demo. (...there are plenty of free game assets out there, creative commons license; drawing attention to yourself by stealing someone elses art is douche behaviour)

The "you can move" is questionable.
Post reply on HN