Forum :: Programming :: HTML Client [Concept]

Arcitex posted: (14th Jan 2012, 05:28 pm)

Desmond posted: (14th Jan 2012, 11:09 am)

One word JAVA

One word: No.

Stop bringing that up, you already admitted you don't know much about this stuff. What's up with this community and giving uninformed opinions?

Flash isn't a good idea either.

Could you enlighten why flash or java would not be the best? I am pretty sure you could do it, but of course it has its downsides. I did make a small attempt in flash with this, but since I am not the best with flash, I ran into issues like loading the bitmaps, masking the colors, etc.

---
http://www.addipop.com

From a completely nontechnical point-of-view: Flash is a dying technology. Even Adobe acknowledges this and is investing heavily in HTML5. They're even making tools to convert Flash to HTML5.

Html5 is pretty much the future, i think. apple didn't add flash support because they know html5 will become way bigger.

---
opensource isometric game engine ~ www.avac-engine.blogspot.com

Meh thanks. Now Dan has got me messing around in HTML5 -.- It seems pretty simple and easy so far.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

clive posted: (14th Jan 2012, 06:55 pm)

Html5 is pretty much the future, i think. apple didn't add flash support because they know html5 will become way bigger.

I had always wondered why they won't support flash.. Seemed very odd to me.. But back on topic, I think the reason why Flash has been suggested is because of the rakuhana forums managed to get a kind of MEOW clone working :P But I'll be sure to have a play with HTML5 at some point in the not too distant future :')

---
If money doesn't grow on trees, then why do banks have branches?

Arcitex posted: (14th Jan 2012, 05:40 am)

It's definitely possible. Don't listen to Sausage. The browser is the future platform upon which pretty much everything will run. With new technologies this stuff is largely becoming possible now, and it's the future.

For this type of thing you basically have two options: HTML5 or Native Client (NaCl).

Native Client, put simply, is a technology built into chrome that allows you to run sandboxed native code. You can run C++ in browser without compromising much speed (the benchmarks I've seen put native client code running only about 5-10% slower on chrome than it would in a desktopapplication). It's really impressive stuff, actually, and native client is just starting to pick up steam. Console quality games can now run in the browser, it's really impressive. Bastion is the best example (previously an xbox game) that I've seen so far. Check it out in the chrome web storeifyou like.

With native client you could develop a client in C++ to run in the browser. Doing this, though, will make your game only work in Chrome. (All the important people use chrome anyway, though.) Your other option, which you probably intended on using is HTML5.

With HTML5 you can take advantage of the canvas element. For networking you can take advantage of HTML5 WebSockets. These should be supported in most modern browsers: Chrome, FF (4+?), IE9+, etc.. (I know there was a security issue with the WebSocket protocol that some research team discoveredand it caused some browsers to disable WebSockets by default, but I'm pretty sure this has already been fixed; it was a while ago).

It's definitely possible with new technologies, and although they might not be fully supported now I think it's a much better idea to develop for a platform that is starting to bloom and grow massively rather than one that is going to slowly die.

I started developing an HTML5 game engine (if you can call it that) a while back for fun. It was more like a weekend hack together just to mess around with canvas, but whatever. I even implemented basic networking support. It was an interesting proof of concept. Nothing amazing but it's prettycool. You can walk around, spawn monsters and shit. You can check it out here: http://dev.rakuhana.org/CANVAS/wut/pc.php (networking is disabled since I don't keep the server running).

I'd say go for it, it would definitely be cool to see.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Wildsurvival posted: (14th Jan 2012, 09:49 pm)

Arcitex posted: (14th Jan 2012, 05:40 am)

It's definitely possible. Don't listen to Sausage. The browser is the future platform upon which pretty much everything will run. With new technologies this stuff is largely becoming possible now, and it's the future.

For this type of thing you basically have two options: HTML5 or Native Client (NaCl).

Native Client, put simply, is a technology built into chrome that allows you to run sandboxed native code. You can run C++ in browser without compromising much speed (the benchmarks I've seen put native client code running only about 5-10% slower on chrome than it would in a desktopapplication).It's really impressive stuff, actually, and native client is just starting to pick up steam. Console quality games can now run in the browser, it's really impressive. Bastion is the best example (previously an xbox game) that I've seen so far. Check it out in the chrome web storeifyou like.

With native client you could develop a client in C++ to run in the browser. Doing this, though, will make your game only work in Chrome. (All the important people use chrome anyway, though.) Your other option, which you probably intended on using is HTML5.

With HTML5 you can take advantage of the canvas element. For networking you can take advantage of HTML5 WebSockets. These should be supported in most modern browsers: Chrome, FF (4+?), IE9+, etc.. (I know there was a security issue with the WebSocket protocol that some research teamdiscoveredand it caused some browsers to disable WebSockets by default, but I'm pretty sure this has already been fixed; it was a while ago).

It's definitely possible with new technologies, and although they might not be fully supported now I think it's a much better idea to develop for a platform that is starting to bloom and grow massively rather than one that is going to slowly die.

I started developing an HTML5 game engine (if you can call it that) a while back for fun. It was more like a weekend hack together just to mess around with canvas, but whatever. I even implemented basic networking support. It was an interesting proof of concept. Nothing amazing but it'sprettycool. You can walk around, spawn monsters and shit. You can check it out here: http://dev.rakuhana.org/CANVAS/wut/pc.php (networking is disabled since I don't keep the server running).

I'd say go for it, it would definitely be cool to see.

May I ask how you got a server-type thing working with this? 

With that example I was using socket.io/NodeJS.

Arcitex posted: (14th Jan 2012, 11:28 pm)

Wildsurvival posted: (14th Jan 2012, 09:49 pm)

Arcitex posted: (14th Jan 2012, 05:40 am)

It's definitely possible. Don't listen to Sausage. The browser is the future platform upon which pretty much everything will run. With new technologies this stuff is largely becoming possible now, and it's the future.

For this type of thing you basically have two options: HTML5 or Native Client (NaCl).

Native Client, put simply, is a technology built into chrome that allows you to run sandboxed native code. You can run C++ in browser without compromising much speed (the benchmarks I've seen put native client code running only about 5-10% slower on chrome than it would in adesktopapplication).It's really impressive stuff, actually, and native client is just starting to pick up steam. Console quality games can now run in the browser, it's really impressive. Bastion is the best example (previously an xbox game) that I've seen so far. Check it out in the chrome webstoreifyou like.

With native client you could develop a client in C++ to run in the browser. Doing this, though, will make your game only work in Chrome. (All the important people use chrome anyway, though.) Your other option, which you probably intended on using is HTML5.

With HTML5 you can take advantage of the canvas element. For networking you can take advantage of HTML5 WebSockets. These should be supported in most modern browsers: Chrome, FF (4+?), IE9+, etc.. (I know there was a security issue with the WebSocket protocol that some research teamdiscoveredandit caused some browsers to disable WebSockets by default, but I'm pretty sure this has already been fixed; it was a while ago).

It's definitely possible with new technologies, and although they might not be fully supported now I think it's a much better idea to develop for a platform that is starting to bloom and grow massively rather than one that is going to slowly die.

I started developing an HTML5 game engine (if you can call it that) a while back for fun. It was more like a weekend hack together just to mess around with canvas, but whatever. I even implemented basic networking support. It was an interesting proof of concept. Nothing amazing butit'sprettycool. You can walk around, spawn monsters and shit. You can check it out here: http://dev.rakuhana.org/CANVAS/wut/pc.php (networking is disabled since I don't keep the server running).

I'd say go for it, it would definitely be cool to see.

May I ask how you got a server-type thing working with this? 

With that example I was using socket.io/NodeJS.

What was the server coded in?

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

Wildsurvival posted: (14th Jan 2012, 11:46 pm)

Arcitex posted: (14th Jan 2012, 11:28 pm)

Wildsurvival posted: (14th Jan 2012, 09:49 pm)

Arcitex posted: (14th Jan 2012, 05:40 am)

It's definitely possible. Don't listen to Sausage. The browser is the future platform upon which pretty much everything will run. With new technologies this stuff is largely becoming possible now, and it's the future.

For this type of thing you basically have two options: HTML5 or Native Client (NaCl).

Native Client, put simply, is a technology built into chrome that allows you to run sandboxed native code. You can run C++ in browser without compromising much speed (the benchmarks I've seen put native client code running only about 5-10% slower on chrome than it would inadesktopapplication).It's really impressive stuff, actually, and native client is just starting to pick up steam. Console quality games can now run in the browser, it's really impressive. Bastion is the best example (previously an xbox game) that I've seen so far. Check it out in the chromewebstoreifyou like.

With native client you could develop a client in C++ to run in the browser. Doing this, though, will make your game only work in Chrome. (All the important people use chrome anyway, though.) Your other option, which you probably intended on using is HTML5.

With HTML5 you can take advantage of the canvas element. For networking you can take advantage of HTML5 WebSockets. These should be supported in most modern browsers: Chrome, FF (4+?), IE9+, etc.. (I know there was a security issue with the WebSocket protocol that some researchteamdiscoveredandit caused some browsers to disable WebSockets by default, but I'm pretty sure this has already been fixed; it was a while ago).

It's definitely possible with new technologies, and although they might not be fully supported now I think it's a much better idea to develop for a platform that is starting to bloom and grow massively rather than one that is going to slowly die.

I started developing an HTML5 game engine (if you can call it that) a while back for fun. It was more like a weekend hack together just to mess around with canvas, but whatever. I even implemented basic networking support. It was an interesting proof of concept. Nothing amazingbutit'sprettycool. You can walk around, spawn monsters and shit. You can check it out here: http://dev.rakuhana.org/CANVAS/wut/pc.php (networking is disabled since I don't keep the server running).

I'd say go for it, it would definitely be cool to see.

May I ask how you got a server-type thing working with this? 

With that example I was using socket.io/NodeJS.

What was the server coded in?

It was NodeJS, which is JavaScript running on the V8 engine.

Arcitex posted: (14th Jan 2012, 11:50 pm)

Wildsurvival posted: (14th Jan 2012, 11:46 pm)

Arcitex posted: (14th Jan 2012, 11:28 pm)

Wildsurvival posted: (14th Jan 2012, 09:49 pm)

Arcitex posted: (14th Jan 2012, 05:40 am)

It's definitely possible. Don't listen to Sausage. The browser is the future platform upon which pretty much everything will run. With new technologies this stuff is largely becoming possible now, and it's the future.

For this type of thing you basically have two options: HTML5 or Native Client (NaCl).

Native Client, put simply, is a technology built into chrome that allows you to run sandboxed native code. You can run C++ in browser without compromising much speed (the benchmarks I've seen put native client code running only about 5-10% slower on chrome than it wouldinadesktopapplication).It's really impressive stuff, actually, and native client is just starting to pick up steam. Console quality games can now run in the browser, it's really impressive. Bastion is the best example (previously an xbox game) that I've seen so far. Check it out in thechromewebstoreifyou like.

With native client you could develop a client in C++ to run in the browser. Doing this, though, will make your game only work in Chrome. (All the important people use chrome anyway, though.) Your other option, which you probably intended on using is HTML5.

With HTML5 you can take advantage of the canvas element. For networking you can take advantage of HTML5 WebSockets. These should be supported in most modern browsers: Chrome, FF (4+?), IE9+, etc.. (I know there was a security issue with the WebSocket protocol that someresearchteamdiscoveredandit caused some browsers to disable WebSockets by default, but I'm pretty sure this has already been fixed; it was a while ago).

It's definitely possible with new technologies, and although they might not be fully supported now I think it's a much better idea to develop for a platform that is starting to bloom and grow massively rather than one that is going to slowly die.

I started developing an HTML5 game engine (if you can call it that) a while back for fun. It was more like a weekend hack together just to mess around with canvas, but whatever. I even implemented basic networking support. It was an interesting proof of concept. Nothing amazingbutit'sprettycool.You can walk around, spawn monsters and shit. You can check it out here: http://dev.rakuhana.org/CANVAS/wut/pc.php (networking is disabled since I don't keep the server running).

I'd say go for it, it would definitely be cool to see.

May I ask how you got a server-type thing working with this? 

With that example I was using socket.io/NodeJS.

What was the server coded in?

It was NodeJS, which is JavaScript running on the V8 engine.

Ahh *looks up on google* *finds  http://nodejs.org/* 

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer

It doesn't matter what language. If you're planning on using WebSockets then you need to implement the WebSocket protocol. Socket.io does this for you and makes everything really easy.

It's actually surprising to see a different game into our eoserv forums.

Pine posted: (15th Jan 2012, 12:30 am)

It's actually surprising to see a different game into our eoserv forums.

Nah, not really. There have been a bunch of them. Hiuriu's Arceus Online, TFG, my Land of Tyril, and a few others. Some of them may have originated as EOSERV's but they have been turned into a game. As I recall, Exiles ES Client is going with his server, which is practicly a new game. He has made his own emulator before as well.

---
Andrewbob - I would be on the fucking copter of rofls

Programmer, Web Developer, and Graphics Designer