Ah discussions, I'm all in favor of these
xarn wrote:I was actually surprised to see that you started it using PHP. With my bird eye view, I have the impressions that PHP is more suited to generate customized web pages and kind of ..."problematic" for interactive content. I mean, when you clic on a link or button, won't you basically receive a new page?
Well, Sandscape is nothing more than "customized web pages", hell, any web application is nothing more than that, some more complex than others
.
PHP is a server-side language, like any server side language it is
not used to create interaction with the user (not the one we are talking about at least), it's used to process requests made to the server and provide the appropriate response. If Sandscape is to comunicate with a server, and it needs to if it's to be a browser based multiplayer game as there is no way too browsers can directly communicate without external help, then it needs to be created or have a major part being developed in one of the various server-side languages.
I could have chosen several others and I actually evaluated the 4 technologies most used, PHP, Python, Java and Perl (and yes I'm deliberately discarding any Microsoft technology). I chose PHP mainly because it's widely used and if I'm not around it's easy for anyone else to pickup, it's cheaper (from free to a few dolars per year) if anyone want's to have it's own server, it allows for fast development and it's easy to learn/understand even if one is not a developer. It's also one of the easiest to setup. Nevertheless, any other of the four I mentioned would be good.
As for getting a new page on links and buttons, well the server returns only what you ask, if you ask for the full page then you get the full page, if you ask for something else, you get that. In any server-side language I can output whatever I want, from a complete page to a simple word.
The interaction you mention is not dependent on the server-side language but on the client-side one, and in this case on the proper use of JavaScript and asynchronous calls (what we usually call AJAX). So it doesn't really matter what language the server runs on.
If you don't use JavaScript then yes, any request will probably result in a full page load. And if you don't want to use JavaScript the only option is to use Flash (I would never use Flash), or Java Applets/JavaFX. Again, it's client-side dependent.
xarn wrote:I was also surprised you discarded the HTML5/javascript combo. Is there a reason for not wanting to take this path
JavaScript is a given, we can't do what we want without it, so this one is pretty much decided
. As for HTML5, I am using HTML5, I'm just not using the Canvas object.
The Canvas object would allow me to draw primitives in a 2D area and it works mostly like the Java 2D API in which I have experience so it would be easy for me to use but you get a context object with a fixed width and height to which you can draw pixel by pixel, you get some useful methods to draw lines and curves and that's about it. Also, performance wise you're pretty much bringing the browser to his knees
. Firefox and Chrome have some decent performance but even then if I start adding more objects to the image the redrawing of the image becomes noticeable.
Also, I would have to maintain a complete game state in JS, and that would mean a lot of JS code for simple things, and any time you update a pixel on the canvas the all area is redrawn. There is no buffer, no easy way to implement dirty rectangles, constraint boxes to prevent cards moving way from the designated area, you have mouse click but no drag, no easy boxing or collision detection, no auto scrolling, coordinates are absolute meaning both users would need a canvas with the same size or I would be forced to scale/translate on the fly.... you get the picture. The Canvas object is great and allows for fantastic things, games in it are easy enough to create but it still has a way to go and I found that I gain nothing by using it. I could do the same, or more, with just JavaScript and the jQuery framework.
With jQuery I don't need to thing about what the size of the user screen is, coordinates are relative so the browser scroll or adapts automatically (to some degree), it has better events and event handling code, it offers nice animations out of the box... it allows me to write less JavaScript and focus only on the mechanics behind the game since most of what I need for a game (or any interactive web application) is already written and performs well in most browsers.
I'm glad you asked about it, if nothing else it forces me to review my choices and see if they are still valid. Hope I have explained, and feel free to ask anything else.
Regards,
Knitter