As discussed in thread1575-1532816: A Disscussion On Where To Start? we are going to have a fairly complex data store, hereafter referred to as The Dictionary.

Now, The Dictionary can be anything from text files, INI files, DAT files, to dBase files (or Fox Pro), to an Access database, MySQL or even SQL. Now as for its structure I propose the following structure (based on an Access db).

tblWordsPhrases
iWordID        Auto Number          Indexed (No Duplicates)
iLenght        Number               Indexed (Allow Duplicates)
vWord          Text (255 characters)Not Indexed (No Duplicates)*

*vWord uniqueness is kept via business rule within program/sub program as new words or phrases are added in.

tblDefinitions
iDefID        Auto Number       Indexed (No Duplicates)
iWordID       Number            Indexed (Allow Duplicates)*
iDefNo        Number            Indexed (Allow Duplicates)**
mDef          Memo

*iWordID is used as foreign key
**iDefNo is use as you would see in a dictionary when a word has multiple meanings or definitions

tblSubWords
iSubID          Auto Number     Indexed (No Duplicates)
iPWordID        Number          Indexed (Allow Duplicates)*
iSWordID        Number          Indexed (Allow Duplicates)**

*iPWordID is used as a business rule foreign key to tblWordsPhrases.iWordID enforced within the program/sub program and points to those "Parent" words that are to be used for mixing the letters up for the jumble program (to be discussed sometime in future)
**iSWordID is used as a business rule foreign key to tblWordsPhrases.iWordID enforced within the program/sub program and points to those "Sub" words or words that can be made from the letters of the "Parent" word

tblThesaurus
iTheoID      Auto Number        Indexed (No Duplicates)
iPWordID     Number             Indexed (Allow Duplicates)*
iSWordID     Number             Indexed (Allow Duplicates)**

Note: Thought about an iOrder field as some thesaurus's have the most similar meaning words first and going on from there but if we follow this rule and use that order then we only need to use the iTheoID field to order by.

*iPWordID is as above for tblSubWords but this table is not for mixing the letters of a word up
**iSWordID is as above for tblSubWords but this field points back to words that have a similar meaning to the word that is pointed to by iPWordID

tblGenHint
iHintID      Auto Number           Indexed (No Duplicates)
iWordID      Number                Indexed (Allow Duplicates)*
vHint        Text (255 Characters) Not Indexed (Allow Duplicates)**

Note: See note for tblThesaurus
*iWordID, Foreign Key
**vHint, contains the text of the hint to what iWordID points to

tblHint
iHintID      Auto Number           Indexed (No Duplicates)
iWordID      Number                Indexed (Allow Duplicates)*
vHint        Text (255 Characters) Not Indexed (Allow Duplicates)**

Note: See note for tblThesaurus
*iWordID, Foreign Key
**vHint, contains the text of the hint to what iWordID points to

tblCWSub
iCWSubID     Auto Number           Indexed (No Duplicates)
vCWSubject   Text (255 Characters) Not Indexed (No Duplicates)*

*vCWSubject, Crossword subject

tblCWWords
iCWWordID      Auto Number           Indexed (No Duplicates)
iCWSubID       Number                Indexed (Allow Duplicates)*
iWordID        Number                Indexed (Allow Duplicates)**
vHint          Text (255 Characters) Not Indexed (Allow Duplicates)***

*iCWSubID, foreign key to tblCWSub.iSubID
**iWordID, foreign key to tblWordsPhrases.iWordID
***vHint, contains the text of the hint to what iWordID points to

tblJQ
iJQID       Auto Number         Indexed (No Duplicates)
iWordID     Number              Indexed (Allow Duplicates)
vQA         Memo                Not Indexed (Allow Duplicates)

Now, I am trying to get people to discuss various things about games in this forum, so if you have any questions please ask. If you have an idea for a word game and do not know how exactly it would work with these tables, please describe your game and hopefully one of us will be able to design or modify a table(s) above to suit that game.

Following is a list of games that I believe the above (off the cuff) design will work for.
Hangman
Word Jumble (make smaller words from larger word)
Word Scramble (puzzle where user needs to find words within a X by Y block of letters)
Wheel of Fortune
Jeopardy
Scrabble
Crosswords

Any other ideas?


 

I would like to add a field to this datastore design. The added field would be appended to tblWordsPhrases

bUsed        Boolean       Used for keeping track of which words have been used

A little experience to relate from doing a word game or two:

The problem with such a thing for word games is that you need to find a common set of words that will work in most cases.  The problem with one of the word games I have here is that you can easily come up with valid words that the game doesn't know.  

So the matter results in a lot of required effort, for most part, to get a common set of words that 1) most people would know (I loaded up my word list into the game above and found it snows in most players) and 2) would be reasonably complete (i.e. common words that most will recognize appear in it).

Next is the matter of true utility.  For a word game, most common words aren't beyond about 18-20 characters, and are easily searched in memory, so most of what is being described for fields isn't necessary in this context.  In fact, for most games, you can cull the dictionary down to 8-10 character words.  So your 255 character field is unnecessary.

Then there's data presentation.  For some games, reordering the words themselves would be useful (word scrambles?).  But for most, all is required is selection of the word and again that isn't too difficult at all, to require indexes or anything of the sort.  The biggest problem I see is the "is this a valid word?" question, and the easiest solution for this is to maintain a sorted and unduplicated list, load it into memory, and do a binary sort.

Truthfully, though, most of what has been posted here is simply overkill.

Measurement is not management.

Quote (me):

and do a binary sort.

That should say "binary search."
 

Measurement is not management.

Ahh... To begin with, it was stated that "The Dictionary" I would be using would be overkill in thread1575-1532816: A Disscussion On Where To Start? because I wanted to use unfamiliar words and not common words as to make this a learning game for both adults and children alike. Also the field does not only contain words but phrases and you would know this if you had read the note denoted by the asterisk(*) thus the field size. also lets not forget the longest word in the english language, supercalifragilisticexpialidocious. Then of course, even most of the commercial like games, meaning freeware, shareware, and example programs, have a limited word store and after awhile it is quite easy to figure out what word is displayed even before the user gives their first letter guess.

So in short. Yes, overkill for reasons as "The Dictionary" will be used for more than one game as noted at the end of the original post. I mean, how would you like it if you just quite hangman and started another game that used the same words? Bored? I would think so!

Okay, I lied, not "in short". Then lets also note that this structure is "proposed" and I am still waiting upon feedback from others who have joined in on previous conversations or others "who are interested" in sharpening their skills or are wanting to learn.

Now, back to overkill. Just because I want to use this datastore design does not mean that others have to use this design. As stated in the second paragraph "The Dictionary" could be anything from text files...



Man, was that defensive or what? Okay end rant in one moment. How does the saying go? If you don't have anything constructive to say...

Oh how I jest now...





In all seriousness, thanks for your input. I'm actually glad to see someone else join in on these discussions as less than 1% of the 1249 members of this forum have chimed in.