et bin voilà :D ! Ne sommes nous pas tous de grands enfants ?
thanks
Version imprimable
et bin voilà :D ! Ne sommes nous pas tous de grands enfants ?
thanks
Je m'étonne que personne n'ai mentionné "Pulpcore" pour la conception d'applets.
Bonne chance à toi
Pour revenir à ton jeu d'echecs, si tu veux le faire en java, je conseillerais une API 3D Java comme jogl ou lwjgl.
Pour l'acces à la base de données, ca devient plus compliqué. Methode bourrin :
Taper dans la BDD directement (en passant par un driver jdbc) : ca marche bien mais tu dois embarquer dans ton applet login/mot de passe sur ta base. Bref, niveau sécurité, c'est affreux.
Le mieux, c'est de passer par un webservice. L'idée, c'est de faire tourner un programme (par exemple une servlet) sur le serveur qui va faire le pont entre ton applet et la base de données. Comme ca, elle seule a besoin de connaitre login/mot de passe de la base de données (mais comme elle tourne sur le serveur, c'est pas grave).
Pour rappel, une applet java (ou une appli) doit etre telechargée sur le poste client pour s'executer. Et c'est tres simple à decompiler (donc à voir le code source). Donc embarquer des infos critiques (genre login/mot de passe de la BDD), c'est pas une bonne idée :aie:
C'est là tout le volet de la sécurité qui rentre en ligne de compte. Chiffrer et sécuriser suffisamment son projet pour que ça ne soit pas rentable pour l'attaquant de le faire. Java possède toutes les apis nécessaire pour protéger efficacement son code et ses accès. On peut aller très loin : SSL, authentification forte, etc ... même dans une applet.
Salut, et ça coute cher ce type ce webservice ? Je suis encore étudiant et jai pas moulte tune ;) Je compte vraiment mettre le PAQUET niveau sécurité car je vais tenter de développer un site pro pour, pourquoi pas, rivaliser à moyen terme avec d'autre sites gratuit et gagner de l'argent avec les pubs.
Oui je ne compte pas bruler l'étape de la sécurisation, elle est primordiale ;)
Ah autre chose, dans un applet java est-ce que je peux mettre en place des champs de formulaire de toutes sortes (dont input image pour lavatar de lutilisateur) ? en fait je souhaite 100% du contenu dynamique du site dans l'applet, no php at all
oui oui on a des JTextField, JTextArea etc., par contre ça ne fera pas le "submit" (requête POST sur une url donnée) tout seul, ce sera à toi de le faire en utilisant, par exemple, la lib Apache HTTP Client.
"No php at all" c'est un autre problème, il faudra quand même du code sur le serveur pour traiter les post, et ça, ça peut se faire soit en php ou asp, soit en java (mais il faudra quand même une couche serveur, ça on ne peut pas s'en passer)
;)
Ca coute le temps de le programmer plus la location d'un serveur.
La location d'un serveur de base chez ovh c'est 15€/mois pour 2G de ram et 100Mbits de bande passante.
Maintenant si tu fais ton webservice en php, tu peux te contenter d'un serveur mutualisé bien moins cher.
Non, c'est à toi de le faire et de choisir la techno adaptée. Si tu as ton propre serveur, cela ne te coutera rien et tu pourras choisir la techno que tu veux. Sinon, il faudra choisir un autre systeme.
Cela dit, quand je parlais de webservice, je parlais au sens tres général. Dans le cas de ton appli d'echecs, on peut imaginer qu'il y aura tres peu d'echanges entre le client et le serveur (sans parler des phases de transitions - login et autre - le serveur ne sera que tres peu solicité, par exemple pour l'informer que le joueur à bougé. Bref, n'importe quel techno, aussi peu performante qu'elle soit pourra aller...
Par conséquent, on pourrait imaginer une page, par exemple php ou autre, qui sera appelée pour servir de webservice. Et avec ce genre de techno, tu trouveras sans probleme des serveurs gratuits (par exemple free)... Mais bon, cette solution n'est qu'un exemple, d'autres plus compétents en webservices pourront peut etre t'indiquer des technos gratuites plus efficaces...
Une petite remarque aussi concernant les applets. Elles sont tres mal referencées (comme le flash d'ailleurs) donc il est important de les encapsuler dans un site pas trop mal foutu si tu veux avoir une chance d'apparaitre dans les moteurs de recherche...
C'est très intéressant ce que tu me dits hwoarang concernant le référencement. Pour moi il est aussi primordial que la sécurité.
Donc tout ce qui est partie dynamique : problèmes échiquéens, profils d'utilisateurs, parties, seek graph (les points représentant les joueurs cherchant des adversaires), formulaires d'inscription. Serait dans l'applet et le reste, contenu autre + forum en php avec les balises <html> générées dynamiquement pour le référencement. Il va me falloir très bien penser hergonomiquement et struturellement le site avant de me lancer tete baissée dans le code, sinon je mexpose à perdre du temps.
Salut Pill_S, j'ai bien avancé dans le tuto de prise en main de java, bon la poo cest pas nouveau pour moi étant donné que jen ai déjà fait en AS.
Tu conseilles donc le plugin (bibliothèque ?) flex pour les trucs de graphisme poussés ? Parce que justement je compte y aller fort avec un échiquier dans lanimation dintro qui se crée rapidement case par case avec des tween en vitesse non uniforme pour un bel effet + alpha qui monte de 0 à 100. Et je souhaite aussi un taux de rafraichissement de 40 images secondes pour une fluidité optimale, alors flex c'est le top ou y a-t'il mieux ?
Pour les anims, je crois que le mieux c'est encore du bon vieux flash à l'ancienne (avec la timebar etc.)
bon, je ne suis pas graphiste et je fais juste un peu de flex pour le boulot, dans des applications financières où les animations sont vraiment très loin d'être la priorité (on se limite souvent à quelques fondus de transitions entre les écrans et ça, ça se fait rapidement avec par exemple avec la classe Fade).
Pour les trucs très poussés, il va falloir se tourner sur les forums adaptés ;)
Tu trouveras facilement bcp d'animations qui claquent vraiment, par exemple, sur flashscene.org
;)
encore une fois je reste sur mon idée de applet a cause de la 3d ;)
c'est vraiment un rêve de proposer un produit différent et original sur la toile
Sinon jai bien avancé dans le tuto et le java ça ressemble énormément à l'actionscipt 2 au niveau de la syntaxe, cool :ccool: j'avais peur que ça soit aussi bas niveau que le C (proche language machine).
Je vous tient au jus pour mon projet, et encore merci à tous pour vos réponses. Si ce projet voit le jour ceux qui mont répondu gentiement auront tous droit à un statut vip sur le site (accès a tous les pbs échiquéens tactiques et stratégiques dispos, et à toutes les vidéos pédagogique)
Edit: jai réctifié mon erreur dans mon post précédent : "prise en main de java" au lieu de "prise en main de flash"
Java est POO, toutes les histoires de gestion mémoire, etc, (en général) ce n'est pas son affaire (il y a le Garbage Collector pour faire le travail). Après la difficulté de Java n'est pas la syntaxe mais de bien maîtriser le concept POO déjà et ensuite de s'y retrouver dans la gestion des multiples API surtout lorsque comme dans l'exemple plusieurs concepts sont en jeux (serveur web, sécurité, ...)
Et petit avis supplémentaire, ne te lance pas dans tout les concepts proposés précédemment en même temps, vas y par étape. Au départ, de maximiser le côté conception pour avoir quelque chose de facile à maintenir. Ensuite, le côté BDD puis plus tard peut être, le côté Web Service à la place. Et encore plus tard, le volet sécurité.
Oui je suis d'accord qu'il ne faut pas tout faire à la fois.
Et également tous ces composants/plugins ça fait un peu peur mais d'un autre côté je me sens pas du tout de réinventer la roue ;)
Au vu de cette video à 1:18 [ame="http://www.youtube.com/watch?v=vVCen2vIXgc"]Fritz12 at ChessCentral - Play on this 3D Chess Board - YouTube[/ame]
Vous pensez que je peux espérer avec java avoir un rendu 3D aussi beau ou est-ce que je me fait de belles illusions ? Là ça ma lair quand même d'être 600 polygones pour les grosses pieces :aie:
Mais ce qui me rassure cest quon ne bouge qu'une piece à la fois (sauf 2 pour le roque) alors une les coordonnées (x,y,z) de types décimale donc qui prennent 3 * 4 octets = 12 octets * 600 * 4/3 40 fois par seconde soit 375 Ko par seconde, et si 10000 joueurs jouent en même temps (c'est bon d'être mégalo :D) mon serveur devrait être trop limité pour ça non ? si je prends la formule serveur java à 15 euros par mois
C'est pas au serveur de gérer l'animation, tout ce qui passera entre le serveur et le client ce sont les coup joués + le temps.
Pour un projet dans cet esprit, j'avais fait un importateur de fichier obj (format commun pour des images 3D). Comme ca, je dessinais avec blender (si tu connais pas, c'est un outil gratuit qui permet de faire de la 3D), j'exportais en fichier obj et j'importais dans java le fichier en question. Ca permettait d'avoir un vrai outil de dessin et de changer facilement le graphisme. Si tu pars sur ce genre de fonctionnement, l'avantage, c'est que tu peux changer la qualité et le design de tes pieces pour l'adapter à la puissance de la machine cible type.
Alors, la, il y a l'air d'avoir un soucis de compréhension de l'applet.
Quand on execute une applet sur un explorateur, elle est téléchargée sur le poste client et s'execute en local. Par conséquent, quel que soit le détail des pieces, il n'y a pas de différence en terme de communication avec le serveur.
Grosso modo, voila le fonctionnement que tu vas avoir (on imagine 2 utilisateurs qui sont en train de jouer) :
1 - Sur son ecran, un utilisateur bouge une piece.
2 - L'applet genere une communication pour dire que l'utilisateur veut bouger le pion de la case 1;2 sur la case 1;4
3 - Le serveur, eventuellement, verifie que la case en question contient bien un pion et valide ou non le deplacement (l'interet de cette étape est d'éviter la triche, par exemple en décompilant l'applet et en faisant des mouvements impossibles)
4 - Si le mouvement est OK, le serveur notifie l'autre joueur.
5 - L'applet de joueur 2 fait l'animation (la encore en local).
Puis ca continue
Dans tous les cas, la communication avec le serveur doit etre la plus courte possible si tu veux etre efficace.
Et comme dans tout developpement web, les données doivent etre verifiées niveau client et niveau serveur (c'est ce que j'ai mis dans l'etape 3). La verification niveau client permet de ne pas faire de demande au serveur qu'on sait d'avance impossible. Et la verification niveau serveur permet d'eviter la triche.
Je reviens aussi sur la necessité du serveur java. Il faut bien comprendre que pour faire fonctionner une applet, tu n'as pas besoin d'un serveur ou tourne java. C'est le client qui telechargera l'applet et qui l'executera sur son poste (lui, par contre, aura besoin de java). Dans ton cas, franchement, le serveur java me parait inutile...
Je rajoute: c'est bien joli cette interface en 3D, mais c'est pas très ergonomique. Pour avoir été joueur d'échec en ligne, comme beaucoup, je préfère de loin un échiquier plat où je peux établir mes stratégie sans essayer de me redemander à chaque fois "c'est quoi le truc au trois quart caché par la tour encore?"