Yes and rule one of asking for help is to use abbreviations and jargon with care as the person reading your post might not know what "NPC" means. I used to mess around with early RPG systems in college decades ago (D&D, Arduin Grimoire...), but "NPC" means what exactly?
This sounds like a kind of modified contact manager where each contact is a character in the game and the contact record--instead of recording name, address, job title, social media links, phone numbers, etc, it records data about that character. Lists of information associated with a given character can be created in a related table and displayed in a portal and there is no reason why such a set of records or any other kind of list save a use values from field value list, can't list the same item more than once.
This has me feeling nostalgic. It was designing a database in BASIC (Not visual Basic) on an old TimeShare minicomputer at the local JC in order to manage a lot of the minutia of running a game that changed my Major from PreMed to CompSci...
Thank you for your answer!
I apologize for the abbreviation, "NPC" of course meaning "non-player character" (as in, animals or other intelligent beings).
I share your attention to detail regarding the subject and love using a database system for designing and testing a game.
Please excuse me for elaborating, but let's say I have tables "NPCs" and "Items", both with an "Attack" field. How can I make an item on the list (the "inventory") affect the NPC's "Attack" value?
I'm reading and watching tutorials as I go but would really appreciate some help. :)
We just called them "monster encounters" and the original point of that old BASIC program was to produce a report where each line of a print out represented a check for a possible monster encounter of from 0 to N monsters from a type selected from a list and from a particular direction (and different values assigned to each listed creature). To check for a possible encounter, I crossed a line off the list instead of rolling dice--which made game play a lot faster with encounters that were both more varied and detailed than the dice and chart method it replaced.
To answer your question, you have both summary fields and aggregate functions that can take the sum, count, maximum or average of a set of values from a related table. So if you had three related records documenting three different attack methods/weapons for a given character, a function could compute the max or sum of the attack values recorded in those three related records depending on whether you want a value representing the most powerful attack or a cumulative characteristic.
Thank you again, PhilModJunk!
I have now learned how to display the inventory itself with items I can choose, but when I make a summary field (for example; "Bonus Attack" to add to the "Attack" of the NPC) I can only choose a total of fields from the current table.
In this case, I would like the "Bonus Attack" of the NPC be a total of all the "Bonus Attack" values of the items shown on the inventory.
To give an example, let's say I have a knight with two swords, both with a "Bonus Attack" value of 10. The "Bonus Attack" of the knight in question should now come to a total of 20. What am I missing here?
What described was not a summary field, but a calculation field using an aggregate function.
To use a summary field--which works but doesn't update as smoothly during some data entry tasks--you would define the summary field in the related table, not the NPC table.
So you can use a calculation field with Sum ( RelatedTable::Field ) defined in the NPC table or a summary field that computes the same total but which is defined in the related table.
I thought it worked for a second but encountered another problem;
The calculated field (sum of the "Bonus Attack" values) takes only one of the identical items into account, for example; The "knight" has two swords (10 "Bonus Attack" each) and another item (5 "Bonus Attack"), which should come to a total of 25, but comes to 15 instead (omitting the other sword).
Thank you again for your help.
Do you have 3 records in the table or 2 records with a field that indicates that you have 2 swords?
If you have 3 related records what you describe should not be the case.
If you have two records, one for each kind of "attack record" with a Qty field of 1 for the bonus attack and 2 for the number of swords, then you need to add a calculation field that computes: Qty * AttackStrength in order for either the sum function or summary field to be able to correctly compute a total by summing this calculation field.
I did have 3 separate records which didn't work for some reason, but tried using a quantity field and finally made it work and compute correctly.
Thank you so much for your help! :)
The three separate records should also produce the correct total as well. Using such a field to show a total for the records shown in a portal--which will be a set of related records, is a very common use of such a calculation field. (Just don't use a number field with an auto-entered calculation.)