Data Model: Add-ons / Patches / Mods

[hsssh]

I'm basing my opinions/ideas on this model: http://wiki.oregami.org/display/OR/UML+Model

First rather minor thing that I think would be useful since you intend to track patch information, I think that there should be additional boolean field called "Major Patch" or something like that. Reason being that many F2P games release weekly patches, most of them are rather trivial (additional items for cash shop, some bug fix), but every 3-4 months bigger patch is usually released that introduces big balance changes (if game is somewhat competitive) and adds some additional content. So if we take something like League of Legends for example, we would have lots of patches and user would be overwhelmed by information. Being able to filter out "minor patches" would greatly increase readability or so I believe.

Next thing is a question about Withdrawal. What is it exactly? When patch isn't available anymore from official sources? Wouldn't in most cases this date be same as release of the next patch? Like I think I would like to see some example on this situation and how would it work out since at the moment that information sounds a bit dubious.

And now something that I might be a bit anal about, namely "Authorized Patch" field. I assume this is to separate official patches from "fan patches"? Now first thing is my assumption that main difference between patch and mod is that patch is official game modification while mod is unofficial (done by fans) modification. So all unauthorized patches should be treated as mods. Mods are often divided into few types: Total Conversion (changes lots of things about the game that it usually can be treated as separate game), unofficial patches (includes bug fixes after developer abandons game and fan translations of, usually, jap games) and other mods (basically anything that doesn't fit in previous categories). There are also some remakes done of older games while using newer game as a base, but I think those fall under Total Conversion type too. In other words my belief is that "unauthorized patches" should be treated as a type of mods and not as a type of patches.

Now I don't see in model anything about mods so my question is, if "fan patches" are going to be the only type of mods tracked? Will Total Conversion mods be ignored or will they be treated as separate games? If so there should be some linking done with original game, I imagine something along what was proposed in this thread.

[MZ per X]

I'm basing my opinions/ideas on this model: http://wiki.oregami.org/display/OR/UML+Model

That's the right base, thanks for contributing to the discussions!

First rather minor thing that I think would be useful since you intend to track patch information, I think that there should be additional boolean field called "Major Patch" or something like that.

Agreed, and added to the model. Feel free to sign up for our wiki, and add an Oregami Standard for patches there, the start item being the definition of an "important patch".

Next thing is a question about Withdrawal. What is it exactly? When patch isn't available anymore from official sources? Wouldn't in most cases this date be same as release of the next patch?

Independent had an example for this in the German part. It was about Eve Online where a controversial patch was rolled back by the developers after strong community protest (in contrast to MobyGames ).

Now I don't see in model anything about mods so my question is, if "fan patches" are going to be the only type of mods tracked?

No way. We want to document as much as possible.

Will Total Conversion mods be ignored or will they be treated as separate games?

These should get its own game entry, as I don't see a difference to construction sets here. You use a game engine to create your own game. We'd just need to add the original game as a game engine, too, or link the Conversion as an add-on with a special property indicating that it's a Total Conversion.

There are also some remakes done of older games while using newer game as a base, but I think those fall under Total Conversion type too. In other words my belief is that "unauthorized patches" should be treated as a type of mods and not as a type of patches.

That special type of Total Conversion would qualify as a new release group of the original game, I think, as its the same gameplay using a different engine. It could be that such conversion qualifies for a new game entry, too, if there's substantial changes compared to the original. We didn't finish our different game criteria, yet, though.

And now something that I might be a bit anal about, namely "Authorized Patch" field. I assume this is to separate official patches from "fan patches"? Now first thing is my assumption that main difference between patch and mod is that patch is official game modification while mod is unofficial (done by fans) modification. So all unauthorized patches should be treated as mods. Mods are often divided into few types: Total Conversion (changes lots of things about the game that it usually can be treated as separate game), unofficial patches (includes bug fixes after developer abandons game and fan translations of, usually, jap games) and other mods (basically anything that doesn't fit in previous categories).

Very interesting points, I must admit that we're lacking in this area, yet. Technically, every patch is an add-on, so the first question would be where to draw the line between patches and add-ons. Up until now, I thought that everything that costs money should be basically an add-on, everything else should basically be a patch, but that's clearly way too simple.

Or do we need to draw a line between patches and add-ons at all? Since every add-on, even the smallest DLC, needs its own entry at game level anyway, we could save every patch with its own game entry, too. Thoughts? I need to think about this a little more.

Let's use this thread for discussing both patches and add-ons, since they're so similar. I will adjust the thread title accordingly (Hope you don't mind.).

[Ultyzarus]

Very interesting points, I must admit that we're lacking in this area, yet. Technically, every patch is an add-on, so the first question would be where to draw the line between patches and add-ons. Up until now, I thought that everything that costs money should be basically an add-on, everything else should basically be a patch, but that's clearly way too simple.

Or do we need to draw a line between patches and add-ons at all? Since every add-on, even the smallest DLC, needs its own entry at game level anyway, we could save every patch with its own game entry, too. Thoughts? I need to think about this a little more.

Let's use this thread for discussing both patches and add-ons, since they're so similar. I will adjust the thread title accordingly (Hope you don't mind.).

I say the difference is that patches are updates that are automatically downloaded to the base game while add-ons must be acquired (for money or for free) by the player and added to the base game.

I still consider Expansions different from mere Add-ons, too, but I don't think that would influence the data-model...

[Rola]

patches are updates that are automatically downloaded to the base game while add-ons must be acquired (for money or for free) by the player and added to the base game

Ehh... back in 1990s we didn't have those automatical patches, we unzipped them ourselves! *cough, cough*

Patch is about fixes. Add-on is new content. Often patches add content thus becoming add-ons. Before people keyed the term "DLC" (nobody used this 10 years ago) expansion packs were paid and usually boxed and and there was no distinction between game code updates and content updates.

Does every single "DLC" of today deserve own entry? or should minor free ones be entered as patches?

[MZ per X]

I say the difference is that patches are updates that are automatically downloaded to the base game while add-ons must be acquired (for money or for free) by the player and added to the base game.

Patch is about fixes. Add-on is new content. Often patches add content thus becoming add-ons. Before people keyed the term "DLC" (nobody used this 10 years ago) expansion packs were paid and usually boxed and and there was no distinction between game code updates and content updates.

Does every single "DLC" of today deserve own entry? or should minor free ones be entered as patches?

All of these points / questions show that we will have a hard time drawing the line between patches and add-ons. That's why I think about merging them into one data structure, with enough properties to separate the wheat from the chaff (see tag list 5 and tag list 6 in the wiki).

[hsssh]

Let's use this thread for discussing both patches and add-ons, since they're so similar. I will adjust the thread title accordingly (Hope you don't mind.).

Don't mind at all, initially I intended to write a bit about DLC/Add-ons too, but somehow forgot about it while writing

Independent had an example for this in the German part. It was about Eve Online where a controversial patch was rolled back by the developers after strong community protest (in contrast to MobyGames ).

I understand, thanks for example.

Very interesting points, I must admit that we're lacking in this area, yet. Technically, every patch is an add-on, so the first question would be where to draw the line between patches and add-ons. Up until now, I thought that everything that costs money should be basically an add-on, everything else should basically be a patch, but that's clearly way too simple.

Or do we need to draw a line between patches and add-ons at all? Since every add-on, even the smallest DLC, needs its own entry at game level anyway, we could save every patch with its own game entry, too. Thoughts? I need to think about this a little more.

Well, as Rola mentioned, there are "free" DLCs... So drawing a line on pricing won't really work.

I think that patches "upgrade" base version of the game while add-ons give optional content. Some player might have DLC A, another might have DLC B, but their "base" version of the game will be same. So basically patches offer "linear" progression of the base game while add-ons branch out.

You can't have patch 1.1 and 1.3 in your game since 1.3 is going to include 1.1 and 1.2. On the other hand you might have DLC A and DLC C in your game and totally skip DLC B.

This is also why I think that unauthorized patches shouldn't be lumped together with official patches. Just because some fan released 1.4 patch doesn't mean that another fan isn't going to release another 1.4 patch that goes into completely different direction.

Now, I'm sure that some "smart" developers have done some interesting patches that don't fit into my "perfect world" but at the moment I don't see better distinction between patches and add-ons.

[MZ per X]

You can't have patch 1.1 and 1.3 in your game since 1.3 is going to include 1.1 and 1.2. On the other hand you might have DLC A and DLC C in your game and totally skip DLC B. This is also why I think that unauthorized patches shouldn't be lumped together with official patches. Just because some fan released 1.4 patch doesn't mean that another fan isn't going to release another 1.4 patch that goes into completely different direction.

This is very good reasoning for these distinctions, I think, thank you!

Now, I'm sure that some "smart" developers have done some interesting patches that don't fit into my "perfect world" but at the moment I don't see better distinction between patches and add-ons.

Corner cases are inevitable. We try to include the most, but some are just too esoteric. Let's see if somebody brings up something when we dive deeper into the discussion.

Or do we need to draw a line between patches and add-ons at all? Since every add-on, even the smallest DLC, needs its own entry at game level anyway, we could save every patch with its own game entry, too. Thoughts? I need to think about this a little more.

Let me elaborate on this point a bit.

I still think that we should drop the idea of a separate data model for patches, because they're so very similar to DLCs, mods, etc.. If we map patches using our generic data model for games / add-ons, we have all the benefits of this for free: a release history for every patch, connecting it to a game using the generic facility, linking screenshots, reviews, whatever to it, a patch having it's own system requirements, and so forth.

Think about a patch changing the system requirements for a game, adding a multi-player mode to it, a major patch being re-reviewed by the gaming press, whatever. Why re-invent the wheel for all this? I say let's treat patches like add-ons, everything will be simpler this way.

[Ultyzarus]

I personally wouldn't like stumbling on a database where patches and DLCs are all mixed together. I do see the similarities that would excuse this, but it seems like it would become a mess.

One other point that differentiates both is the title: to my knowledge, patches are just numbered versions while Add-ons have their own titles.

[hsssh]

Some major patches for F2P games do get names in order to make them feel "more important" but generally speaking most patches can be pinned down with version number or date of release.

I say let's treat patches like add-ons, everything will be simpler this way.

It would be simpler but I'm not sure about usability. For example Magicka has like over 15 DLCs, all priced I think, and over 20 patches. If we make a one list with all of them then its likely to be rather messy list.

[MZ per X]

Of course, if a user enters a term into the default Oregami search later on, or looks up a list of game entries starting with a "B", he/she doesn't want to get a myriad of patches or smallish DLCs as a result. The user wants to see game entries of the types 1, 2, and 4, I think. And that will be no problem, a customizable search will be no problem.

These are all questions of the user interface, but not a question of the technical data model, how we do things under the hood.

[Rola]

Today games are quite modular, but it wasn't always like that. 20 years ago you could talk about new levels for Doom or user mods (conversions), but most games required code update to incorporate new content.

Think of all the upgrades for Operation Flashpoint - as recent as 2001.
http://www.mobygames.com/game/windows/o ... lease-info
In those patches were new vehicles & weapons - wouldn't that classify as DLC today?

How can you call it a mere patch if it adds a whole new dimension to a game - multiplayer!
https://en.wikipedia.org/wiki/Deus_Ex#Multiplayer

New aircraft for IL-2 Sturmovik series weren't separate downloads, they came only with patches.

[MZ per X]

All your examples are strong arguments for handling patches (technically) like add-ons. And these examples also show the need to flag important patches, just like major add-ons.

[MZ per X]

I did a first draft of Oregami's significance criteria for add-ons here. Feel free to comment.

[MZ per X]

All your examples are strong arguments for handling patches (technically) like add-ons. And these examples also show the need to flag important patches, just like major add-ons.

Finally, all done now. I unified patches and add-ons, and removed the duplicated data and the superflous "Patches" table. The patch-specific data have been moved to the RG table for now.