VOGONS

Common searches


First post, by Spearhead

User metadata
Rank Newbie
Rank
Newbie

Upon looking through some games in the database and since the release of 0.63 is already quite old, i wondered if it would be possible to add an option "0.63 CVS" with the option to add the date of the build to another field.

I think this would help those that want to try out the CVS to know what to expect in terms of improvement since the release.

Reply 2 of 8, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

red_avatar, not at all. There's exactly one official CVS version at any time. Don't confuse the plain CVS build with all the patches/enhanced builds.

Reply 4 of 8, by red_avatar

User metadata
Rank Oldbie
Rank
Oldbie

Except that people WOULD use the patched CVS, and then there would be confusion as to why their (patched) CVS could run this particular game that another guy couldn't get to run with a vanilla CVS. Trust me, it would cause confusion. It's confusing enough to keep them all seperated on my hard drive let alone in a data base! If CVS got version numbers and patches were somehow reflected in this, it would be easier, but you'd need a very precise way to keep them apart. Because I know games that a patched DOSBOX will run fine, but a vanilla CVS will refuse to run.

Reply 5 of 8, by vasyl

User metadata
Rank Oldbie
Rank
Oldbie

Yup, CVS is dynamic target, cannot use it there. I would rather have completely different approach: one entry per game and multiple fields for reported successes. After the game is marked 100% playable in an "official" release there should not be success reports about CVS or unofficial releases but there may be a provision for regression. There should be a note field which has no restriction.

Example 1 (normal flow):
The Weird Game I
0.61 Does not run
0.62 Starts, crashes
CVS 9/5/2004 Runs, bad colors in intro
Unofficial from genie_12 9/17/2004 Playable
CVS 9/24/2004 Playable
0.63 Playable
Note: Still plays better with genie_12 builds.

Example 2 (official build regression):
The Weird Game II
0.61 Playable
0.62 Crashes on start
CVS 9/24/2005 Playable
0.63 Playable

Now, this is not allowed:
Example 3 (report on game playable in official build):
The Weird Game III
0.62 Playable
CVS 9/5/2004 Playable <- BAD

This may be allowed but I am not sure:
Example 4 (regression between builds):
The Weird Game IV
0.62 Playable
CVS 9/5/2004 Crashes
CVS 9/17/2004 Playable

In the last example it is better to move those CVS reports to notes anyway.

Reply 6 of 8, by lwc

User metadata
Rank Member
Rank
Member

You totally ignore the fact that sometimes a new version may actually stop supporting a game. Why should we make people think their game works when it doesn't?

Take Archon Ultra, for example:
0.61 - works natively, but without sound.
0.62 - dead! Nothing!
0.63 - works ONLY if you...(see the link above).

Now if you start throwing CVS builds in there, it could look like:
0.61 - works natively, but without sound.
CVS 1/6/2004 - dead! Nothing!
CVS 1/8/2004 - works again, but only if you...
CVS 1/10/2004 - dead! Nothing!
0.62 - dead! Nothing!
0.63 - works ONLY if you...(see the link above).

Reply 7 of 8, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Well hopefully people will report the non-working game and then it can be fixed before bothering with changing the database to report the new status. 😉

How To Ask Questions The Smart Way
Make your games work offline

Reply 8 of 8, by vasyl

User metadata
Rank Oldbie
Rank
Oldbie

I did not ignore that, that's example 2 (build regressions). Overall, it is very tricky topic and the current solution is not really working. I think the basic problem is that you just want to present it as database of games while in reality it is not that different from the regular development database -- each game is a task, not working game is a defect (occasionally, multiple defects). Maybe we just should run regular Bugzilla for it.