Client Ports for Brad's RPG (Ideas and Related Ramblings)

[zourtney]

I thought maybe we could use a separate thread for talking about client for Brad's RPG. That way he can still talk about his class design and stuff and I don't trample on his legitimate work.

That being said, I am interested in writing a PHP/JavaScript based client for this game when it comes about. Naturally, the official Braddish client will have to be made first so he can get the game API all hammered out.

If you haven't done so already, be sure to check out Brad's thread, Flash/C++ Game Project.

[zourtney]

From Brad's thread, here:

What are you making word press themes for? Just out of curiosity.

But thats cool. I never knew you could do that with VMs.

I was starting to make a little website where I could post my programming stuff and a resume. I'm not very good at web design, but I got a little bit done. Plus, making WordPress themes is fun and easy (relatively speaking).

And yeah, those Guest Additions for VirtualBox let you do some cool things, like mounting a folder from the host machine. Very, very handy.

And, for a 3^rd topic in this post, I came across this -- HTML5 examples. If I ever get around to making that HTML-based port of Brad's game, HTML5 could be the way to go. However, the word is that it doesn't work in IE.

Edit: Neatish text manipulation example here.

[Nick]

Nothing ever works in IE until everyone else is supporting it and IE starts looking a little backwards by comparison to browsers that actually get new features. We would all still be using the same feature set that was in IE5 if it weren't for firefox and opera (and maybe safari.)

Plah. IE sucks. I have never really liked it and probably never will.

Looks like I have another web standard to learn. Thanks for the heads up. 

[Brad]

Client ports? Hmmm... 1152 sounds good. Ohhhh... not that kind of port.

I'd be really interested to see you do something in HTML 5. I've only seen a couple examples so far, but what I've seen looks really good.

[Nick]

Edited:
Sadly seems that HTML5 is not very supported in anything but opera and it seems somewhat in firefox, safari and chrome. IE support is coming though.  

With some js we could easily make a passable looking client for the BradGame. (It have a name yet?)

[zourtney]

Yeah: does it have a name?

I guess he's mostly working on the server side of it right now. And the server (as I understand it) could support any type of RPG you want to make up. I keep hearing about aardvarks and stuff, so I'm guessing the actual game isn't hammered out quite yet (jump in and correct me, Brad!)

Anyway, as I understand it (not very well), HTML5 just gives the programmer a little bit better but a little bit better control over drawing functi---ah! dang hamster!

[Nick]

You can draw elements in real time using the client machine though JS. So you could make a game that uses nothing but JS and HTML5 from what I was looking at. Its all rather cool. Ooooh, and better control over context menus too. I have wanted that forever. And that's just because of all the gallery stuff we have worked on.  I can only imagine how coolly that could be used (and probably abused.)

[zourtney]

Sorry, I had a hissy fit and all the sudden had to clean the hamster cage.

But yep, from what I see, this new stuff sounds perfect a low-key game, like we were talking about! I propose (once Brad get an API hashed out) that we port that socket transport layer stuff to PHP and test it good n' fine. Then we sprinkle on a little AJAX because I refuse to have a "game" with constant page refreshes.

I think it'll work well, actually.

[Nick]

Some ajax and HTML5 canvas stuff should make it nice and smooth, for something purely rendered by the browser anyway. 

[zourtney]

So, I was messing around a little bit today (just wait¹) and found a little PHP demo of a socket server/client pair. It looks, as Brad had suggested, to be a piece of cake. But, as we all know, the cake is a---

Nevermind. It's just too much. I apologize.

Anyway, once Brad gets his server code working nicely, I'll start to build a PHP library to talk to it. The code is quite simple actually, but it could use a little bit of an OOP flavor.

@brad - I'll probably wait a while before I do anything with this...about the time you've done it in Flash. But, at some point it'd be nice to have a list of commands and expected server responses. Maybe something more official than a forum post? Meh, what can I say? I like (non-code) documentation

edit: yay paste works properly from the normal notepad app...

[Brad]

I'll make sure to heavily document the network API and how to pack and unpack the packets. It should be pretty solid by the time you want to try and port it.

[zourtney]

I've been lacking an active project at work for a few weeks (think: waiting weeks before someone bothers to review). Anyway, I was looking up random stuff about SVG and the HTML5 canvas element. I came across a somewhat interesting case study from svgopen.org.

Less work-relatedly, it got me thinking about how to implement a browser UI for Brad's game. SVG offers some really nice looking graphics in about 4 lines of code, but it can become very slow when dealing with large DOMs. However, as evidenced by this demo (from case study), you can toss static canvas elements into an SVG DOM. Mixing the two technologies is an intriguing idea which might increase performance, since canvas is pretty darn fast.

But, it begs the question: which on-screen game objects lend themselves to raster images and which lend themselves to vector images?

Here is a different article which may be of interest about How to Make an HTML5 iPhone App.

[Nick]

Now I want to play with that. I bet its harder to do then flash animations, at least for making good ones.  I wonder how long it will be until there is a little animation studio for working with HTML 5 stuff (other then using the video tag.) Perhaps I should revisit the 'Optimized' series....

[Brad]

So Nick was telling me that he was thinking of trying an web version of my game client using jQuery. He was even able to compile and run the server on a linux box after a few case issues.

There is the issue of websockets vs TCP sockets however... the server was written to use TCP sockets as the primary clients were going to be Flash and Android Java based. However stuff written for web browsers using Javascript or HTML5 can only communicate by websockets which use HTTP and port 80 to send/receive info.

Not sure what Nick is going to do to get around that, or if you is going to use AJAX and PHP to send data with "real" sockets.

I should really be letting Nick post about this but Randomland has been so dead lately... we need some kind of discussion around here.

[Nick]

From what I have looked at websockets are better for sustained connections and have much lower overhead. There is a php based server, a JS based one (node.io), and a few others based on java. Not sure how to proceed yet. Ill keep you updated.