API brainstorming

[Alex Wilson]

We can discuss the specifics of the API here that the developers will use to access components of the pine ecosystem like achievements, leaderboards, user info/friends, and online multiplayer gaming. Most of the APIs shouldn't be too hard to figure out (just method naming), but the online gaming will need to have some thought.

[Jeremy Kahn]

I think Luke will have more insight into the structure of the ecosystem than I (he actually plays games and knows what works well, whereas I usually just focus on development, heh).  In any case, I think we can build all Pine APIs into a single, cohesive library.  I started a wiki page for the library/framework, so we can just put everything there and keep the global namespace clean.

I vote that we just call the library "Pine."

var pine = new Pine();

On Wed, Jul 25, 2012 at 4:31 PM, Alex Wilson <arex...@gmail.com> wrote:

We can discuss the specifics of the API here that the developers will use to access components of the pine ecosystem like achievements, leaderboards, user info/friends, and online multiplayer gaming. Most of the APIs shouldn't be too hard to figure out (just method naming), but the online gaming will need to have some thought.

--
You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/NEkZLhT2tOsJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jeremy Kahn

jerem...@gmail.com

https://github.com/jeremyckahn

@jeremyckahn

[Luke Stebner]

I would really like to package in underscore and also backbone and then use backbone for all things API related. How does everyone feel about this?

[Luke Stebner]

And for the nodejs API process I would like to use express and mongoose. I am very familiar with all of these and strongly feel they make quick, modular development and would be a big help to us. If anyone has alternatives feel free to throw them out as well, otherwise please take a look at these and let me know what you all think.

[Luke Stebner]

Lastly (for now), if you guys agree with these do you mind if I start prototyping the nodejs API? I think the best way to figure out what's going to work is going to be to just get in there and start getting something working. If so, I'll start a git repo and then post it up here for everyone to check out. I will also create a nodejs setup guide if anyone here is unfamiliar and thinks that would be helpful to them. 

[Jeremy Kahn]

Everything seems fine, but I question the choice to use Backbone.  As far as I can tell, our API really shouldn't be touching the DOM or dealing with URL routing - it's meant to be a utility library for communicating with the Pine ecosystem and also for interacting with the Node server, among other things.  Underscore is universally useful because it is so generic, but I feel that Backbone doesn't really lend itself to the focus of our API.

Your Node library choices seem fine to me.  I personally love Backbone and am planning to use it for the Pine UI, but I'm not sure if it belongs in our developer-facing API.  Definitely feel free to try something out and put it up on Github, though.  Code speaks louder than words. :)

On Sat, Jul 28, 2012 at 1:51 PM, Luke Stebner <luke.s...@gmail.com> wrote:

Lastly (for now), if you guys agree with these do you mind if I start prototyping the nodejs API? I think the best way to figure out what's going to work is going to be to just get in there and start getting something working. If so, I'll start a git repo and then post it up here for everyone to check out. I will also create a nodejs setup guide if anyone here is unfamiliar and thinks that would be helpful to them. 

--

You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/JRRid00xfnUJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Wilson]

Precisely what I was going to say.

I think putting some ideas up on Github will help us get moving forward and solidify any ideas we have.

[Luke Stebner]

Alright, fair points. Will get something started and report back!

On Jul 28, 2012, at 2:15 PM, Alex Wilson <arex...@gmail.com> wrote:

Precisely what I was going to say.

I think putting some ideas up on Github will help us get moving forward and solidify any ideas we have.

--

You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/DCHWK2JoX2YJ.

[Alex Wilson]

I'm putting together a gist with some ideas for APIs by showing examples of what they would look like in use. I put up a rough idea for the multiplayer API, and I plan on putting up more soon. Any feedback would be great.

https://gist.github.com/3288302

[Luke Stebner]

Hey,

It's a crazy busy week for me, but I'll take a look at this and then give some feedback as soon as I can!

[Alex Wilson]

Do you guys think it would be feasible to allow execution of some game logic in the node process? Some developers might want to do this to prevent easy cheating and such. We could provide an API to communicate with the scripts running in the node process from the browser and vice versa.

[Jeremy Kahn]

While I don't see why we can't or shouldn't allow it, I question if that should be the responsibility of our API. This seems like something that each developer would want to implement in a way that is specific to their game. Can you provide an example use case?

[Luke Stebner]

Maybe we could allow them to write scripts (I could see things like inventory management methods) that are runnable as a node process for their game to communicate with? Of course this would require some extra verifying on our end that they don't do things they shouldn't. But with permissions we could probably handle limiting these scripts enough that offloading tasks would be easy to manage.

I also don't think this is part of the API but a whole new feature.

On Aug 11, 2012, at 10:51 PM, Jeremy Kahn <jerem...@gmail.com> wrote:

> While I don't see why we can't or shouldn't allow it, I question if that should be the responsibility of our API. This seems like something that each developer would want to implement in a way that is specific to their game. Can you provide an example use case?
>

> --
> You received this message because you are subscribed to the Google Groups "Pine" group.
> To post to this group, send email to pine-d...@googlegroups.com.
> To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.

[Alex Wilson]

Maybe in some sort of strategy the developer would want to run the game engine in the background while telling the browser code what to render. This would make it much harder to cheat using something like a JavaScript console. I do like Luke's idea of having them be separate scripts because it makes them much easier to manage.

[Jeremy Kahn]

What you're suggesting sounds like a psuedo-Web Worker.  While I can see the benefits of this, I don't think it is wise to view it as a security measure.  The local Node server is still a client in the context of multiplayer gaming, and we should not be trusting the client for data validity, be it a browser or a Node instance.

Additionally, I'm not sure if it is wise to promote multithreading a game like this, due to the low resources available on the hardware.  I could be really off base with that concern; I'd be curious to see what the real-world performance implications of heavily multithreaded games would be.

I'd say that this type of functionality would be a good experimental API, but I think we would be better served by solidifying the ecosystems and graphics APIs (which I can start a thread for a little later).

On Sun, Aug 12, 2012 at 1:00 AM, Alex Wilson <arex...@gmail.com> wrote:

Maybe in some sort of strategy the developer would want to run the game engine in the background while telling the browser code what to render. This would make it much harder to cheat using something like a JavaScript console. I do like Luke's idea of having them be separate scripts because it makes them much easier to manage.

--

You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/zHYjOfbhNyIJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Wilson]

I want to make a more complete and descriptive document for the API, and I was wondering if there was a tool that you would prefer I use for it. I can just write it out in markdown, but if you know of something to make it easier, I'd like to know about it.

[Jeremy Kahn]

Markdown seems like a good enough choice to me.

[Alex Wilson]

Should I make a separate repo for documentation? It seems to me that the current Pine repo is stuff that will be put onto the Pine device, and I'm not sure that documentation falls into that category.

[Jeremy Kahn]

Yeah, that's a good idea.  I know that Luke started a repo a while back, but it hasn't been modified in a while and I'm not sure if he's been working on it.  I agree that the API and external ecosystem should not be in the Pine client repo, so feel free to start a repo and keep your work there.

[Alex Wilson]

I'm worried that having the pine API and input API loaded every time a game starts up could be slow. If we used a chrome extension we could have the code loaded when Pine starts up and use that extension for showing UI like friends coming online or achievements being gotten. The only thing is that if we decide not to use chrome later, we would need to find another way to do it. What do you think?

[Jeremy Kahn]

This is definitely a valid concern, but why do you think it would be slow?  Is it because of the amount of code needed to make it work, or other performance bottlenecks (such as network I/O)?  As for the file size, hopefully we can keep the compiled binaries small enough so that it's not an issue - but I guess we'll just have to see.

You raise a good point about UI for alerts, so I can see how a Chrome extension would make sense for that.  Can a web page interact directly with a Chrome extension?  I've looked at the API briefly in the past, but I am not terribly familiar with it.

If we end up switching to Firefox OS (and we're still pretty far from seriously considering that option), we can convert our API implementation to work as a Firefox extension - although that is anything but trivial.  Alex, do you have any experience with building Chrome extensions?

On Sun, Sep 16, 2012 at 8:36 PM, Alex Wilson <arex...@gmail.com> wrote:

I'm worried that having the pine API and input API loaded every time a game starts up could be slow. If we used a chrome extension we could have the code loaded when Pine starts up and use that extension for showing UI like friends coming online or achievements being gotten. The only thing is that if we decide not to use chrome later, we would need to find another way to do it. What do you think?

--

You received this message because you are subscribed to the Google Groups "Pine" group.
To post to this group, send email to pine-d...@googlegroups.com.
To unsubscribe from this group, send email to pine-discuss...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pine-discuss/-/gjzWQWnZhT4J.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Wilson]

I'm probably no more familiar with chrome extensions than you, but I'll look into it today. If we can get it to interact directly with code on the page, I'll start work on a basic extension to prove it works.