I'm building a ajax tic tac toe game in PHP/MySQL.
The premise of the game is to be able to share a url like mygame.com/123 with your friends and you play multiple simultaneous games.
The way I have it set up is that a file (reload.php) is being called every 3 seconds while the user is viewing their game board space. This reload.php builds their game boards and the output (html) replaces their current game board (thus showing games in which it is their turn)
Initially I built it entirely with PHP/MySQL and had zero caching. A friend gave me a suggestion to try doing all of the temporary/quick read information through memcache (storing moves, and ID matchups) and then building the game boards from this information.
My issue is that, both solutions encounter a wall when there is roughly 30-40 active users with roughly 40-50 games running.
It is running on a VPS from VPS.net with 2 nodes. (Dedicated CPU: 1.2GHz, RAM: 752MB)
Each call to reload.php peforms 3 selects and 2 insert queries. The size of the data being pulled is negligible. The same actions happen on index.php to build the boards for the initial visit.
Now that the backstory is done, my question is:
Would there be a bottleneck in that each user is polling the same file every 3 seconds to rebuild their gameboards, and that all users are sitting on index.php from which the AJAX calls are made within the HTML.
If so, is it possible to spread the users' calls out over a set of files designated to building the game boards (eg. reload1.php 2, 3 etc) and direct users to the appropriate file. Would this relieve the pressure?
A long winded explanation; however, I didn't have anywhere else to ask.
Thanks very much for any insight.
Use a socket server to share active game information, PHP & MySQL really shouldn't be used to maintain active game sessions.
An opensource example of a socket server would be red5, if you dont mind paying a bit then I would recommend Smartfox.
It's also not too difficult to set up your own socket server, if you're only using it for basic communication between clients.
each game gets its own file. eg, 459675.html or .txt or .json or w/e
this file can be an html page, or whatever you need to communicate the current state of the game.
the clients poll the webserver for the latest version of the file. the webserver acts like a good little webserver and serves this file extremely efficiently from disk because it doesnt need to do any scripting language junk to process the request.
when a client makes a move, it sends request to a script. script rewrites the file...repeat.
your webserver is probably already configured to send last modified headers for static files. your clients(browsers) already know how to do a conditional http request when they're given last-modified header. So, you get bonus efficiency boost for very little work.
Related
I have an HTML/PHP/JQUERY/MYSQL web application.
It's an HTML Bootstrap base, and jquery and other libraries plus my custom scripts, in front.
backend, i have several php files to serve the data.
For this example, say I have a CONTACTS php page where I need to display several data sets:
1) List of contacts
2) List of groups
3) list of tags associated with contacts
I have a backend php file in: engine/contacts.php
this is the php script that serves the contacts data as requested based on GET flags, eg:
engine/contacts.php?list=contacts
engine/contacts.php?list=groups
engine/contacts.php?list=tags
Sure i could serve them up in one call but , by design, each part of the web page (contacts, or groups, or tags) are separate datasets, and this way, if one data set is updated, i can refresh that part only.. eg:
user adds a group , then JS will ajax load:
engine/contacts.php?list=groups
to update the groups area (div)
So, basically, ON PAGE LOAD 3 separate JS calls are fired at the same time load data from the same contacts.php file
IS THIS AN OK Practice? I mean it should be because I see lots of sites doing the same .
And how does this impact the server side? Will the server execute this php file one at a time? will it be better if i separate the files? like:
contacts.php
contacts_groups.php
contacts_tags.php
and simultaneously call them?
The reason I ask is because I'm currently debugging some performance issues. Simply put, i have very light weight PHP/MYSQL web application with HTML5/Jquery front end. The datasets being handled is very minimal and the database tables having less than 50rows
But somehow my application is hitting resource limits on the shared host server, particularly on the 1GB RAM limit side. And i have reproduced this situation on a stand alone domain w/ no other users and it's still hitting the limits.
I have gone through the php scripts and can't find anything. I do have loops, yes, but they are thoughtfully done and terminates after a few iterations.
I'm out of ideas so I'm just trying to explore what else i can poke at.
Would appreciate some guidance, thanks
I think, if you use an OOP structure you can consider a method for handling each request in backend. Although the best way is to use a MVC framework to dispatch the requests with URL routing to special methods :
engine/contacts/contacts
engine/contacts/groups
engine/contacts/tags
I'm running an enterprise level PHP application. It's a browser game with thousands of users online on an infrastructure that my boss refuses to upgrade and the machinery is running on 2-3 system load (yep linux) at all times. Anyhow that's not the real issue. The real issue is that some users wait until the server gets loaded (prime time) and they bring their mouse clickers and they click the same submit button like 10 - 20 times, sending 10-20 requests at the same time while the server is still producing the initial request, thus not updated the cache and the database.
Currently I have an output variable on each request, which is valid for 2 minutes and I have "mutex" lock which is basically a flag inside memcache which if found blocks the execution of the script further, but the mouse clicker makes so many requests at the same time that they run almost simultaneously which is a big issue for me.
How are you, the majority of StackOverflow folks dealing with this issue. I was thinking of flagging the cookie/session but I think I will get in the same issue if the server gets overloaded. Optimization is impossible, the source is 7 years old and is quite optimized, with no queries on most pages (running off of cache) and only querying the database on certain user input, like the one I'm trying to prevent.
Yep it's procedural code with no real objects. Machines run PHP 5 but the code itself is more of a PHP 4. I know, I know it's old and stuff but we can't spare the resource of rewriting this whole mess since most of the original developers left that know how stuff is intertwined and yeah, I'm basically patching old holes. But as far as I know this is a general issue on loaded PHP websites.
P.S: Disabling the button with javascript on submit is not an option. The real cheaters are advanced users. One of them had written a bot clicker and packed it as a Google Chrome extension. Don't ask how I dealt with that.
I would look for a solution outside your code.
Don't know which server you use but apache has some modules like mod_evasive for example.
You can also limit connections per second from an IP in your firewall
I'm getting the feeling this is touching more on how to update a legacy code base than anything else. While implementing some type of concurrency would be nice, the old code base is your real problem.
I highly recommend this video which discusses Technical Debt.
Watch it, then if you haven't already, explain to your boss in business terms what technical debt is. He will likely understand this. Explain that because the code hasn't been managed well (debt paid down) there is a very high level of technical debt. Suggest to him/her how to address this by using small incremental iterations to improve things.
limiting the IP connections will only make your players angry.
I fixed and rewrote a lot of stuff in some famous opensource game clones with old style code:
well, i must say that cheating can be always avoid executing the right queries and logic.
for example look at here http://www.xgproyect.net/2-9-x-fixes/9407-2-9-9-cheat-buildings-page.html
Anyway, about performace, keep in mind that code inside sessions will block all others thread untill current one is closed. So be carefull to inglobe all your code inside sessions.Also, sessions should never contain heavy data.
About scripts: in my games i have a php module that automatically rewrite links adding an random id saved in database, a sort of CSRFprotection. Human user will click on the changed link, so they will not see the changes but scripts will try to ask for the old link and after some try there are banned!
others scripts use the DOM , so its easy to avoid them inserting some useless DIV around the page.
edit: you can boost your app with https://github.com/facebook/hiphop-php/wiki
I don't know if there's an implementation already out there, but I'm looking into writing a cache server which has responsibility for populating itself on cache misses. That approach could work well in this scenario.
Basically you need a mechanism to mark a cache slot as pending on a miss; a read of a pending value should cause the client to sleep a small but random amount of time and retry; population of pending data in a traditional model would be done by the client encountering a miss instead of pending.
In this context, the script is the client, not the browser.
I'm building a multiplayer game in PHP. Each game is split into stages that last a set amount of time - currently 2 minutes. In each stage, players work together for a set amount of time until the game either advances to the next stage, or the stage (and hence the game) is lost, and a new game starts again.
I have a vision of playing the game on an HTML page, where users can see how much time is left in the current stage through a constantly updating countdown clock. When the countdown clock reaches zero, the game either advances or ends, and the result is returned through Ajax. What I'm having problems with is the (theoretical) thought of 100 players playing the game simultaneously.
How do I call the update script? If I call it by running PHP, which player's browser calls it? If a player's browser refreshes the content one second before the stage actually finishes, what happens?
Is PHP the right language for a game like this?
"Is PHP the right language for a game like this?"
Yes, if you do it right. Here's how you do it...
Using a method called Comet, you can have multiple clients pulling data from the server, but only when that data is updated. It works something like this:
Client A makes pull request to server.
Server waits, keeping connection to Client A open.
Client B makes pull request to server.
Server waits, keeping connection to Client B open.
Client A pushes new data to server.
Server pushes new data to Client A and Client B through still open connections.
Client A makes pull request...
etc...
In other words, it means that all clients receive up-to-date information immediately it is pushed to the server by any client. This means you don't have to implement a "refresh every x seconds" system, which is good for 2 reasons:
1) You don;t waste time and bandwidth make requests to the server when nothing has happened;
2) All the clients get data pushed to them at the same time, that's absolutely up-to-date and not x seconds old.
In practice, Comet is implemented via AJAX. Google for some examples of Comet- it's pretty simple, and extremely useful.
In client-server games, your server should be running a simulation in parallel to the client's simulation (the game).
Usually the server simulation is authoritative, so that when, say, a match is over it will inform all clients in the match that the simulation state changed to "match over" or whatever. The client will then lock the UI or present a "Game Over" message or announce winners-- whatever you want.
So for you, your server should run the count down timer, while the clients keeping polling (via AJAX or WebSockets) the server for state changes. When the server's timer hits zero, the next time clients poll the server, the server will say, "Hey, yo-- the game's over!".
Edit
I'd also like to say that PHP will probably work, but you have to understand that PHP was built for web services, not games. Simple games like tic tac toe or checkers or chess can become quite complex when you toss in multiplayer functionality. Simulations often require threading. PHP can do threading but it can get very ugly if you don't know what you're doing.
Well, if you are using the PHP session system, the script will recognize the Ajax request as being from the same user who (for example) logged in into your game.
One second before the stage finishes, well you could return in PHP the time left to the stage so the javascript counter stay synchronized? Both the server and the clients must be aware of the status of the game, else expect hackers somewhen.
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 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.