Non linear storage question.

[cooldude832]

I'm trying to make a game.  A module for this game will be a quest feature, in which I can define random quest each day for you to fulfill.  Such as defeat X things, or take item A to Location this.  My idea is to assign a limited number of quest to distribute each day (as a promotion to get people on my game as they never know when a quest will appear as it is handled by cron, the creation that is).  My problem is this.  My quest have no logical bearing to the data storage between quest of killing stuff and Taking stuff somewhere.  My idea was to make a few generic tables like a Kill X things table, a Take This to point B table etc that I could handle much easier, trying to store in a single table.

I think this can be easily handled given each opponent and character/location is defined  (well the opponents type are, the individuals are not), so I would just need to define my quest saying Item to take = Item Type 1093245 and Person to =  345890543.  and then I have some sort of trigger where if you initialize talk with them it be like Give person 345890543 Item 1093245? and it would handle this. 

 

Any ideas on if this sounds pheasable, or an easier way?

[kratsg]

Well, here's my take.

 

Define your scenarios:

 

Take item A to Person B

Kill X of Monster A and report back to Person B

 

Then, just do a random number generator that will randomly pick a scenario to define random values for.

 

So if I randomly pick item A to Person B scenario, you would have a database of all items, and a database of all people. Randomly pick a row out of each table (under certain limitations I assume, like item price or type of person), combine them together, place in a new row in a table, then just have a check to see if a quest exists for that person etc... IE: quest type=1 and so on..

 

Quest Table:

Item A|X Amount|Monster A|Person B|Scenario Number (contains all variables for all scenarios, combined, the union of..)

 

Then you just look up scenario number, grab the variables you need, and do w/e...

 

I kinda like the idea of this method, it would allow you to add new quests easily, without any hard or major coding.

[cooldude832]

except I will have more than 2 quest types, meaning I don't want to have a bunch of wasted table space when only 1/10th of the fields would be used.  I think I will just have to make each quest type a table + a centralized database that will contain all the repeated data, linking with the centralized key.  I was thinking along the lines of expanding the table as be, but I just don't think it will be a smart idea to have a 100 field table and only be using 5-10 of them.

[kratsg]

Basically, one table contains all the different types of quests, with their unique ids.

 

Then you have another table that contains the ongoing quests, that links to the main quest id table to determine exactly what quest that user is doing.

[cooldude832]

I don't think you get the point, I have a lot of tables

 

Users

Battles

Main_Quest

Quest_type A

Quest_type B

Quest_type C

etc..

Map

Map_tiles

etc

 

And a few others.

[teng84]

i guess this is not php ! i think this is sql issue

[cooldude832]

well my idea is if a flat file would work better, but its really a storage idea.

[kratsg]

How will you determine if a user has a current on-going quest?

 

Also, ask yourself, and answer, "What do I want to store temporarily, what do I want to store permanently?"

[cooldude832]

The active quest is very easy, as I have a table of it with Primary Key and the questID and Completed or not, and then it checks the main table if it is expired or not.

[kratsg]

How about shifting the quests over to the flat-file first?

 

IE: that's a lot of queries. Stick all the active, on-going quests into a flat-file, and only save them into the database if they have been completed. This COULD reduce the number of queries sent back and forth between the user and the database. It depends though, the idea of applicability. Does it matter, back-end or front-end if you use flat-files or database?

 

I'm sure front-end may see some speed boosts, but back-end would definitely see some efficiency if we used flat-files and moved over to database when needed.

[cooldude832]

I have come to this conclusion

 

A) I need to define each quest type as its own table

B) I need a centralized table  of quest with fields like QuestID, NumbertoRelease, TimeOpen, TimeClose, Timelimit Reward, QuestType

C) Individual tables that define the QuestType of table listed in B

D) A third table that defines, User 12345 accepted quest 123 at Time

 

Then I need to define some functions for each of the tables in D, like in a kill X of Y things, I need to draw data of my battle table that says select count(*) from `Battles` Where UserID = '".$userid."' and Time >'".$quest_start."' and $Time < '">$quest_end'"";

My issue with this is in a battle you can battle anywhere from 1-4 opponents, and so 1 row could have 2 "wolves", I think it will be easier to query it each time, than update a count.  My issue is I need to count only the Oppoent1, opponent2, opponet3, oppoent4 files that equal the given opponent type.  Any Ideas?

[kratsg]

Why not, in the quest table, have a column labeled "enemy" and another column labeled "tokill" and then "killcount" such that "tokill" contains the number you have to kill, "killcount" is how many has been killed, and "enemy" is what you have to kill...

 

I'm not quite clear what your vision of the database tables would look like.. Perhaps illustrate some?

[otuatail]

What you need is all quests in a flat table with a field set to Kill=1, or take=2

 

a table of compeditors with a pointer into the current quest.

[otuatail]

I think i get it. But as above the quest table flat bed with a field of type of quest

 

Each compeditor has his own table with

pointer to A quest

Number to be killed STILL

completed booll

 

The next quest can't be atempted untill the last is completed.

Each task table will be generated with a mixture of tasks and kills.

 

Desmond.

 

[cooldude832]

The naming system is transparent, but I will have a generic array of this data stored.  As for my tables I have

 

Users Table:  UseID, Username, Password, Location (for map), Hp, Other stats

Inventory:  This is being stored by a # of a given item type, Not each item individually so it has ItemType, UserId, ItemCount

Battles: BattleID, UserID, Opp1, Opp2, Opp3, Opp4, Opp1Hp, Opp1,str, Opp1 other stats, Timestart, Timeended.

Quest_gen: QuestID, Q_Type, Number Open, Number Total, Tstart, Tclose, Reward

Quest_type1: Quest Type specific info like a battling quest or a gathering quest, etc

Items: Defines each Itemtype

 

That is my basic idea, The Quest_type1 is just 1 of a lot of potential tables,  it will contain each users individual quest actions.

[cooldude832]

I think i get it. But as above the quest table flat bed with a field of type of quest

 

Each compeditor has his own table with

 

The next quest can't be atempted untill the last is completed.

Each task table will be generated with a mixture of tasks and kills.

 

No I would have thousands of table, but I didn't think of having hte single open quest idea.  I think I might add that in

[otuatail]

To be quite honest. This is not realy a subject for this group. This is a PHP group for unique PHP orentated problems. You are trying to create a massive internet game with a database and multiple tables. your problem is not a PHP one, it is a database structure one and not even for the mysql group either.

 

you need to sit down with a piece of paper and draw some schema / flow control of the game and draw up a database layout. But it is not a PHP group problem. Sorry

 

Desmond.

 

[cooldude832]

To be quite honest. This is not realy a subject for this group. This is a PHP group for unique PHP orentated problems. You are trying to create a massive internet game with a database and multiple tables. your problem is not a PHP one, it is a database structure one and not even for the mysql group either.

 

you need to sit down with a piece of paper and draw some schema / flow control of the game and draw up a database layout. But it is not a PHP group problem. Sorry

 

Desmond.

 

 

Your so quick to accuse something of being something it doesn't because you don't get it.  It is a php issue, because there is a bunch of ways to do it with "php", and i'm triyng to get opinions on how to do it the best.  The backend structure can vary from extremely static, to full db, and I'm wondering if people have ideas on which will be best.

[kratsg]

Users Table:  UseID, Username, Password, Location (for map), Hp, Other stats

Inventory:  This is being stored by a # of a given item type, Not each item individually so it has ItemType, UserId, ItemCount

Battles: BattleID, UserID, Opp1, Opp2, Opp3, Opp4, Opp1Hp, Opp1,str, Opp1 other stats, Timestart, Timeended.

Quest_gen: QuestID, Q_Type, Number Open, Number Total, Tstart, Tclose, Reward

Quest_type1: Quest Type specific info like a battling quest or a gathering quest, etc

Items: Defines each Itemtype

 

That is my basic idea, The Quest_type1 is just 1 of a lot of potential tables,  it will contain each users individual quest actions.

 

To me, I like how this is set-up, and it's set-up beautifully. However, actions that a user takes should not really be defined in the database. As far as I'm concerned, a database only needs to know: the start and the end. The in-between can be appended to a unique flat file (which is preferrable).

[cooldude832]

yeah I think i'll run with, and work on specifics as they come.  I think it will require about 10-15 queries per page, but no big deal at that as I don't make sucky queries

[otuatail]

If you are trying to get help on the best way to query a database then that is a database issue.

 

Where is the PHP in "Select * from morons"

 

 

[cooldude832]

Ignorance only covered up my more ignorance. 

There is a huge amount of php to this, and I don't need to justify myself to you, if you can't say somethign nice than don't say anything at all.

[kratsg]

If you are trying to get help on the best way to query a database then that is a database issue.

 

Where is the PHP in "Select * from morons"

 

 

 

Uhhh.... the asterisk, gasp o_o we use it in regexp all the time, as well as php, and other various languages. This is PHP Help, meaning if they know how to do something, and they want to know some ways to go about doing something, they can query the board.

 

Anyhow, just remember with your queries to mysql_free_result after each one, just to help. Every little bit counts. You may want to look into OOP for this a little bit, cause in fact, it may be easier to define the function once, and just call it numerous times... I believe this would be a perfect example for OOP.

[cooldude832]

I've toyed with going OOP on this, but I think my limited knowledge of this will only inhibit my ability to make this work right, my limited knowledge on oop that is

[kratsg]

If you use the basics, you can handle it.

 

IE:

class Quests() {

var $questid;
var $time;
//add more variables to define for this class alone

function read_quest(){
mysql_query("SELECT blah blah FROM blah blah WHERE 'questid' = '$this->questid' ");
//other ways to read, etc...
}

//other functions that are general and helps you

}//end class

 

some php file

include 'above_class.php';//the class above

$quests = new Quests();
$quests->questid = "12";
$quests->read_quest();//runs the function, you can even obtain values from this as if it was a regular return value; thing IE:
$returned_value = $quests->read_quest();//as long as you code the return value; into the original function

 

That's the basics, then it goes on about constructors, extends and things I don't mess with atm.