Looney Labs Icehouse Mailing list Archive

[Icehouse] Re: "What Can I Play" Wiki Plug-In Idea

  • FromDavid Artman <david@xxxxxxxxxxxxxxx>
  • DateFri, 06 Apr 2007 11:49:29 -0700
>Prominently displayed on the first page of the wiki is:

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
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

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

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:

* 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;

Current Thread