Omnicard Réinventer
Imaginer le jeu. Construire les règles.
Un jeu de cartes inventé sur papier avec mon cousin, que j’ai transformé seul en jeu en ligne : les cartes rééquilibrées, le serveur qui arbitre les parties et l’interface.
- 181 cartes dans le catalogue public, réparties en trois univers Galerie publique, version 1.2.0, relevée le 13/10/2026
- ≈ 3 mois de travail cumulé, seul Témoignage, questionnaire D1 et D2
- 5 types de cartes arbitrés par le moteur de règles Règles publiques du moteur, relevées le 13/10/2026
- Besoin
- Faire enfin passer au numérique le jeu de cartes que nous avions inventé sur papier, mon cousin et moi.
- Ma part
- J’ai repris le projet seul : rééquilibré les cartes, écrit le moteur de règles en C# qui arbitre les parties côté serveur, puis construit l’interface Angular.
- Rôle
- Co-auteur du jeu papier ; seul pour le jeu en ligne (équilibrage, moteur, interface)
- Période
- Depuis l’adolescence, puis en ligne
- Équipe
- À deux sur papier, seul pour le code
- Statut
- Hors ligne, en attente de refonte
- Liens publics
Au départ, on plastifiait nos idées
Adolescents, avec mon cousin, on invente un jeu de cartes. On imprime, on plastifie, on recommence, des après-midi entières pendant les vacances. On en sortira « un nombre incalculable d’éditions ».
Le passage au jeu vidéo traîne. Alors je reprends le projet, seul, et je me lance avec les outils que je connais : Angular et .NET.
« Je voulais me lancer direct et pas perdre de temps. »
Du papier au navigateur, la même envie d’inventer.
Rééquilibrer mes propres cartes
Avant le code, il y a eu les cartes. Je les reprends une à une pour le passage au numérique : un coût qui baisse ou qui monte, des statistiques revues.
L’archive publique garde la saison 1 ; on y voit, carte par carte, ce qui a changé.
Une partie en trente secondes
Deux joueurs s’affrontent au tour par tour. Chacun pioche dans un deck de 40 cartes, pose ses unités sur deux lignes, joue sorts, équipements, terrains et pièges, et tente de faire tomber à zéro les points de vie adverses.
À chaque tour, la réserve de mana grandit ; ce qui n’est pas dépensé devient des cristaux, à garder pour plus tard.
- 30 points de vie par héros ; à 0, la partie est perdue
- 40 cartes par deck, à puiser dans les trois univers
- 10 mana au plus, +1 à chaque tour ; ce qui reste devient cristaux, 5 au plus
- 2 lignes d’unités par joueur, 10 places chacune
L’idée devient un jeu
Une collection à explorer, un deck à préparer, des boosters à ouvrir, puis des duels en temps réel.
D’une phrase à une règle
Les outils existaient ; le jeu restait à construire. J’ai écrit le moteur de règles sans moteur de jeu existant. En C#, côté serveur, il démarre la partie, mélange, fait piocher, déroule les tours et résout chaque effet ; le navigateur affiche l’interface Angular.
Les cartes s’appuient sur des effets et des conditions que l’on peut combiner. Sur une carte, une phrase suffit. Le moteur, lui, doit savoir de quels tours elle parle.
Même « GitGud » a sa carte.
L’effet, écrit sur la carte « Dans 5 tours, la partie se termine par une égalité. »
Le serveur arbitre, chaque joueur voit sa partie
-
Le joueur choisit
L’interface Angular : le rendu des cartes, le catalogue, les filtres et l’éditeur de decks.
-
Le moteur résout
Les règles en C#, côté serveur : le moteur vérifie l’action et applique ses effets.
-
La partie se met à jour
SignalR, la liaison en temps réel, renvoie l’état de la partie aux deux joueurs.
Collections et decks conservés dans PostgreSQL.
Sous le capot
Apprendre en dépassant ce que je savais faire : une stack que je maîtrisais, un jeu qu’elle n’était pas faite pour porter.
-
Angular et .NET, une stack que je maîtrisais
- Contrainte
- Le passage au jeu vidéo traînait, et je voulais me lancer sans perdre de temps.
- Choix
- Angular et .NET, que je connaissais déjà, plutôt qu’un moteur de jeu à découvrir.
- Effet
- Un jeu dans le navigateur, sur une stack maîtrisée mais pas faite pour ça.
-
Le serveur arbitre chaque action aperçu
- Contrainte
- Deux navigateurs, une seule partie : il faut un arbitre.
- Choix
- Un moteur de règles en C#, côté serveur : il mélange, fait piocher, déroule les tours et résout chaque effet.
- Effet
- Chaque joueur envoie son action ; le serveur tranche et renvoie l’état de la partie.
C#, forme simplifiée écrite pour cette page : le code est privé // Chaque action d’un joueur passe par le hub de la partie public async Task JouerCarte(DemandeCarte demande) { var partie = SessionDe(demande.Code); var verdict = await partie.ExecuterAsync(jeu => jeu.JouerCarte(joueur, demande.Carte, demande.Cible)); if (!verdict.Reussi) throw new HubException(verdict.Erreur); // refus pour ce joueur seul await DiffuserEtat(partie); // chaque joueur reçoit sa propre vue de la partie } -
Des effets écrits en mots-clés code
Une carte combine des effets et des conditions nommés par des mots-clés : Délai, Rechargement, Quand, Assassinat… Une phrase suffit au joueur ; le moteur, lui, doit savoir quand l’effet part, qui le compte et ce qui l’annule. Le glossaire public en donne la règle.
Le glossaire des mots-clésdocs/keywords.md· Markdown### Délai(N) Effet programmé pour s'exécuter **N tours plus tard**. Le compteur décrémente uniquement à la fin du tour du joueur qui a programmé l'effet. Si l'unité émettrice meurt, l'effet est annulé. ### Rechargement(N) Effet **récurrent** qui se redéclenche tous les N tours (différent de Délai qui ne se déclenche qu'une fois). -
SignalR, le cache et le prérendu serveur
- Contrainte
- Des parties en temps réel, sur une stack qui n’était pas pensée pour un jeu.
- Choix
- SignalR pour le temps réel, puis le cache, le prérendu serveur et un déploiement optimisé.
- Effet
- SignalR, le cache, l’optimisation du déploiement et le prérendu serveur : ce que ce projet m’a appris.
Ce que j’en retiens
« Le projet qui m’a fait le plus apprendre. »
L’un de mes premiers gros projets techniques, avec beaucoup de choses codées de zéro. Le jeu est aujourd’hui hors ligne, en attente de refonte.
Sources et méthode : chiffres, dates, méthode et crédits
Le projet. Le jeu papier, les éditions, la reprise du projet seul, les trois mois de travail cumulé et le choix d’Angular et de .NET viennent de mon témoignage (questionnaire du portfolio, D1 et D2) ; le statut hors ligne, en attente de refonte, est confirmé au 13/10/2026. Le moteur de règles en C# déroule les parties côté serveur : mélange, pioche et tours.
Cartes. Les cartes de la saison 1 sont celles de l’archive du dépôt de présentation. À droite, les exports de l’outil du projet faits le 13/10/2026 ; le catalogue public 1.2.0 affiche encore 4/8 pour Gehrman et 0/4 pour Floppa : Mage. Les effets cités viennent du catalogue public, version 1.2.0, qui compte 181 cartes : 114 Bloodborne, 51 JoJo et 16 WTF.
Règles. Points de vie, deck, mana, cristaux, lignes et types de cartes : version joueur des règles du moteur. Le compte à rebours de GitGud suit le mot-clé Délai du glossaire : le compteur ne baisse qu’à la fin du tour du joueur qui a programmé l’effet, et l’effet est annulé si l’unité qui l’a programmé meurt. Relevés le 13/10/2026.
Captures. Page d’accueil, collection, deck et booster : captures d’une version précédente du jeu, conservées par la première version de ce portfolio ; leur date n’est pas documentée et leurs compteurs ne sont pas des chiffres actuels.
Univers. Omnicard est un projet de fan, non commercial. Les univers, les personnages et les illustrations des cartes appartiennent à leurs ayants droit ; je n’en suis pas l’auteur.
Sous le capot. Le mot-clé Délai vient du glossaire public, à la révision 8be9cbb. Le hub de partie est une forme simplifiée, écrite pour cette page d’après le code privé du jeu, relu le 15/10/2026 : chaque action passe par le serveur, qui renvoie à chaque joueur sa propre vue de la partie.