11-01-2009, 03:18 PM
Quand je parle de temps réel, je parle de chose qui réagirais à la seconde prés (jeu de tir par exemple).
Je ne suis pas sur que l'astuce de facebook fonctionnerait, sans compter qu'il faut prendre en compte la charge d'un tel système
Oui l'AS permet la connexion par socket, et donc peut eventuellement permetre de de faire du temps réel.
Et ce que tu décris Wild-D c'est plus du quasi temps réel que du temps réel.
Enfin bref çà n'était qu'un exemple j'aurrais très bien pu dire "Faire une rotation d'une image sur l'écran" ce qui n'est pas possible avec javascript&HTML or çà l'est avec ActionScript mais je suis pas sur que l'analyse serait identique avec un tel changement de langage!
Enfin bref l'analyse ne dépend pas en théorie du langage, mais il faut bien se rendre compte que défois il faut quand même le fixer avant par exemple à cause de contrainte d'apprentissage, ou encore de moyen financier...
Et donc çà implique de faire une croix sur certaine chose que l'on aurait aimé faire!
Pour moi un bon shéma de conception serait
1)Idée de base: on développe le concept du jeu etc...
2)Revu technique: on vérifie si pour tel ou tel langage les différentes hypothése sont vrai, on cherche ailleurs si c'est pas le cas, ou on fait une croix sur l'idée.
3)On fait l'analyse à proprement parler
4)On code
Evidement en cours de route on peut etre amené à retourner en arrière, on peut même séparé le boulot en plusieurs couche faiblement dépendante et passer à l'étape suivante pour une couche alors que les autre ne sont qu'à l'état d'idée.
Evidement çà demande de faire attention surtout au niveau des dépendance, pour ne pas à avoir à réécrire un code.
Mais bon perso si je devais faire l'analyse UML complète de mon jeu, c'est à dire obtenir un diagramme de classe complet, je crois que j'y serais encore dans 5 ans (et évidement tout serait à revoir à cause de l'évolution technologique).
C'est en partie parce que je vois gros puisque j'ai envie de faire mieux que Ragol qu'on a mis 1 an 1/2 à 2 codeur à dévelloper, et puis rester dans l'analyse continuellement, c'est aussi le meilleur moyen de ne pas avancer à cause du manque de motivation.
Pour tout dire, après avoir étudier l'UML et ses possibilités, j'ai choisis depuis 5 mois de partir sur un modèle beaucoup plus souple, inspiré du schéma d'au dessus.
En gros j'écris toutes mes idées sur papier, en variant les angles d'attaques et les problématiques(çà peut inclure des test) afin d'enrichir et de ne rien oublier ou encore de pas me bloquer dans le futur. Puis là je rédige sur mon wiki le fruit de la réflexion.
A ce moment je formalise çà en différent fichier test d'écrivant le fonctionnement de chaque classe de cette nouvelle partie. Si une classe est dépendante d'une autre je commence d'abord par celle là. si elles sont dépendante l'une l'autre, alors le fichier test sera commun. A ce moment j'ai aussi une idée concrète de la forme des tables affiliés.
Une fois le fichier test créé, j'écris la structure de ma classe, à ce moment je peux éventuellement revoir le fichier test si je découvre quelques choses de plus simple en termes d'utilisation de la classe.
Puis une fois cette structure créé, j'écris le code à l'interieur, revoyant eventuellement le cadre et la forme des tables pour des raisons de rapidité. Un codeur non objet peut facilement réussir à completer ce cadre.
Je documente le tout.
Je debug en faisant tourner mon fichier test, et dés que le fichier test est valide, la classe est terminé et prête à l'emploi par les autres.
Voilà concrétement comment je procéde, et j'ai jamais autant avancé que ces 5 dernier mois. Faut dire qu'avant çà, j'avais déjà une idée concrete de ce que je voulais (c'est une v2 et çà faisait 2 ans que j'y pensais).
Je ne suis pas sur que l'astuce de facebook fonctionnerait, sans compter qu'il faut prendre en compte la charge d'un tel système
Oui l'AS permet la connexion par socket, et donc peut eventuellement permetre de de faire du temps réel.
Et ce que tu décris Wild-D c'est plus du quasi temps réel que du temps réel.
Enfin bref çà n'était qu'un exemple j'aurrais très bien pu dire "Faire une rotation d'une image sur l'écran" ce qui n'est pas possible avec javascript&HTML or çà l'est avec ActionScript mais je suis pas sur que l'analyse serait identique avec un tel changement de langage!
Enfin bref l'analyse ne dépend pas en théorie du langage, mais il faut bien se rendre compte que défois il faut quand même le fixer avant par exemple à cause de contrainte d'apprentissage, ou encore de moyen financier...
Et donc çà implique de faire une croix sur certaine chose que l'on aurait aimé faire!
Pour moi un bon shéma de conception serait
1)Idée de base: on développe le concept du jeu etc...
2)Revu technique: on vérifie si pour tel ou tel langage les différentes hypothése sont vrai, on cherche ailleurs si c'est pas le cas, ou on fait une croix sur l'idée.
3)On fait l'analyse à proprement parler
4)On code
Evidement en cours de route on peut etre amené à retourner en arrière, on peut même séparé le boulot en plusieurs couche faiblement dépendante et passer à l'étape suivante pour une couche alors que les autre ne sont qu'à l'état d'idée.
Evidement çà demande de faire attention surtout au niveau des dépendance, pour ne pas à avoir à réécrire un code.
Mais bon perso si je devais faire l'analyse UML complète de mon jeu, c'est à dire obtenir un diagramme de classe complet, je crois que j'y serais encore dans 5 ans (et évidement tout serait à revoir à cause de l'évolution technologique).
C'est en partie parce que je vois gros puisque j'ai envie de faire mieux que Ragol qu'on a mis 1 an 1/2 à 2 codeur à dévelloper, et puis rester dans l'analyse continuellement, c'est aussi le meilleur moyen de ne pas avancer à cause du manque de motivation.
Pour tout dire, après avoir étudier l'UML et ses possibilités, j'ai choisis depuis 5 mois de partir sur un modèle beaucoup plus souple, inspiré du schéma d'au dessus.
En gros j'écris toutes mes idées sur papier, en variant les angles d'attaques et les problématiques(çà peut inclure des test) afin d'enrichir et de ne rien oublier ou encore de pas me bloquer dans le futur. Puis là je rédige sur mon wiki le fruit de la réflexion.
A ce moment je formalise çà en différent fichier test d'écrivant le fonctionnement de chaque classe de cette nouvelle partie. Si une classe est dépendante d'une autre je commence d'abord par celle là. si elles sont dépendante l'une l'autre, alors le fichier test sera commun. A ce moment j'ai aussi une idée concrète de la forme des tables affiliés.
Une fois le fichier test créé, j'écris la structure de ma classe, à ce moment je peux éventuellement revoir le fichier test si je découvre quelques choses de plus simple en termes d'utilisation de la classe.
Puis une fois cette structure créé, j'écris le code à l'interieur, revoyant eventuellement le cadre et la forme des tables pour des raisons de rapidité. Un codeur non objet peut facilement réussir à completer ce cadre.
Je documente le tout.
Je debug en faisant tourner mon fichier test, et dés que le fichier test est valide, la classe est terminé et prête à l'emploi par les autres.
Voilà concrétement comment je procéde, et j'ai jamais autant avancé que ces 5 dernier mois. Faut dire qu'avant çà, j'avais déjà une idée concrete de ce que je voulais (c'est une v2 et çà faisait 2 ans que j'y pensais).