Keeping it simple: Our minimalist database as a starting point

To provide some context about the archive.

Our archive includes a diverse collection of games from various genres and platforms, including console, home computers and PC. The intended audience for the archive includes researchers, game developers, journalists, and writers to help understand how games have evolved over time. Our goal for the archive is to preserve and document the rich history of gaming and make it accessible to those that want to learn more. 

As we have noted our collection is at writing around 70000 objects. Let’s say that we want to register everything known about an object. What would we want to have in our database?

Well lets begin with general knowledge of the object: 

Name, localization, region, placement, size, condition, content, materials, media, digitized material, backup, test results… Etc. etc. and quickly you realize that it would take well over half an hour to just register a single game. That would of course quickly get out of hand. Not only by the amount of data that we would have to register but also work through all our methodology how to register said data entries. 

For example. How do you consistently register the condition of one cardboard box from the next? How do you discern the condition of DVD-case games? The questions just keep adding up. 

 

So, then you might ask; What is our solution to this? 

We work with the use-case that we want to know if we have a certain object in our collection, where it is, what collection it is a part of and finally what is the smallest discernable difference between two versions of the same game. 

If we spent 5 minutes per object it would take 350 000 minutes or ~5800 work hours to register each object.  Then this is a more attainable goal for us to get to know what we have and where it is in case someone requests to see a specific object or just has a general “Do we have it?” question to decide if we aim to acquire a certain object or do we have a close to complete collection of this and that. 

But by using this iterative process, we can quickly register 70 000 objects, so we know where and what we have. Just the bare necessities to identify and to store the location of the object so it can be found. With this we can hit the ground running and avoid getting bogged down in the details and pushing our starting point further and further back or in this case further into the future. 

But one thing we haven’t touched on is why and how do we handle collections, acquisitions, and provenance of objects? From a personal point of view, If I were to donate my collection to the archive, I would like to tell a story about how or why I have something in my collection most likely. But also, it is from a heritage point of view that we want to authenticate and properly identify objects. The collectors themselves might have a notable importance to the story of the object. 

Looking ahead:

Our plan is to iterate on this initial registration process and gradually add more detailed information about each object. This will include things like descriptions, screenshots, and metadata that can help users explore and discover games in the archive. By taking an iterative approach, we can continue to add value to the archive while avoiding getting overwhelmed by the sheer volume of objects we need to register. 

In conclusion:

If you’re working with a large game archive database, don’t be afraid to think creatively and try unusual design choices.