Aller au contenu
Forma Roblox

Rechercher dans la formation

Module 08 · Leçon 4 sur 5

Mises à jour et événements

Trouve un rythme de mises à jour tenable, publie sans casser les sauvegardes, redémarre les serveurs proprement et organise des événements avec les outils officiels.

  • ⏱️ 35 min
  • 📝 Quiz de 6 questions
  • 🔄 Vérifié le 24 octobre 2026
Sur cette page

🎯 Dans cette leçon, tu vas apprendre à…

  • Établir un rythme de mises à jour réaliste et tenable
  • Publier une mise à jour sans casser les sauvegardes ni surprendre les joueurs
  • Redémarrer les serveurs et prévenir les joueurs avec ServerRestartScheduled
  • Créer un événement limité dans le temps avec l’outil Events du Creator Hub

Un jeu Roblox n’est jamais vraiment « fini ». Après le lancement, les mises à jour donnent aux joueurs des raisons de revenir et te permettent de corriger ce que les statistiques révèlent. Mais une mise à jour mal préparée peut aussi casser les sauvegardes ou couper la partie de tout le monde au mauvais moment. Dans cette leçon, on organise les mises à jour de l’Obby des Nuages et son premier événement.

Pourquoi continuer à mettre à jour

Roblox appelle LiveOps (opérations en direct) le suivi d’un jeu après sa sortie. Sa documentation de game design le découpe en quatre types de mises à jour :

  • un rythme de contenu (content cadence) : des ajouts réguliers et simples qui réutilisent les systèmes existants (nouvelles étapes, nouvelles traînées) ;
  • des grosses mises à jour : de nouveaux systèmes (classement, mode course…) ;
  • des améliorations de confort (quality of life) : interface plus claire, performances, accessibilité ;
  • des corrections de bugs.

La documentation sur la découverte cite d’ailleurs « ce que tu fais » (mises à jour, changements de gameplay) parmi les facteurs qui influencent les recommandations. Une mise à jour ne garantit pas plus de joueurs, mais un jeu abandonné finit par lasser même ses fans.

Un rythme réaliste

D’après la documentation de Roblox sur les mises à jour de contenu :

  • beaucoup de jeux publient du contenu toutes les deux semaines à un mois ;
  • elle recommande de consacrer moins de trois semaines de travail à chaque mise à jour de ce type, pour garder un rythme régulier ;
  • le bon rythme dépend de tes capacités : il doit rester tenable dans la durée.

Pour un créateur seul qui débute, un rythme comme celui-ci est plus réaliste qu’une mise à jour par semaine :

Quand Quoi Exemple pour l’Obby des Nuages
Chaque semaine (si besoin) Corrections de bugs Un checkpoint qui ne s’active pas
Environ chaque mois Contenu 5 nouvelles étapes, 2 nouvelles traînées
Quelques fois par an Événement ou grosse nouveauté Événement « Ciel d’automne », mode chrono

Publier sans casser les sauvegardes

La pire mise à jour, c’est celle qui fait perdre leur progression aux joueurs. Trois règles, en lien avec ce que tu as fait au module 5 :

  1. Ne renomme jamais une clé de sauvegarde ni le DataStore (DonneesJoueurs_v1) : les anciennes données deviendraient introuvables.
  2. Ajoute des champs, avec une valeur par défaut pour les anciens joueurs.
  3. Teste la mise à jour dans Studio avec un compte qui a déjà une ancienne sauvegarde.

Bonne nouvelle : tu as déjà tout ce qu’il faut. Au module 5, le ModuleScript DonneesJoueurs contient donneesParDefaut() (la structure d’une sauvegarde neuve) et completer(), qui remplit les champs absents d’une ancienne sauvegarde à chaque chargement. Pour ajouter un champ, deux gestes suffisent : l’ajouter dans donneesParDefaut() et augmenter VERSION_DONNEES d’une unité (tu l’as déjà fait au module 7 avec le champ achats).

completer remplit alors le nouveau champ des anciennes sauvegardes et met leur version à jour. Grâce au test sur ancienne.version dans Sauvegarder (module 5), un serveur qui fait encore tourner l’ancienne version du jeu refusera ensuite d’écraser ces données plus récentes.

-- Extrait du ModuleScript « DonneesJoueurs » (ServerScriptService), écrit au module 5
-- On augmente ce numéro à chaque nouveau champ : 1 au module 5, 2 au module 7 (achats), 3 ici
local VERSION_DONNEES = 3

-- Structure d'une sauvegarde toute neuve : on y AJOUTE les nouveaux champs
local function donneesParDefaut(): { [string]: any }
	return {
		version = VERSION_DONNEES,
		etape = 0,
		pieces = 0,
		inventaire = {},
		equipe = "",
		achats = {}, -- ajouté au module 7
		-- Ajouté dans la mise à jour « Zone des Orages » :
		zoneOragesDebloquee = false,
	}
end

-- Inchangée depuis le module 5 : complète une ancienne sauvegarde
local function completer(donnees: { [string]: any }): { [string]: any }
	for cle, valeurParDefaut in donneesParDefaut() do
		if donnees[cle] == nil then
			donnees[cle] = valeurParDefaut
		end
	end
	-- La sauvegarde a maintenant la structure actuelle : on met à jour son
	-- numéro de version (sans jamais baisser celui d'une sauvegarde plus récente)
	if donnees.version < VERSION_DONNEES then
		donnees.version = VERSION_DONNEES
	end
	return donnees
end

-- Exemple : une sauvegarde d'avant la mise à jour (et d'avant le module 7)
local ancienneSauvegarde = {
	version = 1,
	etape = 12,
	pieces = 340,
	inventaire = { TrailNuage = true },
	equipe = "TrailNuage",
}
local donnees = completer(ancienneSauvegarde)
print(donnees.zoneOragesDebloquee) --> false : le nouveau champ existe maintenant
print(donnees.etape) --> 12 : la progression est conservée
print(donnees.version) --> 3 : la sauvegarde porte maintenant le numéro actuel

Comme donneesParDefaut() fabrique une nouvelle table à chaque appel, chaque joueur reçoit sa propre copie des tables par défaut (comme inventaire) : aucun risque que deux joueurs partagent le même inventaire.

Redémarrer les serveurs

Ce qui se passe quand tu publies

D’après la documentation officielle, publier une nouvelle version ne déplace pas les joueurs déjà en jeu. Les serveurs ouverts continuent avec l’ancienne version, et les joueurs passent à la nouvelle au fur et à mesure que ces serveurs se vident. C’est sans risque, mais des joueurs peuvent rester longtemps sur des versions différentes. La documentation conseille de redémarrer les serveurs si le format des données sauvegardées change.

Le bouton « Restart Servers »

Au moment de la rédaction, sur le Creator Dashboard : ouvre ton jeu, puis Configurations › Server management, sélectionne les lieux, et clique sur Restart Servers. Deux options sont proposées :

  • Restart only servers with outdated versions : ne redémarre que les serveurs qui font tourner une ancienne version. La documentation recommande de la cocher presque toujours.
  • Delay server restart : laisse aux joueurs un délai de 1 à 60 minutes avant la fermeture, pour qu’ils puissent finir ce qu’ils font.

Ensuite, Roblox arrête d’envoyer vers ces serveurs les joueurs qui cliquent sur Jouer (ils restent joignables par invitation, téléportation ou profil d’un ami), attend le délai choisi, puis téléporte automatiquement les joueurs vers un serveur à jour. Les joueurs d’un même serveur arrivent ensemble sur le même nouveau serveur.

Prévenir les joueurs avec ServerRestartScheduled

Quand tu lances un redémarrage avec délai, l’événement game.ServerRestartScheduled se déclenche sur les serveurs concernés. Il transmet :

  • restartTime : un DateTime (un objet qui représente une date et une heure), le moment le plus tôt où le serveur peut s’arrêter ;
  • source : Enum.CloseReason.DeveloperUpdate pour tes mises à jour, ou Enum.CloseReason.RobloxMaintenance quand Roblox fait de la maintenance ;
  • attributes : une table d’informations facultatives (vide si aucune).

On s’en sert pour afficher un compte à rebours aux joueurs. Crée d’abord un RemoteEvent nommé AnnonceRedemarrage dans ReplicatedStorage.Remotes (avec Rojo, il se déclare dans default.project.json, comme les autres RemoteEvents). Les deux scripts ci-dessous correspondent aux fichiers src/ServerScriptService/Redemarrage.server.luau et src/StarterPlayer/StarterPlayerScripts/AffichageRedemarrage.client.luau : tu peux les demander à Claude Code avec le prompt de l’encadré qui suit, puis les relire avec les explications de cette section.

-- Script « Redemarrage » (côté serveur) à placer dans ServerScriptService
-- Prévient tous les joueurs quand un redémarrage est programmé
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local remotes = ReplicatedStorage:WaitForChild("Remotes")
local annonceRedemarrage = remotes:WaitForChild("AnnonceRedemarrage") :: RemoteEvent

game.ServerRestartScheduled:Connect(function(restartTime, source)
	-- restartTime est un DateTime : on compare des secondes « Unix »
	local secondesRestantes = restartTime.UnixTimestamp - DateTime.now().UnixTimestamp
	secondesRestantes = math.max(0, secondesRestantes)
	local minutes = math.ceil(secondesRestantes / 60)

	local message
	if source == Enum.CloseReason.DeveloperUpdate then
		message = "Nouvelle version de l'Obby des Nuages ! Le serveur redémarre dans "
			.. minutes .. " min. Ta progression est sauvegardée."
	else
		message = "Maintenance de Roblox : le serveur redémarre dans " .. minutes .. " min."
	end

	-- On envoie le message à tous les joueurs présents sur ce serveur
	annonceRedemarrage:FireAllClients(message)
end)
-- LocalScript « AffichageRedemarrage » (côté client) à placer dans StarterPlayer > StarterPlayerScripts
-- Affiche l'annonce de redémarrage dans une notification Roblox
local ReplicatedStorage = game:GetService("ReplicatedStorage")
local StarterGui = game:GetService("StarterGui")

local remotes = ReplicatedStorage:WaitForChild("Remotes")
local annonceRedemarrage = remotes:WaitForChild("AnnonceRedemarrage") :: RemoteEvent

annonceRedemarrage.OnClientEvent:Connect(function(message: string)
	-- SetCore peut échouer si l'interface Roblox n'est pas encore prête : on protège l'appel
	local ok, erreur = pcall(function()
		StarterGui:SetCore("SendNotification", {
			Title = "Mise à jour",
			Text = message,
			Duration = 15,
		})
	end)
	if not ok then
		warn("Notification impossible : " .. tostring(erreur))
	end
end)

Communiquer les nouveautés

Une mise à jour que personne ne remarque ne sert pas à grand-chose. Plusieurs canaux existent :

  • La description du jeu : une courte ligne « Nouveautés » en haut (leçon 1), qui ne repousse pas trop bas le reste.
  • En jeu : un panneau ou un message au spawn qui présente la nouveauté.
  • Les annonces de mise à jour (update announcements), dans Engagement › Events & Updates au moment de la rédaction : elles arrivent dans les notifications Roblox des joueurs qui ont activé les notifications de ton jeu. Elles sont limitées à 60 caractères et à une tous les trois jours. La documentation conseille d’être précis (« Nouvelle Zone des Orages : 5 étapes ! » plutôt que « Corrections de bugs »).
  • Ta communauté (leçon 5).

Les notifications d’expérience, que ton jeu envoie lui-même aux joueurs qui les ont acceptées, sont abordées au module 6 (Donner envie de revenir). Retiens juste que leurs règles d’usage interdisent les notifications publicitaires déguisées et la fausse urgence.

Organiser un événement

Pourquoi des événements

La documentation de Roblox décrit le contenu à durée limitée comme un bon moyen de relancer l’intérêt : des objectifs à accomplir ou des objets à gagner pendant une période donnée. Pour l’Obby des Nuages, un événement « Ciel d’automne » pourrait proposer pendant deux semaines une étape spéciale et une traînée orange à débloquer.

L’outil Events du Creator Hub

Au moment de la rédaction, les événements se créent dans Engagement › Events & Updates, bouton Create Event or Update. Tu y définis :

  • une miniature propre à l’événement (la documentation conseille qu’elle soit différente de celles du jeu) ;
  • une catégorie, un titre, un sous-titre et une description facultative ;
  • les dates de début et de fin ;
  • le lieu où arrivent les joueurs qui rejoignent l’événement ;
  • la visibilité : privé pendant la préparation, public quand tu es prêt à le promouvoir.

Tu peux publier au maximum 10 événements en cours ou à venir. Une fois public, l’événement apparaît :

  • dans une section Events de la page du jeu, avec un bouton Join Event (pendant l’événement) ou Notify Me (avant) ;
  • sur une page dédiée que tu peux partager ;
  • dans l’onglet Events de ta communauté, si le jeu appartient à une communauté.

Les joueurs qui cliquent sur Notify Me reçoivent une notification au début de l’événement.

Les vitrines supplémentaires

  • La liste Trending Events in Experiences de la page Charts met en avant des événements actifs. Au moment de la rédaction, il faut notamment un événement public, commencé depuis moins de 7 jours, avec au moins 1 000 inscriptions (RSVPs).
  • Le programme Off-Platform Featuring permet de proposer un événement pour être mis en avant hors de Roblox (magasins d’applications, canaux marketing de Roblox). Il faut avoir au moins 13 ans et une adresse e-mail liée au compte, soumettre l’événement (option Submit for Featuring) au moins 7 jours avant son début, et c’est Roblox qui sélectionne, sans garantie.

Pour un premier jeu, ces vitrines sont difficiles à atteindre : concentre-toi sur un événement simple, bien annoncé à tes joueurs actuels.

Ce qu’il faut retenir

  • Choisis un rythme tenable : corrections quand il faut, contenu environ chaque mois, événements de temps en temps.
  • Ne renomme jamais tes clés de sauvegarde ; complète les anciennes données avec des valeurs par défaut.
  • Publier ne déplace pas les joueurs : Restart Servers (avec « outdated versions » et un délai) les envoie vers la nouvelle version.
  • game.ServerRestartScheduled permet d’afficher un compte à rebours avant un redémarrage programmé.
  • L’outil Events & Updates crée des événements visibles sur la page du jeu, avec notifications pour les joueurs inscrits ; évite toute fausse urgence.

Sources et pour aller plus loin

Quiz : vérifie tes acquis

6 questions · réussite à partir de 70 % · valide chaque réponse pour voir l’explication

  1. Question 1Vrai ou fauxQuand tu publies une nouvelle version, tous les joueurs passent immédiatement sur cette version.
  2. Question 2QCMPourquoi cocher Restart only servers with outdated versions lors d’un redémarrage ?
  3. Question 3QCMTu ajoutes un champ zoneOragesDebloquee aux données sauvegardées. Que faut-il faire pour les anciens joueurs ?
  4. Question 4QCMQue dit la documentation sur les annonces de mise à jour (*update announcements*) au moment de la rédaction ?
  5. Question 5Trouve le bugCe Script serveur doit prévenir les joueurs du nombre de secondes avant un redémarrage. Où est le bug ?
    local ReplicatedStorage = game:GetService("ReplicatedStorage")
    local annonce = ReplicatedStorage.Remotes.AnnonceRedemarrage
    
    game.ServerRestartScheduled:Connect(function(restartTime, source)
    	local secondes = restartTime - os.time()
    	annonce:FireAllClients("Redémarrage dans " .. secondes .. " s", secondes)
    end)
  6. Question 6Améliore ce promptTu veux que Claude Code prévienne les joueurs avant un redémarrage des serveurs. Quelle version du prompt est la meilleure ?
    Le prompt de départ
    préviens les joueurs avant un redémarrage

    Choisis la meilleure version de ce prompt.