Forums > Suggestions > Tab for DLC in game information page
Simon Carless (1834) on 2/13/2016 2:00 PM · Permalink · Report
How would we link these together do you think? Is there data right now in tech specs that says it's DLC? (Forgive my ignorance...)
Patrick Bregger (300026) on 2/13/2016 2:14 PM · Permalink · Report
The genre add-on. However, this is part of our biggest data structure problem (besides useless compilation entries), for example outlined in this post. The data structure was designed for retail games and it just does not work anymore.
Tracy Poff (2094) on 2/13/2016 7:48 PM · Permalink · Report
We have an Add-On genre, as Patrick says. The problem is that we don't have any information about what game the add-ons... add on to.
The problem with DLC, compilations, special editions, etc. isn't technically challenging to solve, but a comprehensive solution (such as Sciere's that Patrick mentioned, or my own proposal which I think I linked to recently) would take perhaps some dozens of man-months of work updating the DB, so it's not a path to set out on lightly.
Simon Carless (1834) on 2/13/2016 9:43 PM · Permalink · Report
Blah. Unfortunately this seems lower priority just cos it's so horrific to sort out compared to other 'wins'.
Patrick Bregger (300026) on 2/14/2016 8:17 AM · edited · Permalink · Report
I agree with SilentRay on that one. If I read Tracy Poff's post correctly (it is relatively easy to solve from the programming side and the only problem is the migration of the existing data), then we should do it as fast as possible. The longer we wait, the bigger the task gets. I also don't think it is important to migrate everything at once. Set a point "from today we do this right", migrate the most important series and do the rest when we stumble over it. It is better to have a good system in place that only part of the database uses than having no good system at all.
If it turns out like I imagine it, the migration process should be minimal from the end-user perspective. Just set a database connection (x is an add-on of y, x is a special edition of y, x is part of compilation y, x is an enhanced version of y, maybe even x is a remake of y) and then the system automatically does the rest.
At the same time, this system may be the solution to our mod problem.
Tracy Poff (2094) on 2/14/2016 9:25 PM · Permalink · Report
Let me expand on the situation a little bit, then, since there's interest.
it is relatively easy to solve from the programming side and the only problem is the migration of the existing data
I wouldn't say 'the only problem', precisely. When I say it's not technically challenging, I mean that no matter what we choose to do, on the back end it'll basically come down to just adding a table or two to handle the extra data, plus making whatever interface changes are necessary to support it. It's unlikely to require anything exceedingly novel or esoteric from a technical perspective, though it could be more or less time consuming depending on the complexity of the solution we choose.
And that is the first hurdle: picking a good solution. It doesn't have to be perfect, of course--the perfect is the enemy of the good, as they say--but we don't want to rush and end up with a solution that solves just the DLC problem, but leaves us no better--or even worse--on related issues. Since changing again in the future would mean duplicating again the man-years of effort migrating data, we definitely want to be pretty sure we have a good enough solution before we commit to any changes.
Given we can decide on a reasonable solution, I agree with you on this: we should begin as soon as is practical, because it'll just take longer the more we put it off.
(That said, I am myself not prepared to implement a change on this scale immediately--'not technically challenging' doesn't mean 'not requiring planning'.)
If it turns out like I imagine it, the migration process should be minimal from the end-user perspective. Just set a database connection (x is an add-on of y, x is a special edition of y, x is part of compilation y, x is an enhanced version of y, maybe even x is a remake of y) and then the system automatically does the rest.
The situation you describe would mean we basically just make a bunch of special-case relations between games. It's probably the conceptually simplest solution, but something a little more structured might serve us better. My proposal a couple of years ago was essentially to allow releases to attach to multiple games (in addition to some other rearranging of the data), which I still think is a good idea, though it's not by itself a solution to the mod or DLC issue--it addresses rather the problem of special editions and compilations.
That's not to say a simple game relation system isn't useful. Actually, I use a relations system like you propose for my private notes on games, and it's very handy:
While we're speculating, let me sketch an outline of a relations-between-games system such as this:
- Games may be related to one another. The relationships are asymmetric, i.e. "A is a remake of B" does not also mean "B is a remake of A".
- Relationships may be of a number of types, e.g. remake, mod, sequel, add-on.
- The types can be defined dynamically, e.g. by admins, as with adding new tech specs.
- Display of these relationships is handled automatically by the software.
This kind of system will not, I think, do much to solve our compilation/special edition problem, because we will still have to make game entries for those in order to use them in relations. It would, at least, allow for a cleaner and more useful display of the contents of a compilation, or a listing of compilations that contain a game. If perhaps not a complete solution, it could be a component of a solution.
Simon Carless (1834) on 2/15/2016 3:40 PM · Permalink · Report
OK, I'm warming to this idea if it solves X problems at once, not just DLC. Which specific relationships between items do people think we should document that are non-subjective? (I'm not a big fan of 'Influenced By' but I like DLC, In X Compilation, etc...)
Tracy Poff (2094) on 2/15/2016 4:54 PM · Permalink · Report
Climbing up on my soapbox, here: I think that 'relations' that have to do with how a game was released should properly be documented as releases. Making a new game entry for every special release and compilation, the way we currently do, is, to put it bluntly, insane, and and I don't recommend that we do anything that entrenches it further. Strictly speaking, relations indicating that a game is part of a compilation are better than not recording that data at all, but I'd much rather we work out a better solution for that.
As far as non-subjective relations go, off the top of my head...
- A is an add-on for B
e.g. DLC, expansion packs - A is a remake of B
e.g. the Grim Fandango remake - A is an alternative version of B (probably a bad name for this relationship)
e.g. Super Mario USA -> Dokidoki Panic, Adventures of Lolo 2 (US) -> Adventures of Lolo (Japan) (we don't have separate entries for these, though) - A is a clone of B (sometimes this is subjective, though)
e.g. Donkey King -> Donkey Kong
Patrick Bregger (300026) on 2/15/2016 5:42 PM · edited · Permalink · Report
To be honest, I don't see how your proposal with releases does eliminate the need for creating new game entries for compilations. If I understand it correctly, the idea is that you would make a release info for the release of game A in compilation B and associate all relevant information to that release which is then displayed in game entry A. However, compilations also (may) have data which has no direct relation to any game but does belong to the compilation itself (cover art, MobyRanks, general compilation credits, etc.).
The main flaw I see is that we document releases and not games. All information on games which were not released independently would be lost because we don't have a game entry to add a release to. Of course we could always change this, but this would open an all new bag of worms (e.g. what to do with Action 52). The same applies to games which simply don't have an entry yet.
I don't think variants should be a direct relation. It boils down to gameplay/presentation similarities which are better suited for game groups. Maybe it could be interesting to add relations like "sequel to", "prequel to" etc. Of course this would only be a slighter different thing than our series game groups.
Tracy Poff (2094) on 2/15/2016 6:13 PM · Permalink · Report
To be honest, I don't see how your proposal with releases does eliminate the need for creating new game entries for compilations. If I understand it correctly, the idea is that you would make a release info for the release of game A in compilation B and associate all relevant information to that release which is then displayed in game entry A. However, compilations also (may) have data which has no direct relation to any game but does belong to the compilation itself (cover art, MobyRanks, general compilation credits, etc.).
The thrust of my proposal was that those things would attach to releases, rather than games, which (as you have noticed) is the more logical place for them, anyway.
The main flaw I see is that we document releases and not games. All information on games which were not released independently would be lost because we don't have a game entry to add a release to. Of course we could always change this, but this would open an all new bag of worms (e.g. what to do with Action 52). The same applies to games which simply don't have an entry yet.
Right. That's what my proposal was meant to change. Put all the relevant stuff on releases and let them attach to multiple games, and then our game entries can actually be game entries, rather than release-entries-with-more-releases-attached. The solution I envisioned for only-released-in-compilation games was to add a new game entry for them with the compilation as a release.
I don't think variants should be a direct relation.
By this you mean clones? Yes, as I said, it could be subjective in some cases whether one game is a clone of another. The drawback of using groups is that we don't then have a programmatically-accessible relation between a clone and the game it's a clone of.
If you meant 'alternative version', then I disagree--the examples I gave weren't just gameplay/presentation similarities, but games that were changed substantially enough in localization to be considered separate games.
Maybe it could be interesting to add relations like "sequel to", "prequel to" etc. Of course this would only be a slighter different thing than our series game groups.
I thought of this, too. Having prequel/sequel relations for games that are really prequels/sequels (i.e. a continuing story, like the Mass Effect series) could be good.
Cavalary (11445) on 2/15/2016 9:45 PM · Permalink · Report
Having no separate entries for editions, compilations and so on, which is what I understand from your take of switching to documenting games instead of releases, will throw a wrench in lists, and also possibly mess up affiliate programs / advertising.
I think they have to be there, but with a system that allows linking, so you'll be able to see all editions of a game, all compilations a game is in, all additional content for a game...
Tracy Poff (2094) on 2/15/2016 10:24 PM · Permalink · Report
Having no separate entries for editions, compilations and so on, which is what I understand from your take of switching to documenting games instead of releases, will throw a wrench in lists, and also possibly mess up affiliate programs / advertising.
'Have' lists naturally attach to releases, anyway, and favorites lists could attach to either games or a game/release combination (or as it currently does, to game/platform combinations). As for affiliate programs/advertising... I'm not sure how it would be a problem. The data would all still be pretty much the same, it'd just be connected differently.
It wasn't really my intention to revive my old proposal, though; I was just using it as an example of a more structured approach. It didn't get any support back then and clearly isn't getting any now. If people are interested in an approach like this, I can put together a more detailed proposal that benefits from my new familiarity with how MobyGames works, but I don't want to waste time defending something nobody thinks is a good idea.
Patrick Bregger (300026) on 4/23/2016 4:36 PM · edited · Permalink · Report
Sorry for the late answer, but I needed some time to think about it.
Right. That's what my proposal was meant to change. Put all the relevant stuff on releases and let them attach to multiple games, and then our game entries can actually be game entries, rather than release-entries-with-more-releases-attached. The solution I envisioned for only-released-in-compilation games was to add a new game entry for them with the compilation as a release.
The more I think about it, the more I love the idea. It would make the structure of the database much more logical and would serve to solve a lot of problems at once. The whole "document releases instead of games" philosophy creates more problems than it is worth in our time of digital distribution. It may even be a tool to solve our problems with emulation releases.
I see a few problems, of course. What to do with those compilations of never individually released games like I linked above? We need a good solution what to do when a compilation or special edition is added before the game entries - basically the contributor of the game needs to know that there is some other release in the database which requires a primary connection. We'd also need to revamp the have lists so we can choose releases.
In my opinion it would be worth exploring this further after the genre rehaul is done (great work btw, I really appreciate the work you are doing for this site.)
By this you mean clones? Yes, as I said, it could be subjective in some cases whether one game is a clone of another. The drawback of using groups is that we don't then have a programmatically-accessible relation between a clone and the game it's a clone of.
I dislike the term "clone" because it has a negative tone. I prefer "variant". I think those are better suited for game groups because it allows to define the important aspects (what makes it a variant of game X?) individually.
If you meant 'alternative version', then I disagree--the examples I gave weren't just gameplay/presentation similarities, but games that were changed substantially enough in localization to be considered separate games.
No, those definitely need a primary connection.
I thought of this, too. Having prequel/sequel relations for games that are really prequels/sequels (i.e. a continuing story, like the Mass Effect series) could be good.
However, I have difficulties imagining that this would work as alternative system to our series game groups. It would be confusing to have two systems which depict two similar things. IMHO it should be able to replace series/universe groups completely in the long run.
Patrick Bregger (300026) on 5/7/2016 3:40 PM · Permalink · Report
Just for reference, the setup of OGDB is more or less what was suggested.
Simon Carless (1834) on 5/7/2016 4:48 PM · Permalink · Report
We do really need a solution for this and I'm def. in favor of this solution - all this separate DLC hanging out there and nonlinkable is sorta insane :P
SilentRay (1) on 2/14/2016 7:11 AM · Permalink · Report
Why comprehensive, all we need for that is some sort of field where we could post names or links if such article exist of addons/dlc's. Perhaps something similar to game groups, ofc it will take a lot of time to fix info of all games that have addons but what else left, leave base as it now forever and never try to make it better?