aboutsummaryrefslogtreecommitdiff
path: root/TODO.txt
diff options
context:
space:
mode:
Diffstat (limited to 'TODO.txt')
-rw-r--r--TODO.txt28
1 files changed, 28 insertions, 0 deletions
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.
+
+---