Sandscape - WTactics browser game

Browser based open source cross platform solution for easily playing customizable card games online vs other players. Lead dev: knitter
User avatar
xarn
Posts:101
Joined:Thu Oct 13, 2011 11:50
Sandscape - WTactics browser game

Post by xarn » Sat Oct 15, 2011 14:59

Hi folks! Hi Knitter!

I just wanted to start an informal discussion about this. I guess it fits better here than in the general forum.

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? This means the page will be reloaded every time the user makes some action, which looks very "heavy" to me.

I was also surprised you discarded the HTML5/javascript combo. Is there a reason for not wanting to take this path?

Cheers
Knitter
developer
Posts:87
Joined:Mon Jan 17, 2011 11:26
Location:Leiria, Portugal
Contact:

Re: Sandscape - WTactics browser game

Post by Knitter » Sat Oct 15, 2011 18:07

Ah discussions, I'm all in favor of these :D
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
Rejoice! For very bad things are about to happen.
User avatar
Ravenchild
developer
Posts:131
Joined:Sat Sep 04, 2010 19:21
Location:Germany

Re: Sandscape - WTactics browser game

Post by Ravenchild » Sun Oct 16, 2011 18:18

One important thing to note: Sandscape is designed as a sandbox to play in. No checking for rules. It is just for moving cards around and playing with others over the web. So it can't be used as a competetive platform because you hardly notice if your opponent cheats.

This freedom is intentional so that we can easily test new rule mechanics without changing any code. Once the rules are fixed (and we still need some more time for this) someone can consider writing (or extending) a tool to enforce a play according to the rules.
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Sandscape - WTactics browser game

Post by snowdrop » Sun Oct 16, 2011 18:35

Ravenchild wrote:So it can't be used as a competetive platform because you hardly notice if your opponent cheats..
I disagree in the sense that it is just as easy to notice if an opponent cheats as it would have been if you played the game in real life, using paper cards on a table.

Games played in "real life" lack rules enforcing as well, yet they are played successfully in competitive environments.

Only time I can think of this being affected or considered a potential problem is in world championship-situations, where there is often a human judge involved. Thing is that it is only involved if there is a controversy - the players still play/behave like they would have even without the judge. For example, they don't wait for him/her to give the ok-sign for every specific action they take.
Knitter
developer
Posts:87
Joined:Mon Jan 17, 2011 11:26
Location:Leiria, Portugal
Contact:

Re: Sandscape - WTactics browser game

Post by Knitter » Mon Oct 17, 2011 10:03

Never thought about cheating in Sandscape but I don't see how it will different from a real life game. It's true that rules aren't to be enforced by the system, but the rule text will be shown if available and you will be able to see every action that you opponent performed, so in that regard it's the same, or as close as possible, to a real life game.
Rejoice! For very bad things are about to happen.
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Sandscape - WTactics browser game

Post by snowdrop » Mon Oct 17, 2011 13:16

Knitter wrote:...but the rule text will be shown if available
It always is, at least on the cards, since they have the text on them ;) As longa as people can see a hi-res version-view of a card in SS they'll also be able to read the rules. (Some clients also give the player the option to display rectangles and computer placed text within them on top of the cards, as a "layer", just to heighten readability. While it is nice to have such an option, I have never seen it used in real games and it usually ends up making it all look really bad in the end.)
User avatar
xarn
Posts:101
Joined:Thu Oct 13, 2011 11:50

Re: Sandscape - WTactics browser game

Post by xarn » Mon Oct 17, 2011 14:19

Woah ...time flies!
Knitter wrote:Ah discussions, I'm all in favor of these :D
Me too! :D

Before I go on, I would like to emphasize that I distinguish strongly between two aspects of the game:

The place where people login, can access their account details, scores, etc. In other words, everything that has to do with "persistent" data. Like the portal of the game. There, I second your choice that PHP is a fine choice.

The other part is the game itself, interactive part where the actual gameplay takes place (using cards, swap turns, etc) which is more like a "flash game" in my view. I'll focus here solely about the latter one.

Here also, like you do, I favor javascript based solutions instead of flash/silverlight/javaFx,etc. I mean, js and html looks like all we need for such a game. We are definitely on the same boat.

Graphics

I initially had in mind to use the canvas because it sounded nice. Just a flat simple, no-frills place where you can just draw stuff. But I can also live without it. Btw, I see you mentioned performance problems using the canvas, which I'm really surprised of. Did you use double buffering? (Not drawing on the canvas directly but on a buffer first)

Code: Select all

buffer = document.createElement('canvas');
// ...draw stuff on the buffer
canvasContext.drawImage(buffer, 0, 0);
However, despite I had some personal interest/curiosity in this buffer, it is indeed perhaps not needed. I guess I'll be fine with using pure html. I don't know JQuery, but if it simplifies life, I'm taker!

Game mechanics
Knitter wrote:Also, I would have to maintain a complete game state in JS
...well, I would say this is definitely the way to go. Actually, I would say that this is absolutely needed. Especially once the game mechanics will come in play, it'll be important to know at any time what's on the table, in the hands, in the graveyard, the cards themselves and be able to manipulate them. In my opinion, an internal and complete representation of the game state is the corner stone of all of this. I doesn't need to be complicated, it just need to be the central point.

Moreover, I would ideally enforce that what you see, at any point in time, is just a representation of this state. When an event occurs, it would change the internal representation, send the event over the network and update the graphical representation. So that the real "truth" is the one represented by the internal representation, while the graphics are merely a representation of it.

Networking
Knitter wrote: 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 also believe websockets are meant to fill this gap.
http://en.wikipedia.org/wiki/WebSocket
This enables to open a TCP/IP connection from a browser. Alternatively, like the old-fashioned way, asynchronous javascript requests can be used in the browser.

Here, I would personally use JSON objects to exchange data/events between the browser and the server. This is the most easy format to manipulate in js and is readable. For the server, which would receive JSON requests and send JSON response, I would likely choose python as the way to go. It looks to me as the most lightweight and most productive.

Methodology

I extremely like your XP idea. Spike solutions and frequent prototyping seems the way to go for me also!

Probably, we can soon plan out our first mini spike soon!

Cheers!
Let's raise our glasses on a nice together working! :mrgreen:
Knitter
developer
Posts:87
Joined:Mon Jan 17, 2011 11:26
Location:Leiria, Portugal
Contact:

Re: Sandscape - WTactics browser game

Post by Knitter » Mon Oct 17, 2011 14:42

xarn wrote: The place where people login, can access their account details, scores, etc. In other words, everything that has to do with "persistent" data. Like the portal of the game. There, I second your choice that PHP is a fine choice.

The other part is the game itself, interactive part where the actual gameplay takes place (using cards, swap turns, etc) which is more like a "flash game" in my view. I'll focus here solely about the latter one.
They aren't that different in the sense that they both need some server-side language, even the "game" area needs a server-side language.
xarn wrote: Did you use double buffering? (Not drawing on the canvas directly but on a buffer first)
Yes, I did try some performance tweaks/tests , but that isn't really double buffering since we won't be using the swap capabilities of the graphics card. We would be swapping an HTML element by another and hope the browser does it fast enough :). Off course, my Macbook Pro runs anything I tested but I was aiming at some lower specs like most netbooks around ;).

Naturally, I have to say I tested this around January this year, I know FF and Chrome have release updates that offer better speed and most of my code could have been optimized.
xarn wrote:...well, I would say this is definitely the way to go. Actually, I would say that this is absolutely needed.
No, the client controls nothing, everything is managed in the server and it's the server that has a full game representation. At least that's the idea. The client side will have the needed code to implement interaction but only the server can validate any move the user does.

I felt it was the easiest way to control 2 complete independent clients where both users can move cards around and do anything at the same time. If the client had a complete representation I would have to make the client solve collisions, this way the server is king :).

Especially once the game mechanics will come in play, it'll be important to know at any time what's on the table, in the hands, in the graveyard, the cards themselves and be able to manipulate them. In my opinion, an internal and complete representation of the game state is the corner stone of all of this. I doesn't need to be complicated, it just need to be the central point.

So, the game is maintained by the server, clients send requests to the server and will update their visual representation if possible.
xarn wrote: I also believe websockets are meant to fill this gap.
They still require a server to start communication and maintain communication, plus it has several security problems that meant Opera disabled support after version 11 and there is little support in other browsers, FF > 6 and Chrome have support for it, but IE and some others are way behind. Don't get me wrong, I'm all for completely ignore IE :D.
xarn wrote: For the server, which would receive JSON requests and send JSON response, I would likely choose python as the way to go. It looks to me as the most lightweight and most productive.
Like I say, it was one of those I evaluated but didn't choose for the reasons stated before.
xarn wrote: I extremely like your XP idea. Spike solutions and frequent prototyping seems the way to go for me also!
It's not really an idea, it's the way I work :).
Rejoice! For very bad things are about to happen.
User avatar
xarn
Posts:101
Joined:Thu Oct 13, 2011 11:50

Re: Sandscape - WTactics browser game

Post by xarn » Mon Oct 17, 2011 19:29

They aren't that different in the sense that they both need some server-side language, even the "game" area needs a server-side language.
Sure, but my point is:
- the first is more about delivering web-pages
- the second is more about handling data

So, personally, i like php for simple web stuff ...but when it comes to actual programming, i don't like it. Sure, you can do everything with every language, but still, it's definitely not the language i would choose for the second part.

With python you can test out things without actually needing web pages nor a server. I think of it as much better suited. Not only is it easier to write in python (in my opinion) but I think it also ensures a better distinction between the logic and the presentation.

In the end, all that would be needed is a html page, a few js scripts and a python script listening to a port. This looks to me both more lightweight and easier.
No, the client controls nothing, everything is managed in the server and it's the server that has a full game representation.
Sure. I didn't implied that the client controlled everything. I only meant that it also has an abstract representation of the game board, which would probably be the same as the server or similar.

I'm fine with the client controlling nothing. However, let me mention that it has the drawback that the consequences of any small action needs a round way trip to the server:
clic on a card > go to the server > process > come back > display changes
...but if the latency is small, i guess it's acceptable.
Let's go for the server king!
I felt it was the easiest way to control 2 complete independent clients where both users can move cards around and do anything at the same time.
...oh ...I wrongly assumed it was turn based, that each player only played on its turn.
...little websocket support...
Good point. I personally think it's just a question of time and it would be my pick, but i'm fine also with classic AJAX (although it might have an impact on latency since a new connection has to be established for each message). Anyway, it should be possible to make a small abstraction around this to be able to switch from one to another without too much difficulties.
Like I say, it was one of those I evaluated but didn't choose for the reasons stated before.
...eeeh ...I think i missed it. :roll:
Knitter
developer
Posts:87
Joined:Mon Jan 17, 2011 11:26
Location:Leiria, Portugal
Contact:

Re: Sandscape - WTactics browser game

Post by Knitter » Mon Oct 17, 2011 20:32

xarn wrote: Sure, but my point is:
- the first is more about delivering web-pages
- the second is more about handling data
It's a way of seeing things, to me it's just output.
xarn wrote: With python you can test out things without actually needing web pages nor a server. I think of it as much better suited. Not only is it easier to write in python (in my opinion) but I think it also ensures a better distinction between the logic and the presentation.
I don't see what tests you would do without a webserver seing this is a web, or browser based, application. If you're talking about unit tests or any other automatic test I do those in PHP like I do it in Python. But if I'm making HTTP requests then I need a server to handle them, even if it's one made in Python as a testing server.

As for distinction between login and presentation, I don't see your point. One thing has nothing to do with the other, you separate logic and presentation in any existing language, it's programmer dependent, not technology related.
xarn wrote: In the end, all that would be needed is a html page, a few js scripts and a python script listening to a port. This looks to me both more lightweight and easier.
Sorry, don't follow. What exactly does Python do that removes the need for an HTTP server in a HTTP based application? And what do you mean about lightweight, I have never seen a Python server implementation that was faster than Apache or Lighttpd, and I really don't see what you mean by a "python script listening to a port". I also thing the easiness of Python's syntax is way overrated, I find Python programs harder to read then Assembly, and I've done more Python than Assembly :D, still, if I had thought that Python would be best I would have chosen it despite my lack of taste for it, but I really don't see where Python offers advantages over PHP, or any of the other two that I thought of.
xarn wrote: clic on a card > go to the server > process > come back > display changes
Why would you go to the server on a card click?, but I see your question. Only actions that affect the game area are sent to the server since those actions represent a change to the state of the game. A click represents nothing.

But yes, there is a server call for every action that should affect the game state. Would it be any different if the client controlled more? Any update the client made would need to be sent to the server so that the other clients could know about.

Currently the flow is more or less the following: Game action > Server request (same time: If possible update visual) > Server responds with next move.. Here, the next move is either nothing if the request is valid, or an order to move to the last position/state if the move is invalid. This is still something I'm thinking of.

It's not that hard to move from client to server, but for the moment I see no reason to remove control from the server.
xarn wrote: ...oh ...I wrongly assumed it was turn based, that each player only played on its turn.
No, the idea is that the software should be as similar to a real table/game as possible and thus only limited restrictions are imposed. Cards can be moved freely whenever the user wants, naturally the other clients (there could be more than one) will be updated, but almost any action is allowed. Some exceptions are related to places where you want to move the cards to, but most actions are free. This is also in the hope of minimizing inconsistency problems between clients.

This is, of course, the first version and much may change in the future but the basic structure and technologies will only be reconsidered if there is strong arguments to it.
Rejoice! For very bad things are about to happen.
Post Reply