11-05-2013, 12:06 PM
Faut voir, pour le joueur lambda, car je sais que ce joueur lambda verra immédiatement que son PC ne démarre plus directement sur sa session utilisateur (à cause de la session ASP.NET MA si tu souhaites donner le détail à ton codeur).
Donner le jeu "as it" (plug & play) serait envisageable, sans trop de gène pour l'utilisateur lambda, avec la méthodologie suivante:
- Le jeu est dans un dossier principal ("loupe")
- Un ou plusieurs sous-dossier(s) dans ce dossier principal, avec l'exécutable de jeu (dossier /bin), les ressources média (/images, /son, /textes, etc). Ce qui te permettra des modifications aisées (il te suffit de changer les images dans /images pour que la modification se voit immédiatement dans le jeu)
- L'exécutable est fait dans le langage que tu veux
- Le dossier principal contient un programme ("jouer.exe"), en C/C++ ou autre langage PORTABLE (donc, qui se lance sans devoir installer des trucs), et ce programme vérifie que .NET framework ou tout autre dépendance nécessaire est installée et à jour.
L'utilisateur lambda va ainsi télécharger le fichier zip, et l'extraire (sur son bureau, ou n'importe où). Il obtient ainsi un dossier "Loupe", avec, dedans, "jouer.exe" et des sous-dossiers. En bon utilisateur lambda, il lance "jouer.exe" (qui utilise l'icone du jeu loupe d'ailleurs). Ce soft lui dira alors "pour jouer à Loupe, il faut installer .NET framework. Il doit être téléchargé puis sera installé silencieusement. Voulez-vous continuer" (ou autre texte similaire) si jamais .NEt framework n'est pas présent (ou est d'une version incorrecte). Le joueur lambda va donc dire "bon, ben je clique sur 'Installer .NET puis jouer", ce qui ne va pas changer son expérience de jeu. Si .NEt est déjà en place, "jouer.exe" ne fait que lancer le fichier du jeu qui se trouve dans /bin. Cela ne change pas l'expérience utilisateur. Si le joueur n'est pas "lambda", il pourra refuser d'installer .NET (et ne jouera pas).
Si tu veux porter sur console, il te suffira de porter le contenu des sous-dossiers (écrit dans le langage que tu veux).
Si tu veux faire un système de mise à jour, tu pourras le greffer à jouer.exe, sans aucun dégât sur le jeu en lui-même.
Si tu veux changer des ressources du jeu (images, vidéos, textes), tu pourras le faire sans demander à ton codeur de recompiler ou de ré-empaqueter l'installateur.
Le jeu sera plug & play, facilitant son partage.
Jouer.exe peut te servir de "traqueur" sur l'utilisation faite de ton jeu (jouer.exe peut demander, au premier lancement, d'accepter la licence qui dit que cette acceptation sera transmise au serveur pour que tu puisses compter combien de gens jouent au jeu), tu pourras aussi faire des stats "temps réel" (savoir en temps réel ou presque combien de gens jouent au jeu).
Tu pourras stabiliser le jeu: si jouer.exe tourne en arrière-plan, et que le jeu crash, alors jouer.exe peut le détecter car le processus du jeu lui-même, loupe.exe, n'existera plus, et jouer.exe pourra dire "Envoyer un rapport de plantage et relancer le jeu?"
Tu pourras faire des statistiques-joueurs (afficher, sur ton site, que "Machin a trouvé l'énigne bidule!") et donner ainsi un aspect communautaire.
Merci de ta réponse et des éclaircissements. J'espère que ces pistes que je te donne (après avoir peut-être un peu trop flingué l'installateur, mais quand je suis frustré j'ai du mal à le cacher) pourront te permettre d'améliorer cet aspect du jeu.
(Note: le fait d'utiliser un système de sous-dossiers peut également permettre aux joueurs, potentiellement, de créer des skins, des sons, des traductions ou même de nouvelles énigmes, et les partager sur le site du jeu, cela renforcerait l'aspect communautaire, cela te soulagera d'un travail non négligeable puisque les utilisateurs s'amuseront à le faire, et cela peut te mener à des idées d'énigmes, de skin ou autres, que tu n'aurais jamais eu sinon).
Donner le jeu "as it" (plug & play) serait envisageable, sans trop de gène pour l'utilisateur lambda, avec la méthodologie suivante:
- Le jeu est dans un dossier principal ("loupe")
- Un ou plusieurs sous-dossier(s) dans ce dossier principal, avec l'exécutable de jeu (dossier /bin), les ressources média (/images, /son, /textes, etc). Ce qui te permettra des modifications aisées (il te suffit de changer les images dans /images pour que la modification se voit immédiatement dans le jeu)
- L'exécutable est fait dans le langage que tu veux
- Le dossier principal contient un programme ("jouer.exe"), en C/C++ ou autre langage PORTABLE (donc, qui se lance sans devoir installer des trucs), et ce programme vérifie que .NET framework ou tout autre dépendance nécessaire est installée et à jour.
L'utilisateur lambda va ainsi télécharger le fichier zip, et l'extraire (sur son bureau, ou n'importe où). Il obtient ainsi un dossier "Loupe", avec, dedans, "jouer.exe" et des sous-dossiers. En bon utilisateur lambda, il lance "jouer.exe" (qui utilise l'icone du jeu loupe d'ailleurs). Ce soft lui dira alors "pour jouer à Loupe, il faut installer .NET framework. Il doit être téléchargé puis sera installé silencieusement. Voulez-vous continuer" (ou autre texte similaire) si jamais .NEt framework n'est pas présent (ou est d'une version incorrecte). Le joueur lambda va donc dire "bon, ben je clique sur 'Installer .NET puis jouer", ce qui ne va pas changer son expérience de jeu. Si .NEt est déjà en place, "jouer.exe" ne fait que lancer le fichier du jeu qui se trouve dans /bin. Cela ne change pas l'expérience utilisateur. Si le joueur n'est pas "lambda", il pourra refuser d'installer .NET (et ne jouera pas).
Si tu veux porter sur console, il te suffira de porter le contenu des sous-dossiers (écrit dans le langage que tu veux).
Si tu veux faire un système de mise à jour, tu pourras le greffer à jouer.exe, sans aucun dégât sur le jeu en lui-même.
Si tu veux changer des ressources du jeu (images, vidéos, textes), tu pourras le faire sans demander à ton codeur de recompiler ou de ré-empaqueter l'installateur.
Le jeu sera plug & play, facilitant son partage.
Jouer.exe peut te servir de "traqueur" sur l'utilisation faite de ton jeu (jouer.exe peut demander, au premier lancement, d'accepter la licence qui dit que cette acceptation sera transmise au serveur pour que tu puisses compter combien de gens jouent au jeu), tu pourras aussi faire des stats "temps réel" (savoir en temps réel ou presque combien de gens jouent au jeu).
Tu pourras stabiliser le jeu: si jouer.exe tourne en arrière-plan, et que le jeu crash, alors jouer.exe peut le détecter car le processus du jeu lui-même, loupe.exe, n'existera plus, et jouer.exe pourra dire "Envoyer un rapport de plantage et relancer le jeu?"
Tu pourras faire des statistiques-joueurs (afficher, sur ton site, que "Machin a trouvé l'énigne bidule!") et donner ainsi un aspect communautaire.
Merci de ta réponse et des éclaircissements. J'espère que ces pistes que je te donne (après avoir peut-être un peu trop flingué l'installateur, mais quand je suis frustré j'ai du mal à le cacher) pourront te permettre d'améliorer cet aspect du jeu.
(Note: le fait d'utiliser un système de sous-dossiers peut également permettre aux joueurs, potentiellement, de créer des skins, des sons, des traductions ou même de nouvelles énigmes, et les partager sur le site du jeu, cela renforcerait l'aspect communautaire, cela te soulagera d'un travail non négligeable puisque les utilisateurs s'amuseront à le faire, et cela peut te mener à des idées d'énigmes, de skin ou autres, que tu n'aurais jamais eu sinon).