Je doute que le temps de la RAM (ordre de grandeur: nanoseconde) impacte plus ton jeu que le temps du réseau (ordre de grandeur: seconde). 
C'est la raison pour laquelle le long-polling sert simplement à ne lancer qu'une requête réseau, à "squatter" la RAM du serveur qui va roupiller (sleep) jusqu'à ce qu'un truc se passe avant de répondre les infos demandées. Cela évite de faire des requêtes en boucles traitées le plus vite possible par le serveur.
Les données HTTP ou websockets sont tout aussi interceptables: l'utilisation de l'un ne requiert pas plus et pas moins SSL que l'autre. Pour des données de jeu amateur sans visée commerciale ni professionnelle, osef: ce n'est pas la priorité.
SSL ne sert qu'à lire le traffic entre un client et ton serveur. Si tu as un panneau d'admin codé en javascript qui envoie une requête avec le mot de passe de la BDD (ou autre), oui, on pourra te pourrir ta base (mais si t'as codé comme ça, t'as vraiment foiré ^^ ). Sinon, non, ta BDD sera sauve. Le seul éventuel risque résiderait dans l'interception du trafic entre un admin loggé sur le jeu et le serveur du jeu. Là, le pirate qui écoute la communication pourrait alors connaitre le cookie de session de l'admin, le récupérer et se faire passer pour un admin.
Mais bon... Penses-tu que des pirates seraient intéressés par le fait de se connecter à ton jeu en tant qu'admin, sachant que l'interception du trafic réseau est plus du ressort de la police, de la NSA et de la mafia que du kéké qui veut gagner des ressources sur l'île du coeur?
(PS: une requête HTTP est simplement des données [HEADER] envoyées par un client [NAVIGATEUR] vers un serveur, qui lui répond alors [réponse HTTP] des headers [obligatoires, avec entre autres le status de la réponse, ie 200,304,403... et les cookies] et un éventuel body [facultatif, c'est le contenu HTML, JSON, XML, PNG ou autre représentant les données de la ressource demandée]).
C'est la raison pour laquelle le long-polling sert simplement à ne lancer qu'une requête réseau, à "squatter" la RAM du serveur qui va roupiller (sleep) jusqu'à ce qu'un truc se passe avant de répondre les infos demandées. Cela évite de faire des requêtes en boucles traitées le plus vite possible par le serveur.
Les données HTTP ou websockets sont tout aussi interceptables: l'utilisation de l'un ne requiert pas plus et pas moins SSL que l'autre. Pour des données de jeu amateur sans visée commerciale ni professionnelle, osef: ce n'est pas la priorité.
SSL ne sert qu'à lire le traffic entre un client et ton serveur. Si tu as un panneau d'admin codé en javascript qui envoie une requête avec le mot de passe de la BDD (ou autre), oui, on pourra te pourrir ta base (mais si t'as codé comme ça, t'as vraiment foiré ^^ ). Sinon, non, ta BDD sera sauve. Le seul éventuel risque résiderait dans l'interception du trafic entre un admin loggé sur le jeu et le serveur du jeu. Là, le pirate qui écoute la communication pourrait alors connaitre le cookie de session de l'admin, le récupérer et se faire passer pour un admin.
Mais bon... Penses-tu que des pirates seraient intéressés par le fait de se connecter à ton jeu en tant qu'admin, sachant que l'interception du trafic réseau est plus du ressort de la police, de la NSA et de la mafia que du kéké qui veut gagner des ressources sur l'île du coeur?
(PS: une requête HTTP est simplement des données [HEADER] envoyées par un client [NAVIGATEUR] vers un serveur, qui lui répond alors [réponse HTTP] des headers [obligatoires, avec entre autres le status de la réponse, ie 200,304,403... et les cookies] et un éventuel body [facultatif, c'est le contenu HTML, JSON, XML, PNG ou autre représentant les données de la ressource demandée]).