Discussions making.

Dites, ceux qui utilisent le sbs de victor ont il eu une baisse de framerate lors des combats ? Je dis ça parce que sur mon ancien pc le jeu laggais avec plus 3 ennemis dans les combats.....

Tu pourrais faire une démo ?

Oulà, ça prendrai trop de temps à configurer surtout avec les modif' faites dessus. x) Ça ne bug pas chez moi de toute façon.

Pourquoi tu fais un sujet alors ? xD

Parce que je veux savoir si les pc moins puissant n'aurait pas ce lag. x)

Salut à tous, je vous indique que la première partie d'un tutoriel intéressant a été publié sur BilouCorp : http://www.biloucorp.com/creer-son-propre-systeme-de-quetes-partie1-17 Bonne lecture !

Je n'ai pas tout lu, mais pour ce que j'ai vu (tout ce qu'il y a avant la mise en place de la couche dynamique) c'est très bien expliquer et facile à mettre en pratique (grâce à la mise en page), merci de l'avoir posté ici.

Aucune si cela a déjà été poster. Jeu dans le même style que Yume Nikki. [ytube]http://www.youtube.com/watch?v=VJprpAVf0v0[/ytube] Nom : IB Support : Rpg maker 2000 Langue : anglais (mais made in Japan) Lien de téléchargement : http://www.vgperson.com/games/ib.htm

Pas fan de ce genre de jeu.

http://conquerirlemonde.com/blog/2010/02/16/erreur-classique-n%C2%B010-le-plantage-post-proto/ Bonne lecture~~

[quote="RitoJS"]Dites, ceux qui utilisent le sbs de victor ont il eu une baisse de framerate lors des combats ? Je dis ça parce que sur mon ancien pc le jeu laggais avec plus 3 ennemis dans les combats.....[/quote] J'ai un fait similaire avec un autre SBS, je me demande à quoi cela est dû...

Rito > très sympa comme article, qui résume bien ce qui se passe Après je suis pas tout à fait d'accord avec la conclusion. Faire des jeux courts et simple ça a les mêmes risques qu'un jeu long et compliqué. Faut aussi me dire comment vous avez l'impression d'allez vite au début, parce que j'ai l'impression d'y allez en marche arrière dans mon projet . Puis une fois fini recommencer an augmentant "légèrement" la difficulté, ça à aucun intérêt, on va avoir l'impression de refaire la même chose encore et encore. C'est plus lassant que de devoir créer 15 map d'une même zone à la suite . Ce qui démotive un créateur c'est surtout le manque de critique (qui servent à améliorer le projet) et de test (le manque de test vient souvent du manque de temps des joueurs potentiels), parce qu'il se dise que l'histoire plaît pas, que le mapping est raté, et j'en passe ! Tiens, ça ma rappelle un ancien débat

Pas faux sur le manque de critique. ^^ Après pour la sensation d'aller vite. Oui oui, ça m'est déjà arrivé. Quand je me préparais pour la sortie de la première démo de la princesse déchue, j'allais vite ! J'étais vraiment motivé. Depuis, grosse baisse de rythme même quand je travaillais la version 2 j'allais beaucoup moins vite qu'avant. x) Edit: Chaos=> Du coup, je me demande si c'est pas les script qui sont trop gourmand pour Ace. x)

Je ne cache pas que j'ai un très grand nombres de scripts qui reproduisent seulement des trucs basiques... Zeus peut en témoigner, lol. Concernant l'article... Nous avons des raisons différentes et la mienne qui ne fut pas citér est le manque de régularité. Activer ces petits doigts et son cerveau pour maker, n'est pas chose courrante pour moi. L'envie est là mais le corps suis pas, lol. Puis d'un autre côté, ce n'est pas un mal de gagner un peu d'expérience avec un plus petit projet. Il y a tellement de choses que je ne sais pas faire.

Sous vous avez plusieurs scripts qui font la même chose, c'est normal. En programmation, il n'y a pas qu'une seule solution et beaucoup s'amuse à coder une solution à un problème (même si ça a déjà été fait)... Après, outre les algos derrière, les scripts n'ont pas tous la même complexité temporelle. Mais ça n'empêche pas que certains scripts sont codés comme les pieds. Ensuite, pour l'article... Il sort comme solution : "faites des projets plus courts". Je vais ajouter un truc : "Avant de commencer un projet, bossez-le en amont." Vous ne pouvez pas imaginer la puissance du cahier des charges, très souvent mésestimé (même en milieu pro, j'en ai fait l'amère expérience. Et, d'après d'autres retours d'informaticiens, le cahier des charges est souvent mal fait). Il permet de : 1 - de vous fixer sur des objectifs. 2 - d'avoir une ligne directrice QUI NE CHANGERA PAS, peu importe les années. 3 - de mettre d'accord tout le monde. D'ailleurs, un des commentaires le dit bien. Aller, je le quote parce qu'il exprime bien l'idée. [quote]Fou … je suis passé à côté de ces problèmes. Dans notre équipe, le développement va au rythme de chacun. Chaque partie du jeu est fortement distincte des autres partie du jeu. On appelle ça des modules. Cela à plusieurs avantages : - un module du projet est plus court que le projet lui-même … le « momentum » est donc proportionnellement plus grand sur chaque module. La satisfaction du module finie est aussi directement ressenti par les félicitations des joueurs. - Le projet Magdales grossi tout le temps depuis 7 ans. - Lorsqu’un DEV a fini sa partie, il peut en attaquer une autre tout de suite après. - Si un DEV abandonne sa programmation, on n’a plus qu’à finir son travail. Au pire, on abandonne son travail, ce qui n’impacte pas le jeu. Les modules de mon jeu sont visibles ici : http://www.drafts.fr/fiche-projet.php?Id=20 Actuellement 4 modules sont en cours. Par ailleurs, le découpage de la responsabilité intellectuelle avait été discuté dès le début du projet. Lorsqu’un DEV qui l’équipe, il embarque les sources du jeu au moment de son départ. Le nom de domaine, le nom du jeu et la partie physique (serveur, doc, compte bancaire) sont de ma responsabilité personnelle.[/quote] Son groupe travaille par modules et communique souvent. Ça a la même fonction qu'un cahier des charges. Vous définissez les objectifs et lorsqu'un quitte... Pas grave, un autre peut reprendre sa partie ou on peut abandonner cette partie (parce qu'on a déterminé dans le cahier des charges ce qui était important et ce qui l'était moins). Après, ça demande aussi l'utilisation d'outils externe (pack office, mais aussi par exemple svn / ssh / dropbox pour garder des sauvegardes du projet et bosser en coordonnant le tout, des logiciels de suivi de problèmes (ou trackeur de bugs) etc...). Ah oui, le cahier des charges ne sert pas uniquement en travail d'équipe... Mais plus que tout à vous, même quand vous êtes seul...