à 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

 

 

 

 

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.

Projet In The Dark – #1

Bonjour à tous! Comme promis, voici une mise à jour sur le remake/reboot/re-whatever du SDTMAG, que j’ai intitulé In The Dark.

J’ai une vingtaine d’heures à date, 12-13h sur ce qui se passe en arrière-plan  (structuration du code, logique interne du jeu, etc) et le reste sur le visuel.
Le jeu est capable d’afficher des lumières et de les déplacer, et c’est à peu près tout.

Voici un aperçu :

itd_1_1

La prochaine étape est de coder le chargement des niveaux depuis des fichiers, et d’implémenter le fonctionnement des entités du niveau (autrement dit faire fonctionner les ennemis et les items). Ensuite, ce sera d’attribuer des images aux dites entités. Et après je ne sais pas trop. Une chose à la fois, comme on dit.

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.

Analyse #3 – Chivalry : Medieval Warfare

Jeu analysé : Chivalry : Medieval Warfare

Nombre d’heures jouées : 2

Présentation

Chivalry : Medieval Warfare (Chivalry pour les intimes) est un jeu de combat médiéval à la première personne. Le joueur y incarne un soldat, et se bat contre d’autres joueurs, en équipe ou seul contre tous.

20160508202238_1

Il peut choisir parmi quatre classes : l’archer, très faible mais pouvant attaquer de loin ; le combattant, puissant et rapide dans la mêlée mais possédant peu de protection ; le conquérant, maniant une lance ou une épée longue, mais se déplaçant un peu moins vite que le combattant ; et finalement, le chevalier, classe très lente mais portant une armure lourde, et pouvant infliger d’importants dégâts.

20160508202335_1

Bien que le joueur puisse joueur seul, la plupart des modes de jeux se déroulent dans un contexte d’équipe : le joueur choisit le camp des Agathiens (bleus) ou des Masons (rouges). (L’histoire de ces 2 camps est plutôt floue, et franchement pas très intéressante et/ou bien présentée. Tout comme le jeu, je n’y accorderai ici pas vraiment d’attention particulière). Ces modes de jeux vont de l’accomplissent d’objectifs (ex : tuer une cible X) au match-à-mort d’équipe en passant par le classique « roi de la montagne ». Bref, rien de bien nouveau de ce côté.

Là où Chivalry est digne d’être remarqué, c’est son combat. C’est un système qui se veut plutôt réaliste, et chaque coup est porté comme si le personnage maniait une véritable épée de quelques kilos. Quand le joueur clique pour frapper, son endurance (représentée par une barre au bas de l’écran) diminue, et le coup arrive après un bref délai. Les classes les plus lourdes (comme les chevaliers) se déplacent lentement, et les plus légères rapidement. En plus de sa barre d’endurance, le joueur possède une barre de points de vie, également située au bas de l’écran, et qui diminue quand il reçoit des coups.

Analyse

Design

Les mécaniques de base de Chivalry sont au nombre de deux et sont les suivantes : le déplacement (ou positionnement) et le timing. Peu importe sa classe, le joueur devra faire preuve d’une bonne utilisation des deux pour gagner.

Là où le timing se manifeste, c’est dans les coups. Étant donné que chaque coup demande un certain temps pour être donné, le joueur ne doit pas frapper son adversaire trop tôt ou trop tard. Contrairement à d’autres jeux, où ceci est vite pardonné au joueur, le fait de manquer un coup peut signifier la défaite contre un adversaire le moindrement entraîné. Car si lui n’a pas essayé de parer votre coup et s’est, par exemple, déplacé sur votre flanc au moment où vous brandissiez votre épée, vous êtes vulnérable le temps que votre coup se termine. Et comme les armes font des dégâts importants, un coup au flanc sans armure peut provoquer votre mort, même avec une barre de vie remplie.

20160508202459_1
L’action de parer un coup.

L’autre manifestation du timing est dans les combos. Si le joueur appuie sur la bonne touche d’attaque au bon moment, il peut effectuer un combo, qui infligera des dégâts supplémentaires à l’adversaire.

Le positionnement est aussi un élément crucial du jeu. Il suffit simplement, comme je l’ai mentionné plus tôt, de se déplacer un brin pour ruiner le timing d’un ennemi et l’achever.

Le joueur possède une barre de vie et une barre d’endurance. Ce sont les deux ressources principales qu’il aura à gérer durant la partie. L’endurance descend quand le joueur effectue une action comme porter un coup, parer, feindre, sauter… La vie ne remonte jamais, contrairement à l’endurance, qui se régénère quand le joueur est au repos. Le joueur se pose donc deux questions avant d’entrer dans un combat : « ai-je assez de vie? » et « ai-je assez d’endurance? »(pourrais-je porter assez de coups/effectuer assez d’actions?). Or, étant donné que la vie baisse de manière importante quand le joueur subit des dégâts, une barre de vie remplie à moitié est presque équivalente à une barre de vie presque vide : dans les deux cas, on meurt si l’on reçoit un coup provenant d’autre chose qu’une dague.

Étant donné que la vie diminue très rapidement et brusquement, les combats entre deux joueurs ne durent rarement plus que quelques secondes, le temps de deux ou trois coups. Malgré leur courte durée, ces combats restent quand même plutôt lents à cause du temps que prend chaque coup à être porté.

Le joueur se pose aussi deux autres questions avant d’entrer en combat : « mes coéquipiers sont-ils avec moi? » et « mes ennemis sont-ils trop nombreux? ». En effet, il est beaucoup plus difficile d’éviter les coups de six personnes que ceux d’une.

Points faibles

Cependant, ces deux dernières questions ne sont pas aussi importantes que les deux premières, à propos de la vie et l’endurance. Et c’est une des manifestations des points faibles du jeu.

L’importance de ces questions est moindre relativement aux premières, parce que dans la plupart des cas, le joueur n’a pas besoin de son équipe pour gagner. Étant donné qu’il suffit d’un seul coup bien placé pour éliminer un ennemi, plus le joueur est bon – c’est-à-dire qu’il maîtrise le positionnement et le timing, plus la présence d’alliés devient inutile. Un joueur suffisament compétent peut facilement survivre à un affrontement à deux et même trois contre un. (Cependant, bien sûr que même avec tout le talent du monde, un joueur ne survivra pas à un dix contre un)

Un autre exemple de la défaillance de l’aspect « jeu d’équipe » de Chivalry est la composition des équipes. Ou, plus précisement, son absence. Je n’ai jamais eu à réfléchir sur mon choix de personnage, à me poser la question « de quoi est-ce que mon équipe a besoin présentement ». J’ai toujours pris la classe que je voulais sans considération pour mon équipe, et je ne me le suis jamais fait reprocher, et je n’ai pas remarqué de corrélation entre mon choix individuel et les défaites/victoires de mon équipe.

Le jeu d’équipe est négligé, au profit des capacités individuelles. Et en quoi ceci est une faiblesse du jeu?

J’hésite encore présentement à dire que c’en est une. Cependant, ce qui me pousse à mentionner la chose ici est que sur les sept modes de jeu, un seul ne met pas le joueur dans une équipe. Je n’arrive pas à saisir pourquoi mettre autant d’efforts dans un aspect défaillant du jeu.

Certains me diront peut-être :

Le jeu d’équipe est peut-être défaillant, oui, mais c’est parce que tu as joué à bas niveau! À haut niveau, chez les vétérans, ce n’est plus la même chose.

C’est probablement vrai. À haut niveau, j’imagine que le jeu doit être beaucoup plus complexe, et demande plus de réflexion. Mais ceci, en soit, est un problème. Ce n’est pas un défaut unique à Chivalry, loin de là, mais il est tout de même présent. Le problème peut aussi se formuler de cette façon : un jeu ne devrait pas offrir une expérience grandement différente selon le temps passé sur le jeu.

De plus, à part l’absence de jeu d’équipe à bas niveau, il existe d’autres symptômes de ce problème : les combos. Dans les premières minutes de jeu, en plein dans le tutoriel, le joueur apprend à faire des combos. Mais une fois plongé dans une vraie bataille, ces combos sont vite oubliés. Le joueur se contente de frapper comme il peut, sans se concentrer sur les combos. Et il peut très bien se débrouiller ainsi. Pourquoi utiliserait-il les combos, s’il lui suffit simplement de frapper normalement pour gagner? Les combos demandent un timing excellent et un positionnement adéquat, pour juste un peu plus de dégâts. Les coups normaux ne demandent qu’un timing et un positionnement approximatifs, pour des dégâts certes moindres qu’avec un combo mais tout de même considérables.

À haut niveau, il est probable que le joueur ait à utiliser des combos et à faire preuve de maîtrise du jeu, mais définitivement pas à bas niveau. Et la conséquence de ceci est que le jeu peut sembler pauvre, même ennuyant pour les nouveaux joueurs qui ne verraient sa complexité potentielle. Les combats extrêmement courts empêchent les débutants de constater l’utilité des combos et des techniques avancées, car ces combats se finissent presque tous très rapidement.

Finalement, pour ajouter à l’aspect ennuyant du jeu, la majorité des combats se déroulent sans musique, dans une ambiance sombre et oppressante. Ce type d’atmosphère sied peut-être à d’autres types de jeux, mais définitivement pas à un jeu d’équipe de combat tel que Chivalry.

Points forts

Le principal point fort de Chivalry est la satisfaction qu’il apporte par son immersion. Chaque coup est un véritable coup ; la hache d’armes d’un chevalier n’est pas une tapette à mouches, c’est une foutue hache d’armes qui peut facilement tuer en un coup. Pareil pour les arcs des archers : une flèche dans le coco et c’est fini.

20160508201014_1

Le système de combat de Chivalry est satisfaisant, car les coups, sans être frustrants, ne sont pas faciles à porter mais infligent tellement de dégâts qu’on croirait vraiment manier une véritable arme.

De plus, l’accès du joueur à une grande variété d’armes renforçe le sentiment d’immersion du joueur. Haches, arbalètes, lances, hallebardes, épées courtes, épées longues, dagues…

Le joueur peut aussi crier, sauter et donner des coups de pieds. Ces choses peuvent sembler anodines, mais ce sont des petits détails comme ceux-ci qui font en sorte que le joueur se sent véritablement dans la peau d’un soldat du Moyen âge.

Conclusion

Chivalry est en quelque sorte un simulateur de combat médiéval. Le joueur se sent vraiment comme un combattant grâce à la variété d’armes et d’actions qui lui est offerte, et grâce au réalisme des dites actions. Cependant, cette immersion et sa complexité sont obstruées par le fait que le joueur n’a justement que recours à cette complexité seulement à partir d’un certain niveau. Avant de franchir ce point, le jeu peut sembler ennuyant.

Analyse #2 – Transistor

Jeu : Transistor

Nombre d’heures jouées : 2

Présentation

20160501155151_1.jpg

Transistor est un jeu de rôle et d’action, qui mêle le temps réel au tour par tour. Le joueur y incarne une jeune rebelle du nom de Red, et explore une grande ville futuriste rongée par un mystérieux mal, le Process. Ce dernier est en fait un ensemble d’ennemis divers et variés.

Le jeu est composé d’une successions de phases de combats contre le Process, entrecoupées par des périodes, plus courtes, de déplacement et de repos.

Afin de vaincre le Process, le joueur possède un arsenal varié de fonctions. Ces fonctions ont pour effet, une fois activées, de téléporter le joueur sur une courte distance, d’infliger des dégâts dans une zone précise, ou encore de devenir momentanément invisible. De plus, au fil du jeu, le joueur obtient de nouvelles fonctions différentes.

Il peut aussi combiner ces fonctions pour en modifier le comportement. Prenons par exemple la fonction Switch(). Celle-ci peut changer un ennemi en allié pour une durée limitée. Cependant, si elle est jumelée à une autre fonction, disons Crash(), cette dernière pourra bénéficier d’un bonus du genre « les ennemis touchés par Crash() infligerons 50% moins de dégâts au joueur ».

20160501155220_1.jpg

Le joueur peut seulement avoir accès à quatre  fonctions à la fois (deux fonctions jumelées ne comptent que pour une).

Le combat ne se déroule pas de manière classique : dès le début du combat, le joueur peut arrêter le temps et planifier un nombre limité de mouvements et actions. Une fois le temps « réactivé », ces actions sont exécutées automatiquement, l’une à la suite de l’autre, et après un cours délai, le joueur peut recommencer le processus.

Il peut aussi simplement ne pas toucher au temps du tout et réagir en temps réel aux gestes de ses ennemis.

Analyse

Design

La chose qui démarque ce jeu de ses prédecesseurs, son élément le plus distinctif, c’est le système de  combat. Et c’est pour cette raison que je ne m’attarderai que peu sur les autres facettes du jeu.

Contrairement aux autres jeux de rôles « classiques », ce système est flexible et permissif. Vous ne vous déplacez pas de case en case, et vous n’avez pas une seule action à effectuer par tour. Vous gérez votre temps comme vous l’entendez. Vous allez précisément où vous voulez, au pixel près. Vous pouvez choisir de prendre votre tour entier à seulement vous déplacer sur une longue distance, ou encore d’alterner entre les coups et les esquives.

20160502114352_1
La phase temps réel
20160502114413_1
La phase arrêt du temps

De plus, comme je l’ai mentionné plus tôt, le joueur n’est pas tout le temps dans cette phase d’arrêt du temps.Il alterne entre cette dernière et le déplacement en temps réel, où il est plus vulnérable, car ses attaques ne s’effectuent pas de façon instantanée.

 

Dans la phase de planification, deux principaux choix s’offrent au joueur : jouer de manière prudente en s’assurant d’être en sécurité pour la période de temps réel, ou risquer d’y être vulnérable pour faire plus de dégâts/se repositionner de façon plus avantageuse.

Points faibles

Le principal point faible de Transistor se situe dans son accessibilité. Le combat se base sur le système classique des jeux de rôles qui n’est déjà pas simple, et rajoute une couche de complexité avec la mécanique d’arrêt du temps.De plus, les fonctions et leurs utilités ne sont pas toujours évidentes. Le joueur peut se retrouver un peu perdu devant l’étendue des possibilités de fonctions et de combinaisons qui s’offrent à lui, et risque de manquer un certain degré de la complexité du jeu.

Par exemple, toutes les fonctions possèdent un coût d’utilisation Turn(), qui indique précisement la quantité de points d’actions requise afin de l’utiliser pendant une phase d’arrêt du temps. Ceci permet de planifier avec exactitude les déplacements et les gestes du personnage. Cependant, je ne me suis que rarement retrouvé à étudier ces coûts d’utilisations. Je ne me contentais que d’utiliser ces fonctions sans me préoccuper de ce coût, et je réussissais quand même à finir le niveau.

Cependant, plus tard, j’ai porté attention à ce coût et à une variété d’autres statistiques sur ces fonctions, et j’ai commencé à prendre plus de plaisir au combat, car j’avais l’impression d’avoir plus de contrôle.

Le problème ici est que Transistor n’effectue pas un très bon travail pour expliquer sa complexité au joueur. Le jeu semble d’abord complexe – à cause de son système de combat pas exactement tour-par-tour et pas exactement action non plus -, puis simple quand on se rend compte qu’on a pas vraiment besoin de porter attention aux statistiques des fonctions pour gagner, puis complexe encore quand on s’intéresse aux dites statistiques.

Points forts

Le point fort principal de Transistor est son combat, grâce à l’immersion qu’il apporte. Il est à la base un combat typique de jeu de rôle avec tous ses avantages, dans lequel il faut user de stratégie pour vaincre l’ennemi. C’est un type de combat qui a déjà fait ses preuves – et que j’analyserai probablement plus tard.

La phase principale du combat de Transistor est celle de l’arrêt du temps. En son coeur, cette phase est une période dédiée à la planification et à la tactique, la stratégie. Et classiquement ce genre de période se ressent comme quelque de lent.

Il faut aussi noter que le joueur n’est pas contraint par des limites qualitatives (ex : se déplacer seulement dans quatre directions)  mais plutôt par des limites quantitatives (ex : se déplacer un maximum de 10 mètres). Et cette absence de limite « traditionnelle » (qui donne une grande liberté au joueur), combinée avec l’alternance des périodes d’arrêt du temps et de temps réel (ce qui apporte de la tension), fait que durant le combat, le joueur ne se sent pas dans un contexte statique et lent. Le combat semble beaucoup plus nerveux, beaucoup plus réactif,  bref beaucoup plus dynamique qu’un combat traditionnel de jeu de rôle. Et c’est le principal point fort du jeu.

De plus, ce combat offre une grande liberté du côté de la planification, en permettant au joueur de choisir ses options parmi un ensemble de fonctions et de combiner ces dernières. En plus de la liberté, ce système renforçe l’immersion du joueur, car à chaque fonction est attachée un personnage, dont on peut lire quelques informations quand on consulte la fonction.

20160428111016_1.jpg
Les informations sur la fonction Mask()

Il faut aussi mentionner qu’esthétiquement, Transistor est un chef d’oeuvre. La bande sonore est magnifique et, même dans un contexte où la technologie est omniprésente et où on pourrait s’attendre à des tons plus métalliques, l’environnement est coloré et lumineux.

20160428111141_1.jpg

Conclusion

Transistor est un excellent jeu, très bien conçu, qui prend le combat classique du jeu de rôle, et tout en conservant ses avantages, le rend plus dynamique. Malheureusement, la complexité de ce combat, jumelée à une explication plutôt faible de celui-ci, pourra priver certains joueur d’expérimenter pleinement tout le potentiel et le plaisir du jeu, qui reste quand même bon.

Analyse #1 – The Elder Scrolls V : Skyrim

Jeu : The Elder Scrolls V : Skyrim (version vanilla, sans DLC ni mods)

Nombre d’heures jouées : 300

Le premier jeu que j’ai analysé est The Elder Scrolls  V : Skyrim (je l’appellerai dorénavant simplement Skyrim, pour faire court). Cette analyse se divisera en quatre parties : la présentation du jeu, le design, les points faibles et finalement les points forts.

Tout d’abord, la présentation.

Si vous êtes familiers avec Skyrim, cette partie n’est pas essentielle à la compréhension de l’analyse, et vous pouvez sauter jusqu’à la véritable analyse. Je vous invite tout de même à y jeter un œil, question qu’on soit tous sur la même longueur d’onde.

Présentation

Skyrim est un jeu d’aventure, qui mêle action et exploration. Le joueur y incarne l’élu d’une prophétie dans le monde de Tamriel, et possède la liberté de personnaliser son avatar presque entièrement comme il le veut. Le joueur a la possibilité de jouer trois types de personnages : guerrier, voleur ou mage. Le guerrier va se jeter dans la mêlée, le mage va combattre à distance en se servant de sorts, et le voleur va se cacher jusqu’à ce qu’il puisse porter un coup unique et fatal.

final
Un paysage classique de Skyrim
Au cours de son exploration, le joueur pourra ramasser  divers objets tels des pièces d’armures, des livres (qu’il pourra lire pour son plaisir et pour apprendre des sorts), des peaux et des métaux (avec lesquels il pourra créer de l’équipement), et d’autres babioles. Il trouvera ces objets dans des coffres et sur les dépouilles de ses ennemis. D’ailleurs, ceux-ci sont plutôt variés : zombies, géants, mammouths, sorciers, harpies, tigres à dents de sabre, dragons, gobelins, elfes, autres humains, robots (!)… Ils sont tous répartis aux quatre coins du jeu, en passant par les villages, les plaines, les cavernes, les temples et les donjons. De plus, le joueur a accès à toutes les parties du jeu dès le départ.

Le joueur progresse en accomplissant des quêtes. Il possède aussi un niveau, qui augmente au fur et à mesure du jeu. À chaque augmentation, il peut spécialiser son personnage dans une des catégories citées plus haut (guerrier, voleur ou mage). Il est à noter qu’il peut se spécialiser en voleur à un niveau et en mage au suivant. Le jeu n’impose pas de restriction sur cet aspect.

Analyse

Design

Skyrim est composé de trois aspects principaux : l’exploration, la personnalisation et le combat, et tous ces aspects sont, en quelque sorte, imbriqués les uns dans les autres. Par exemple, la personnalisation est une des motivations derrière l’exploration et le combat : en explorant et en combattant, le joueur collectionne des items lui permettant de personnaliser son avatar. Par ailleurs, le joueur peut aussi personnaliser sa manière de combattre : il choisit son style de combat entre mêlée, distant ou furtif. J’expliquerai plus en détails en quoi consistent ces manières de combattre dans la prochaine section.

Le combat

Le combat est simple : le joueur sélectionne une arme, un sort, ou une combinaison des deux (un « item » dans chaque main). Puis, pour frapper ou lancer un sort, il vise dans la direction voulue. Les armes, sauf l’arc, ne touchent qu’à courte distance, le joueur doit donc se rapprocher de ses ennemis et se placer à portée de leurs propres armes ; les sorts, eux, peuvent parcourir de longues distances en ligne droite avant de frapper une cible.La plupart des armes se manient de la même façon à peu de choses près : les haches frappent moins rapidement que les épées mais font plus de dégâts, les dagues inversement, etc. Les sorts, eux, se divisent en deux parties : les zones à effet et les tirs précis. Cependant, dans ces deux zones, le fonctionnement reste – tout comme pour les armes – à peu près le même : certains sorts ralentissent les ennemis, certains font un poil plus de dégâts, etc.

20160425101754_1

Le joueur a également la possibilité de passer inaperçu aux yeux de ses ennemis. Pour ce faire, il doit simplement s’accroupir quand ses ennemis ne le voient pas. Il peut alors se déplacer un peu plus lentement mais il est plus difficile à détecter. À haut niveau, il peut même passer de l’état « détecté » à « invisible » en s’accroupissant derrière un ennemi. Ceci permet au joueur d’éliminer un à un ses ennemis.

De plus, le joueur peut attaquer n’importe quel personnage du jeu. Que ce soit un marchand, un messager, un cocher, un empereur, un garde… Personne n’est à l’abri*.

*sauf les enfants. Mais ça se contourne avec des mods.

La personnalisation

Dans un autre ordre d’idées, le joueur a aussi en tout temps – incluant en combat – accès à son inventaire (il peut aussi sauvegarder n’importe quand, sauf quand un ennemi est à proximité). Cet inventaire contient tout ce qu’il a ramassé lors de ses pérégrinations : armures, potions, livres, etc. Il contient aussi ses sorts. Il peut donc, à tout moment, changer d’équipement et passer de mage à guerrier, en remplaçant un sort « boule de feu » par une épée à deux main et une robe de sorcier par une armure en acier. Le joueur a donc la possibilité de changer rapidement de style de jeu.

D’ailleurs, plus le joueur passe de temps à jouer avec un certain style de jeu (Voleur, par exemple), plus il acquiert de points d’expérience. Après un certain nombre de points, il augmente son niveau, et obtient par ce fait un point de compétence, qu’il peut dépenser comme bon lui semble dans l’un des 18 arbres de compétences qui s’offrent à lui. Ces 18 arbres sont des regroupement de talents, de bonus et d’habiletés, et se regroupent en 3 catégories : Voleur, Mage, et Guerrier. Par exemple, Guerrier contient entre autres les arbres « Forge », « Armure lourde » et « Armes à deux main ». Voleur contient « Vol à la tire », « Discrétion » et « Armure légère », pour n’en nommer que quelques un. Vous comprenez le principe.

20160425101113_1
Quelques arbres de compétences des catégories Voleur et Mage
Un des facteurs clés de ce système de niveau est qu’il ne contraint pas le joueur à se spécialiser dans une seule chose : il lui permet d’être tout ce qu’il veut en même temps (attention : cela ne veut pas dire que c’est une bonne idée de le faire). Le fait est que le joueur peut passer une partie du jeu à jouer en Voleur, et l’autre partie à jouer en Mage sans que le jeu s’y oppose.

L’exploration

Le dernier aspect – et non le moindre – de Skyrim est l’exploration. Ses limites sont simples : si un endroit est visible, il est accessible. Le joueur peut donc se déplacer presque partout, et ce de trois façons : à pied, à cheval, et par le voyage rapide. Cette dernière méthode fonctionne comme suit : une fois un élément trouvé (un village, un château, etc), un marqueur indiquant la position de cet élément apparaît sur la carte du joueur. Le joueur peut alors se téléporter à la position d’un de ces marqueurs. Il peut également acheter les services d’un cocher, qui le transportera à l’une des principales villes, peu importe que le joueur l’aie visitée ou pas.

20160425105119_1

Le monde de Skyrim est extrêmement vaste, et offre des paysages souvent impressionnant, malgré un penchant pour le blanc, le gris et le bleu pâle. La présence de ces paysages est une des choses qui poussent le joueur à explorer. L’autre motivation derrière l’exploration est la personnalisation : la plupart des éléments que le joueur trouve en explorant permettent d’approfondir la personnalisation de son avatar. Les pierres de compétences fournissant un bonus, par exemple, ou simplement la multitude d’armes, d’armures et de livres de sort que le joueur peut trouver.

Points faibles

La principale faiblesse de Skyrim, celle dont découlent la plupart des autres, est la suivante:

Le jeu essaie de faire trop de choses en même temps.

Commençons par l’une des manifestations les plus évidentes de cette faiblesse : le combat. Le premier gros problème avec celui-ci est qu’il manque cruellement de tension. Comme je l’ai mentionné, le joueur a toujours accès à son inventaire, qui contient des armures, des armes, et des potions. Ces dernières se divisent en plusieurs types, mais le plus important et le plus problématique est celui de la potion de vie. Son effet redonne au joueur une partie de ses points de vie, et ce instantanément. Ceci en soit n’est pas un problème : ce genre de potion est présent dans énormément de jeux vidéos sans que ça ne cause de souci. Là ou se situe le pépin, c’est qu’à cause du système d’exploration et d’inventaire du jeu, le joueur est amené à posséder un grand nombre de ces potions. Ceci a pour effet que l’utilisation ou non d’une de ces potions n’est plus une décision importante, c’est simplement un automatisme, car il n’y a presque aucune conséquence à le faire.

20160425102317_1

Dans un combat classique, le plaisir vient en partie de la tension et du danger. Un combat qu’on ne peut pas perdre est aussi désagréable qu’un combat qu’on ne peut pas gagner. Et dans Skyrim, le danger vient de la perte de vie. Mais quand cette perte de vie peut être presque annulée par l’utilisation d’une potion à chaque 8 secondes, le danger disparaît.

Un des moyens utilisés par les joueurs pour contrer ce problème est de régler le niveau de difficulté au plus élevé. De cette manière, les ennemis font beaucoup plus de dégâts, ce qui fait que le joueur peut mourir en seulement deux ou trois coups. Le combat devient alors un peu plus dangereux, car l’efficacité d’une potion est amoindrie de beaucoup : il est nécessaire de consommer beaucoup plus de potions en mode difficile pour survivre pour une durée déterminée, comparé aux autres degrés de difficulté.

On voit donc qu’il existe en quelque sorte une solution au problème de la tension du combat. Mais cette solution est trouvée seulement en jouant au jeu d’une manière précise. Bien que ceci puisse être argumenté (et le sera probablement éventuellement), je ne pense pas que l’on puisse pardonner les problèmes d’un jeu sous prétexte qu’on peut les éviter en jouant d’une manière spécifique.

Ce problème vient du fait, comme je l’ai mentionné plus tôt, que Skyrim essaie de faire beaucoup de choses en même temps et ne le fait pas bien. Pour conserver l’aspect personnalisation et exploration, le joueur a constamment accès à son inventaire même en combat, ce qui cause le problème des potions et de la tension.

Un autre des problèmes de Skyrim est justement lié à la difficulté : c’est une difficulté que j’appelle quantitative. Je m’explique.

Prenons Super Mario World, par exemple : plus le jeu avance, plus il demande au joueur de faire preuve de timing, de précision et de bons réflexes dans ses sauts et son déplacement. C’est une augmentation de difficulté qui se base sur des critères qualitatifs, qui demande un effort de plus au joueur. C’est donc une difficulté qualitative.

Skyrim, quant à lui, incorpore une difficulté quantitative : le jeu ne demande pas tellement plus d’effort du joueur au début ou à la fin, car les seules choses qui augmentent au fil du jeu, ce sont des quantités.Un mort-vivant se combattra de la même façon après une heure de jeu qu’après 200. La seule différence, c’est qu’au lieu de lui infliger 5 dégâts et qu’il perde 5 points sur 10, vous infligez 50 dégâts et il perd 50 points sur 125. Oui, ses points totaux ont augmenté, le rendant plus long à vaincre, mais vous n’avez pas à trouver de nouvelles tactiques de combat, ou à perfectionner votre positionnement ou votre timing. Il suffit simplement de donner quelques coups de plus.

Une difficulté quantitative n’est donc pas réellement une difficulté. C’est plutôt un semblant de système de progression, qui ne fait que montrer un nombre qui grandit. Et ceci est beaucoup moins satisfaisant qu’une difficulté qualitative, qui demande au joueur de réellement s’améliorer.

Un autre des problèmes du combat est sa simplicité. Le combat dans Skyrim est extrêmement simple : il ne demande pas de réflexes développés, de timing serré ou de précision. Il se résume à pointer dans la direction générale de l’ennemi puis de frapper. Quoiqu’il se complexifie légèrement quand on s’équipe d’un bouclier, celui-ci n’est pas obligatoire, encore moins nécessaire au combat.

Je considère ces derniers problèmes comme du design paresseux. C’est encore, je pense, une manifestation du fait que les développeurs ont voulu créer tellement de choses en même temps. J’imagine qu’ils ont du laisser certaines choses de côté pour se concentrer sur d’autres. Cependant, ceci n’est que spéculation.

Alors, en dépit de ceci, comment Skyrim a-t-il pu être un succès aussi retentissant?

Points forts

La force de Skyrim tient en un mot : immersion.

Cette immersion est créée de plusieurs façons.

Premièrement, le joueur possède une liberté sans précédent. Il peut aller où il veut, combattre qui il veut et de la façon dont il le désire, s’habiller comme il veut, ressembler à qui il veut… Comme on peut le voir, c’est l’aspect de la personnalisation qui va contribuer le plus à cette liberté, et qui va de ce fait sauver le jeu en entier.

20160425105315_1

En effet, le joueur peut modifier son personnage comme il le désire, et les possibilités s’offrant à lui sont énormement nombreuses. Il peut choisir d’être un Orc sorcier doté d’une dague et d’une armure lourde, un barbare pyromancien, un assassin qui manie la hache… Et la simplicité du combat permet justement au joueur de changer de style de jeu sans trop de problèmes, car il n’a pas de nouvelles choses à apprendre.

20160425101741_1

Le deuxième facteur qui contribue à cette immersion provient de l’aspect de l’exploration. Le monde de Skyrim est un monde tellement vaste, et il inclut une mythologie extrêmement riche et complexe. Un des facteurs motivants de l’exploration est justement d’apprendre de nouvelles choses à propos de cet univers. Ce n’est pas un monde construit à la va-vite, bien au contraire. C’est un monde travaillé méticuleusement. Il y a tellement de choses à découvrir, et tellement de quêtes à accomplir qu’on peut se perdre des heures et des heures à se promener dans les cavernes, les villes, les forêts, les montagnes…

20160425102505_1
Proche des ruines d’Ustengrav
Finalement, la dernière chose contribuant à l’immersion est l’ambiance. Tout d’abord, Skyrim possède purement et simplement une des plus somptueuses bandes sonores de l’histoire des jeux vidéos. Cette musique est dynamique, et change selon la situation du joueur – combat, promenade, dialogue, etc. Pour accompagner cette musique, Skyrim offre des paysages fabuleux et impressionnants, souvent grandioses, tels une fortresse perchée au somment d’une grande montagne, ou un château sur le bord d’une falaise bordant l’océan, et même une énorme caverne souterraine de la taille de la moitié du continent. Et ce monde est garni de créatures et d’humains, ce qui le rend d’autant plus vivant.

Conclusion

Skyrim n’est pas un mauvais jeu. C’est un jeu qui a simplement voulu faire beaucoup de choses en même temps, et a dû en laisser certaines de côté pour se concentrer sur d’autres. L’immersion est grande grâce à la liberté qu’apporte la personnalisation et la richesse du monde que l’on découvre grâce à l’exploration, mais le combat, dans la plupart des cas, n’est tout simplement pas vraiment amusant. Il n’est pas assez mauvais, cependant, pour venir ternir le plaisir qu’il y a à parcourir durant des heures les contrées de Tamriel.