Il faut que vous le sachiez et pas seulement dans la colle. (le blog de vimes)
Retour au blog <<

La démo du projet de mon stage

Lundi 11 février 2008 à 21 h 02
Je n'en avais pas trop parlé sur ce blog pour diverses raisons - la plus importante étant que je ne savais pas par quel bout m'y prendre - mais j'ai fais un stage de Programmeur Gameplay chez Monte Cristo entre Mai et Décembre 2007. Sur le moment j'ai trouvé ça vraiment très formateur. Avec le recul, je me dis que c'était même plus que ça, c'était une expérience énorme.

Quelques mois plus tard, la démo de Silverfall - Earth Awakening (le jeu sur lequel j'ai bossé) est mise en ligne et j'en profite pour faire le lien ici. D'abord, parce que ça me fait plaisir de soumettre à l'ire de la masse un jeu auquel j'ai participé. Et puis, parce qu'à mon goût le jeu n'a pas bénéficié - pour plein de raisons diverses là aussi - de la couverture marketing qu'il méritait ... un brin de pub ne fait jamais de mal.
Pis j'en profites pour confier mon admiration pour le talent et la tenacité des gens qui ont bosser sur ce jeu avec des moyens quand même limité... j'ai pas vraiment eut l'occasion de le faire à l'époque, et c'est un des trucs que je regrette.

Et pis faites pêter les comz, comme les jeunes disent.
par skaven
Lundi 11 février 2008 à 21 h 12
cool :)
Quels sont les algos/méthodes/... que tu as appris et mis en oeuvre?
Pour quelles problématiques?
par vimes
Lundi 11 février 2008 à 21 h 43
POur la méthode générale, c'était du Agile-programming sans le nom : échéance en jours/semaines, version à livrer rapidement, beaucop d'itération pour raffiner, peu de docs.
J'ai principalement co-designé(en soft hein, pas en game design)/implémenté 5 systèmes de gameplay : le craft, l'enchantement, la démonization, les personnages pré-tirés et le trading en réseau. (j'ai fait plein de truc à côté, genre réorganisation et nouvelle feature de l'UI, mais).
En terme d'algo, ça se traduit pas par des concepts révolutionnaires ou une implémentation particulièrement tordues. Finalement, comme il s'agit d'un stand alone, beaucoup de problématique de base avaient déjà était résolues et le plus important était de fournir des systèmes robustes et flexibles avec de bons points d'entrée pour les designers.
Bon, ya quelques trucs auxquels j'ai du me frotter pour debugger des features et ya eut un truc que j'ai pas réussi à surmonter, mais rien de bien méchant . Et puis , j'ai passé une bonne partie du stage à travailler sur des feature dite ponctuelle (i.e. qui s'effectue sous l'impulsion du joueur et qui n'ont d'effet que sur la frame d'après), donc j'avais pas tout le temps le couteau du framerate sous la gorge.

Pour ce qui est des design patterns, j'ai mangé BEAUCOUP de component, pas mal de manager et de MVC (travesti en autre chose d'ailleurs) et si je ne m'abuse, du factory dans 1 ou 2 cas. Yavait aussi du streaming, mais je sais pas si on peut considérer ça comme un design patterns. Et puis ya tout les designs patterns qu'on applique sans s'en rendre compte parce que c'est ce qui le plus efficace/simple/naturel.

Maintenant, que je relis le message, je sais pas si j'ai répondu à ta question... si c'est le cas, dit le j'essaierais de faire mieux :)
par skaven
Lundi 11 février 2008 à 21 h 49
tout ca en C++?
Du scripting?
Des coroutines/threads lourdes ou légères?
J'aime pas le scrumm.
Comment se faisait le lien entre les assets et ton code de gameplay?
As tu fait des placeholders?
As tu fait un profilage de ton code pour savoir combien de temps cpu ca prends? si oui, combien?
A quoi ta servi le streaming?
Tu veux m'aider sur le codage/debogage du gameplay de mon ptit jeu de course?
par vimes
Lundi 11 février 2008 à 22 h 26
Les systèmes étaient en C++, avec à la charge du programmeur de révéler au système de script maison les fonctionnalités nécessaires aux designer. Je me suis quand même retrouvé à faire des trucs assez complexes en script histoire de filer une version de base hautement modifiable aux designer et parce que pour tester c'était plus facile.
Je comprends pas ta 3ème questions.. mais on avait que deux threads : 1 pour l'éxécution séquentielle et un autre qui prenait des requêtes et qui les éxécutait de manière asynchrone.
Je sais pas ce qu'est scrumm.
Le lien entre assets et code gameplay se faisait par fichier XML(en tout cas pour mes fonctionnalités)... si c'est bien la question que tu poses.
Le profiling état inclus de base, donc on pouvait facilement le rajouter pour les nouvelles fonctions... on le faisaient pas systématiquement, seulement lorsqu'il y avait une chute de framerate trop importante.
Placeholder ? Genre des art assets temporaires ou bien?
Le streaming a servi a générer des textures customisée pour le craft... ça a aussi été utilisé pour loader les ennemis et le terrain.
Le débogage de ton projet m'intéresse bien, par contre, je peut rien te promettre en terme d'assiduité.
Toutes les personnes enregistrées peuvent poster un commentaire dans ce blog.

Commenter

Tags autorisés : [b] [/b], [i] [/i], [u] [/u], [code] [/code], [img]Adresse d'une image[/img], [url=Adresse d'un site web] [/url]
Vous pouvez aligner vos images à droite ou à gauche en modifiant le tag [img] comme ceci : [img right] ou [img left].

Pour vos vidéos/animations flash : [video]Adresse d'une animation[/video], pour préciser la largeur et hauteur : [video width=100 height=200]...[/video]