Tournament Hub (C4A2?) Design and Plans

[pmprog]

So as some of you might have read, I'm looking into working back the TournamentHub, and wanted to share my current plans to get some feedback and guage interest.

Functionality I'm planning to include

• Friends listSee friends online
• What they're playing
• Instant messaging

[*]Scoreboard
[*]Multiplayer games

• Register your server as a game host
• Find open hosts
• Turnbased game API

[*]Game Launcher

• Something similar to this, but probably windowed -- https://www.youtube.com/watch?v=ZPdPd2rnzwQ

[*]THub Overlay

• Accessible from anywhere
• Terminate processes
• See friends list
• Considering: Plugin modules for extra features

This will be bundled in 4 components

• Developer API Library (Source)C libraryRegister / Log On
• Currently Playing
• Friends
• Scores
• Multiplayer

[*]Website (URL; Source)

• Front end componentRegister / Log On
• Friends
• Scores

[*]Back end component

• For communicating with DevAPI

[*]Launcher (Source)

• Considering Qt
• Window with Minimise to Tray
• Search for installed games (*.desktop files?)
• Manually add games/software
• Chat functionality

[*]Overlay (Source)

• FunKey Monkey plugin to handling keyboard input (Source)
• Ability to render over any display (X, GLES, Console, etc.) -- Having problems with this at the minute, my DRM example won't render when X is active
• View highscores (Use "Currently Playing" to auto-jump to game)
• Considering chat functionality

 

[Neelix]

A couple of thoughts...  don't know how much they are worth though.

If you're considering QT anyway, could you take advantage of panorama for the launcher?

It occurs to me that your planned launcher looks like it may contain most of the functionality needed to be the Pyra's equivalent of Mini-menu - Could this stand alone as the Pyra's main interface if that's what the user wanted?

-Neelix

 

[pmprog]

I have considered panorama, but 1. I couldn't build it on my desktop iirc, and 2. I don't understand QtQuick; so unless somebody who does "get it" wants to do the launcher with panorama, it's unlikely to be used.

As for using the launcher as minimenu, sure, there shouldn't be a reason you couldn't do that

 

[bzar]

Couldn't build panorama? It should build with the instructions on the readme. Hunh. :blink:

Anyway, use what you're comfortable with. If you find yourself looking into QtQuick, I can probably fill you in on stuff. Can't participate myself though

Good luck with this ^_^

 

[pmprog]

Couldn't build panorama? It should build with the instructions on the readme. Hunh. :blink:

Hmm, just remoted home, it looks like it had compiled. I'm sure I had some issues with it, but it was a while ago. Maybe it was just me, and I couldn't figure out how to get started.

I'm currently trying to develop an overlay prototype, but it's not going very well. So I might try and finish the developer API and website back-end first, then put together a test client before expanding it into the website, launcher and overlay.

With a working back end and a simplistic client, will at least be able to gather if anyone is interested, and maybe convince a could of devs to try including the highscores functionality in their games/ports

 

[God Ginrai]

I would suggest making an API that launchers can use and have your launcher be a reference implementation. (like Weston for Wayland)  That way, other launchers can implement the same functionality.

-God Ginrai

 

[comradekingu]

Seeing what games your friends have. Making challenges/compos as a game-mode.

Also tie into the rating of/donations to games on the repo.

And some automation on downloading games.

 

[Silent-Hunter]

Will the overlay have a browser?

 

[Neelix]

A way to opt in or out of the score sharing on a game by game basis mightn't be a bad idea.

-Neelix

 

[skeezix]

It your purpose to be a client for C4Av2, or as a standalone launcher, or both, integrating it all together?

(It matters, because if you wat to do a friends list, but also be an independant launcher, than I guess you're doing your own friends list thing; but if its more C4A oriented, we coudl do the friends list based on C4A account-id's and servers.)

C4Av2 is (possibly, TBD) more about being a pandora/pyra/other (r-pi, PC, etc) hub; initially just for scoring and stuff as it does now (but better.. multiserver aware, cross server challenges, dynamic tournaments, all that stuff), but possible extending into other features that seem organic or logical (ie: friends list might make sense?) .. host one server (or more) at ED's site, so its more an official thing, for instance.

But you coudl entirely go your own way as your'e motivated, so go go go

As my time is limited, I was figuring on working on C4Av2 server only, and let all client and library work be others; or maybe I'll just kick it off and help with ideas? I don't want to be a limiting factor :/

jeff

 

[pmprog]

Will the overlay have a browser?

That depends. If I have to render everything in the overlay by hand - no. If I end up just having a Qt window, then yes, I could embed QWebKit

It your purpose to be a client for C4Av2, or as a standalone launcher, or both, integrating it all together?

Well, I haven't seen any C4Av2 info around, so I've kind of gone with my own thing. The launcher I'm planning links everything together using the DevAPI.

C4Av2 is (possibly, TBD) more about being a pandora/pyra/other (r-pi, PC, etc) hub; initially just for scoring and stuff as it does now (but better.. multiserver aware, cross server challenges, dynamic tournaments, all that stuff), but possible extending into other features that seem organic or logical (ie: friends list might make sense?) .. host one server (or more) at ED's site, so its more an official thing, for instance.

They are some good points, which are worth adding in. I've paid for a server with domain already, but if we add the multiserver, that's not a problem if ED wanted to host one too

As my time is limited, I was figuring on working on C4Av2 server only, and let all client and library work be others; or maybe I'll just kick it off and help with ideas? I don't want to be a limiting factor :/

I posted a link to my website source repo. All the api*.php files will be the code behind the DevAPI requests, feel free to fork.

One quick question for everyone, would it bother you if you had to confirm an email address to activate your account? It'd only be a one-time thing

Edit: Guess I should really add the database schema to my github some time too...

 

[thatgui]

One quick question for everyone, would it bother you if you had to confirm an email address to activate your account? It'd only be a one-time thing

The reasonable part of me says: that depends on your reasoning behind it, what security measures you have in place to protect that data. The non reasonable part says NO!

 

[bzar]

Will the overlay have a browser?

That depends. If I have to render everything in the overlay by hand - no. If I end up just having a Qt window, then yes, I could embed QWebKit

QtWebKit is being deprecated in favor of blink-based QtWebView. Just a side note

 

[pmprog]

One quick question for everyone, would it bother you if you had to confirm an email address to activate your account? It'd only be a one-time thing

The reasonable part of me says: that depends on your reasoning behind it, what security measures you have in place to protect that data. The non reasonable part says NO!

Only in so much as to email you password reset, friend requests, when you're high score has been broken, etc... In other words, only for the purposes related to the Tournament Hub. It'll be stored in plaintext in the database, but aside from when you enter it into the registration form, it'll never be displayed or exposed outside of the website PHP, and only used for sending related emails

I've modified the system so that you don't have to activate your email, and what I'll do is just not send emails to a non-activated email. This does mean that if you lose your password on a non-activated account, you've lost the account (though I suppose I could make this an exception to the email rules). I'm also thinking about the potential for lots of "dead" accounts building up.

Will the overlay have a browser?

That depends. If I have to render everything in the overlay by hand - no. If I end up just having a Qt window, then yes, I could embed QWebKit

QtWebKit is being deprecated in favor of blink-based QtWebView. Just a side note

Well, whatever I can embed without having to write my own html renderer then

 

[thatgui]

Only in so much as to email you password reset, friend requests, when you're high score has been broken, etc... In other words, only for the purposes related to the Tournament Hub. It'll be stored in plaintext in the database, but aside from when you enter it into the registration form, it'll never be displayed or exposed outside of the website PHP, and only used for sending related emails

I've modified the system so that you don't have to activate your email, and what I'll do is just not send emails to a non-activated email. This does mean that if you lose your password on a non-activated account, you've lost the account (though I suppose I could make this an exception to the email rules). I'm also thinking about the potential for lots of "dead" accounts building up.

If one does not need to activate the E-Mail, why bother asking for one ? My suggestion would be to make entering an E-Mail address a optional field in the process, and inform the user about the benefits entering an E-Mail adress will give him/her. Also warn the user that he won't be able to recover his account if he forgets the passwort. With that in mind the potential for "dead" accounts piling up is surely there, but the userbase will probably not that big, and you could reduce that pile every now and then with a job that deletes accounts that don't have an E-Mail and were not used for 6/12/18/? months (also hint at that during registration).

Do you have any plans on connecting your account management to other systems, like this board. Don't know if that is possible, but how about one could just use the credentials from this board to login ?

 

[pmprog]

If one does not need to activate the E-Mail, why bother asking for one ?

Because when I started writing the software, it was I guess leaving it blank will be handy

My suggestion would be to make entering an E-Mail address a optional field in the process, and inform the user about the benefits entering an E-Mail adress will give him/her. Also warn the user that he won't be able to recover his account if he forgets the passwort. With that in mind the potential for "dead" accounts piling up is surely there, but the userbase will probably not that big, and you could reduce that pile every now and then with a job that deletes accounts that don't have an E-Mail and were not used for 6/12/18/? months (also hint at that during registration).

Yeah, probably the best way.

Do you have any plans on connecting your account management to other systems, like this board. Don't know if that is possible, but how about one could just use the credentials from this board to login ?

At the minute, no, as I'm not sure how any of that would work, but I've not even looked into it

 

[comradekingu]

An option to not suck at flappy bird. I feel this has much room for improvement.

 

[pmprog]

An option to not suck at flappy bird. I feel this has much room for improvement.

Tournament Hub won't help with that - on the contrary, it'll tell you (and potentially everyone else) how bad you are at it

 

[Rockthesmurf]

The less barriers you give the user the better. A lot of mobile games these days let you play without logging in at all, it will just create an anonymous user for you. On top of that, when you do decide to login, you effectively link your account to a login, so you can give the user options of how to login (Facebook, Twitter, email address) and also allow the user to link multiple servers, so the flow can be along the lines of:

1. User downloads game
2. User runs game and plays as anonymous user
3. After each round, the game hints at user of the benefits of authenticating
4. After a few rounds the user decides to authenticate, using Facebook
5. Their Facebook account is linked to what was the anonymous user, it is no longer an anonymous user, and things like the name are automatically filled from Facebook
6. At the end of their next round it shows their Facebook friends who also have the game, so you can compare scores, the game hints if they link Twitter they'll see their Twitter friends too
7. After a few rounds the user links Twitter

Of course an issue on Pandora/Pyra is the community is so small that I dare say the amount of friends any of us have on Facebook/Twitter that also have a Pyra is zero, although it would be pretty neat to find out one of your Facebook friends of people you follow on Twitter in fact does have a Pandora/Pyra without you ever realising. I have no idea if the provider of the forum boards provides external oauth access, but if this is the case it would seem like a neat mechanism (that way you could pull the photo/username from the forum and immediately people would recognize other people in the game from when they have browsed the forums).

 

[skeezix]

okay, so you're building a server and the works, gotcha. Sorry, didn't look at your repo yet

Do you have, or can add a few fields.. I had been planning for C4Av2 to make good use of submission data -- the submitted source (r-pi, pandora, pc, etc), and a unified game list (for that server); on a given user device, they would have their user file, which woudl include a list of servers it knows about, and the user-id/unique-id on each, and the preferred default server. (ie: this way they could have multiple servers and pick which account/server they want to use, which then queries ot find the game list on that server, etc. It also means can do 'test servers' easily, for trialing your new game for awhile before promoting over to a live release server, etc.)  Then the scoring woudl be purely dynamic -- a default set of screens like 'show top 100 players, for month/year X/Y, for device Pyra', but you coudl easily add new report screes which include pyra + pandora of the same game-id, or r-pi + pyra, or all of them, etc. Likewise, any given person coudl kcik off their own tournament .. ie: all goals to make it fun, but less administrivia by .. admins. So any user coudl just opick a list of 10 game-ids, and startup a tournament, and issue challenges, and all of that. Really dynamic. One database per server, but making good use of these genre fields, source submission fields, etc.

Guess I'm saying.. don't make it pyra or pandora specific; keep it wide open, and then could be a server for pyra + pandora, and other servers for r-pi, or just one big server for it all, etc.

I keep thinking it'd be cool to backport a few games to gp2x (say) with some sort of score submission thing, keep lots of platforms involved, and grow it bigger than our small community. *shrug*

jeff