>CHRIS: >Prominently displayed on the first page of the wiki is: >http://icehousegames.org/wiki/?title=Choosing_games Hmph... I never noticed that. It's not on the Navigation panel, which is what I click straight through, usually, to get to Existing Games or Games In Dev. Could it be added to the Navigation as well, for folks like me who won't read through a bunch of text to find links to major sections? ... So... I have a new game and it's finished. I have to figure out which of the SEVERAL headings on that page apply, then add links to them; then I have to post a link to it in Existing Games, also. Oh, then add (inadequate) Category tags, in case folks go hunting that way. Maybe the wiki needs a road-map page for game designers (also with a link in Navigation) so we can find the myriad locations in which we should provide links? I've posted three games so far, and I reckon they're not showing up in even half the places they should. [edit-They are now! :)] >Which is perfectly adequate for the purpose. Well, I was going for a BIT more than "adequate." Like, "cool, dynamic, user-centric, customized, intuitive, Web2.0." Look, the two forms would take me maybe an half day to design, depending upon the coding environment--if I could work in a WYSIWYG environment, I could do it in even less time. (NEW IDEA: Forget doing another widget; instead, make designers use a form like the users, to add/modify a record to the Pieces Required per Game database. That solves a LOT of wiki integration, post-Save processing coding.) The database table is totally trivial. I'd probably be able to define it in ten minutes. The web host probably has an interface for adding a database (or table to an existing one) and so that's another half hour or so of banging on its interface (or one command line issue, for a DBA). PERL scripting a parser to do the audit... not sure on this one, but it seems like short work for a professional coder. I'd *guess* about a half day to do such simple math code. It might be a *little* hard to get it to do two things: take query by user and pass to page create script OR write new/update db record, if from designer), but I reckon that would just be an argument that's passed by the form Submit which, in turn, directs the script's results (RETURN) to one or the other channel. Integration into the wiki itself--making the PERL auditor query the database then build a new wiki page out of the results--again, not sure, but I've seen THOUSANDS of web sites with similar functionality. It's the basic notion of dynamic pages, and I bet the wiki itself is "built up" from database queries, at its core. Again, a pro should be able to knock this out in very little time. So, if our target is "adequate," then forget the whole idea. But if we at least consider the notion a bit before outright rejection it looks like this is what it will take: * Setup database table: 15 to 60 minutes * Define Designer form: 1 to 2 hours ** Write parsing/audit script, called by the form's Submit button: 2 to 4 hours for real coder; pretty tricky, for me to learn from scratch *** Write SQL record create script, which is passed results of parsing script: minutes, for a DBA; maybe 2 hours for me to learn from scratch (it should be a one-line script; I just don't know the precise syntax). * Define User form: 1 to 2 hours, maybe less, given it's a subset of the already-designed Designer form ** Reuse above parsing/audit script, called by the form's Submit button: 0 minutes *** Write SQL Search, which is passed results of parsing script: trivial for a DBA; pretty tricky, for me to learn from scratch **** Write Page Create script, which is passed results of Search: unknown * Place User form on main page: ten minutes * Place link to Designer form in navigation panel, as "Register a Game": ten minutes for a wiki admin * Test and tweak: varies, but probably little more than an hour, if the DBA and coder are on hand during testing. SO I see about 4 hours of my time, about an hour of DBA time, and an unknown (but likely similar scaled) amount of time for a coder who can take SQL results, "wrapper" them with proper wiki code, then pass to the wiki in the format it wants. Odds are good that such a coder could also handle the DBA stuff--SQL is pretty easy, compared to PERL or C. ... Damn... it just occurred to me: this is NO DIFFERENT from the "AutoBartender" scripts one finds all over open source libraries these days. You've seen them: input the contents of your bar, your mixers, and garnishes; and they kick out every mixed drink you can make with those ingredients. Functionally, we want the same thing: input the products you own; and it kicks out the games that can be played using just them. About all we have as extra complexity is parsing the "sets" into individual pieces by color, to make efficient searches across the database. And, again, that's about a half day or less for a coder. ANYWAY, sorry so long (again) but this thread could actually become a project plan, so I am trying to be thorough even as I try to persuade that it's doable and worthwhile; David