Initially I thought the spark was the thing I needed to use to hit the particles and not the sphere. Didn’t take long to figure that out though.

I didn’t notice any major bugs. I did manage to get the pause/play state confused once. I think I brought up the instructions menu when there was another menu showing before I began a level. Then when I dismissed the instructions menu, I went straight into the game, even though it was paused.

So, thinking about rating 3D models, it might score highly for its creativity, but poorly on the technical implementation. This is much more informative than an average rating of 3 (out of 5).

Wikiup :
@travis
First, presenting a content author or developer with a contract is a huge assistance in creation. It presents both author and developer with a known, working system towards which they can build. It reduces the number of properties the content author has to look at and thereby simplifies the UI when entering data. (I can imagine an answer where the content tool can enforce a contract, even if the system doesn’t innately require it. That would possibly solve the UI problem.)

Good question and good answer That’s the general idea that I had in mind. In a data storehouse for multiple games and game types, it seems to me that flexibility is important in the storage service and game and tool cohesiveness has to be left to the individual games and tools. Editors not tied to any particular game could even show a list of the contracts the current object meets and update it as attributes are added and removed, while editors with a more specific focus can simply offer a fixed list of required attributes.

…I’d be concerned that we might end up with versions well-suited to one contract (and therefore highly rated), but poorly suited to others for which it might happen to qualify.

That’s a really good point that I hadn’t considered. A partial solution could be that an *intended* contract is (optionally?) specified in definitions, and those are favored in queries. Submissions that don’t even meet their intended definition can be rejected outright. This devalues the flexibility somewhat though, because if I really want to create a game-agnostic creature it may just not show up anywhere.

…Surely it would be far faster to assign a contract ID to each class, rather than build a lengthy WHERE statement?

Yes absolutely, though I suspect we’ve been thinking of different schemas all along. My concept has been that attributes of objects are in a separate table with their name and value and a relation to the object, trading speed of some queries for flexibility and space. This means that as new contracts are defined their attribute lists don’t have to be a subset of a master list that comes from the columns of the classes table.

I’m pretty sure this schema would just require one JOIN and a long WHERE statement to get the compliant objects list and do it all in one DB hit. If the storage service ended up scaling out to multiple application servers you may want to do the filtering in the application code rather than on the DB. With the hybrid approach from before the difficult task of finding all compliant objects could just be a fallback after searching by intended contract.

The idea has a lot less punch with intended contracts added in – it starts to feel like an unnecessary appendage.

So here’s a different idea: maybe querying for objects by a contract also gets objects in that contracts subclasses? It slows down the query for an object again but makes headway in the ‘meaning of intelligence’ mismatch issue.

I’m looking for a way to promote cross-game objects. Obviously multiple games could subscribe to the same contract, but these contracts still represent a big fragmentation of the content. Wikipedia is so excellent because millions of users collaborate on one big pile of content. If I can just decide to be a TwitchRing developer and work on only objects for TwitchRing contracts, how is this very different from the “share your character/board/…” stuff that’s already out there on a game-by-game basis?

First, presenting a content author or developer with a contract is a huge assistance in creation. It presents both author and developer with a known, working system towards which they can build. It reduces the number of properties the content author has to look at and thereby simplifies the UI when entering data. (I can imagine an answer where the content tool can enforce a contract, even if the system doesn’t innately require it. That would possibly solve the UI problem.)

Second, lazy assignment presumes that a definition which includes all the necessary properties is therefore suitably compliant with the contract. But I’m not sure this is necessarily the case. For example, two game systems might have an intelligence property, but one also has wisdom and intuition properties. The author of the first system presumes that intelligence represents all mental processes, while the author of the other shifts game balance by moving responsibility for certain processes to these other properties. I’d be concerned that we might end up with versions well-suited to one contract (and therefore highly rated), but poorly suited to others for which it might happen to qualify.

Finally (and this is an area where you know more than I, so I’ll defer if you think I’m wrong), I would imagine that searching the DB for compliant versions in this manner would be very slow. Surely it would be far faster to assign a contract ID to each class, rather than build a lengthy WHERE statement?

I appreciate your further input.

so when i define my green dragon, instead of saying this is a WiRPS green dragon, I simply define all the attributes required for WiRPS. then when a green dragon meeting the WiRPS criteria is searched for, mine comes up as an option. this way mine will also come up as an option for any contract that represents a subset of WiRPS, even contracts that were created after my dragon.

this version would allow more sharing of objects between games, as instead of asking whether the object was created *specifically for my game*, it asks whether it meets the demands of my game.

Mike :

…are you saying that a dragon could be pulled at random out of the wikiup system during game play, if it meets a predefined contract? Or would a developer choose the dragon during game development and have it baked into their game?

Either. That’s up to the game developer. She could tag a specific class version and use that, or she could request a version dynamically at runtime. Filtering by contract simply ensures that whatever she picks meets her game’s needs.

Mike :

Is a contract like a theme which runs over say a set of objects or is each contract specific to an individual object?

A contract would usually apply to a general system, rather than any individual class, though specific classes and their descendants would be targeted. In programming terms, it would be like defining an IMyGameWeapon interface. You wouldn’t be defining anything specific about any specific weapon, but you’d be dictating what an weapon would need to implement in order to meet the contract definition (and therefore appear in your game).

Mike :
Actually a little diagram of data flow/contract subscription may help a lot.

Good idea. Will attempt to do tonight!