Bonjour a tous,

Je viens vous présenter Relic (working title, release title TBD), un projet sur lequel je travaille depuis qq mois. Le jeu est actuellement jouable mais demande encore des phases de test, d'ajout de contenu et de traitement graphique.

• APERCU

Relic est un jeu action-aventure dans la lignée des Zelda 2D (TLoZ, ALTTP, DX, OoA, OoS). Les détails du scénario restent a définir, mais on retrouve une zone d'exploration extérieure semi-ouverte, des donjons intérieurs mêlant puzzles et combats, et la nécessite de collecter des items pour progresser.

• SCREENSHOTS

Visuels temporaires, issus de la derniere version de developpement

• FONCTIONALITES PRINCIPALES

- Habillage rétro mais gameplay moderne avec prise en main ergonomique
- Action dynamique avec des combats en temps réel
- 4 environnements extérieurs avec des thèmes graphiques distincts
- 5 donjons avec leur lots de puzzles, monstres et boss exclusif
- 16 items a collecter conférant interactions et aptitudes (8 actifs, 8 passifs)
- Monde extérieur semi-ouvert en "onion skin" se débloquant avec la progression
- Bestiaire varie avec une 20aine de types d'ennemis aux comportements différents
- Gameplay riche avec les traditionnels interrupteurs, teleporteurs, obstacles, secrets, etc.

• INFOS

- Temps de jeu estime : ~10h, +~5h completionist
- Taille de la zone de jeu : ~150 écrans
- Equipe : moi-même, tout seul comme un grand
- Temps de développement : ~6 mois en partant de rien (~4 accomplis, ~2 restants)
- Sortie : ~été 2016 TBC sur Steam et itch.io

• DEVELOPPMENT

Je travaille en solo, et je m'occupe de la programmation, de la production, du game design, du level design, du QA ainsi que des ressources additionnelles quand je ne trouve pas ce dont j'ai besoin.

Le jeu est entièrement jouable en terme de "flow" (progression, collecte des items, mécaniques de gameplay, types d'interactions, etc.) mais seulement ~20% du contenu est réellement en place a l'heure actuelle (level design, variétés de puzzles, disposition des monstres).
La partie "finie" du jeu constitue une "vertical slice" qui va me permettre de procéder aux premiers focus tests pour collecter les retours utilisateurs et procéder aux itérations nécessaires avant de poursuivre.

Il reste donc surtout a faire du remplissage et de l'habillage, ainsi que tout le contenu secondaire : scénarisation, tutoriel, audio, etc. ; de mémé que qq fonction alites tardives : options, configuration des controls, filtres graphiques, etc.

• BIOGRAPHIE

On me demande parfois mon parcours, donc qq mots sur ma bio - j'ai 35 ans et suis issu d'une double formation ingénieur / master informatique en imagerie et traitement du signal. J'ai travaille presque 12 ans en UK dans l’industrie du jeu vidéo en tant que responsable technique et producer sur des AAA PC et consoles.

J'ai commence a développer des jeux a mon compte il y a ~1 an, avec un premier petit projet publie sur Steam il y a qq mois. Mon activité personnelle n'est pas encore rentable, mais c'est un bon moyen de découvrir le cote "entreprise" et "publication". Mon but est d'arriver a toucher un public plus large au fil des projets, et intéresser d'autres créateurs pour s'associer dans des productions de plus grande envergure.

https://www.jeuxvideo.com/forums/42-31-41992037-1-0-1-0-greenlight-parasite-platformer-retro-non-lineaire.htm
https://www.jeuxvideo.com/forums/42-31-39974651-1-0-1-0-guide-de-production-pour-amateurs-et-independants.htm

• TECHNOLOGIES

Le jeu est programme en Typescript, superset de Javascript, langage a forte productivité permettant une excellente architecture de projet en terme de maintenabilité (en gros, JavaScript avec des concepts objet, en l'attente d'ES6).

Ce choix permet de cibler "facilement" les plate-formes web et desktop (Windows, Linux, MacOS). En contre-partie, l’intégration de certaines technos liées aux plate-formes de distributions (e.g. API SteamWorks natives) est au mieux délicate, sinon impossible.

Le moteur utilise est Phaser 2.4.4 et j'utilise Tiled pour le level design. C'est une toolchain simple et facile d'utilisation, mais éprouvée et robuste.

En parallèle de Phaser, j'ai développé mon propre framework ECS (Entity-Component-System) pour maximiser la reutilisabilite de mes blocs de logique et de mes éléments de gameplay. Je compte capitaliser sur ce framework et l’étendre pour mes projets suivants, notamment un dungeon crawler et un coop-shooter, qui devraient être plus rapides a développer en partant de cette base.

• ECS

Mon ECS me permet une approche entièrement data-driven ou tout le gameplay est specifie directement par les fichiers de définition des entités (.json) et les données d'instances du level file. Cela permet de rajouter du contenu, creer de nouvelles combinaisons de logique, et équilibrer les éléments existants, sans la nécessité de "re-programmer" le gameplay. C'est plus long a mettre en place que coder directement le gameplay, mais c'est aussi bcp plus flexible et réutilisable.

Toujours dans un soucis de factorisation, mes fichiers de définition d’entités (prototypes, ou blueprints selon la terminologie des frameworks) supportent l’héritage multiple

Qq exemples de fichiers de définition d’entités avec héritage -

Ici une base pour des ennemis / monstres ; "Resettable" et "HealthDrop" sont des groupes de composants herites d'autres definitions :

{
	"id" : "Enemy",
	"base" : [ "Resettable", "HealthDrop" ],
	"components" :
	[
		{
			"type" : "PositionAttributeComponent"
		},
		{
			"type" : "VelocityAttributeComponent"
		},
		{
			"type" : "HitboxPhysicsComponent",
			"hitbox" : { "width" : 16, "height" : 16, "offsetX" : 0, "offsetY" : 0 },
			"immovable" : false,
			"drag" : 0
		},
		{
			"type" : "OverlapperPhysicsComponent",
			"groups" : [ "Player" ],
			"message" : "Attack"
		},
		{
			"type" : "OverlappedPhysicsComponent",
			"group" : "Monster"
		},
		{
			"type" : "BumpControlComponent",
			"speed" : 160,
			"duration" : 0.1
		}
	]
}

Une specialisation d'ennemi, ou on herite la plupart des fonctionnalites, et on ne fait que rajouter les comportements de combats et l'affichage :

{
	"id" : "Eye",
	"base" : [ "AirEnemy" ],
	"components" :
	[
		{
			"type" : "HealthStatComponent",
			"health" : 2
		},
		{
			"type" : "VulnerabilityStatComponent",
			"entries" :
			[
				{ "prototype" : "SwordUse", "damage" : 1 },
				{ "prototype" : "AxeUse", "damage" : 2 },
				{ "prototype" : "PickUse", "damage" : 2 },
				{ "prototype" : "HammerUse", "damage" : 2 },
				{ "prototype" : "SpearUse", "damage" : 2 }
			],
			"invulnerabilityTime" : 0.5
		},
		{
			"type" : "SpeedStatComponent",
			"speed" : 16
		},
		{
			"type" : "FleeControlComponent",
			"range" : 64
		},
		{
			"type" : "ShootFeatureComponent",
			"prototype" : "Projectile",
			"warmupTime" : 1,
			"cooldownTime" : 1,
			"aim" : "Player"
		},
		{
			"type" : "CharacterDisplayComponent",
			"texture" : "Monsters",
			"animations" :
			[
				{ "name" : "IdleUp", "frames" : [ 104 ], "mirror" : false, "framerate" : 0, "loop" : false },
				{ "name" : "IdleDown", "frames" : [ 104 ], "mirror" : false, "framerate" : 0, "loop" : false },
				{ "name" : "IdleLeft", "frames" : [ 104 ], "mirror" : false, "framerate" : 0, "loop" : false },
				{ "name" : "IdleRight", "frames" : [ 104 ], "mirror" : false, "framerate" : 0, "loop" : false },
				{ "name" : "WalkUp", "frames" : [ 104, 105 ], "mirror" : false, "framerate" : 5, "loop" : true },
				{ "name" : "WalkDown", "frames" : [ 104, 105 ], "mirror" : false, "framerate" : 5, "loop" : true },
				{ "name" : "WalkLeft", "frames" : [ 104, 105 ], "mirror" : false, "framerate" : 5, "loop" : true },
				{ "name" : "WalkRight", "frames" : [ 104, 105 ], "mirror" : false, "framerate" : 5, "loop" : true }
			]
		}
	]
}

Il n'y a plus qu'a re-combiner les composants au chargement et assembler avec les donnees d'instances (position, etc.) venant du level file pour obtenir des entites operationnelles.

• CONTRIBUTEURS

Les ressources graphiques utilisées jusqu’à pressent sont réalisées par 3 artistes. Les assets sont soumis a licences d'utilisation ou sont distribues sous CC0/CC-BY(-SA).

Henrique "7Soul" Lazarini
Environnements, monstres
http://7soul.tumblr.com/

Michele "Buch" Bucelli
Environnements, entités diverses
https://www.patreon.com/buch/

Carl "Surt" Olsson
Personnages additionnels
http://uninhabitant.com/

Voté "Oui, pourquoi pas"
Tout simplement parce qu'en soit, ca n'a pas l'air mauvais, mais je me demande ce qui fait qu'il se démarque des autres jeux du genre, étant donné que les graphismes sont basiques, et que le gameplay ne me semble pas exceptionnel non plus.

A voir en vidéo !

Pareil que mon VDD, j'attends de voir si le fond est intéressant même si j'apprécie en général ce format de jeu

Une presentation vraiment complete. ;)
Moi je suis chaud pour tester ton jeu et te faire une critique constructive. sinon je dirais oui pour le sondage faudrait juste un truc qui le sortirais du lot

Oui effectivement, les elements fondamentaux du gameplay central ne brillent pas pas leur originalite. Ce choix s'explique principalement par 2 elements :

- la plateforme ; si les jeux action-aventure de ce type sont legions sur console (ou plutot "ont ete" en 2D), on en trouve au final assez peu sur desktop. J'espere toucher un public un peu different

- le facteur risque. Le projet s'incrit dans une capitalisation incrementale de mes developpements. Je me focalise surtout ici sur la technologie, dans l'idee de faciliter les projets futurs. Je ne souhaite donc pas cumuler tous les risques en meme temps (risque technologique + risque gameplay + risque cout, etc.). A l'issu de ce projet, mes techno seront en place, je pourrais donc deplacer le risque vers le gameplay, pour qqch de plus audacieux

Pour les tests, il me reste encore un petit peu de preparation a faire ; et ce premier focus test ne sera pas "autonome" et devra se faire sous "controle" du developpeur (manque du tuto, de certaines instructons en jeu, etc.). Le but sera surtout de se concentrer sur la prise en main, l'ergonomie et l'interet global de l'exploration, des puzzles et des combats.

Je comprends ;)
Si tu a besoin quand meme n'hesite pas

Avec plaisir ! Je previens juste que ce sera un test "accompagné", pour avoir le feedback en live, et en se focalisant sur certains aspects en faisant abstraction d'autres.

Avec ton bagage technique et pro tu faits du Javascript...

Mon langage de predilection, c'est le C++ ! Mais JAMAIS je n'aurais ma productivite actuelle avec du C++, surtout pour cibler une variete de plateformes comme je le souhaite, notamment web. Meme s'il existe des solutions partielles, c'est de la complexite en plus.

Quand on part C++, ca veut aussi dire qu'on va avoir du C# pour la toolchain (bcp plus interessant a interfacer) et un langage de script pour le gameplay (maison, LUA, etc.). On arrive deja sur au moins 3 technos. Plus les contraintes que le cross-platform impose au niveau des frameworks et libs. Plus les contraintes de typage fort.

Avec du Typescript, j'ai la structure d'un code C++ avec la productivite du Javascript, des phases de transpilation immediates, et la possibilite d'utiliser le meme langage pour le framework, la toolchain et les scripts gameplay.

Travaillant en solo, je privilegie la productivite ; donc ca passe aussi par le choix des technos les plus appropries, meme si pas mes preferees. C'est egalement la possibilite d'apprendre une techno qui me servira pour la partie multiplayer / serveur quand je voudrais faire du coop / pvp.

Oui, GameDev Tycoon avait fait un binding maison, mais assez incomplet et maintenant obsolete :/ GreenWorks ; ca a p-e evolue depuis, je retournerai voir ! Ca reste possible, au moins en partie, mais clairement pas immediat.

Ah je suis très content de voir un projet ambitieux avec Phaser sur ce forum

Je m'amuse beaucoup avec en ES6, c'est devenu assez agréable de faire un jeu propre et maintenable en JS maintenant. J'aime beaucoup la façon dont tu gères ton code avec les fichiers json, c'est génial.

Quant au jeu, ça a l'air bien sympa, je vote

Bon courage pour la suite !

Merci bien !

Apparement un Phaser 3 (dont j'ai oublie le nom de code) est en preparation ; mais pas le temps d'attendre.

Tu utilises quoi pour ES6, vu qu'on est encore loin d'une adoption suffisante dans les browsers ? Tu passes par le transpiler Babel ? J'ai hesite avec le TypeScript au debut du projet, les deux ayant l'air tres tres proches.
Migrer de l'un a l'autre ne devrait pas etre tres difficile, si necessaire.

Pour les fichiers de def de components, le json est franchement une benediction ! Pour avoir fait des ECS dans des langages compiles, c'est une toute autre complexite. Quand il faut parser tous ses bidules fortement types, construire a la main des bouts de composants pour les donnees templates, qu'on se retrouve avec d'autres bouts de composants des donnees du level file, qu'il faut assembler tout ca, et qu'il faut encore greffer les donnees de runtime et bien d'autres, c'est bcp plus laborieux pour aboutir, finalement, a des entites operationnelles !
Ici c'est d'une simplicite enfantine. Apres je me force quand meme a "parser" mon json (= simplement affecter les membres a des classes typees) pour m'assurer que mes composants sont "bien construits".

Original de mêler vue de dessus et vue 2D iso...

Pourquoi avoir fait le choix d'un jeu pixelisé ? C'est comme cela avec la plupart des jeux de toute façon, soit c'est le côté prog qui est développé, soit le côté visuel. C'est pas possible de faire un jeu qui soit aussi bien intelligent que visuel pour une fois ?

Le melange de perspectives est a la fois un grand classique mais aussi une necessite pour ce genre de jeux ; c'est "aberrant" mais c'est le meilleur equilibre en termes de lisibilite et jouabilite.

Generalement on va trouver les maps exterieures en 2D iso (espaces plus ouverts), les maps interieures en top-down (salles plus fermees, avec "fausse" profondeur laterale), et les personnages / items / animations en mix 3/4 voire cote

Avec toute forme de projection, le scrolling ou transition d'ecrans generera necessairement une deformation de parallaxe. La seule vue "correcte" possible serait une top-down ortho, qui "ecrase" toute la profondeur et donne des environnements tres plats. De meme pour les personnage qui, si vus purement dessus, ne ressemblent a rien

Ex. typique sur un Zelda 1 ou c'est flagrant du fait de la faible diversite graphique :
https://i.ytimg.com/vi/iM/iMDzi4HNOXI/maxresdefault.jpg

Qu'on retrouve sur des episodes ulterieurs :
http://www.zeldainformer.com/2012/04/20/Zelda%20Dungeon%20ALttP.jpg

Le melange de perspectives ne choque pas la perception et ne nuit pas a la bonne comprehension de l'environnement.

Le cote pixelise, c'est surtout une contrainte tres forte de disponibilites de ressources. Il est tres difficile de trouver des assets suffisament complets et de qualite uniforme pour creer un jeu. Le plus delicat etant toujours les animations, qu'il faut faire sur mesure.

N'etant pas artiste moi-meme, ca me permet aussi d'arriver a me debrouiller pas trop mal quand il me faut realiser certains elements specifiques pour combler les manques dans les ressources existantes.

Des packs de tiles, sprites et animations en plus haute resolution represente une masse de travail enorme que je ne suis pas en mesure de commander a l'heure actuelle. Ce sera un investissement a venir pour des projets futurs, quand mes technos seront rodees. Ajd je travaille sur ces projets a plein temps ; impossible de trouver des personnes competentes capables d'en faire autant sachant que l'activite, au moins dans un premier temps, ne sera clairement pas rentable.

Je reviens sur un point :

soit c'est le côté prog qui est développé, soit le côté visuel

Pour les projets en micro-equipe, voire menes en solo comme c'est ici mon cas, il est impossible de couvrir toutes les disciplines necessaires a la creation d'un jeu. Si on considere ce projet, j'occupe deja 7 roles d'une equipe de developpement (prog framework, prog gameplay, game design, level design, production, QA et publication), je n'ai ni le temps ni les competences pour faire en plus la partie sonore (musique, sfx) et graphique (sprites, animations, effets, etc.) par moi-meme

Rajouter des personnes et contibuteurs pour aider au projet, c'est des contraintes, des couts et des risques qui ne sont pas pertinents a mon stade.

Donc prendre une direction artistique "retro" me permet de realiser qqch a ma portee, tout en conservant une qualite de finition que j'espere "correcte". (apres certains sont allergiques au pixel retro ; d'autres aiment bien. Moi c'est le "HD vector" dont j'ai horreur par exemple).

D'ailleurs un projet mene par un artiste sera souvent oriente "narratif" (bcp de ressources visuelles, peu de gameplay). Un projet mene par un programmeur sera oriente "abstrait" (peu de ressources visuelles, gameplay complexe). Des qu'on ajoute de la complexite a la narration, ou des ressources au gameplay, c'est exponentiel : toutes nouvelles feature a besoin d'autant plus de support technique et artistique pour etre implemente. Cela contraint a faire bcp plus de travail, d'ou temps de dev intenables, ou reduire considerablement le "scope" et donc faire plus un prototype plus qu'un jeu. Dans tous les cas, intenable financierement.

L'equilibre est delicat.

J'ai pas le temps de faire un avis constructif alors je dirai simplement que oui ça peut franchement m'intéresser, et ça fait plaisir de voir une présentation aussi complète.
Le style graphique laisse penser à une forme d'hommage envers les Zelda 2D, du coup comme la limite entre inspiration et plagiat est toujours un peu floue, je suis curieux de voir où se situe(ra) Relic.
En tout cas, bravo pour le travail accompli et bon courage pour celui à venir !

D'ailleurs une des difficultes recurrentes quand on s'attaque a un gameplay "classique", c'est le nombre de conventions admises etablies au fil du temps, conventions qu'il ne faut pas casser sous peine de perdre le joueur.

Le genre action-aventure 2d a ete tres represente a une epoque, et a constitue le gros de la logitheque "aventure/rpg" de toute une generation. Un certains nombre de standards admis se sont imposes, en termes de types d'interactions, mecaniques de gameplay, utilisation d'items traditionnels, etc. Le challenges consiste donc a conserver ces conventions pour ne pas derouter le joueur, tout en innovant avec des elements nouveaux ou des solutions alternatives.

Un de buts de mes projets est de m'ameliorer en game design ; partir d'un genre connu en apportant ma touche est une moyen de minimiser le risque tout en presentant ma vision personnelle.

Merci pour ces explications.
Intéressant.
Malgré tout, pour les pixels, et sans vouloir faire de mauvais jeu de mot, je ne sais pas si c'est vraiment très reluisant, toussa...
En tout cas moi, quand j'ai l'esprit un peu nostalgique, je préfère télécharger une ROM pour émulateur...

Pour les jeux de type médiéval, il existe déjà d'innombrable ressources graphiques dans le domaine libre de droit, c'est sans doute le genre qui a le catalogue le plus complet je crois.
Quitte à compléter un peu avec des nouvelles créations.
Cela dit des packages tout fait "clé en main" qui contiennent des sprites, items, etc. Il ne doit pas y en avoir tan que ça, oui, c'est vrai...
Donc oui comme le jeu est déjà bien avancé dans la conception, c'est sans doute mieux de le laisser ainsi, pour les plus nostalgiques...
Mais par la suite, ce serait peut-être bien de faire un jeu avec des graphismes d'une meilleure qualité, voir même carrément marquer la différence avec des graphismes 3D adaptés à de la 2D.
Enfin c'est juste un avis, après, bon...

Merci pour la critique, toujours utile -

On trouve effectivement enormement de ressources disparates, mais dans la mesures ou elles sont rarement crees avec les meme contraintes (resolution, perspective, angle de vue, niveau de details, style, colorimetrie, etc.) il est impossible de les mixer de maniere esthetique. C'est une necessite que de se limiter a des sets homogenes, et donc generalement mis a disposition par un petit nombre d'artistes, dans des packs coherents.

Il reste encore pas mal de traitement graphique a faire avant la sortie (diversite, qualite, effets et ombrages, shaders, etc.). De plus cela n'empeche pas d'embaucher si besoin un artiste sur la fin pour repasser derriere et refaire une partie des ressources quand tout est fonctionnel.