Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Conceptually speaking how would one go about writing an achievement system for a website using PHP and MySQL?
Is the only real way of doing it is to constantly do MySQL queries to test for achievements and such?
You have two options, and most likely can combine them:
You can have a cron-job that runs every X-minutes, and runs over the database looking at each user and checks if they deserve a new badge.
For example, StackOverflow implements this for the Nice Answer badge. Everytime it runs, it checks how many Answers with +10 upvotes you have, and sees if you need to be awarded another badge. (It sees 5 posts with 10 upvotes and 4 Nice Answer Badges, you get a badge). Jeff has already stated that this means if you get an answer that gets a 10 vote, then downvoted, and then another post gets 10 votes, you won't get a badge.
The second option is event-based triggers. Which are really simply:
$badgeSystem->giveBadge("Some Badge Name", $User_ID);
This can be used for events you know are happening. Like the Autobiographer badge. Chances are the user won't fill out his profile unless the submit button is pressed, so the site could just check if the user has filled out the entire thing, and if they have, and they still need the badge, they get it.
The cron-job should be used for actions that are constantly checked. Things like quantitative goals like visiting the site for 150 days, or editing 500 times.
The event-based trigger should happen when an event will only happen if the user doesa specific action, such as submitting a form.
(You could probably use either for almost any situation. The event-based trigger gives quicker feedback though..)
Another option is to use the API from a gamification platform company such as http://iactionable.com
You might want to consider asking a similar question on meta, to see if Jeff is willing to share any of his lessons learned in this arena. If you do, the question should be specifically about the way SO approached the problem. This question, however, is a perfectly valid question for this site (since it is asking about created a new project, inspired by what was done on SO).
I suspect, though, that the SO team has a job that periodically runs a set of queries to look for new badges to award, and then awards them. This is why badges aren't awarded immediately after the action is taken to earn them.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I want to develop a currency system on a custom forum I've been working on, but I don't know the best approach.
Should I add a new "gold" field to my user table and increment with sql statements?
id, user, pass, created_at, gold
Logic: user creates new forum post; update user table: gold + 1
OR
Should I add a transactions table that logs everything and do a count where user = x?
id, user_id, amount
1 3 1 (new forum post)
2 3 1 (new forum post)
3 12 -5 (item purchase)
4 3 -1 (deleted post)
5 9 1 (new forum post)
OR is there an even better approach?
It highly depends on what you want to do with it and which way to program you prefer.
To approach it with some facts though:
I expect a forum to be fast. For that you should only use simple Select. Functions like SUM() take a bit more time to perform. In a small system that will most likely not be a problem, but mysql-db usually scale very bad, so you should keep that in mind from the beginning.
You definitely want a way to track transactions. Mostly to be able to check what is actually going on. Even if you make a great system to deal with your gold you still want to be track what happened from time to time. For that it's handier to store transactions.
Redundant data and transaction synchronization can be a problem. Every transaction system has the problem to keep everything synchronized. With MySQL that's not so difficult, as tables can be locked while you perform transactions. But redundant data is way more of a pain. You have to ensure that you change data everywhere at the same time before other actions can interfere.
On a basic system I would store the data in the user-table and keep all transactions as a log in another table. But never use that for an output to the user. For any further it depends on what your system needs.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am wondering, when you want to make a php based games, that requires the player to wait for something, for example: I paid 100 gold to explore, and every 5 minutes I will receive loot. The exploration will ends in 30 minutes for example. I want to know, which is the best and why. Here are the options:
Keep record of starting time of the exploration command issued, then every time the one specific exploring player open the page, calculate everything and show the result then keep it in the database.
Make a cron job to calculate exploration of EVERY player currently exploring every 5 minutes and update it to database.
Make a cron job every 30 minutes to calculate and update everything for EVERY PLAYER, but also allow SPECIFIC PLAYER to update just like option 1.
option 3 is basically combination of option 1 and 2. Thanks for the help. I am not sure about the performance issue so I need to know from people who already had experience in this.
These are just some personal opinion, might not be the best choice.
2) is more of a general approach for multiplayer game that has player interaction, but it puts constant strain on the server, which seems to be over kill as I seriously doubt your game would have complex interaction between players.
1) is probably the way to go unless your calculation is very complex and take a long time. The possible drawback is that you'll probably have trouble handling lots of simultaneous request to update. But from what you describe I don't think that'll happen.
3)This is hard to comment on because I have no idea if your calculation-time would depends on how much time it has pass since last update. If you calculation is time-indepentdent, then it's a horrible method as you spend time to update data that no one might need AND you are open to traffic spike as well.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm sure all of you have seen at some point at some website some message - i.e. you logged in and it stated something like "There will be a planned maintenance downtime at Tuesday 5PM PST". And then you have the tick mark for the message. When you click on it, you don't get the message shown any more.
Now, my question is how to handle this in the database. I.e. if you have 1M registered users and you decide to store this "seen" record for every user you'll end up with a 1M table which has to be read from every time someone logs in. On the other hand, if you have 10 messages like that - of course your table grows much faster. And finally, there could be messages like "Johnny,Harry,Diane and 5 of your other friends have updated their profile."
You could have like 10-50 messages like that daily. What I'm trying to think of is the best approach to this. I've implemented a lot of solutions in the past but I'm rethinking and am wondering of how others in the community are handling problems like that!
Edit:
#hakre
Thank you for your comment. Actually, I did describe one way I handled it in the question itself. Don't get me wrong but if I propose solutions, answers tend to discuss those proposed solutions which isn't something I'd like.
Do you have any NoSQL at hands?
I use redis, and I would create an set with all the users ids as members of the set (add the ids if the user should be marked as seen)... To check if the user has seen the message a simple SISMEMBER will suffice and it's O(1)...
Plus, you won't need any db query or alter table for the seen field.
http://redis.io/commands/sismember
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am new to making games, and I am writing one for fun using php and javascript. I am using MySQL to store all of the info of the users of the game. The game is kind of like managing a sports team. You have a few variables (cash, assets, players, staff, etc...) and you take on all the roles of a sports manager. I know it exists, this is just a personal challenge.
My question is, what is the best and most efficient way to get information from the database into the game?
1. Do I have to run an sql query on every page?
2. Do I have to update my database EVERY single time something is updated?
3. Is it possible to get all of the information from the database when the user logs in, let him/her play, then only update the database with the new information when the session is killed?
Sorry for the lack of code, just looking for a starting point because it would be helpful to me to know this before I start writing a lot of the game.
Thanks
No, you don't necessarily have to run a MySQL query on every page load. You could store the results of such queries in a cache system such as memcached, or keep necessary data in $_SESSION.
No, you can use similar workarounds as before, but if the user disconnects you may end up with unsaved changes.
Well, you could load the data relevant to the user and write your own session handler for saving the data when the session is destroyed, but although I haven't ever tried it I would say there's a very real risk of losing data if, for example, your server is restarted or PHP's garbage collector callback is not called for some reason.
Overall, I think you may perceive SQL queries as much heavier than they actually are. If your database structure and indexes are set up correctly, your queries and updates shouldn't take longer than about 0.01 seconds each to complete.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Given a product id, associates have to navigate a vendors website, log in, perform a search, in order to get details on a product for a customer.
My employers want a program that can use the product id, and navigate the vendors website, and perform the search and everything to get the information thus saving the associate from having to manually repeat this task every time a customer wants more information about a product.
I know many sites use methods to prevent (CAPTCHA) exactly what I am trying to do. So I do not know if that automatically makes my given project an "evil" one. But I certainly do not have evil intentions, my employers simply want to save associates time on getting information that they are going to get regardless. However, if this is "evil" please explain why, so I can explain to my employers why we should not go down this road. That being said...
How can I make something like this in PHP?
It depends on what site you are trying to access. Many sites have an API that can be used to access data. If that's not the case, you may need to write a program that loads the html using a GET request, parses through the response, and retrieves the information you want. Without more details, that's the best answer I can give.
To start with I'd recommend reading up on cURL and DOM
cURL: http://php.net/curl (for fetching pages, even simulating search form)
DOM: http://www.php.net/manual/en/book.dom.php (to parse the fetched pages)