Reminder for those interested in LARP and/or Querki -- this weekend, at the Radisson Chelmsford (the usual site of Intercon), is NELCO: the New England LARP Conference. I expect it to be a lot of fun: there is going to be a full schedule of panels, a Build Your Own Game, and generally lots of folks talking about the writing and playing of LARP.
I've got several panels on Saturday, including a one-hour sneak peek at Querki at 1pm. This is going to be a high-danger event: I'm going to do a demo of building a Space on the fly, with very little pre-canned, so it's pretty certain that *something* will go wrong. But I'd love to have folks come by, ask questions, and participate in the demo. (I'll be encouraging audience members to help me design a Space for building a LARP -- with any luck, it'll be a fun exercise.)
So if you're free, come on by, at least for Saturday. It promises to be an interesting day...
Mind, I believe that, even now, it's already pretty much the easiest way to deal with a lot of problems: if your requirements are fairly simple (and most LARPs really aren't that demanding in terms of features), Querki's almost as easy to use as a wiki and *much* more powerful in many ways. But I'm painfully conscious of the fact that it's only about 10% of where I want it to be, and not very "pretty" for demo'ing yet...
A couple of questions.
Do you think this is the right tool to use for storing arbitrary knowledge/properties? How about representing them in memory?
Are you sure pointers to parent is the right thing to do? This is the usual problem: if a member of a collection points to the collection, it cannot be a member of another collection; the world had so many troubles with this design, e.g. screen menus, etc. It's easy to implement, but hard to use. Probably have to introduce intermediate delegates for each collection (an additional indirection layer).
I'm actually seriously looking for something to represent hierarchical property sets, so I'm pretty interested.
Relationships actually mostly are *not* hierarchical in Querki. The most important types are Link Sets and Tag Sets, which are basically arbitrary multi-valued pointers. I'm finding that I tend to use those even in cases where I initially think the data is strictly hierarchical, so that I have more flexibility down the road.
By and large, you rarely set something up with a direct single-valued pointer to a parent. Instead, it's more common for the parent to have a List or Set of its children, or sometimes for the children to have a multi-valued pointer to its "parents".
Where are you picking up on parent-child relationships? Aside from the Model hierarchy itself (which is a strict hierarchy, but that doesn't *mean* as much as it does in most programming languages), its not something I use all the much...
https://github.com/jducoeur/Querki/wiki/Database-design
Anyway, I have to try it. The hierarchy is not an issue; it is actually not a hierarchy, but compound keys that I extract from html divs, spans and tables, with values attached. My purpose is to make my code read html the way humans read it when they want to find values, like in a spreadsheet, but with more dimensions.
That's largely because the language is really, in most important respects, duck-typed. That is, you usually care about what Properties a Thing *has*, more than what Model it *is*, and absolutely any Thing can have any Property added to it. So where you would use multiple inheritance in a more conventionally class-based language, you instead just add Properties as needed in Querki.
(The Spaces themselves actually *are* multiple-inheritance: mixins are pretty important for the long-term plans. But that's more cognate to importing multiple packages in a Java-like language.)
Anyway, I have to try it.
Okay, cool. At the very beginning, Alpha is going to be necessarily limited to friends-and-family (for legal reasons), but once I have the company properly incorporated (hopefully pretty soon), I'll be looking for more people to kick the tires, and I'd be happy to have you come try it out then...