Bonjour,
il serai bien de pouvoir se connecter a une base de donnée mysql afin de pouvoir stocker des information tels que des score, des clé d’activation et autre…
Serai t-il possible que cela soit ajouter a game develop ? (envoie et reception de données à une bdd MYSQL)
Tu peut le faire déjà.
Tu crée ta bdd et tu transit tes donnée de ton application/jeux à une page web qui envoie à la bdd.
Il y a un tuto sur le wiki.
Ouai mais cela nécésite d’ouvrir une page web et de tous faire en php (cela me gène pas) mais a chaque fois ouvrir une page web pour s’inscrire/ se connecter (par exemple) est rapidement énervant !
Cela serait mieu InGame directement ?!
Ca sert à rien d’installer une base de données MySQL en local.
Imagine que tu fasses de même pour tous tes projets => autant de serveurs MySQL qui tournent pour rien en arrière plan. Imagine maintenant que tous les créateurs fassent de même avec leur projet. Imagine enfin que l’un d’eux utilise le même nom de BDD que le tien pour l’un de ses projets.
Bref, ce sera trop lourd, trop lent et trop source de bugs. Le MySQL, c’est en ligne sur un serveur unique.
Pour une BDD en locale, le plus simple, c’est de créer des fichiers xml qui contiendront tes données de jeu (y compris le profil de tes joueurs en local). Tu peux les crypter pour éviter les hacks.
Tu peux ensuite, “pour le fun”, y ajouter une fonction Mise en Ligne, qui enverra les données importantes vers ton serveur MySQL en ligne, pour les classements, cloud et que sais-je d’autres.
[…]
Moi je trouverais ça bien que les jeux puissent se connecter, envoyer et recevoir des informations d’une base MySQL directement en jeu, sans passer par les fonctionnalités réseaux existantes, ça faciliterais la tâche.
4ian, on peut avoir un avis ?
Actuellement, je pense que trop peu de monde en aurait l’usage pour que je développe et maintienne une telle extension.
[…]
Je pense qu’actuellement le système XML est suffisant, car suffisant pour tout stocker. ( Pour ceux qui ne sont pas familier avec le système, le principe d’un fichier XML est également un arbre. ).
Les fonctionnalités XML intégrées sont très efficaces ( je ne vois pas d’où vient l’argument doubler les performances d’ailleurs 
) pour peu qu’on prenne le soin d’ouvrir et de refermer le fichier en mémoire, et l’extension XML avancé offre un accès à la plupart des fonctionnalités de la bibliothèque XML utilisée par GD lui même pour gérer les fichiers de jeu.
Bref, personnellement je ne passerai pas de temps sur cette extension qui ne sera probablement jamais utilisée dans l’état actuel ( Je reviendrai peut être sur mon point de vue si un jour un énorme jeu developpé avec GD en ressent vraiment le besoin ). Je préfère pour ma part donc passer mon temps à simplifier l’utilisation de XML. Mais rien n’empêche les personnes sachant programmer d’en faire une, quitte à l’intégrer dans GD si elle est réalisée avec grande élégance et performance.
Je suis plutôt d’accord sur l’inutilité d’une base de données pour GameDevelop. En revanche, il serait tout à fait intéressant d’avoir, en plus des fichiers XML, la possibilité de manipuler des fichiers bruts, binaires, tout simplement pour lire et stocker des volumes de données importants (je pense nottament aux niveaux/maps, en XML les grosse maps par exemplent multiplient vite la taille du fichier (et la vaste majorité des données ne sont que des balises).
Par contre en effet, je ne suis pas opposé à la manipulation de texte “brut”, car l’usage est très différent du XML.
Du texte ou du binaire finalement ?
Orion parle de fichiers binaires et 4Ian de textes.
Le binaire m’intéresse à moi aussi.
Au final la manipulation est semblable, on manipule des fichiers binaires d’une façon très proche de celle dont on manipule les fichiers textes.
Ah bon ?
Je n’avais jamais vu ça car ma formation et expérience c’était que le binaire c’est octet par octet, tandis que le texte c’est ligne par ligne, donc très différent.
Ok bein du moment que vous y arrivez c’est le principal hein^^
On peut tout à fait traiter le binaire “ligne par ligne” (en considérant certains octets comme un retour à la ligne) ou les textes caractères par caractères.
Ah bon, ok
Je suis plus habitué à Delphi et le traitement est différent en Delphi.
A plus et bonne continuation