Sur un serveur FiveM ou RedM, le joueur passe une bonne partie de son temps à lire des informations et à cliquer dans des menus : inventaire, notifications, téléphone, banque, factures, HUD. Ces interfaces conditionnent directement l’expérience de jeu. Une interface claire se fait oublier ; une interface confuse rappelle à chaque instant qu’on est derrière un écran, et pousse les joueurs à éviter les fonctionnalités qu’elle sert.
Le design UI/UX pour FiveM et RedM a ses propres contraintes : un écran déjà chargé par le jeu, des joueurs en pleine action, des menus utilisés des centaines de fois par soirée. Voici les principes que nous appliquons pour concevoir des interfaces de serveur RP lisibles, rapides et cohérentes.
UI et UX : quelles différences ?
Les deux notions sont souvent confondues, alors qu’elles répondent à deux questions différentes.
- L’UI (interface utilisateur) concerne ce que l’on voit : couleurs, typographies, icônes, espacements, états des boutons, animations. Elle répond à la question « est-ce lisible et agréable ? ».
- L’UX (expérience utilisateur) concerne ce que l’on fait : le nombre d’étapes pour accomplir une action, l’ordre des informations, les retours après un clic, la façon dont on se repère. Elle répond à la question « est-ce que j’arrive à faire ce que je veux, vite et sans erreur ? ».
Une belle interface peut être pénible à utiliser, et une interface très efficace peut être visuellement austère. L’objectif est de réunir les deux : une ergonomie pensée pour le gameplay, servie par une identité visuelle cohérente avec l’univers du serveur.
Les erreurs fréquentes dans les interfaces de serveurs RP
Certaines erreurs reviennent sur la plupart des serveurs, quel que soit le framework.
- Des interfaces trop chargées. Tout afficher en même temps oblige le joueur à chercher. Une information secondaire peut attendre un clic ou un survol.
- Une mauvaise hiérarchie visuelle. Si le titre, le prix et le bouton d’action ont la même taille et la même couleur, l’œil ne sait pas où se poser. L’élément le plus important doit se voir en premier.
- Des informations difficiles à lire. Texte trop petit, contraste insuffisant sur fond semi-transparent, police fantaisie illisible en petite taille : le décor du jeu change sans cesse derrière l’interface, il faut donc prévoir un fond suffisamment opaque.
- Une navigation peu intuitive. Des menus imbriqués sur quatre niveaux, une touche différente pour fermer chaque fenêtre, pas de retour en arrière : le joueur se perd.
- Des menus incohérents entre eux. Un inventaire d’un style, une banque d’un autre, des notifications d’un troisième. Le serveur paraît alors assemblé de pièces détachées, même si chaque ressource est réussie isolément.
- Des interfaces qui prennent trop de place. Un HUD qui masque le centre de l’écran ou une notification qui recouvre la minicarte gênent le jeu lui-même.
Concevoir une interface adaptée au gameplay
Une interface de jeu ne se conçoit pas comme une page web. Elle s’affiche par-dessus une scène en mouvement, souvent pendant une action.
Respecter le champ de vision. Le centre de l’écran appartient au jeu. Les éléments permanents (jauges, argent, notifications) se placent sur les bords, de préférence dans des zones constantes que le joueur apprend à regarder sans y penser.
Distinguer le permanent de l’occasionnel. Un HUD doit être discret et rester lisible d’un coup d’œil ; un menu ouvert volontairement peut occuper davantage d’espace, puisque le joueur s’y consacre.
Adapter l’interaction au contexte. Un menu qui s’ouvre en courant doit pouvoir se manipuler au clavier ou se refermer instantanément. Un menu de gestion, consulté à l’arrêt, peut proposer une navigation plus riche à la souris.
Donner un retour à chaque action. Un clic sur « Acheter » doit produire une réponse visible : confirmation, message d’erreur explicite, mise à jour du solde. Sans retour, le joueur clique deux fois et achète deux fois.
Respecter l’univers. Sur RedM, une interface en verre néon détonne en 1899 ; sur un serveur FiveM futuriste, un parchemin paraît déplacé. La direction artistique doit servir la cohérence visuelle du serveur, sans sacrifier la lisibilité.
Les bonnes pratiques pour développer une NUI
Sur FiveM et RedM, les interfaces sont des NUI : des pages web (HTML, CSS, JavaScript) affichées par un navigateur Chromium intégré au client du jeu. Une ressource déclare sa page dans son manifeste, puis le script client et l’interface communiquent par messages.
-- fxmanifest.lua
ui_page 'html/index.html'
files {
'html/index.html',
'html/style.css',
'html/app.js',
}HTML et CSS
Gardez une structure simple et sémantique : des boutons pour les actions, des listes pour les listes, des titres pour les titres. Côté CSS, pensez aux différentes résolutions : une interface calibrée en pixels fixes pour un écran 1080p devient minuscule en 1440p ou en 4K. Des unités relatives (rem, vh, clamp()) et une taille de base qui suit la résolution évitent la plupart des surprises.
JavaScript et communication avec le client du jeu
Le script client envoie des données à l’interface avec SendNUIMessage, et l’interface les reçoit comme un événement message du navigateur. Dans l’autre sens, l’interface appelle une fonction enregistrée côté client avec RegisterNUICallback, en envoyant une requête fetch vers l’adresse de la ressource.
-- client.lua
RegisterCommand('menu', function()
SetNuiFocus(true, true) -- clavier et souris vers l'interface
SendNUIMessage({ action = 'open', title = 'Inventaire' })
end)
RegisterNUICallback('close', function(data, cb)
SetNuiFocus(false, false)
cb({ ok = true })
end)// html/app.js
window.addEventListener('message', (event) => {
if (event.data.action === 'open') openMenu(event.data.title);
});
function closeMenu() {
fetch(`https://${GetParentResourceName()}/close`, {
method: 'POST',
headers: { 'Content-Type': 'application/json; charset=UTF-8' },
body: JSON.stringify({}),
});
}Gestion des événements
Centralisez la réception des messages dans un seul écouteur qui aiguille selon le type d’action, plutôt que de multiplier les écouteurs. Pensez aussi à la sortie : la touche Échap doit toujours fermer l’interface et rendre le contrôle au jeu, sinon le joueur reste bloqué avec le curseur à l’écran.
Optimisation
Une NUI qui reste affichée tourne en permanence. Évitez les animations infinies, les ombres et flous coûteux sur de grandes surfaces, et les mises à jour trop fréquentes : un HUD n’a pas besoin d’être rafraîchi soixante fois par seconde pour afficher une jauge de faim. Côté Lua, n’envoyez un message que lorsqu’une valeur change réellement, et masquez entièrement les interfaces fermées.
Accessibilité
Un contraste suffisant entre le texte et le fond, des tailles de texte confortables, des couleurs qui ne portent jamais seules une information (ajoutez une icône ou un libellé pour les daltoniens) et la possibilité de naviguer au clavier profitent à tous les joueurs, pas seulement à ceux qui en ont besoin. Les règles WCAG donnent de bons repères, même si elles visent le web.
L’importance d’un design system
Un design system est un ensemble de règles et de composants partagés : une palette de couleurs, une échelle de typographies, des espacements, des styles de boutons, de champs, de cartes et de notifications. Sur un serveur RP, il répond directement au problème des menus incohérents.
Concrètement, cela signifie que l’inventaire, la banque et le téléphone utilisent les mêmes couleurs pour les mêmes rôles (action, danger, succès), les mêmes boutons et la même typographie. Le joueur apprend une fois comment fonctionne l’interface, puis il retrouve ses repères partout. Pour l’équipe de développement, c’est aussi un gain de temps : un nouveau menu se construit à partir de composants existants au lieu de repartir de zéro.
Techniquement, un design system se traduit souvent par des variables CSS communes (couleurs, tailles, rayons, ombres) et une bibliothèque de composants réutilisés d’une ressource à l’autre. C’est l’approche que nous suivons sur nos propres ressources : côté FiveM, le HUD, les notifications et l’inventaire du Pack Essentiels partagent les mêmes composants ; côté RedM, KS-Notify RedM et KS-Target RedM suivent la même logique.
Les interfaces de gestion et dashboards
Les interfaces ne servent pas qu’aux joueurs. Trois publics ont des besoins de gestion très différents :
- Les administrateurs ont besoin d’aller vite : rechercher un joueur, consulter son historique, appliquer une sanction, se téléporter, gérer les entités. Les actions fréquentes doivent être à un clic, les actions dangereuses protégées par une confirmation. C’est la logique de KS-Admin RedM.
- Les entreprises du serveur (ranchs, saloons, commerces, services publics) ont besoin de suivre leurs comptes, leurs employés, leurs stocks et leurs factures sans quitter le jeu. Un tableau de bord lisible, avec les chiffres clés en haut et le détail en dessous, évite de transformer la gestion en corvée.
- Les équipes de développement ont besoin d’outils de diagnostic : journaux, états des ressources, configuration en jeu.
Dans tous les cas, un dashboard réussi hiérarchise l’information : ce qui demande une action d’abord, les indicateurs ensuite, les détails à la demande.
Concevoir une interface personnalisée
Les interfaces génériques ont un avantage évident : elles sont disponibles tout de suite. Leur limite apparaît vite sur un serveur qui a une identité forte : elles ne parlent pas le même langage visuel que le reste, n’affichent pas les informations propres à votre gameplay et obligent parfois à contourner leur logique.
Une interface personnalisée part de vos besoins réels : quelles informations vos joueurs consultent le plus, quelles actions ils répètent, quelle ambiance vous voulez installer. Elle s’intègre à votre design system, respecte votre époque et votre ton, et peut évoluer avec le serveur. C’est un investissement plus important au départ, qui se rentabilise par la cohérence de l’ensemble et par le temps gagné par les joueurs à chaque utilisation.
Questions fréquentes
Quelle est la différence entre une NUI et une interface native du jeu ?
Une interface native utilise les menus et éléments d’affichage du jeu lui-même, avec un style imposé. Une NUI est une page web affichée par-dessus le jeu : elle offre une liberté totale de design et d’interaction, au prix d’une attention particulière aux performances.
Quels langages faut-il connaître pour développer une interface FiveM ou RedM ?
HTML, CSS et JavaScript pour l’interface elle-même, et Lua (ou un autre langage pris en charge par FXServer) pour le script client qui l’ouvre, lui envoie des données et reçoit ses actions. Certaines équipes utilisent un framework JavaScript comme React ou Vue, compilé avant d’être intégré à la ressource.
Une interface peut-elle faire baisser les FPS ?
Oui. Une NUI mal optimisée, avec des animations permanentes, de nombreux effets de flou ou des mises à jour trop fréquentes, consomme des ressources côté client. Une interface bien conçue reste légère, surtout lorsqu’elle est fermée.
Comment garder une interface lisible sur toutes les résolutions ?
En utilisant des unités relatives plutôt que des pixels fixes, une taille de base qui suit la résolution de l’écran et en testant au minimum en 1080p, 1440p et 4K, ainsi qu’avec une interface du jeu agrandie ou réduite.
Les interfaces RedM se conçoivent-elles comme celles de FiveM ?
Techniquement, oui : le principe des NUI est le même. La différence est surtout artistique : l’univers de 1899 appelle d’autres matières, d’autres typographies et d’autres codes visuels qu’un serveur GTA RP contemporain.
En résumé
Une bonne interface de serveur RP est d’abord lisible, rapide et cohérente ; son apparence vient servir ces qualités. Hiérarchiser l’information, respecter le champ de vision, donner un retour à chaque action, s’appuyer sur un design system et soigner les performances de la NUI : ces principes valent autant pour FiveM que pour RedM.
La conception d’interfaces fait partie de notre cœur de métier, au même titre que le développement de scripts et la 3D. Vous pouvez découvrir notre approche sur la page du studio, parcourir nos scripts FiveM et nos scripts RedM, ou lire notre guide pour créer un serveur RedM RP.
