à la Une

Projet In The Dark #4

itd_4_1

Ça avance!

J’ai travaillé quelques dizaines d’heures, et je suis plutôt satisfait du résultat. Je commence à sentir que je développe bien un jeu et pas une démo ou un prototype.

Je ne pensais pas avoir autant de fun à travailler dans Unity. Les résultats se font sentir extrêmement rapidement, et je suis agréablement surpris de la liberté que j’ai, comparée à celle que j’avais quand je travaillais à partir de rien. Évidemment, si je fais tout moi-même depuis le début, j’ai le contrôle total, mais je dois justement tout faire moi-même. Et si je veux arriver à mes fins, tout faire moi-même veut dire développer un moteur graphique, une gestion de la physique en 2D, un système d’animation, un système de sauvegardes, une gestion de l’audio, des contrôles…Toutes des choses qui ont été faites maintes fois, et mieux que tout ce que j’aurais pu faire, par des gens beaucoup plus expérimentés que moi.

Avec Unity, toutes ces choses ont déjà été faites, à un certain degré. Je peux donc véritablement me concentrer sur la chose qui m’intéresse : le jeu en lui-même. Je n’ai plus l’énorme contrainte de devoir développer toute la machinerie en arrière.

En plus, le principal outil de travail de Unity est le langage de programmation C#. Ça me fait donc un petit bonus d’expérience en langages autres que le C++ que j’utilise depuis à peu près 5 ans.

(oh boy on dirait vraiment que j’fais de la pub pour Unity mais ç’en est pas ok tout le monde? j’aurais pu prendre un autre moteur de jeu et j’aurais probablement dit des trucs semblables)

C’est pas mal ça.
Si ça vous intéresse, j’ai écrit en annexe un sommaire de ce que j’ai fait. Je ne l’ai pas inclu dans l’article principal car c’est un peu long et pas franchement agréable à lire. Ça ressemble plus à des patch notes qu’à d’autres choses, et je tiens à ce que ces mises à jours ne portent pas seulement sur qu’est-ce que j’ai fait, mais aussi (et surtout) sur le processus de développement derrière ce que je fais.

Over.

ANNEXE

Voici un sommaire de ce que j’ai fait, ce que j’ai ajouté  et ce qu’il reste à faire.

Éléments de base du jeu (présents dans la démo) développés :

  • Déplacement et collisions
  • Lumière du joueur
  • Système de magie (barre de magie, lumières, murs magiques)

Éléments de base du jeu développés ET modifiés :

  • Checkpoints, trésors et fin de niveau : Le joueur n’est plus obligé de ramasser tous les trésors, il doit seulement en trouver un certain nombre, puis traverser la porte de la fin du niveau. De plus, les trésors sont à présent dissociés des checkpoints.
  • Ennemis : Le « fantôme » de la démo apparaît maintenant seulement dans le monde magique.
  • Items : Ils ne s’activent plus au contact, mais sont plutôt gardés en réserve jusqu’à activation (à la Mario Kart).

Éléments de base du jeu absents présentement :

  • Timer global du niveau (il ne sera probablement pas dans la version finale, après réflexion)
  • Apparition progressive des fantômes
  • « Menu »
  • « Portails » qui mènent d’une partie d’un niveau à une autre.

Et finalement,

Les ajouts qui ont été fait par rapport à la version de base, ainsi que les ajouts que je prévois faire :

  • FAIT : Nouveau type d’ennemi, qui appartient au monde normal et qui possède une intelligence artificielle plus développée que celle du fantôme.
  • FAIT : Plusieurs lumières différentes sont présentes dans les niveaux, versus la lumière unique du joueur dans la démo.
  • FAIT : Portes qui mènent à plusieurs niveaux à partir d’un seul niveau (hub world)
  • FAIT : Ajout d’une minimap.
  • À FAIRE : Au moins un autre type d’ennemi (que j’ai déjà en tête).
  • À FAIRE : Au moins un autre type d’item (que j’ai déjà en tête).
  • À FAIRE : Musique, ambiance sonore.
  • À FAIRE : Système de sauvegardes.
  • À FAIRE : Plein d’autres choses

 

 

 

 

Publicités

ITD, Unity et Game Design

Bonjour à tous!

Ça fait un petit moment que je n’ai pas donné de nouvelles. Mais ça ne veut pas dire que je n’ai rien fait !  Voici ce sur quoi j’ai travaillé.

Le code du projet In The Dark

Après avoir publié mon dernier post, j’ai passé une bonne semaine à lire des choses sur la programmation de jeux et les design patternspour ensuite passer une autre semaine à écrire le code du jeu sur papier.

 

La transition vers Unity

Après avoir écrit quelques pages de code sur papier, j’ai commencé à le retranscrire à l’ordinateur pour me rendre compte (heureusement assez rapidement) que

  1. Je suis un programmeur beaucoup moins bon que je ne le pensais
  2. Même si les trucs auxquels j’avais pensé avaient fonctionné, je n’aurais pas obtenu la qualité que je voulais à la fin sans passer beaucoup trop de temps à mon goût sur le développement.

Ces réflexions m’ont donc mené à la conclusion suivante : le meilleur moyen de faire ce que je veux, c’est d’utiliser un moteur de jeu. Et Unity s’est présenté tout seul : 2D et 3D, gestion de lumières, physique, etc… Mais c’est aussi un moteur assez populaire dans l’industrie, donc ça me fait de la pratique.

(By the way je vais probablement faire un article à propos de mon point de vue sur les façons de développer un jeu bientôt)

Voici d’ailleurs un aperçu après quelques heures.

itd_unity_1

Je vais reprendre les posts du développement du projet sous peu, vous aurez donc des nouvelles plus détaillées que de simples captures d’écrans.

Le game design

Finalement, j’ai aussi travaillé sur un ou deux articles à propos du game design. Je ne sais pas exactement quand ils seront prêts à paraître.

À venir

Le plan pour les prochaines semaines :

1) Travailler sur Unity et donner des nouvelles du développement;

2) Travailler sur mes articles sur le game design et la façon de faire des jeux;

3) Ne pas échouer mes cours à l’université (les examens intra sont dans une semaine)

Charles out. 10-4.

 

 

 

 

 

 

Projet In The Dark – #3

‘CTRL+A’
‘Delete’

On repart de zéro.

Pourquoi?!

Le code que j’ai écrit est horrible. C’est simple de même.

Après 35 heures de travail, j’ai commencé à rencontrer des complications : d’abord un manque de perfomance (à première vue étonnant considérant que c’est un jeu en 2D qui pourrait tourner sur une patate), mais surtout des problèmes similaires à ceux que j’avais rencontré quand j’ai fait la démo. J’ai du me rendre à l’évidence : j’avais réécrit la démo, seulement en un brin plus organisée. Mais le code lui-même est probablement pire que celui que j’ai fait pendant la relâche (ce qui explique le manque de perfomance).

Pour faire simple, disons qu’au lieu de coder, je veux faire un mur de briques.Avec la démo, j’ai simplement entassé quelques briques ensemble. Ça fonctionnait, le mur n’était pas vraiment solide mais il l’était assez pour remplir ses fonctions de mur. Avec le vrai projet, je me suis dit que ça serait une bonne idée de rajouter du mortier pour que le tout reste en place. J’allais avoir beaucoup plus de briques après tout, était donné la taille du projet.J’ai donc trouvé un peu de mortier, et j’ai commencé à construire mon mur. Dans ma tête, je faisais un mur comme ça :

itd3-1.png

Mais je me suis rendu compte que je construisais plutôt un truc comme ça:

itd3-2.png

 

Voilà. Sans trop entrer dans les détails, mes briques étaient difformes, pas vraiment organisées, et (je sais, ça parait pas trop sur l’image) mon mortier était mou.

J’avais le choix: soit continuer à bâtir par dessus mon tas de code immonde et au final de livrer un produit moyen, soit essayer de prendre toutes les briques une à une et de les remodeler puis de les replacer comme je pouvais dans le mortier, soit de recommencer un mur au complet. J’ai choisi la dernière option, mais cette fois, je vais avoir un plan détaillé. Pour vous donner une idée, le plan que j’avais au départ ressemblait à ceci (toujours dans la métaphore du mur de briques) :

itd3-3.png

Pas très utile comme plan si on veut savoir comment fonctionne le mécanisme du pont-levis.

Durant les cinq années pendant  lesquelles j’ai programmé, je n’ai jamais fait de plan détaillé de code – je n’en ai jamais eu besoin. Souvent, quand le programme est assez petit, on saute cette étape et on se débrouille tout de même très bien. Mais pour les plus gros programmes, c’est important de faire un plan. J’étais au courant de cette règle, mais je l’ai ignorée et j’ai surestimé mes capacités à improviser du code.

Pour les prochains jours (et peut-être semaines, je ne sais pas), je travaillerai exclusivement sur le plan du code, jusqu’à ce que je sois satisfait. Je me donne un bon trois semaines pour le faire.

Over.

Projet In The Dark – # 2

30 heures de développement effectuées.

Dans la démo (SDTMAG), après 30h (approx 6 jours)
– Timer
– Barre de magie
– Items
– Déplacement & collisons
– Plusieurs niveaux

cap_6_2_

30h dans In The Dark
– Déplacement & collisions
– Affichage d’images
– Base du système de magie

itd_2_1

Je suis lentement en train d’arriver au niveau d’avancement de la démo de la relâche. Je passe beaucoup plus de temps à coder et ce pour arriver aux mêmes résultats, mais ça en vaut la peine. Quand j’ai arrêté le projet de la démo, j’en étais à un point tel qu’il m’était pratiquement impossible d’ajouter un nouveau type d’ennemi ou d’item ou même d’ajouter un niveau sans faire entre 10 et 100 lignes de code supplémentaires. Je ne pouvais pas non plus changer l’affichage sans changer la moitié du code. Chaque petite modification me prenait un temps fou à effectuer. Bref, c’était le chaos. C’est pour ça que j’ai recommencé à zéro, et pour ça que les résultats se font sentir moins rapidement sur cette version, car je prend le temps de faire du code efficace (enfin, plus que sur la démo).  Cependant, quand je vais avoir atteint le niveau technique de la démo (dans environ 20 ou 30h, je pense), le reste du travail se fera quasi uniquement à l’extérieur du code.

Cela dit, les choses avancent tout de même plus rapidement que ce que j’espérais. Justement, je pensais prendre un peu plus de temps sur l’organisation du code, la structure, etc. mais tout cela s’est codé relativement rapidement, à ma grande suprise.

Les prochaines étapes dans les jours qui vont suivre seront :

  • Coder les effets des items
  • Coder la transition entre les niveaux
  • Coder le système de magie au complet (barre, cooldown, etc)
  • Coder le système de temps du niveau

Après ça (mais c’est pas pour tout de suite) y’aura les menus, les écrans de Game Over, etc…

C’est tout pour cette fois, merci d’avoir lu!

Over.

Le retour et le plan de match

Je n’ai pas vraiment d’idée pour commencer le post donc on va y aller direct.

Je n’ai pas fait de publications cet été pour deux raisons: premièrement parce que j’ai animé dans un camp de jour – c’était trippant, mais j’étais épuisé mentalement quand je revenais chez moi donc je n’avais pas vraiment la force de me concentrer sur quoi que ce soit – et deuxièmement parce que je savais pas quoi publier. J’avais envie d’écrire quelque chose mais je ne voulais pas publier juste pour publier. Pour ce qui est des analyses, elles vont probablement revenir mais plus sporadiquement. Je ne prévois pas accomplir l’objectif des huit analyses que je m’étais donné, et je ne m’en sens pas déçu. Avec le recul, je ne suis pas satisfait de ces analyses, pour toutes sortes de raisons que je pourrais présenter plus tard, cette publication n’étant pas l’endroit pour le faire.

Cette publication est plutôt destinée à vous informer de ce que je compte faire durant les prochains mois – un plan de match, si vous voulez.

Sans plus attendre :

Je rentre à l’université dans 1 semaine et demi (en informatique). Entre temps, je veux recommencer à programmer sérieusement, surtout sur un projet en particulier : refaire le jeu que j’ai fait en sept(9) jours pendant la relâche en mars dernier, mais je veux produire une version complète avec de la musique, un style visuel plus poussé et des niveaux plus grands, plus intéressants et surtout plus nombreux.

Je souhaite publier des mises à jour sur le projet tout au long de son développement (que je vais poursuivre durant l’université) , comme je l’ai fait la dernière fois. Ces mises à jour ne seront pas quotidiennes. Attendez-vous à une communication à peu près hebdomadaire. Je me donne fin décembre comme période limite pour avoir une version publiable du jeu.

J’aimerais aussi commencer une série d’articles sur le game design et la façon dont je vois les choses concernant le sujet. Je ne prévois pas d’horaire précis de publication, cependant.

J’aimerais aussi écrire, d’ici la fin de l’année, au moins un article n’ayant aucun lien avec les jeux vidéos. Je n’ai aucune idée de quoi, mais j’aimerais le faire. En même temps, comme je l’ai dit, je ne veux pas publier pour publier, donc si je n’ai pas d’idée, too bad.

Ah et aussi peut-être faire un retour sur les analyses.

Donc voilà, c’est pas mal ça le plan de match. Faire un jeu – écrire des trucs sur le game design – écrire des trucs sur autre chose, et vous tenir au courant de tout ça.

Merci d’avoir lu jusqu’au bout!

 

Mise au point

Bonjour, tout le monde.

Cette semaine, pas d’analyse. Pour des raisons que j’expliquerai plus bas, je prends une pause d’analyses, et j’en profite pour vous jaser de 2-3 trucs.

Le changement de nom

Certains l’auront peut-être remarqué, le site ne se nomme plus arandomdev.wordpress.com mais lecharlesmurphy.wordpress.com. J’ai décidé de changer, car je ne trouvais pas arandomdev assez.. Professionnel? Je ne suis pas vraiment sûr, mais quelque chose me dérangeais. Je pense que ça faisait trop « je suis simplement un dev parmi tant d’autres MAIS LISEZ CE QUE J’ÉCRIS QUAND MÊME plz ». Je ne suis pas trop sûr de la façon de l’expliquer. Bref, maintenant c’est lecharlesmurphy (le le est là parce que « charlesmurphy » était indisponible).

La pause

Je prends une pause d’analyses pour cette semaine, et très probablement la semaine prochaine. Pourquoi?

  1. Je voulais clarifier certaines choses avant de continuer. Tout d’abord, de mon côté, je ne suis toujours pas certain de mon public cible. De plus, je  voulais répondre à quelques questions concernant les analyses.
  2. Mon ordinateur s’est malencontreusement retrouvé dans un état de coma forcé suite à un système de refroidissement qui ne refroidit plus, et des températures de 100 C sur mon pauvre CPU. Je ne peux donc plus vraiment jouer à quoi que ce soit. Cependant, ça devrait être réparé sous peu.
  3. La pause de la semaine prochaine est expliquée par un phénomène très simple : ma transformation en blob difforme et vide d’énergie immédiatement après la fin de la session. Je ne fournirai essentiellement plus d’effort intellectuel pour les 4 ou 5 prochains jours suivant mon dernier examen.
  4. La pause de cette semaine est justifiée par la fin de session et le fait que j’aie besoin d’étudier un peu plus (entre vous et moi, cette dernière raison est entièrement du bullshit que je me dis pour avoir l’impression que je tiens mes études à coeur – je serai très bien capable d’écrire une analyse quand même)

Les analyses

J’aimerais aussi profiter de l’occasion pour répondre à quelques questions qui m’ont été posées lors des 3 dernières semaines concernant mes analyses.

Pourquoi as-tu joué seulement 2h sur Chivalry et Transistor, alors que tu en as joué 300 sur Skyrim?

Il y a plusieurs parties de réponses. Premièrement, ce qui explique le 300h sur Skyrim est simplement le fait que c’est un jeu auquel j’ai joué bien avant de penser faire des analyses, contrairement aux deux autres, auxquels je n’avais peu ou pas joué avant les 3 dernières semaines.

La courte durée de jeu est due à deux choses :

  1. Je suis aux études, la fin de session approche et je n’ai pas tout le temps du monde. Il m’est impossible de passer 25h par semaine sur un jeu. Cependant, j’ai quand même un peu plus que 2h de temps libre par semaine. Alors pourquoi ne pas en faire plus? Ce qui m’amène au deuxième point.
  2. Je considère que, pour la grande majorité des jeux, un 2h de jeu est amplement suffisant pour avoir une idée solide de la profondeur du jeu. Si ce dernier ne réussit pas à me communiquer cette profondeur en moins de deux heures, je pense que c’est un problème. C’est d’ailleurs le cas pour Chivalry, dans lequel je commençais à peine à saisir les possibilités qui s’offraient à moi après y avoir joué. Je pense qu’un jeu ne devrait pas être intéressant seulement après que le joueur aie passé un certain temps dessus ; il devrait l’être dès le début.
    Parallèlement, je fais aussi cet exercice dans le but de m’améliorer en tant que game designer. Je pense qu’un bon game designer devrait être capable de comprendre et déconstruire les aspects d’un jeu sans avoir à y jouer longtemps*.

Alors pourquoi avoir choisi Skyrim?

Parce que ça fait un méchant bout que je pense à Skyrim. J’avais déjà du matériel de prêt pour une analyse qui attendait simplement d’être traduit de mon cerveau à mon ordinateur. C’était l’analyse la plus facile à faire dans ma tête, et c’était en quelque sorte un test, un premier essai, afin de vérifier si j’allais vraiment aimer la chose.

Et à l’avenir, je ne promets pas de faire uniquement des jeux auxquels je n’ai jamais joué. J’aimerai bien aussi analyser des jeux auxquels je joue depuis longtemps, comme Skyrim. Bref, je veux m’exercer à analyser des jeux que j’ai envie d’analyser, que ce soit mes jeux favoris ou des nouveaux.

Le public cible

Il m’est arrivé plusieurs fois en cours d’écriture de remarquer que je pourrais utiliser des notions poussées du game design et des termes propres à ce domaine. À chaque fois, j’hésitais à le faire, car je ne voulais pas perdre mes lecteurs avec des mots inconnus, ni prendre le temps de les expliquer rapidement et de risquer de les confondre encore plus. J’ai donc décidé de me contenter d’utiliser des termes généraux, comme « mécanique » (qui est quand même poussé, mais assez connu pour que je puisse le prendre) et « aspects ».

Je me rend compte aujourd’hui que j’aurais pu faire des analyses beaucoup plus poussées, beaucoup plus intéressantes si j’avais abordé quelques notions avancées de game design. Le hic, évidemment, c’est que j’aurais probablement perdu la majorité de mes quelques lecteurs.

J’ai donc à décider quel est mon public cible. Les gens qui connaissent beaucoup de choses sur le game design? Les gens qui veulent simplement voir si le jeu est bon ou pas? Les gens à mi-chemin entre les deux? Je vais y penser. Dès que j’ai une réponse claire, je vous en informe.

De plus, suivant ma décision concernant le public cible, il est fort probable que le format des analyses change. Il pourrait ne plus avoir d’analyses à chaque semaine mais plutôt aux deux semaines, par exemple.

Conclusion

Fin. À dans deux semaines pour la prochaine analyse, et peut-être avant pour d’autres choses!

 

*Pour plus d’infos sur cette manière de voir les choses, je vous renvoie ici.

SDTMAG #8 – Final

Bon, eh bien.

C’est fait. Ça ce sera pas vraiment fait en 7 jours (plutôt en 9), mais quand même. J’ai réussi à créer un jeu simple en moins de deux semaines.Je suis plutôt fier de moi.Bon, il n’est pas complètement terminé – il manque des niveaux, il y a sans doute 2 ou 3 bugs à corriger, des choses à ajuster au niveau du gameplay – mais l’important est là. Je considère l’objectif comme accompli.

Si j’ai une chose à retenir de ce projet, c’est ça :

Si tu veux faire quelque chose, commence. Et tout de suite.

Je dois admettre que ça ressemble un peu trop au slogan de Nike à mon goût, mais ça reste ce que je retiens. J’ai trop attendu avant de commencer ce jeu là. J’ai trop hésité, je me suis trop dit « faut que ça soit excellent ».

Et avant, quand je commençais un jeu, je faisait toujours plus que ce qu’il fallait et je finissais par me décourager au bout de 2 semaines, parce que c’était simplement épuisant.

Je suis extrêmement content de m’être botté le cul et d’avoir commencé quelque chose, finalement, même si je ne pensais pas avoir la capacité de faire quelque chose de génial. Et en effet, le jeu est loin de l’être, et le code derrière – oh! vous devriez voir le code! – est probablement le pire code que j’ai écrit durant la dernière année. Mais ce code fonctionne. Et dans ces 9 jours, c’était strictement ça le but.

Pour le plaisir – et aussi pour un soupçon de nostalgie -, voici la première capture d’écran du jeu, prise le samedi 27 février, comparée à la dernière, prise ce soir le dimanche 6 mars.

normal_sc
Le joueur n’était même pas bloqué par les murs.

cap_final

 

Une dernière chose : vous pouvez télécharger la dernière version du jeu ici. Bien qu’elle soit encore inachevée, elle est plus complète que la précédente. Je vais probablement y retoucher un peu durant les semaines à venir, dont restez à l’affût d’un nouveau post.

Merci de m’avoir suivi durant ces 9 jours!

Sur ce, je vous quitte. À un prochain jeu!

a random dev