I would like to create a chess multiplayer game,1player vs 1player .
I will use flash for animations and client and a server-side language for checking if the moves are correct, record each player action to a database, decide winner and give some credits to the winner.
My main programming language is PHP and I will have someone do the flash work depending on my directions.
I would like to know if anybody tried to do this before , or if you have any tutorial, guide, steps to follow when developing p2p games ? I want to do this efficiently and to be able to support up to at least 100 players on a VDS with 512 RAM .
I am planning to have the game work like this :
1) Initialise variables like credits, player names inside the flash client , after retrieving them from php
2) Start the game
3) If I am player2 and player1 is thinking of a decision, the flash client will send requests to the PHP file to check the database if player1 made any decision. If so, it will be my turn to do a decision and move a piece
4) When my turn comes , no requests are sent to the PHP anymore, until I want to move a piece . When I try to do that ,it sends a request and the PHP will check if my move is valid, and return some variables that flash will use to show error or move pointer back to player1
The game will also have a timer that will sync with PHP. Each player can think 20 seconds to do a move.
1)Any suggestions for my implementation ?What im looking for are suggestions to improve efficiency on this and reduce server load and if someone ever had any experience with a similar project, how did they do it, or how would they do it ?
2)My implementation of periodical HTTP requests isnt such a good idea, because I know that the server can become overloaded, I'd like to know if someone can suggest any alternative but secure option . 100 users at the same time would mean about 100 HTTP requests/second. Is that a number that a VDS can handle for days ?
Later Edit :
After the replies that I got on this post , I came to the conclusion that using sockets instead of HTTP requests every second would be the best idea to use when waiting for a move on the opposite player.
My game would have 100 tables available for players, with 1 socket for communication and 1 port for each table . So 1 socket with 100 ports. PHP will communicate to flash the socket and port for the table , when the game starts and the initialisation variables are sent.
I plan to use flash to listen to the socket server and see what happens when the opposite player must move .
When I move , flash will check if the move is valid from it's side, then send data to PHP . PHP will return OK or NOT and will also update the data on the socket port.
About the socket , Im not sure javascript would be a good option for this, so Im thinking about PHP sockets or JAVA sockets.
PHP sockets seem to be my first option , due to familiarity with the language.
My 2nd would be to rent a smartfoxserver and my 3rd would be to use the services of Player.IO.
Im planing to create a very nice game and sell it. The graphics are pretty much done and they look great. The hardest part is doing this efficiently and easy to install after.
Thank you for your time ! Regards
The server load for a game like this should be really minimal. If you're using flash, I would take advantage of the socket object and just open a socket to your server, that way you don't need to pester it with questions about what has changed... it will notify the clients when/if something noteworthy has.
Otherwise your plan is a pretty good one, so, you'll probably have to ask some specific questions about things that you're stumped by.
If you REALLY want to reduce server load, write the chess logic in the flash client and let IT decide if an attempted move (by the player) is illegal, or if the player has lost or whatnot... use the server strictly for message relay and data storage.
It's sometimes a mistake to design a project around what you have available, such as PHP knowledge and access to a server with 512 MB of RAM. There are a lot of projects where you should consider your resources first, but an independent, first time game project isn't one of them.
Even though your primary language is PHP, you shouldn't restrict yourself from working on the Flash portion yourself. Also, using a web server and database as a communication method for a multiplayer game will result in some very clunky behavior.
You aren't limited by your VDS either. You can use a micro instance on Amazon EC2 for free for a year. If setting up an EC2 server from scratch seems daunting, there are tutorials all over the internet that take you from start to finish.
The front end of your game can be written in Javascript or Flash AS3. There are a lot of game development libraries available for both. Flixel, Flashpunk, and PushButton are free AS3 game libraries. MelonJS is a Javascript/HTML5 game library. All of them have extensive documentation and a good community.
You can write the server backend using node.js and use socket.io to handle your game communications, even if you don't know anything about packets -- or you could use something like Player.IO if you want to pay a little money and have an outside service worry about that for you.
If you write the backend properly, one hundred users won't be a problem for your server. You'll need to start thinking about new hardware when you get in the thousands.
And since you're looking for general game making advice, start reading articles on blogs like #AltDevBlogADay. You'll pick up a lot of insight on design from other people passionate about games.
Related
I am a programmer at an internet marketing company that primaraly makes tools. These tools have certian requirements:
They run in a browser and must work in all of them.
The user either uploads something (.csv) to process or they provide a URL and API calls are made to retrieve information about it.
They are moving around THOUSANDS of lines of data (think large databases). These tools literally run for hours, usually over night.
The user must be able to watch live as their information is processed and is presented to them.
Currently we are writing in PHP, MySQL and Ajax.
My question is how do I process LARGE quantities of data and provide a user experience as the tool is running. Currently I use a custom queue system that sends ajax calls and inserts rows into tables or data into divs.
This method is a huge pain in the ass and couldnt possibly be the correct method. Should I be using a templating system or is there a better way to refresh chunks of the page with A LOT of data. And I really mean a lot of data because we come close to maxing out PHP memory and is something we are always on the look for.
Also I would love to make it so these tools could run on the server by themselves. I mean upload a .csv and close the browser window and then have an email sent to the user when the tool is done.
Does anyone have any methods (programming standards) for me that are better than using .ajax calls? Thank you.
I wanted to update with some notes incase anyone has the same question. I am looking into the following to see which is the best solution:
SlickGrid / DataTables
GearMan
Web Socket
Ratchet
Node.js
These are in no particular order and the one I choose will be based on what works for my issue and what can be used by the rest of my department. I will update when I pick the golden framework.
First of all, you cannot handle big data via Ajax. To make users able to watch the processes live you can do this using web sockets. As you are experienced in PHP, I can suggest you Ratchet which is quite new.
On the other hand, to make calculations and store big data I would use NoSQL instead of MySQL
Since you're kind of pinched for time already, migrating to Node.js may not be time sensitive. It'll also help with the question of notifying users of when the results are ready as it can do browser notification push without polling. As it makes use of Javascript you might find some of your client-side code is reusable.
I think you can run what you need in the background with some kind of Queue manager. I use something similar with CakePHP and it lets me run time intensive processes in the background asynchronously, so the browser does not need to be open.
Another plus side for this is that it's scalable, as it's easy to increase the number of queue workers running.
Basically with PHP, you just need a cron job that runs every once in a while that starts a worker that checks a Queue database for pending tasks. If none are found it keeps running in a loop until one shows up.
i cam across some older topics about this but since there is a lot of new techniques for creating web content i have to ask again.
My background:
I have good knowledge of xhtml/css/javascript/php/mysql. I have no trouble making a webshop from scratch including a comprehensive database and a cms to easily add/modify products. I am very comfortable using PHP and mysql to store data. A attempt at a tribal wars clone does not scare me at all. I also made a couple of games with c#/xna but i am still considering myself novice. I dabbled with flash and feel this could probably be used to get the result i want.
My project:
A 2D mmo tactical shooter. Players should be able to move across a fairly large maps and get position updates of other users very quickly. The game will hold a lot of maps and most maps should be able to handle just a couple of players. Hub maps and maps of interest however should be able to handle at least 100 players without lag.
It would be awesome if combat could be resolved real time on the map but i already thought of other ways to resolve this like opening an instance map where players could enter to join combat. I'm also considering a more tactical turn based approach on combat but it depends on the pro's and con's of real time combat.
To sum it up:
I am sure i can manage everything except for the graphical implementation. Mysql should not have much trouble querying the local player positions in a couple of milliseconds.
I cam across a game named Deeppolis that pretty much resembles graphically what i want. I'm still considering making this as a downloadable client but i am very interested what my options are if i'm going to do this browser based as browser based games tend to get more people attracted.
Thanks for reading this wall of text :D.
you would not want to "query mysql" to get player positions if this is real time. You will want to create a socket server that all clients connect to. the socket server would keep a subscriber list of all connected clients in memory. this way when one client sends a message to the socket server, the socket server can immediately push needed data to whichever clients need it. you would also want to keep a model of the game state in memory in your socket server to prevent cheating etc. you would only use a database for long term storage, everything else should be in memory. also keep in mind shared servers will likely not allow you access to sockets to create a socket server, so you will need a private server.
client side: javascript & socket.io (socket client)
server side: javascript & node.js (socket server)
I am building a poker game via html/php/ajax (and some other stuff) NO-FLASH .
I have little experience in programming games , so i have small question !
assuming ur playing poker , how your browser will know that some player threw a card ?
shall my browser send ajax request to know if somebody made a move ??? or is there anyway to treat ajax->php like a socket ajax<->php ??
I hope someone understands my question , thanks
Depending on the amount of traffic you'll, face, a good idea is to use a Message Queue server, such as Apache ActiveMQ along with something to allow all browsers to connect to ActiveMQ and receive 'push' messages from it, on the lines of Orbited 2 - this one is prepared for changes on the websocket protocol as new reviews are generated (not sure a consensus over the protocol has been reached yet).
The best bet for you is to research a relatively old technology, but not widely used (I mean, when compared to Ajax) that is known both as Comet and Ajax Push.
It's obvious there are several other implementations, such as APE, and you would probably want to pick the one (whose programming language and/or API) you feel mostly comfortable with.
Why is HTTP-Polling so laggy?
What I have is a button, and whenever a user clicks it a MySQL database field gets updated and the value is displayed to the user. I'm polling every 800 milliseconds and it's very laggy/glitchy. Sometimes when clicking the button it doesn't register it. And I actually need to be polling quite a bit more frequent than every 800 milliseconds.
This is also with just 1 user on the website at a time... When in the end there is going to be many at once.
HTTP-streaming/Long-polling/Websockets instead of polling
When you need real-time information you should avoid polling(frequently). Below I would try to explain why this is wrong. You could compare it to a child in the back of your car screaming every second "are we there yet" while you are replying "we are not there yet" all the time.
Instead you would like to have something like long-polling/HTTP-streaming or websockets. You could compare this to a child in the back of your car telling you to let him know when "we are there" instead of asking us every second. You could imagine this is way more efficient then the previous example.
To be honest I don't think PHP is the right tool for this kind of applications(yet). Some options you have available are:
hosted solutions:
http://pusherapp.com:
Pusher is a hosted API for quickly,
easily and securely adding scalable
realtime functionality via WebSockets
to web and mobile apps.
Our free Sandbox plan includes up to
20 connections and 100,000 messages
per day. Simply upgrade to a paid plan
when you're ready.
http://beaconpush.com/
Beaconpush is a push service for
creating real-time web apps using
HTML5 WebSockets and Comet.
host yourself:
http://socket.io:
Socket.IO aims to make realtime apps
possible in every browser and mobile
device, blurring the differences
between the different transport
mechanisms
When becoming very big the "host yourself" solution is going to less expensive, but on the other hand using something like pusherapp will get you started easier(friendly API) and also is not that expensive. For example pusherapp's "Bootstrap" can have 100 concurrent connections and 200,000 messages per day for $19 per month(but when small beaconpush is cheaper => do the math :)). As a side-note this plan does not include SSL so can not be used for sensitive data. I guess having a dedicated machine(VPS) will cost you about the same amount of money(for a simple website) and you will also have to manage the streaming solution yourself, but when getting bigger this is probably way more attractive.
Memory instead of Disc
whenever a user clicks it a MySQL
database field gets updated and the
value is displayed to the user
When comparing disc I/O(MySQL in standard mode) to memory it is extremely slow. You should be using an in-memory database like for example redis(also has persistent snapshots) or memcached(completely in memory) to speed up the process. I myself really like redis for it's insane speed, simplicity and persistent snapshots. http://redistogo.com/ offers a free plan with 5MB of memory which will probably cover your needs. If not the mini plan of $5 a month will probably cover you, but when getting even bigger a VPS will be cheaper and in my opinion the prefered solution.
Best solution
The best solution(especially if you are getting big) is to host socket.io/redis yourself using a VPS(cost money). If really small I would use redistogo, if not I would host it myself. I would also start using something like beaconpush/pusherapp because of it's simplicity(getting started immediately). Hosting socket.io(advice to play with it on your own machine for when getting big) is pretty simple, but in my opinion more difficult than beaconpush/pusherapp.
Laggy/glitchy? Sounds like a client-side problem. As does the button thing. I'd get your JavaScript in order first.
As for polling, 0.8 sounds a bit time-critical. I don't know about most countries, but here in the third world simple network packets may get delayed for as long a few seconds. (Not to mention connection drops, packet losses and the speed of light.) Is your application ready to cope with all that?
As for an alternate approach, I agree with #Vern in that an interrupt-driven one would be much better. In HTTP terms, it translates to a long-standing HTTP request that does not receive a response until the server has some actual data to send, minimizing delay and bandwidth. (AFAIK) it's an older technique than AJAX, though has been named more recently. Search for "COMET" and you'll end up with both client- and server-side libraries.
there are many things that might cause the lag that you are experiencing. Your server might be able to process the requests fast enough, but if the connection between your client and the server is slow, then you'll see the obvious lag.
The first thing you should try is to ping the server and see what response time you're getting.
Secondly, rather than poll, you might want to consider an interrupt driven approach. This means that only when your server replies, will you send out your next request. This makes sense, so that many clients won't be flooding the server with requests till the point the server cannot cope. This is especially true, then the RTT (Round-Trip-Time) of your request is pretty long.
Hope it helps. Cheers!
A good place to start would be to use a tool like Firebug in Mozilla Firefox that will allow you to watch the requests being sent to the server and look for bottlenecks.
Firebug will break down each part of the request, so you can see if you are having trouble talking to the server or if it is simply taking a long time to come up with a response.
Along with #Vern's answer I would also say that if at all possible I would have the server cache the data ahead of time and then all of the clients will pull from that same cache and not need separate MySQL calls to reach the same data for every update. Then you just have your PHP update the cache whenever the actual DB data changes.
By cache I mean having php write to a file on the sever side, and then clients will simply look at the contents of that one file to see the most updated info. There might be better ways of caching, but being that I have never done this personally before, this is the first solution that popped into my mind.
I want to start a project for facebook and the application will be like real-time multiplayer chess game. The problem I'm having is I have no idea how to store the data when a player moves one piece and update the new position in player2 browser. I'm gonna use PHP, MySQL for server side and jQuery for Client Rendering. The simplest idea is to store the data in XML or MySQL and re-generate the result to player2 browser. But I know that when thousand of players are playing, it will not be an efficient way. Since I don't have time to study new language for this project, I'm gonna have to stick with PHP. I'm not going to use flash either because I want my client side light-weight and flash-free. So is there any way that will solve my problems?
you would have to be polling server for update every.. maybe 2 seconds, depends on server load. If you used flash, there would be another option - to use sockets, it's much more suitable for multiplayer games, but i don't think you could make it without some third-party runtime.. HTML5 has some kind of websockets, but it's very bad when it comes to cross-browser compatibility
I guess going through a server is your only option. That is to store the game status is xml or a sql db. And than the clients need to frequently poll this status, e.g by jquery ajax. Having the clients to communicate directly p2p is not possible with standard web components.