Little Blog Story

Game-Design & Modding le blog de belzaran.

Articles taggés avec ‘level design’

Post-mortem : cs_bladerunner

Mardi 21 décembre 2010

cs_bladerunner

Petit retour sur cs_bladerunner, première map stratégique que j’ai publiée. C’était un véritable test en tant que level-designer : allais-je arriver à faire une map jolie ET jouable ?

L’origine de cs_bladerunner est assez originale. A l’époque, j’ai eu une idée de mod inspiré de la scène finale de Blade Runner : un joueur, équipé d’un révolver pénètre dans un lieu et doit abattre quatre réplicants, armés de leurs seuls poings. Le gameplay serait orienté sur un jeu de cache-cache : l’environnement est sombre et regorge de cachettes en tout genre pour que les réplicants puissent surprendre le Blade Runner.

N’ayant à l’époque aucune compétence en coding et quasiment aucune en modeling, j’ai abandonné cette idée rapidement (rien que d’en parler, ça me donne envie de la mettre en oeuvre maintenant !). Cependant, l’idée d’une map dans un environnement proche de Blade Runner m’a donné envie de l’exploiter.

Le concept

la map regorge de coins sombres

la map regorge de coins sombres

Le concept de la map est dérivé de mon idée précédente. Comme la map est pour Counter-Strike : Source, le game type Hostage Rescue paraissait le plus adapté. J’ai ainsi développé un pseudo scénario : les réplicants se sont réfugiés dans un immeuble abandonné avec des otages, les blades runners doivent sauver les otages.

La map devait à l’origine être quasiment l’immeuble de la scène de fin de Blade Runner. Après visionnage des scènes, ce n’était pas forcément facile à réaliser. J’ai alors adapté la map afin qu’elle soit plus resserrée mais également plus lumineuse. Comme je voulais que la map se passe essentiellement en intérieur (pour des questions d’optimisation, mon cauchemar), j’ai supprimé l’idée de l’accès au toit.

Niveau ambiance, il fait nuit, il pleut et le fameux dirigeable passe avec ses lumières et ses messages. La map sera donc sombre, avec beaucoup de zones d’ombres. Contrairement à beaucoup de maps CS:S, je veux donner une ambiance forte à ma map. On peut discerner ici mon amour immodéré pour le jeu en solo et les jeux d’ambiance (F.E.A.R. en tête)

Le layout

Le layout est basé sur un immeuble. Il est donc très carré et possède peu d’endroits ouverts. Pour CS:S, ce n’est pas vraiment un problème. Le fait d’utiliser uniquement des salles/couloirs m’a simplifié la tâche, permettant de contrôler les déplacements des joueurs et donc les stratégies possibles.

layout

Lescalier de secours

L'escalier de secours

L’immeuble comporte trois étages. Cela rend le gameplay original. En effet, la map est peu étendue mais possède plusieurs niveaux. Si les niveaux restent très classiques dans leur construction, les accès sont eux très différents. La première partie de l’immeuble est un grand escalier en colimaçon. C’est le point de départ des contre-terroristes (CT). De l’autre côté de la map, un autre escalier, droit, permet d’arriver à tous les niveaux. Dans la cour, un escalier de secours permet d’accéder aux étages. Il a l’avantage d’être mieux protégé (accès par des portes fermées) mais il est moins pratique et plus long à utiliser (situation en retrait dans la map, échelle pour y accéder…). Enfin, un ascenseur abandonné permet de passer du niveau 2 au niveau 3 par une échelle de secours. Bien que dangereux à utiliser, sa situation dans la map est une alternative intéressante pour surprendre l’équipe adverse.

Les otages sont évidemment au niveau 3, en retrait. Ainsi, la map s’apparente à un siège. Les zones de ralliement pour les otages sont situés de part et d’autre de la map, à l’extérieur de l’immeuble. En cela, tout est très logique. Le premier escalier rencontré est évidemment la solution la plus simple, l’escalier suivant étant beaucoup plus loin. Reste la possibilité bien sûr de surprendre l’adversaire en empruntant plusieurs escaliers différents. En cela, la souplesse des changements d’étages (entre 3 et 4 possibilités à chaque fois) apportent un peu de profondeur et de diversité au gameplay.

Malgré l’espace étriqué, il existe des endroits où se tirer dessus à mi-distance. Au dernier étage, un long couloir mène de la cage d’escalier aux chambres où sont retenus les otages. Il n’est pas rare que cet espace soit un lieu d’affrontement (flashbang et fumigènes ont tendance à s’y amonceler). De même il existe une grande salle au niveau 2 où les mitraillages sont légion.

Au final, le gros avantage du layout c’est qu’on se retrouve facilement dans la map. On ne fait que passer de pièces en pièces et d’étages en étages.

Beta-test

Malgré que la version “finale” reste une version beta, il y eut une première version à tester d’abord. Comme je jouais beaucoup à CS:S à l’époque, je l’ai simplement proposé à mon serveur préféré (les OGT) et on a pu la tester ensemble. Les impressions étaient plutôt bonnes mais deux points ont nécessité des recadrages (que seuls des tests contre des humains ont pu mettre en évidence).

Le premier point gênant était que les terroristes devaient forcément commencer une partie dans un couloir donné. Or, ce couloir étant très long, il était possible aux CT de lancer directement une flashbang dedans… Les terroristes se trouvaient aveuglés systématiquement. Cela n’avait pas de conséquence immédiate (le temps que les CT arrivent, tout le monde était parti !), mais c’était très pénible et pénalisant. J’ai donc simplement ajouté une porte pour que les terroristes puissent passer ailleurs. D’où l’importance de toujours donner le choix…

Le deuxième point était que les deux points de ralliement pour les otages pouvaient être campés en même temps par un seul terroriste ! Il était donc déjà arrivé qu’un CT se fasse fragger juste avant que les otages ne rejoignent le point de ralliement… Pour cela, j’ai ajouté un véhicule qui protège le CT et empêche à un terro de guetter les deux points à la fois.

Résultat ?

une des pièces de limmeuble

une des pièces de l'immeuble

Au final, la map possède une vraie ambiance (même si elle sera trop sombre pour certains). On entend la pluie, l’orage, de la vapeur d’eau s’échappe des conduits, les lumières sont dynamiques, les ombres franches… Par contre, on pense relativement peu à Blade Runner. Certains éléments ont été modélisé pour l’occasion, mais ils sont souvent à des endroits peu ou pas du tout visité par les joueurs (notamment dans la rue). Cependant, m’inspirer de Blade Runner m’a permis de développer un concept de map sympa et quelques models sympas (notamment le grand escalier).

De petite taille, la map a l’avantage d’être très facilement mémorisable. Les salles sont assez différentes pour qu’on les reconnaisse et les voies d’accès sont suffisamment claires pour être repérées immédiatement. Son aspect cloisonné gênera fortement les campeurs et plaira aux adeptes du fusil à pompe. Elle est clairement peu ouverte et ne plaira pas à tout le monde. En revanche, elle est très bien optimisée grâce à ça.

Cette map est, je pense, peu adaptée aux gros joueurs de CS:S. Ils lui reprocheront d’être trop petite, trop confinée (pas de tirs de loin, ni de snipe) et pas assez lisible (beaucoup de coins très sombres). C’était un parti pris, donc ça ne me gêne pas, mais il est évident que ce genre de choix n’est pas le meilleur moyen de vendre sa map.

Le plus gros défaut est l’aspect extérieur. En effet, une fois le gameplay finalisé (et c’est le cas ici), j’avais prévu de retravailler  (voire travailler tout court) la rue qui est désespérément vide. Clairement, cela montre que la map n’est pas terminée. Mais comme 95% du jeu se fait ailleurs que dans la rue principale… Je regrette bien sûr de ne pas être allé au bout, mais mes limitations en terme de modeling à l’époque peut l’expliquer.

Et après ?

J’ai été terriblement limité dans cette version par le moteur Source. S’il était adapté au concept d’un immeuble, il était trop vieillissant en terme de lumières dynamiques. J’avais prévu à l’origine toute une série de lumières filtrant à travers le toit. J’ai pu au final en mettre une complètement esseulée, que personne ne remarquait au final.

Même si cela peut paraître prétentieux, j’avais l’impression d’être allé un peu au bout du moteur. J’avais fait une map jolie avec un gameplay qui tenait la route, mais je voulais aller plus loin dans les lumières (et notamment les contrastes). C’est pourquoi j’ai, un mois plus tard, acheté Unreal Tournament III dans le but de mapper dessus. J’ai plusieurs fois eu envie de retourner sur Source (notamment quand je galérais sur l’Unreal Editor). Je regrettais également le gameplay de CS:S, qui est sympa à mapper je trouve. Il n’est pas trop ouvert, pas trop compliqué et possède une dose de stratégie non-nulle. Au final, je n’ai jamais plus pu retourner sur Source à cause de deux points essentiels :

  • obligation de compiler la map pour la tester (et la compilation est longue…)
  • intégration des models customs complètement abracadabrantesque.

Bientôt, un retour sur ma toute première map : gg_techcenter.

LA MAP

Je lâche un peu la génèse pure de Little God Story pour parler un peu de level-design. Ici, il est question d’un puzzle du jeu, de l’idée de départ jusqu’à la conception finale (graphique et technique). Je prends ici l’exemple du puzzle considéré comme le plus réussi par les testeurs. Il a subi également nombre de remaniements et de changements, ce qui à mon avis justifie d’en faire un bilan.

Pour les gros fans de Little God Story qui craignent que je spoile (si ça existe, signalez vous !), évitez de lire car la solution de l’énigme est donnée !

Idée de départ

Je rappelle que Little God Story est un jeu mixant phases de plateformes et énigmes, le tout en utilisant les quatre éléments. Lors des premiers tests, certains ont regretté le manque de phase de plateforme pure. Je me suis donc mis en tête de faire une énigme incorporant un aspect plateforme. Rapidement me vient à l’idée de faire une plateforme tournante sur laquelle le joueur devrait sauter pour passer un fossé. Le fait qu’elle bouge obligerait le joueur à sauter au bon moment. Afin d’ajouter un côté puzzle, une tuyère créerait une flamme au niveau de la plateforme tournante, forçant le joueur à l’éteindre pour passer. On peut donc résumer l’énigme à :

  1. Eteindre la flamme
  2. Activer la roue
  3. Traverser la fosse en sautant sur la plateforme mouvante

Premiers tests

En terme de level-design, je pense tout de suite à mettre deux interrupteurs : un de Terre pour actionner le mouvement de la roue et un d’Eau pour noyer la tuyère et donc l’éteindre. Rapidement, je crée un prototype de ma salle et les problèmes surgissent, certains n’ayant pas été anticipés…

  • si l’Eau monte trop haut, on peut franchir le fossé en nageant
  • on peut sauter sur la tuyère pour traverser le fossé
  • le joueur va avoir tendance à activer les boutons sans se demander à quoi cela peut servir

Première ébauche du puzzle

Première ébauche du puzzle

Pour le premier cas, deux possibilités : faire que le fossé se remplisse puis se vide complètement ou faire que l’eau baisse légèrement de niveau. J’ai choisi la deuxième option car elle permet de changer l’ambiance de la salle. En effet, les reflets de l’eau amènent à la fois du dynamisme par le mouvement des vaguelettes, mais également un aspect beaucoup plus froid que la chaleur des flammes précédentes. Cela permet d’utiliser une même salle pour faire deux ambiances différentes.

Dans le deuxième cas, j’ai simplement modifié un peu le principe. Au départ, il y avait trois tuyères alignées. J’ai réduit le nombre à une (afin d’éviter un passage simple) et j’ai créé un modèle de collision beaucoup plus abrupte que le précédent, empêchant le joueur de prendre appui sur l’objet.

Pour le troisième aspect, j’ai décidé de séparer les deux boutons en les positionnant dans deux salles différentes : l’un en face de la roue (bouton Terre), l’autre dans une salle indépendante (bouton Eau). Les problèmes n’ont pas tardé à arriver : quand on actionne le bouton Eau, on ne peut pas voir ce qui se passe. Certes, on peut le deviner, mais c’est trop léger. J’ai donc ajouté en premier lieu une cinématique lors de l’actionnement de l’interrupteur Eau. Ce genre d’artifice est rarement apprécié des joueurs. En effet, trop de cinématiques cassent l’ambiance et le dynamisme de l’aventure.

Plus loin dans le level-design

Même si mon énigme marchait plutôt pas mal, elle était très légère niveau level-design. Certes, j’avais travaillé les lumières pour un rendu sympa mais très proche des salles précédentes. J’ai alors décidé de reprendre entièrement la conception du lieu pour le rendre plus intéressant.

Il faut savoir qu’en level-design, il y a deux choses à essayer d’éviter le plus possible (selon moi en tout cas) :

  1. Le syndrôme “couloir” : on va dans une salle, on passe une porte, on arrive dans une autre salle, on passe la porte…
  2. Le syndrôme “ouvert” : le monde est tellement ouvert qu’on ne sait pas où aller.

Il est ainsi important dans les jeux linéaires (dont fait partie Little God Story par son essence même) d’éviter l’impression d’être dans un couloir trop balisé. Et dans les jeux ouverts limiter un minimum l’ouverture par des falaises par exemple pour guider le joueur. Dans Little God Story, je suis un peu coincé par le côté puzzle qui nécessite beaucoup de goulets d’étranglement, des endroits où le joueur doit forcément passer. La facilité serait un design en couloir. Un peu plus difficile, en croix (histoire de faire marcher le joueur et de lui donner l’impression d’ouverture).

J’ai opté pour un chemin en croix en essayant au mieux d’y mettre une logique afin de faire accepter au joueur la nécessité de faire ces allers-retours (pas toujours agréables, il faut bien l’avouer). Dans ce cas-là, j’ai déplacé la salle du bouton Eau et ajouté des vitres afin de permettre au joueur de voir directement l’effet de son action. Plus de cinématique ou d’ambiguïté, le joueur voit immédiatement ce qu’il a fait. De plus, les fenêtres en verre donnent des effets de distorsion sympathiques et enrichissent le design de la salle. De même ajouter des tuyaux allant de la “salle de contrôle” à la salle principale amène des éléments de décor bienvenus.

Complexification de l’énigme

La nouvelle salle vitrée de linterrupteur Eau

La nouvelle salle vitrée de l'interrupteur Eau

Cependant, l’énigme reste très bête. Appuyer sur deux boutons, qu’importe l’ordre ! Afin de donner un aspect plus sympa à l’ensemble, il faut ajouter un dynamisme. Pour cela, je vais utiliser l’arme que j’ai codé : les boules de feu. En effet, le joueur, en mode Feu, peut lancer des boules de feu et détruire de petits objets en bois. J’ai donc ajouté un bout de bois qui bloque l’ouverture d’une grille, qui elle-même donne accès à la salle du bouton d’Eau. Le joueur doit donc remarquer ce bout de bois, le détruire, puis ouvrir la grille.

Sans changer réellement le côté énigme, il s’est avéré que le concept du bout de bois à détruire a posé problème à certains testeurs, repoussant la résolution de l’énigme. Le résultat était simple : le joueur comprend qu’il doit passer cette grille mais n’y arrive pas. Enfin, il y avait un côté puzzle réel dans cette énigme. A ce niveau-là, l’énigme a été testée et plutôt approuvée comme la plus intéressant et réussie du jeu (qui est loin d’être terminé).

Depuis, j’ai ajouté des armes d’Eau, d’Air et de Terre même si toutes leurs fonctionnalités ne sont pas implantées. Les idées actuelles seraient du genre :

  • TERRE : permet de défoncer des objets au contact (exemple : défoncer un objet qui gêne le passage)
  • AIR : permet de déplacer des objets à distance, en les poussant ou en les tirant (exemple : actionner un levier hors de portée)
  • FEU : permet de détruire un objet en bois ou d’allumer un feu (exemple : détruire une barrière qui gêne le passage, allumer un feu pour démarrer une machinerie, faire fondre de la glace)
  • EAU : permet d’éteindre une flamme, geler de l’eau ou induire un courant dans de l’eau stagnante (exemple : actionner la roue d’un moulin, arrêter une machinerie…)

Toutes ces possibilités sont encore à l’étude et pourront être (je l’espère) étendues à d’autres possibilités. Parfois, sans faire partie d’une énigme, ces petites choses peuvent amener un peu de dynamisme. J’ai ainsi rajouté une grille à dégommer avant d’entrer dans la salle au bouton Eau. C’est inutile mais assez fun (même si l’effet reste à travailler pour être vraiment sympa).

Dernière chose ajoutée et non des moindres, la roue ne s’actionne non plus avec un bouton, mais par l’action de l’eau. En gros, il faut immerger la fosse d’eau. Avec l’arme d’Eau, on donne un courant à cette eau. Ce courant actionne alors des pales qui, par un système d’engrenage, fait tourner la roue principale. Ainsi, le côté énigme est renforcé car la solution est beaucoup moins évidente qu’un gros interrupteur lumineux en plein milieu du chemin…

Voilà où en est l’énigme actuellement. Il reste beaucoup de boulot (notamment sur les effets de transition : la mise en route d’un courant dans l’eau et du fonctionnement progressif de la roue).

Amélioration des graphismes

J’ai déjà dit que les graphismes avaient été amélioré par le changement du layer (disposition des salles) global et la mise en place de fenêtres. Mais c’était nettement insuffisant. En effet, il faut prendre en compte le jeu (et le niveau) dans son ensemble. Or, cela fait plusieurs salles que le joueur ne voit pas la lumière du jour et qu’il se balade dans des salles carrées, éclairées par des flammes (torches, tuyères…) et des boutons (surtout verts et bleus/blancs). Si le tout est plutôt sympathique à l’oeil, il est aussi particulièrement répétitif et donc lassant. Cette énigme passe un palier supplémentaire dans ce que doit faire le joueur, il est donc essentiel de lui donner un impact graphique qui va avec. J’ai donc revu une grande partie de la conception de la salle principale afin de lui donner de la personnalité.

Pour changer un peu, j’ai décidé de laisser entrer la lumière du jour par le toit en le détruisant (très) partiellement. Cela amène non seulement un dissymétrie bienvenue mais renforce également le côté abandonné du château (qui fait partie du scénario). La lumière du jour (bleutée) amène des ombres supplémentaires (et donc un aspect moins vide à l’ensemble), une colorisation supplémentaire mais également un peu de lumière. En effet, quand on éteint la tuyère en la noyant, la salle perdait sa principale source de lumière et finissait pas être trop sombre. La salle est au départ très lumineuse, avec des ombres marquées et des couleurs chaudes. Après activation du bouton Eau, on découvre une salle dominée par un côté plus froid (présence d’eau, lumière bleutée) et aux ombres adoucies. Avec une même salle, on fait deux ambiance différentes.

L’ouverture dans le plafond m’a permis également de faire un effet assez courant avec un cône lumineux plein de poussières en suspension. Cela amène un côté marquant à la salle, mais également du mouvement (même s’il est léger). De plus, cet effet se voit de loin et pousse le joueur à aller voir ce qu’il y a  et à réfléchir ainsi à l’énigme plutôt que de seulement activer des boutons (ce que ne faisaient pas forcément les testeurs, se lançant sur le premier interrupteur venu).

Dernière chose pour ajouter à l’ensemble. L’ouverture dans la plafond m’a permis d’ajouter des feuillages qui accentuent l’impression d’abandon du lieu et qui ajoutent également du mouvement (un buisson étant soumis au vent).

version actuelle du puzzle

version actuelle du puzzle

Ambiance sonore

Une des premières choses qui choquent quand on joue à une version alpha ou beta, c’est le manque d’ambiance sonore. Il manque souvent de la musique, des sons d’ambiance ou des sons tout court ! Un joueur accepte mal qu’il fasse une action sans qu’un bruit, même mineure, ne lui confirme que son action est prise en compte. C’est vrai aussi bien quand il actionne un interrupteur que quand il essaie  de pousser une grille (même s’il voit une main s’activer à l’écran !) Ce genre d’aspect est relégué assez tard dans le développement car ce n’est pas l’aspect le plus essentiel dans le jeu et que les (bons) sound-designers sont rares. Pourtant, on connait tous des jeux qui nous ont marqué par leur ambiance sonore (F.E.A.R., Bioshock…) et d’autres qui nous ont au contraire paru ridicules à cause de leur doublage foireux et de leurs armes qui font moins de bruit qu’un pétard mouillé (Alpha Prime…).

Ici, au niveau sonore, il y a deux/trois choses à implanter (dont certaines ne le sont pas encore) afin de rendre crédible et compréhensible l’énigme. Par exemple, il est bon que quand la roue se mette à tourner, le joueur l’entende (au cas où il ne regarde pas là à ce moment-là). Voilà en gros le listing de ce qu’il faudrait implanter, dans le meilleur des cas :

  • Bruit de flamme intense pour la tuyère
  • Bruit de flamme léger pour les torches présentes
  • Bruit mécanique de la roue qui tourne
  • Bruit de l’eau stagnante
  • Bruit de l’eau qui coule
  • Bruit de l’eau qui rempli la fosse
  • Bruit de la herse qui se lève
  • Bruit de la herse qui a fini de se lever
  • Bruit de l’interrupteur qui s’active
  • Bruit du bout de bois qui explose
  • Bruit de la grille qui tombe

On voit qu’avec une seule énigme, pas mal de sons sont à trouver (et encore, j’enlève toute la partie relative au joueur : bruit de l’arme d’eau, de feu, du joueur qui marche, qui saute, qui se blesse, qui meurt, etc.). Il faut rajouter à cela qu’ils doivent avec une certaine spatialité (si le joueur est loin du son,il l’entend moins que si je suis à côté) et qu’il faut gérer les différents volumes sonores.

Je ne cache pas que, évidemment, d’une énigme à l’autre, certains sons sont récupérés…

En conclusion

J’ai passé ici toute la partie liée à la gestion des scripts (”si j’appuie là, ça fait ça”) qui n’est pas toujours simple à mettre en place. Cette gestion prend en compte autant les sons, les déplacements d’objets et les déclenchements d’évènements.

J’ai également décidé de créer un niveau prototype pour tester l’énigme avant de la complexifier ensuite. Le fait de ne pas avoir encore tout implanté dans le jeu au début du design (notamment la gestion des armes) m’a évidemment posé des problèmes et m’a pas mal ralenti. Evidemment, le mieux aurait été d’avoir mieux conçu l’énigme en amont, afin d’éviter de refaire certaines parties.

Unreal Safari : Post-mortem (2)

Lundi 19 juillet 2010

unrealsafari

La première map : WAR-Gizeh

Après les premières hésitations, je me met à travailler sérieusement sur une map dans l’environnement Gizeh. Pour y aller petit à petit, je tente d’abord des maps uniquement extérieures, avec des temples ouverts sur le ciel. A force de recommencer, je commence à avoir une bibliothèque de modèles assez importante qui me permet, quand je redémarre une version de la map (ce qui arrive assez souvent) de ne pas passer des journées entières à tout refaire. Je travaille pas mal la modélisation modulaire qui permet de modéliser de façon plus souple.

Cependant, les brouillons de maps n’atteignant jamais une version suffisante. Je ne peux donc pas vraiment tester ces layouts en terme de gameplay. Lassé par la grande taille des maps Warfare, je décide alorsd’essayer de faire une version 100% dans un village. Le côté confiné est un désavantage certain, mais il me permet de mieux maîtriser les déplacement des joueurs. Avec le recul, cette idée était très mauvaise. Ce genre de map n’est pas du tout adaptée au mode de jeu. Je revenais à mes (mauvais) réflexes de level-designer pour Counter-Strike : Source.

Techniquement, les rendus rappellent UT2003/2004. J’apprends alors à utiliser à bien les textures de type normal maps (relief), specular maps (reflets) et shadow maps (ombres). Cela m’a pris du temps, me demande souvent plus de travail, mais j’obtiens enfin eu un rendu in-game supérieur à ce que je faisais sous Source. Il m’aura fallu des mois pour ça.

Une fois ces techniques maîtrisées, je redémarre une dernière fois WAR-Gizeh. Globalement, la réalisation de la map ne posera pas de problèmes particuliers. Mon idée ici est de publier une map Warfare (c’est-à-dire pour UT3) que je modifierai ensuite pour mon mode “Warfare pour animaux”. En effet, à ce stade, le mode de jeu prévu pour Unreal Safari est une Warfare sans véhicule. Pour ceux qui ont joué à ce mode de jeu, ils comprendront sans peine que :

1 - inutile de faire un mod pour ça
2 - les véhicules sont un des grands intérêts du mode Warfare

Cependant, l’idée de faire une map publiable est certainement la meilleure idée que j’ai eu ici. Car elle me permettait de me prouver que j’étais capable de faire une map avec 90% d’éléments custom sur l’Unreal Engine. Le layout est pas mal mis en cause et changera au fil des bétas. Très vite, j’apprend à écouter la communauté, même si ses exigences sont parfois décourageantes. Ajouter des points de contrôle par exemple demande énormément de boulot, car il ne faut qu’ils ne soient pas destructible de trop loin (donc il faut les protéger). De même, ajouter des véhicules implique un équilibrage pas toujours évident. Au final, en écoutant les remarques, la map a pris beaucoup en intérêt stratégique car au départ, il n’y avait pas beaucoup de possibilités de jeu et la map devenait vite répétitive. Il est à noter que la communauté m’a poussé à faire une version Necris en plus afin de plaire au plus grand nombre !

layout

WAR-Gizeh ne sera jamais utilisé pour Unreal Safari. Mais ce n’était pas une perte de temps car elle m’a permis de :

1 - Me faire connaître un peu dans la communauté
2 - Constituer une banque de modèles et de textures pour Unreal Safari
3 - Apprendre de nombreuses techniques supplémentaires
4 - Travailler le level-design d’un mode de jeu pour lequel je n’avais jamais mappé
5 - Me prouver que ma “patte” graphique était appréciée et considérée comme original

Il est à noter que plusieurs mois après la release, j’ai été contacté par des joueurs qui voulaient que je corrige les quelques soucis restant sur cette map. Contrairement à ce que je croyais, cette map a donc été jouée sur certains serveurs.

Je termine là-dessus afin de préciser l’importance des avis de la communauté. J’ai eu la chance de faire partie de communautés pertinentes (bien que peu nombreuses) qui m’ont soit aidé techniquement, graphiquement ou au niveau du gameplay. Sans eux, je ne serais pas allé loin. Ces communautés sont Mapping-Area, Unreal.fr et Unreal-Design.

beta_2_01 beta_2_07 beta_2_06

Liens : http://www.moddb.com/mods/unreal-safari/addons/war-gizeh