Game spek
was up on my screen from last night when I went into the office this morning 
Mainly thinking out loud. Inspired thoughts are welcome. Spin is not. ~TIA
The gaming component of the site needs to be additional to all other elements, yet integrated so that it can have affect and collect information on any aspect of anything.
Best place for this is the quad table I think.
New context type “game”.
Quad format of game.<user id>.<metric>.<value>
Then get the game.<user id> frame for all metrics or access individual metrics as desired.
All actions have metrics. This is basically atomization, but for a different purpose than stream resolution.
For instance, when an author adds a post (post meaning any kind, not just a thought), edits a post, tags something, does a search, clicks on a search result, follows a tag, etc, etc, these will be recorded under that metric.
Some recordings will simply be a count. Other recordings will be multiple values modified on the JSON object stored for the metric.
Who or the exact identity of what (title etc) an author is interacting with will not be recorded. This is not necessary for gaming and is borderline invasion of privacy as well. It also would vastly bloat the database.
Game events can use the general event system as quad event.<user id>.<event name>.<event action>
Event frames mainly transit back to the browser in the “fbi” JSON package and browser plugins read and manage them firing specific actions as necessary.
For instance, an event named userComments could trigger when the author has posted 20 comments and update the “completion” metric and fire the completion event to see if the user has cumed out and can graduate … if so the “graduation” event will fire and do wonderful things on the user’s screens and probably send them an email too.
Because the whole gaming system is primarily browser plugin based it is light weight and does not load the server or page builds and can be extended nearly infinitely with additional on demand plugins.
All that needs to be server side is recording of metrics and pass through to browser of game and event frames.
This also means that virtually all of the game logic can be written in JavaScript which is about 20 times superior to PHP for writing such logic … and will directly transfer to server side nodejs someday too.
Mainly thinking out loud. Inspired thoughts are welcome. Spin is not. ~TIA
The gaming component of the site needs to be additional to all other elements, yet integrated so that it can have affect and collect information on any aspect of anything.
Best place for this is the quad table I think.
New context type “game”.
Quad format of game.<user id>.<metric>.<value>
Then get the game.<user id> frame for all metrics or access individual metrics as desired.
All actions have metrics. This is basically atomization, but for a different purpose than stream resolution.
For instance, when an author adds a post (post meaning any kind, not just a thought), edits a post, tags something, does a search, clicks on a search result, follows a tag, etc, etc, these will be recorded under that metric.
Some recordings will simply be a count. Other recordings will be multiple values modified on the JSON object stored for the metric.
Who or the exact identity of what (title etc) an author is interacting with will not be recorded. This is not necessary for gaming and is borderline invasion of privacy as well. It also would vastly bloat the database.
Game events can use the general event system as quad event.<user id>.<event name>.<event action>
Event frames mainly transit back to the browser in the “fbi” JSON package and browser plugins read and manage them firing specific actions as necessary.
For instance, an event named userComments could trigger when the author has posted 20 comments and update the “completion” metric and fire the completion event to see if the user has cumed out and can graduate … if so the “graduation” event will fire and do wonderful things on the user’s screens and probably send them an email too.
Because the whole gaming system is primarily browser plugin based it is light weight and does not load the server or page builds and can be extended nearly infinitely with additional on demand plugins.
All that needs to be server side is recording of metrics and pass through to browser of game and event frames.
This also means that virtually all of the game logic can be written in JavaScript which is about 20 times superior to PHP for writing such logic … and will directly transfer to server side nodejs someday too.
Tags
- item 19845
- gameify
Comments
Holmes says
2016-02-03 06:26:01 [item 19845#44349]
whew! … well at least now we are back where we were …. please consider my Gameify of thinking.domains as my continuation to this thought.
Seth says
yes it was 
seems like things need to happen on the server as well as the client when events happen. like for example a person earning a new pallet on their RTE box. right?
I don’t see how high & versatile usage of fbi – equates to a game – someone/something needs to evaluate the quality of such usage. Could search for something obscure like the titmouse in a treasure hunt, though.
2016-02-03 06:26:05 [item 19845#44350]
dA2016-02-02 17:49:26 19837%252344296
Have you watched the video? If you do, you will understand. Until you do, your wasting both of our time talking about it. Thanks.
Yes Seth. The events happen on the client. But if an event results results in a change, then an AJAX request will be dispatched to update the server quads as appropriate. Very light weight server side.
2016-02-03 06:29:06 [item 19845#44352]
incidentally this was the train that i intended to delete because, imho, it is just hairing into the static of rwg … and as such can never contribute to the main thought at hand.
2016-02-03 06:31:48 [item 19845#44353]
Don’t care about that, but I thought the AJAX thing was good added knowledge for you. It was an answer to a real question you had about where things happen.
Seth says
2016-02-03 06:47:45 [item 19845#44358]
what kind of a “javascript event” would “fire” when a person signs up having been invited by another member?
2016-02-03 06:54:59 [item 19845#44359]
A traditional invitation would be a url that included a special code. The system would detect that an incoming code exists and fire the event for a code existing. The event would load extra libraries and decipherer the code and update the persons session and/or account accordingly.
Another path could be coupons. A person can get a coupon code in some way and enter it in a coupon dialog at the site to start the event chain.
Another path could be coupons. A person can get a coupon code in some way and enter it in a coupon dialog at the site to start the event chain.
2016-02-03 07:06:28 [item 19845#44364]
such an event would happen when the invited person clicks the sign up button and the server verifies their credentials and builds their author quad. sure sounds to me like that is not a client side javascript event … though maybe it could via ajax be contrived to be such.
2016-02-03 07:08:49 [item 19845#44366]
Yes. There isn’t any substantial difference as long as the communication pathway security is maintained.
Seth says
2016-02-03 06:33:52 [item 19845#44354]
one specific question is, if the domain operator is trading money for access to tools (premium accounts), can a person earn that same access by contributing posts (or other things like that) ? How does the events recorded in the quads make that work?
2016-02-03 06:38:51 [item 19845#44356]
The quads only store metrics and fire events. The event handlers then run rules on the metrics and when a rule matches, then the person’s account is updated accordingly. Right now I expect the rules to be just javascript in the event handlers. I don’t see a need to store rules as quads and build a rule runner for our expected level of gaming.
2016-02-03 06:44:44 [item 19845#44357]
these “javascript events” happen only on a client browser ...right? What if the event was a person completing a paypal donation? What kind of a “javascript event” would fire?
2016-02-03 06:57:55 [item 19845#44361]
Not any different. We specify the return url for any payment service to return to. That url can contain anything that can be read by server and browser in any manner that is desired and secure and then do whatever.
2016-02-03 07:02:52 [item 19845#44362]
where i am confused is thinking “javascript events” happen only on the client browser ...or at least must start there. yet many of the events are going to be “first known and verified as happened” only on the server. do you see my confusion?
2016-02-03 07:06:36 [item 19845#44365]
Not really. I work with the browser and the server as a contiguous whole. Now that they pass back and forth a JSON state block containing everything in the whole fbi world that is known, there is little difference between them. I choose where to put the code based on other things, not on if it is server or browser.
See Also
- Thought about: jane mcgonigal: gaming can make a better world | ted talk with 7 viewings related by tag "gameify".
- Thought Eliminate clumsiness for starting with 3 viewings related by tag "gameify".
- Thought about: create a free blog at thoughts with 3 viewings related by tag "gameify".
- Thought Million dollar thought. with 0 viewings related by tag "gameify".
- Thought Gameify of thinking.domains with 0 viewings related by tag "gameify".