I’ve had a time, I’ll tell you wut. My original category system got broken out into a classification and category system, with a classification being a top level and the category being a subset, which meant I had to go back and modify my existing test code (DB, DB Access, Routers, and website) to handle the new feeds. Not particularly difficult, but I did it because I needed to confront the difficult task of cataloguing not just a galaxy, but all of the items in it.

Like any game, Star Citizen has a lot of items — and will have a lot more before its completed. Because an item’s acquisition location is going to be unique (no one item is universally available at “a vendor”) many orgs have taken to compiling lists of where items are located in the game. On top of that, there’s always “The Meta” to contend with: which items will give a player the biggest bang for his or her buck — sometimes literally when we’re talking about weapons. There are many catalogues already in play around the web, but any org worth its salt is going to want to maintain their own list, if for no other reason than to ensure that they have all the info while possibly keeping some away from the public and behind closed doors.

To that end, I had to come up with a way to allow for an admin to approach the site with the intent of registering “a new item”. The easy way would be to figure out every item “type” in the game and to build a data store for it. I say “easy” only because it would be working entirely with known quantities; every FPS weapon has the same properties, which are different from every FPS armor piece, so an “FPS Weapon” table would have specific fields, and “FPS Armor” table would its own different fields. Considering the game is still in development, new items with new properties might appear or be removed at any time without warning. Rather than force myself to have to modify the data tables when this happens, I set up a dynamic property system test.

Classification and Categories

Classifications are top-level organizational records. We can expect to see entries such as “FPS weapons”, “Ship Components”, and “Clothing”. All items in the game will fall into a very broad classification. Each item will also sub-sort into a category. An “Energy (Laser)” category will belong to “FPS weapons” class, while “Jackets” will be a subset of “Clothing”. This is a parent (Classification) and child (Category) relationship so I can build a display that lists all categories with their classifications pretty easily.

Item Properties

Before an actual item is entered anywhere, there need to be properties ready for it. Using the Cornerstone universal item finder tool, I looked at a specific item (the FPS Weapon “Custodian SMG”) and yoinked the properties listed in the grid. As these properties are shared for all FPS weapons, these properties are linked to that classification via the classification record’s ID. Whenever a user wants to add a new item, they will have to select the classification to begin. This will present them with a form that will give them fields that match the data_type of the property defined in the database.

The data_type is a bit tricky because not all properties will be text or integer values. For example, on the CStone site, the FPS weapon class has a property column called “Type”. In my system, this value became a “Category” entry. That means that when a user is defining a new item of the FPS weapon class, when the “Type” property is being rendered, I have to use the data_type value to figure out what kind of input element to display. Text and integer can use normal text inputs, but when the data_type equals “Category”, I’ll have to load up a drop-down list which displays category records…and not just any category records, but records filtered by the new item’s selected Classification. That way no item will be classified as “Food” while also getting a category drop down offering “Quantum Drives”.

Property Values

Then comes the moment of truth. The user gives the item a name and description and enters values for all properties associated with the classification to which this item belongs. Saving the new record is going to mean one record for every property which links the item, the property, and the value. Using the Custodian as the example, there are seven properties for one item. When we get 10 single FPS weapon items, that’s 70 property records. At 100, we’re looking at 700 records. The number of records in the property value table is going to increase significantly over time, and we’re just talking about FPS weapons here. Later, when we get to something like ship components, which have at least twice the number of properties, the property value table is going to fill up fast.

Conclusion

Because the variety of items in Star Citizen would make it difficult if not impossible to “hard code” a schema to collect all details for any given item both now and in the future, I’ve created a test which allows for a classification to have associated properties. When an item is assigned to that classification, an admin can be presented with properties specific to that item classification, negating the need for regular database maintenance when new items are released, or existing items are modified. However, the one-value-record-per-property-record means that the property value table is going to fill up fast, taking up more space on disk and possibly affecting performance.