Multiple choice answers sort of....

[salukigirl]

I'm trying to make a training system for a pet game I'm making. What will happen is the player is asked a question and is given 4 anwers to choose from, if they get it right their pet knows 5% more of what they are training it. (there will be a meter to show what % it has learned) and if they get it wrong 5% is taken away (unless it is 0%, then it just stays at 0%)

I'm not quite sure how to set the page up but it will be for a specific animal(one the player chooses)

Varibles to know:

Pet_name
pet_type
pet_id
pet_owner
ptraining
sit
down
rollover

The words in red are the training fields that the % has to be incresed.
Based on the different kind of training each of the questions will be different, but I'm just looking for a basic template on how to accomplish this......... :happysad:

 

[oscetips]

how good is your web design and programming skills?
easiest way i'd set it up is have your pet variables (Pet_name, pet_type, pet_id, pet_owner) in a mysql database.

create a frontend form, offer the options to the user, and when they've selected an option, they'd click [Submit] button to post the fields to a php script which can then update the database.... hows that sound?

 

[salukigirl]

I get what you mean, but how to I set which answers are correct, and how do I update the pet's training varible by a precent?

 

[leafypiggy]

http://www.w3schools.com/PHP

Look at ALL the tuts there. They will help a lot

 

[woiwky]

Personally, I think the best set up would be 3 tables. One to store the tests, another to store the questions, and a third to store the answers(both right and wrong). This would provide the most flexibility and make it easy to edit tests from an admin section.

The tests table would have to store at least the test id, name, and possibly which stat it's meant to increase.

The questions table would need columns for the question id, test id, and id of the right answer.

Then the answers table would just need 3 columns for the answer id, corresponding question id, and the text of the answer itself.

Generation could then be done by selecting (possibly random) questions along with the right answer and some random wrong answers. And grading would be done just by comparing the given answers to the right answers.

 

[salukigirl]

http://www.w3schools.com/PHP

Look at ALL the tuts there. They will help a lot

That doesn't help at all, all those are are function tuts. What I am doing is much more advanced =/ :thumbsdow
Edit:

Personally, I think the best set up would be 3 tables. One to store the tests, another to store the questions, and a third to store the answers(both right and wrong). This would provide the most flexibility and make it easy to edit tests from an admin section.

The tests table would have to store at least the test id, name, and possibly which stat it's meant to increase.

The questions table would need columns for the question id, test id, and id of the right answer.

Then the answers table would just need 3 columns for the answer id, corresponding question id, and the text of the answer itself.

Generation could then be done by selecting (possibly random) questions along with the right answer and some random wrong answers. And grading would be done just by comparing the given answers to the right answers.

I get what you mean. thanks I'll try that out

 

[mattura]

Why not use a single table for the tests/questions/answers?
you could have fields:
id,question,ans1,ans2,ans3,ans4
where ans1 is always correct (you can use php to shuffle how the choices are presented). If you have multiple tests, just add a field to indicate which test set each question belongs to. The rest is all queries...

 

[woiwky]

Why not use a single table for the tests/questions/answers?
you could have fields:
id,question,ans1,ans2,ans3,ans4
where ans1 is always correct (you can use php to shuffle how the choices are presented). If you have multiple tests, just add a field to indicate which test set each question belongs to. The rest is all queries...

One table is possible, but sloppy. Two tables is more flexible, but having to add more columns to add more answers isn't really good practice. Plus you'd have to store the answer text in the value of the (assumed) radio buttons and compare that rather than numeric ids, which is again not good practice. Three tables offers the most flexibility and ease of use.

You should always format your db in whatever way is most malleable and efficient. Since you can deal with multiple tables in a single query, there's really no reason not break up common data into more manageable groups.

 

[marshian]

I think the best database structure would be something like this:

• questions
  • id
  • question
  • response1
  • response2
  • response3
  • response4
  • rightanswer
• pets
  • id
  • owner
  • name
  • type
  • training
  • sit
  • down
  • rollover
• users
  • id
  • {anything you know of your users goes here}