Comment fonctionne le tirage OGiveaway ?

Chaque tirage repose sur un seed (32 octets aléatoires), dont le hash SHA-256 est affiché sur l'overlay avant le tirage. Le seed en clair n'est révélé qu'après. Comme l'algorithme ci-dessous est entièrement déterministe, n'importe qui peut reprendre le seed révélé et vérifier, sans nous faire confiance, que le hash annoncé à l'avance correspond bien et que le gagnant affiché est bien celui produit par cet algorithme.

1. Hash de preuve

hash = SHA-256(seed), affiché avant le tirage.

2. Générateur pseudo-aléatoire (mulberry32)

Un seul seed principal sert à dériver un sous-seed indépendant par usage (répartition en équipes, noms d'équipe, chaque round, duel final) via HMAC-SHA256(clé = seed, message = "purpose"), dont les 4 premiers octets (big-endian) alimentent un mulberry32 :

function mulberry32(seed32) {
  let a = seed32 >>> 0;
  return function next() {
    a |= 0;
    a = (a + 0x6D2B79F5) | 0;
    let t = Math.imul(a ^ (a >>> 15), 1 | a);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

3. Répartition en équipes

Les participants sont mélangés (Fisher-Yates seedé par purpose = "team-split") puis coupés en deux moitiés (équipe A / équipe B). Les noms des deux équipes sont tirés dans une liste fixe de noms "fun" via purpose = "team-names".

4. Bataille rangée à points de vie

À chaque round, le pool de survivants est coupé en deux équipes aussi égales que possible (purpose = "round-<n>-split"). Chaque équipe démarre avec le même total de points de vie (proportionnel à son effectif) ; à intervalle régulier, un tirage à pile ou face seedé décide quel camp frappe en premier — chaque membre de ce camp inflige des dégâts aléatoires (1-10, parfois critiques ×3) à l'équipe adverse (purpose = "round-<n>-battle-tick-<t>") — puis, seulement s'il y a survécu, l'autre camp riposte à son tour de la même façon : cette résolution séquentielle rend une égalité parfaite (les deux équipes à 0 PV sur le même tick) mathématiquement impossible. Chance de critique élevée (18 %) sur les deux premiers ticks d'un round, normale (5 %) ensuite, quasi nulle (0,8 %) dès qu'un camp passe sous 25 % de ses PV max. La première équipe à tomber à 0 PV est éliminée en bloc ; l'autre passe au round suivant en entier, PV pleins, avec de nouvelles équipes reformées au hasard (nouveaux noms d'équipe aussi, purpose = "round-<n>-names"). Dès qu'un split 50/50 normal risquerait de faire tomber le nombre de survivants sous le nombre de gagnants demandé, l'algorithme repêche des éliminés du/des round(s) précédent(s) pour reconstituer un pool de taille exactement 2×N, garantissant un dernier combat équilibré N vs N. Si l'effectif de départ est trop petit pour qu'un tel repêchage soit seulement possible, un mécanisme de repli à base de duels individuels prend le relais (halving puis round d'ajustement, purpose = "precise-trim") — avec un seul gagnant demandé sur un tout petit groupe, ce mécanisme se résume au duel final classique.