Vapor Library

[Bobbyjoness]

So in my mind I see Vapor becoming something like steam but just for love. And some of the things I would like to see Vapor have would be cool if it was able to be integrated into the games it runs. Like for example user accounts. A sdk would most likely be simple with only 4 to 5 APIs being available at the launch of the sdk. And if Vapor takes off I'm sure we can make it better. The goal I have is for one day to have Vapor be the face of Löve. Kinda like a public ambassador. So far love has been a close community many projects only being played by Löve devs. But what if Vapor can help alleviate this issue? For that to be true I believe Vapor needs to become the kind of game client a user and dev would like to use.

[pablomayobre]

Why just LÖVE? Again, if you have a RESTful API any one can target it... Anyway, arent we trying to end up being GameJolt?

[Bobbyjoness]

Because it's brand pride if you stick to Löve, but I understand what you mean

[pablomayobre]

I dont think "Brand Pride" is good, LÖVE community is not that big, so games are sparse (even more finished games). A client with just a few games is not something people wants hahaha

PS: This same applies to what we were discussing in #201

[Bobbyjoness]

I a sdk is different set of APIs from the APIs needed for a client. And I'm thinking that it would be best if it relied on the client.

[pablomayobre]

Well I must discern about that, it should totally not rely on the client, what about if you want to use Vapor services but still provide other mean of distribution? You would need to have different executables... That is surely not how other services do this stuff

(Still I consider this issue and issue #200 to be a little bit outside of the current scope of Vapor)

[Bobbyjoness]

Scopes expand. And yeah maybe not dependent on the client idk.

[pablomayobre]

You are right in that Scopes expand... But you are expanding TOO fast, I think we should have 1.X working before starting all this.

I still think this is the way to go though... but we should wait till the rest is working fine and is stable

[Bobbyjoness]

I personally think we should test current design ideas and other things with 0.x which is why I made so many issues. I want to know how we would like to have all these things so I can start testing and designing implementations in 0.x which is currently in a releasable state. Which it can help us get feedback now. That way it would all be integrated in 1.x from the start.

[pablomayobre]

It's like making a mess bigger so that when you tidy everything up you are not missing anything... Not sure it is a good idea but could work idk

[Bobbyjoness]

Yeah just like that. For example for user accounts to be implemented the easiest way is to have it integrated directly into 1.x from the start

[pablomayobre]

Not sure, if you have something solid for 1.x you could just add what is missing pretty easily without making too much of a mess... right now 0.x stuff is all over the place, you can't separate anything... So adding stuff to it would later mean trying to abstract it from each thing without breaking everything and then keeping it tidy enough so that it doesnt break the structure of 1.x, that or rewriting it from the ground which would mean a wasted effort

[Bobbyjoness]

You'd not understanding most work is backend.

[pablomayobre]

I understand that... but there is still a lot to do in the client...

[josefnpat]

I have a problem with the terminology of "SDK" as that implies it is a development tool on it's own.

I would be in favor of a "library" to integrate into games for vapor 1.x. I can see this being advantatious especially if #200 comes to frutition.

Minimal matchmaking servicies could allow for:

local matchable_friends = {}
for _,friend in pairs(vapor:getFriends()) do
    if friend:getPublicGameID() == vapor:getPublicGameID() and
        friend:inPublicGame() then
        table.insert(matchable_friends,friend)
        print("found friend match, connect to:",
            friend:getPublicGameIP(),":",
            friend:getPublicGamePort())
    end
end
return matchable_friends

As I mentioned in https://github.com/josefnpat/vapor/issues/200#issuecomment-114721865

I don't think 0.8.0 has enough games to warrant this infrastructure, and such an extension I will not be interested in supporting myself if this gets into the 1.x roadmap.

While I understand @Bobbyjoness want to add 0.9.x games to the website, with 0.10.0 coming out "soon enough" I don't think enough game developers will be prepared to use and support a "vapor 1.x library". Feel free to prove me wrong by having those developers chime in here. I can chime in, especially with Xapalus, as such a previously mentioned matchmaking service would be awesome. But alas, I am one developer.

[pablomayobre]

Well I give an up vote to it, but I consider it should be a future feature... not important right now!