Widescreen Gaming Forum

I can't help much with detailed reports myself, since I never buy games on release and that's not gonna change any time soon (or ever for that matter)

Just in case there's ever a migration to a new system however, I could probably dedicate some time to help with data transitioning

I think a database should encompass both the MGL Data & wiki Data though (if a wiki can go through a database at all, since I don't really know)
this would be the best way to go since it would avoid any inconsistency between the MGL & the wiki and with the appropriate form should lighten the load.

In my mind I also see directly on the form the possibility to upload needed DR images with an image host partnership (so directly from one's Hard Drive)


Also I already did some wiki stuff on the galciv2 wiki some time ago (if one search for it, one will see that I was a featured user, I gave up because I lost interest in the game and there was too much updates that invalidated data, and now most data would have to be redone to handle the game alone & its two extensions since we lacked the foresight to do a design open for extensions)
That said I don't know what needs to be done in this wiki and its design escapes me a bit (Unlike other wikis, I didn't find a wiki welcome page for example, so I guess the wiki is thought as an extension of the WSGF itself...)

Likewise here to assist if needed, Skid, I also do some web development, although more towards CSS/HTML/Java and some PHP, so if you felt like this was something you wished to persue, I would be more than willing to assist with any front end stuff, and where I can with any backend stuff.

If you want assistence or even someone to discuss brainstorming, feel free to give me a poke, ill be happy to help where I can.

Likewise here to assist if needed, Skid, I also do some web development, although more towards CSS/HTML/Java and some PHP, so if you felt like this was something you wished to persue, I would be more than willing to assist with any front end stuff, and where I can with any backend stuff.

If you want assistence or even someone to discuss brainstorming, feel free to give me a poke, ill be happy to help where I can.

Front end would be the bit I would need the most help with, my layouts have never been the best to look at, although I try to at least make them functional or practical, (see http://www.skid-inc.net/ for the last front end I designed, although that was designed to be modular to a point so it could be easily reused for something else.)

http://xgo.skid-inc.net is a really old game based of the X series of games, its no where near finished, but you can fly around, trade, buy a new engine, get a new ship... thats probably it, tickers working though, once ever 10 or 15 minutes I forget which. http://xgo.skid-inc.net/test.php was a layout prototype I played around with around a year or 2 ago (you navigate around the map by middle clicking once to bring up the auto scroll or whatever its called). The other site I made that is online is probably the most complete and despite its age and being dead now (old online community) is probably still the site I'm most proud of. Mainly because of how much time I put into it, if you want to have a look at that drop me a PM and I'll give you the URL and create you an account (mostly so I can force your level).

Just to chime in here, I am very hesitant to add any new or additional systems to the site. What we have works, we just need help to update it. Any new system would still require manpower to update.

If anyone wants to help update the Wiki, I would gladly accept your help.

BTW, is it just me or does the menu on the left hand side of the home page appear below the main section on other peoples computers as well?

To me its stacked up in the top left corner.

Image - in line with scan ad
HOME - in line with main section (starts JUST below the text "Main Page)"
FORUM
FAQ's.. etc
WIKI SEARCH
ERGO TECH
BENCHMARKS
WSGF Community - with the facebook logo roughly in line with the DR for Duke Nukem 3D.

Just to chime in here, I am very hesitant to add any new or additional systems to the site. What we have works, we just need help to update it. Any new system would still require manpower to update.

If anyone wants to help update the Wiki, I would gladly accept your help.

it needs to be thought over for sure. One needs to be sure that the move is the right one

nevertheless I think manpower for updates could be saved by such a system in the long run.
I mean I just thought about something, an extended system could include :
-any user use a simple form to post/update his report: a forum post is automatically made by the system
once approved, a wiki entry & an MGL entry are added with any desired modification, addendum or whatever ...
-any user could update the report with additional data which would behave more or less the same way

complex to setup ? for sure... maintenance ? hum shall not be much... updates ? simplified & accelerated by a LOT
+ the side benefits of easing user searches, sorting, & the like
you're the one to decide in the end anyway, and a move like this shall NOT be rushed, rather carefully planned, thought over & over & over & over + alpha & beta tested :wink:

Let me make a few suggestions for the DB design.

"Tested Resolutions" and "Tested Aspect Ratios" should be different tables, and "screen_change" should be in the latter. We don't extensively test each and every resolution - we just check to see if they work or not. Also, I don't understand what your "group" and "url" fields are there for.

Under the "detailed report" table, these fields should be removed:
calculated_grade
potential_grade
major_omissions
minor_omissions
cce

All of those are derived values, determined by looking at the data that is (or is not) in the DB.

Also if current DRs was to be put into the database they would probably have to be done by hand, via forms created, this would be an extremely lengthy task

I've been doing more or less exactly that, ever since I wrote the first DR. Granted, it's not perfect - I've set it up more for easy data entry than for performance (the first version was an Excel spreadsheet!). But the data is all there, and it can be migrated programmatically.

The real time consumer, as I see it, would be creating the forms, for data entry, retrieval, and especially administration. For this reason, I've always seen a DB as something that would be nice to have, but probably won't happen. Such a thing would indeed save lots of manpower in the long run, but there's always the matter of initial time investment.

Under the "detailed report" table, these fields should be removed:
calculated_grade
potential_grade
major_omissions
minor_omissions
cce

For a program execution point of view its a hell of allot faster calculate those values when the DR is created or edited, and then to simply call the values out when the DR is viewed. Reason being, a DB could be coded to work out the grade automatically rather then have you do it each time, if this is the case and the information is put into some sort of list view, then every time someone views the list the server will have to do multiple calls to the database to work out each value. This puts unessential strain on the server when the information its trying to collect (in this example the calculated_grade) can be saved and called off in one command on a single table.

Granted some of the fields could go, it would all depend on how the final system would work.

For a program execution point of view its a hell of allot faster calculate those values when the DR is created or edited, and then to simply call the values out when the DR is viewed.

But from a maintenance point of view, you're shooting yourself in the foot by going to the trouble of creating a DB, only to have it store redundant data. That's the whole point of having a DB in the first place - so that you *don't* store (and therefore have to maintain) redundant data. The grading rules can be (and have been) changed - what if they do? You'd have to update all of those fields for each and every game, manually. Even less drastic changes, like making a minor update to the information of one game, would require far more work.

A better way to reduce server strain would be to use materialized query tables. Updating them whenever a record is added or changed should be fine - it takes my computer about eight seconds to calculate those values for 423 games.

Data is only redundant if the data isn't used, the grades are always used, even if they change, and as I said it would be possible to automate the grading system on both creation of a DR and editing of a DR. Changing the parameters for grading would only need a single script to automatically go though each game and check its grade is correct and regrade if needed.

There would be no point in creating a database if you don't automate things like that, otherwise all your doing is copying data from text form into a form that can be manipulated easier. The grades only change on 2 conditions, 1, the DR changes for whatever reason, more information is added, a patch is released, or 2 because the grading system changes.

1: On change of a DR, automatically pass the DR though the script designed to calculate the grade when the submit button is pressed.
2: On change of grading system, change the script that calculates the grade and run a toolbox script designed to pass each DR though the new grading script in turn.

Data such as grades are nothing compared to things like images, and I doubted the server will miss then 423bytes it would take to store single character grades in a database.

Data is only redundant if the data isn't used

Data is redundant if it exists in more than one place. Whether it gets used or not from all of these places is irrelevant.

as I said it would be possible to automate the grading system on both creation of a DR and editing of a DR.

That sort of automation is really just asking for trouble. Materialized query tables is a standard DB feature, meant exactly for this kind of situation - derived values that do not change often.

Data such as grades are nothing compared to things like images, and I doubted the server will miss then 423bytes it would take to store single character grades in a database.

It's not an issue of space. It's an issue of maintainability, complexity, and logical consistent DB structure.

Right, and if your going to put all the information in a DR into a database, that would include one field for the grade, no duplication there.

I was under the impression you had a spreadsheet that automatically worked out the grades. Even if that isn't the case the grade needs to ether be generated or manually stored. If its going to be generated it makes no sense what so ever not to store it rather then generate it every time its needed.

Right, and if your going to put all the information in a DR into a database, that would include one field for the grade, no duplication there.

The "grade field" is nothing but a composite of several other fields. It's duplicate information.

I was under the impression you had a spreadsheet that automatically worked out the grades.

It's an Access DB - one that isn't quite third normal form, but the grade is calculated via queries, as it should.

If its going to be generated it makes no sense what so ever not to store it rather then generate it every time its needed.

This is exactly the problem that materialized query tables were invented to solve.

While all of this might automate the moving of data from one point to another, there is still the problem of getting the data in the first place. If no one posts info, screenshots or a DR - there is nothing to upload.

The Wiki is out of date, and I'm hoping to correct that sooner (sooner if there is any help). But, considering there are only a few people who routinely contribute information on game analysis, I'm not sure we're solving the root problem...

give me the ability to alphabetize the lists and I'll do so

however I won't alphabetize 2 separate lists for each letter - split into "retired" and current or whatever by entirely arbitrary means