Idée originale

Comme plusieurs projets sur ce site, celui-ci a commencé lors d’un week-end de développement sur le site Developpez.com.

L’idée était d’explorer des ruines sous-marines dans le but de trouver des clés pour ouvrir des portes jusqu’à atteindre une "salle du trône". Il n’y avait pas vraiment de challenge dans le jeu, la seule difficulté était donc de cacher les clés à des endroits où la caméra fixe du jeu permettait difficilement de les voir. Pour le personnage du joueur, j’ai simplement pris le cube avec une texture de brique que j’avais utilisé pour un précédent projet, d’où "Swimming Brick".

Pendant le week-end, des gens qui trouvaient les graphismes sous-marins moche m’ont demandé pourquoi je ne situais pas plutôt le jeu dans l’espace. La vérité est que je voulais faire un jeu de nage parce que je trouvais que la nage était un mécanique trop peu explorée dans les jeux, et quand elle l’était elle était rarement bien exécutée.

L’un des gros problèmes que j’ai eu pendant le week-end était que je n’avais aucun système de collision 3D dans mon moteur, j’ai donc du en bricoler un assez buggé pour pouvoir finir dans les temps.
Quelques jours plus tard, j’ai changé le système pour qu’il utilise une grille en 3D: plus facile à développer et à tester, mais limite quelque peu la liberté de création des maps.

Évolutions

Au cours des mois suivants, j’ai entrepris un chantier ambitieux: refaire un système de collision 3D permettant le maximum de liberté dans la création des maps.
Après quelques expérimentations et des détours dans de mauvaises directions, j’ai fini par me rendre compte que j’étais en train de faire quelque chose de très proche du système de collision de Quake et autres jeux similaires: j’ai donc entrepris de faire un parser de .map - le format des maps des jeux Quake et d’autres jeux de la même famille comme Half-Life - , ce qui me permet maintenant de créer des maps avec l’un des éditeurs de maps pour Quake déjà existants au lieu d’avoir à faire le mien.

N’ayant pas vraiment mappé sur des jeux de ce genre, à part quelques expérimentations dans WorldCraft pour Half-Life quand j’étais au collège, j’ai fait un petit état de l’art des éditeurs encore utilisés aujourd’hui, et je me suis tourné vers TrenchBroom.



TrenchBroom est un éditeur de maps pour le premier Quake - dont la scène mapping est toujours active - et d’autres jeux similaires, sorti pour la première fois en 2013, développé par Kristian Duske. Son idée était de pouvoir éditer des maps comme si on était déjà à l’intérieur du jeu, son éditeur permet donc d’agir dans la vue 3D, contrairement à des éditeurs plus anciens comme GTKRadiant où les vues d’édition principales sont en 2D et où la vue 3D sert principalement d’aperçu.


J’ai profité de ce projet pour faire évoluer mon moteur de jeu sur plusieurs aspects:

• Le rendu: j’ai ajouté une spotlight et des ombres, j’ai fait un shader d’eau avec réflexion et réfraction, ce qui m’a amené à avoir un système de render-texture réutilisable pour d’autres features, et le jeu nécessitera encore d’autres améliorations
• C’est sur ce projet que j’ai commencé à créer ceq, mon mini-langage de script
• J’ai commencé à implémenter un rendu de texte propre pendant que je travaillais sur ce projet

J’ai également décidé de remplacer la caméra fixe par une caméra derrière le joueur, pour pouvoir faire des niveaux plus compliqués.

Mon but est que ce jeu devienne d’un niveau commercial.

Téléchargez la dernière version (Windows)

Plus d’informations ici: https://www.developpez.net/forums/d1600230/applications/developpement-2d-3d-jeux/projets/we-jv6-swimming-brick/