From e4fad5b38b3c520bcdb5bd21fcba7e3032d6d983 Mon Sep 17 00:00:00 2001 From: zlg Date: Sun, 24 Oct 2021 19:16:32 -0700 Subject: README.md: Flesh out and reorganize --- TODO.txt | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'TODO.txt') diff --git a/TODO.txt b/TODO.txt index 185dd89..6f54d7f 100644 --- a/TODO.txt +++ b/TODO.txt @@ -4,3 +4,31 @@ * Write GUI * Write docs * How? Sphinx? Needs research + +--- + +Consider adding a 'dates' table that matches games to dates for purchase, +beating, and completing. Currently implemented via RFC2822-style headers within +the 'notes' field. More research is needed to determine if the notes field or a +table is a better way to achieve this. If an addition to the database format is +deemed necessary, a restructuring may be in order. + +--- + +One of the things curious about managing a game collection that doubles as a +backlog is, you get games on systems that were originally on other systems. How +do you classify those games? The original game is the actual content you're +playing, but you bought it for the newer system! If you track ownership +correctly, you'll put it under the new system. If you care about tracking the +original release, you're a little stuck. + +A perfect example is Virtual Console games on the Wii, WiiU, and 3DS. These +games should have their ownership tracked under Wii, WiiU, or 3DS, but the +original releases are on NES, SNES, etc. Ideally, it should be tracked as a +duplicate of the respective game on NES and SNES if you've owned or beaten them. +That hints toward needing games to have pointers of some sort, to add some +meaning to what's *truly* owned, and what's *been played through*. + +This points to the idea of release types. More experimentation is needed. + +--- -- cgit v1.2.3-54-g00ecf