MArcomage

The amount of information stored for a replay must be big.
I mean you are also storing the cards text (or some pointer to the card version), right?

Thanks

PS: about my 8) I said search because to display then in the replay list would (i think) make the row in the list bigger

No, actually instead of cards, only pointers are stored. This saves much space, but has a disadvantage. When we modify cards, old replays that has them will become out of date. This means that card effect will no longer be matching the card description. There are multiple ways how to deal with this problem and we are currently deciding what to do.

1 - archive entire card database each time it is modified (we would like to avoid this)

2 - each time card database is updated move old replays to a different replay group and mark them as "outdated" to distinct them from new replays

3 - ignore the card changes, since the outdated replays are still viewable and former card effect can be seen from the changes on game attributes and/or player hands. In one update not many card modifications are implemented, so it will not effect the replays very much, but the changes will stack with each update, so the older the replay is, the more outdated it can become.

Couldn't you create a new listing for a card when it is modified? If a card named "DPsycho Warrior" was card number 478, and it underwent a change in a future update, the outdated version could remain as card #478, and the newly modified version could be assigned to the next available number. Existing decks would then need to be auto-refreshed so anyone foolish enough to use as silly a card as "DPsycho Warrior" would have their decks pointing to the correct card. In this way, as another benefit, games already in progress during the time of an update wouldn't have to have their cards-in-deck suddenly change on them, something that occurs currently.

I recognize that this may make the card database much longer than necessary if several changes are made along the line, and existing cards would probably need a new tag marking them as Active/Inactive. Also, updating existing decks might be unwieldy, with the best option there to perhaps be to have the system drop cards that have become flagged Inactive. These considerations taken into account, would it be at all feasible?

This solution is equivalent to 1 and I would avoid it preferably.

If DPsycho's method is possible it's probably the most elegant to the users.

If I look at option 2, I thing it might have it's charm to have replays ordened by update. I suppose that we don't want to store infinite games, so this makes room for a policy like 'Replays after X card updates will be deleted'. Also one could gather info over tactic changes per update (more building victories etc.).

If replay rating system i mentioned will be implemented, space for #1 "old cards saving" can be saved by deleting unmarked replays.

Another minor problem is when we change keyword (or any other core mechanic) old replay with old cards will still not match today game realities.

1)DPsycho solution would only increase the cards database maintaining several obsolete versions of the cards used in replays.
That would make that after every update the decks/current games would need to be updated to the "new card number" (or card version number).
2)Another way would be to have for each cards a change history with a date that would be used in the replays.
3)Or marking the replays using old cards versions with some note saying that the cards used were changed.

In my oppinion, replays should only be kept for one week and then deleted. This way we can keep the database clean.

I think 3) is really the best option. People are smart enough to be able to figure out what's going on, and I don't think going back to really old replays is going to happen that often.

On the other hand, I don't think there's any reason to regularly wipe the replays, unless Mojko says that they're really taking up too much room.

Well, I'm also in favor of 3, although I don't think replay deletion is necessary. Currently, the game replays shouldn't take too much space, but we will be able to verify that in time.

If they would take too much space I would propose to delete them every 3 or 6 months.

Still, an 'Outdated' mark or folder shouldn't be hard to make and avoid potential confusing.

After some time I came up with this idea: Store number of views for each replay. In regular intervals all replays with N or less views will be deleted (starting with N = 0). However, only replay data will be deleted. The replay header that contains statistical information (who won, number of rounds...) will not be deleted.

This way we will keep our database clean and we don't have to deal with out-of-date cards very much (since most of such replays will be deleted).

The question is, if N = 0 is a good constant. Number of views technique has an advantage compared to user voting. Use voting would require a table of size number_of_replay times number_of_users. Number of views requires only number_of_replays records.

What if each player were allowed to choose up to three replays that he would like to have kept on the system? That way, if there's one of which someone is particularly fond, he can protect it that way without having to look at it every day to ensure it's not purged. People who don't care about or rely upon replays won't add to the number saved. For those who do, it gives a way to save links to favorites in their player profiles for quick and easy access.

Adding an additional saved replay could be worked in as a level-up reward, too.

If the "number of view system" is implemented the only thing a user needs to do is to view a replay to prevent it's deletion. This system would be the best solution, however what I can't say is how many replays people were viewing. I think the best way is to test it. So first I implemented a number of views mechanism and then we will see how many replays actually got viewed.