CONNEXION
  • RetourJeux
    • Tests
    • Soluces
    • Previews
    • Sorties
    • Hit Parade
    • Les + attendus
    • Tous les Jeux
  • RetourActu
    • Culture Geek
    • Astuces
    • Réalité Virtuelle
    • Rétrogaming
    • Toutes les actus
  • RetourHigh-Tech
    • Actus JVTECH
    • Bons plans
    • Tutoriels
    • Tests produits High-Tech
    • Guides d'achat High-Tech
    • JVTECH
  • RetourVidéos
    • A la une
    • Gaming Live
    • Vidéos Tests
    • Vidéos Previews
    • Gameplay
    • Trailers
    • Chroniques
    • Replay Web TV
    • Toutes les vidéos
  • RetourForums
    • Hardware PC
    • PS5
    • Switch
    • Xbox Series
    • Overwatch 2
    • FUT 23
    • League of Legends
    • Genshin Impact
    • Tous les Forums
  • PC
  • PS5
  • Xbox Series
  • PS4
  • One
  • Switch
  • Wii U
  • iOS
  • Android
  • MMO
  • RPG
  • FPS
En ce moment Genshin Impact Valhalla Breath of the wild Animal Crossing GTA 5 Red dead 2
Etoile Abonnement RSS

Sujet : Besoin de conseils pour création d'un jeu UNITY 3D

DébutPage précedente
1
Page suivantePage suivante
NemezysGamer NemezysGamer
MP
Niveau 1
03 août 2022 à 14:43:46

Bonjour à toutes et tous,

Merci infiniment à ceux et celles qui prendront la peine de lire le pavé qui va suivre jusqu'à la fin.

Je me présente brièvement:
Cela fait presque 15 ans que je réfléchis à la création d'un jeu vidéo multijoueur (suis un gamer passionné depuis tout petit, j'ai 38 ans) de type "Art of conquest", "Ogame", "Vikings: War of Clans" etc... avec bien évidemment pas mal de différences de gameplay mais l'idée de base est là.
Je ne souhaite pas faire un jeu par navigateur mais une véritable application (avec un exécutable) et dans ce but je me suis spécialisé dans le domaine informatique en commençant par le technicien informatique il y a 10 ans, puis je suis devenu développeur web full stack il y a 5 ans et aujourd'hui je me forme à UNITY 3D.

J'ai passé beaucoup de temps sur pas mal de forums à lire les expériences des uns et des autres sur la création de jeu et la majorité s'accordent à dire que faire connaitre un jeu est plus simple et abordable sur PC que sur mobile.
Je visais (à la base) un jeu mobile (car tout le monde a un smartphone) en pensant ne pas viser trop haut pour mon premier jeu publié mais ce que j'ai lu me fait penser que je suis peut-être dans l'erreur.
Cela dit, si je développe pour PC/MAC le jeu ne sera pas du tout le même (beaucoup plus beau et plus complet car plus de ressources matérielles) et prendra bien plus de temps à développer (ce qui ne me pose pas de problème en soi)

Je suis vraiment à l'aise avec UNITY et le côté "programmation" est vraiment très simpliste à réaliser pour moi, J'avais prévu (à la base aussi) un petit crowdfunding pour financer une éventuelle com et peut-être aussi la fin du développement (le côté graphismes qui serait long tout seul).

--- 1 Sachant ceci, ma première interrogation est la suivante:
Selon vous, vaut-il mieux partir sur un développement PC/MAC avec de moindres coûts quitte à démarrer lentement et plus tard (comme la majorité, j'en suis conscient) ou alors, se lancer avec un peu de moyens sur mobile directement ? (je compte, de toutes façons sortir le jeu PC/MAC mais je ne sais pas si je commence par CE projet là, je suis un débutant dans le développement du jeu vidéo même si j'ai de l'expérience en programmation).

En tant que développeur web, j'ai fais plusieurs essais de création de jeu "pour me faire la main" mais la technologie web ne me convient pas vraiment (passer par des Sockets, la 3D, les animations etc...) pour ce que je veux réaliser.

De ce fait, me voilà sur UNITY aujourd'hui pour enfin commencer la réalisation de mon projet mais un problème (où plutôt "interrogation") apparait avec cet outil génial qu'est UNITY.

--- 2 La structure des données
En tant que développeur web je maîtrise les base SQL, les API et le JSON, les "PlayerPrefs" de UNITY ne suffiront pas du tout au vu de la quantité de données qu'il y aura à stocker, cependant malgré tous les tutos et cours que j'ai fait sur la gestion des données avec UNITY, j'ai un véritable penchant pour la base SQL mais je n'ai pas réussis à trancher cette question essentielle et j'aimerais avoir votre avis là dessus (stockage en base, via API ou en local).

Merci d'avance pour vos réponses et pour avoir lu jusqu'ici, désolé pour le côté un peu exhaustif mais c'est vraiment important comme décisions alors j'expose la situation telle qu'elle est.

Albundy1 Albundy1
MP
Niveau 6
04 août 2022 à 13:12:11

--- 1 Sachant ceci, ma première interrogation est la suivante:

Selon vous, vaut-il mieux partir sur un développement PC/MAC avec de moindres coûts quitte à démarrer lentement et plus tard (comme la majorité, j'en suis conscient) ou alors, se lancer avec un peu de moyens sur mobile directement ? (je compte, de toutes façons sortir le jeu PC/MAC mais je ne sais pas si je commence par CE projet là, je suis un débutant dans le développement du jeu vidéo même si j'ai de l'expérience en programmation).

->quitte à démarrer lentement et plus tard

C'est plutôt juste mais je sais pas si sur portable c'est beaucoup mieux par contre, il n'y a pas de recette miracle faut croire :(

--- 2 La structure des données

Les PlayerPrefs me suffisent donc malheureusement je ne pourrais pas t'aider sur le coup.

Lapintade Lapintade
MP
Niveau 17
04 août 2022 à 23:15:00

Salut.
Je pense que le choix PC/mobile est pas forcement pertinant dans un premier temps. Dans ton cas, ce qui va etre compliqué c'est de produire ton jeu (c'est a dire de faire toute la creation des données...).
Tu as l'air d'avoir deja compris, mais aussi bien sur mobile que sur PC, la visibilité c'est important. Tu va passer beaucoup de temps et beaucoup d'argent pour créer ton jeu, mais au final il ne sera pas visible, et peu de joueurs l'acheteront. Il faut aujorud'hui prevoir presque autant de budget pour le faire connaitre.
Il y a aussi un gros facteur chance ensuite. Meme un excellent jeu, trés bien marketté, peu ne pas se vendre.
Y a pas trop de recette miracle (sinon on serait tous riches lol).
Si tu sais tu ca, tu sera encore mieux preparé pour te lancer.

NemezysGamer NemezysGamer
MP
Niveau 1
05 août 2022 à 08:38:38

Bonjour et merci pour vos réponses,
Je suis bien conscient qu'il n'existe pas de solution "magique" et qu'il n'y a presque que le travail qui importe (malgré une chance potentielle mais je n'ai jamais eu de chance donc je ne compte pas du tout dessus) mais , de base, je m'étais dit que le développement sur mobile serait plus simple que celui pour PC car moins de données, jeu plus léger et donc plus simple et "rapide" à développer pour un débutant dans le jeu vidéo.
Ce que tu me dis LaPintade, c'est ce que j'avais envisagé (prévoir un budget pour la com quoi qu'il arrive) et je suis assez d'accord avec toi, les seuls sites gratuits de développement de jeu ne suffiront pas pour la promotion de celui-ci.

Pour ce qui est de la difficulté de développement, pour avoir créé mes 3 premiers jeux sous UNITY, une chose est sûre, ce sera long, mais en revanche c'est vraiment un jeu d'enfant à coder.
Le seul véritable problème qui s'oppose à moi de ce côté là c'est la structure des données (API ou SQL, j'ai laisser tombé le stockage en local après réflexion ).
Quel est le plus rapide d’exécution et le plus "sécurisé" (pour moi c'est SQL pour la sécurité mais je ne suis pas du tout un pro de la cyber-sécurité) ?

T3rry T3rry
MP
Niveau 10
06 août 2022 à 18:25:33

Qu'est-ce que tu entends par API ? Parce qu'une api c'est juste une interface qui permet de communiquer entre un back-end et un front-end, T'as quand même besoin de SQL ou alternative pour pouvoir faire ton API

Sinon oui le sql c'est pas une mauvaise idée selon moi, si c'est autant utilisé dans le web c'est pas pour rien, c'est que ça fait le taff niveau sécurité

Après qu'est-ce qui pose réellement problème dans le fait de stocké localement ? C'est plus rapide et y'a pas besoin d'accès à internet

ThetaTauTau ThetaTauTau
MP
Niveau 8
06 août 2022 à 22:26:58

Pour un jeu dans le style des MMO par navigateur, commence par réfléchir à comment gérer le serveur.

Les jeux classique style ogame, travian etc. utilisent les technologies web (serveur php), tu es dévellopeur web full stack. Il semble donc indiqué d'utiliser un serveur web classique avec Unity comme client à la place du navigateur. Pas forcément en php par contre, node est probablement plus adapté en 2022, ou alors un truc en C# pour pouvoir réutiliser le même code que pour le client. Mais bon à priori tu t'y connais plus que moi là dessus...

NemezysGamer NemezysGamer
MP
Niveau 1
08 août 2022 à 14:22:39

Merci pour vos réponses!
1- T3rry:
Une API est une interface de communication entre 2 applications en effet, mais ça peut aussi être tout simplement un fichier JSON hébergé en ligne sur lequel on se connecte pour exploiter ce dit fichier. (exemple: pour créer un site de location de vélib à Lyon, il suffit de se connecter à l'API qui stocke ces data et à l'exploiter avec du JS (ou autre, c'est un fichier JSON qui est retourné donc tout langage pouvant exploiter le JSON) pour savoir s'il reste des vélibs disponibles).

Avec UNITY, je peux héberger une API sur un site privé et l'appeler et l'exploiter au même titre qu'une base SQL, mais comme tu l'as bien fait remarqué, le SQL est sécurisé par l'hébergeur alors qu'un site privé devra être sécurisé par nos soins... Ce que je trouve risqué.

Pour le stockage en local, ce qui me pose problème c'est les MAJ du jeu.... ça me parait plus complexe et lourd de coder une modif sur chaque client que de mettre ma base à jour. Ce sera du MMO donc modifier 1 seul fichier SQL me parait plus simple et plus efficace mais je me trompe peut-être.

2- ThetaTauTau:

Avec UNITY le serveur web sera géré par PHOTON (module de UNITY) et la configuration de celui-ci se fait en C# dans l'éditeur de jeu directement (ça c'est OK pour le moment).
La communication entre les data et le jeu c'est plutôt simple avec UNITY (rien à voir avec du PHP), c'est surtout la structure des ces dites data qui me pose des interrogations.

J'étais parti sur l'idée de stocker en local les infos profil (pseudo, avatar, mail etc...) et le reste (tout ce qui est données du jeu: nbr d'unités, ressources, combats etc...) en base. Mon collaborateur m'a suggéré d'en faire aussi une partie en API pour les données les moins sensibles, du coup, je m'interroge sur la pertinence d'un tel boulot (coder et sécuriser un site, sans parler de devoir mettre à jour plusieurs bases sur plusieurs supports différents) dans cette situation.
Plus j'y réfléchis et plus je me dit que de tout mettre en base SQL serait le plus simple mais avec autant de choses en base, quelle va être la performance de la communication? Bref, j'y suis presque mais je patauge encore un peu sur ce point.

Selon vous, quelle serait la structure la plus adaptée?
Et encore merci! ^^

ThetaTauTau ThetaTauTau
MP
Niveau 8
08 août 2022 à 21:36:02

Si le gameplay que tu envisage se rapproche des mmo par navigateur classiques, il n'y a pas de soucis de performance particulier avec une basse de données SQL, parce que les données ne sont pas mis à jour si souvent que ça.

Par exemple dans le cas de la production de ressources, même si les ressources ont l'air d'augmenter en temps réél, en réalité la base de donnée n'est mise à jour que quand certains événements se produisent (achat d'unités, fin de construction d'un bâtiment, retour d'une armée etc.). Le reste du temps la quantité de ressource est inférée à partir de la quantité de ressource lors de la dernière mise à jour de la bdd, de la production et du temps écoulé.

Idem pour le déplacement d'une armée, seule la date de départ, la destination et la vitesse ont besoin d'être stocké en BDD, pas besoin de mettre à jour la position en temps réél.

Par contre si tu as des données qui changent très souvent, comme la position d'un personnage dans un RPG, là ça peux poser problème si tu enregistre tout en BDD. Cela dit Photon ou les autres trucs similaires gèrent très bien ça. Il suffit alors de sauvegarder de temps en temps en BDD.

Message édité le 08 août 2022 à 21:37:04 par ThetaTauTau
NemezysGamer NemezysGamer
MP
Niveau 1
08 août 2022 à 23:31:27

@ThetaTauTau
Bah en fait, oui, le jeu aura une partie similaire aux jeux par navigateurs (évolution de sa base, son économie avec des générateurs de ressources, ses unités...) mais il y aura aussi un gameplay très différent pour les combats car jouables et poussés avec un système de classes (heal, tank, dps, troll etc...).

Du coup, il y aura des données très variables et d'autres un peu moins (d'où mon idée ,au départ, de stocker quelques données en local), on pourrait aussi dire, des données éphémères (data des combats ou l'économie par exemple) et des données "persistantes" (technologies, évolution de la base etc...).

Je peux aussi me servir des PlayerPrefs de UNITY pour stocker quelques données (ça se fait un par un, donc, assez restreint mais utilisable).
Encore une fois j'en viens à la question de la maintenance, avoir différents types de data sur des supports différents est-il une bonne solution?

Car plus ça va et plus je me dis que ça parait incontournable d'avoir une partie en SQL, quelques PlayerPrefs et peut être même du local selon le type de données que je veux stocker (temps réel et long terme), ce qui signifie qu'à chaque MAJ il faut maintenir tous les types de bases (ça me parait bizarre en tant que développeur web mais logique à la fois au vu de la situation). Dans le domaine du jeu vidéo c'est peut être comme ça que ça se passe... (je n'ai pas vraiment trouvé d'info là dessus pour le moment, d'où ce post).

Quand j'ai fait mes tests sur navigateur, j'ai vite compris que la base ne suffirait pas et qu'il fallait du JS (oui j'aime bien JS ^^) pour éviter de saturer cette même base, ce qui signifie que je stockais pas mal de données sur le client (donc en "local") et le reste en SQL mais c'était très limité pour de multiples interactions entre joueurs (les sockets ne suffisaient pas).

J'ai utilisé la technique que tu as cité pour mettre à jour les générateurs de ressources via des événements, et ça, ce "cache"... je le stocke où sous UNITY ? Sur le client en crypté, sur le serveur PHOTON, autre part?

Message édité le 08 août 2022 à 23:32:00 par NemezysGamer
ThetaTauTau ThetaTauTau
MP
Niveau 8
09 août 2022 à 11:31:54

J'ai utilisé la technique que tu as cité pour mettre à jour les générateurs de ressources via des événements, et ça, ce "cache"... je le stocke où sous UNITY ? Sur le client en crypté, sur le serveur PHOTON, autre part?

Le client en a besoin pour mettre à jour les ressources en temps réél. Pas besoin que ce soit crypté. Faut juste faire gaffe à n'envoyer à un client que ses données et pas celles des autres joueurs.

Il faut aussi que ce soit stocké sur la BDD parce que ce sont des données critiques que tu ne veux pas perdre.

Quand à les conserver comme un objet C# dans ton serveur photon, je ne pense pas que ce soit nécessaire. Dans les jeux classiques en php rien n'est stocké en dehors de la BDD. J'avais fait un prototype avec node et je faisait pareil. Dupliquer les données semble plus plus problématique qu'autre chose.

NemezysGamer NemezysGamer
MP
Niveau 1
09 août 2022 à 12:41:56

Ok, donc si j'ai bien compris ce que tu me dis, toi, tu chargerait les données du lancement du jeu via la BDD, ensuite, pour les données "éphémères" (qui varient tout le temps) tu les gères via du local avec des sauvegardes en BDD de temps en temps via des évènements (déconnexion, constructions de bâtiments ou unités etc...).
Et ce stockage de données éphémères tu le ferais comment sous UNITY?
Création d'un fichier avec lecture/écriture (XML, JSON etc... qui du coup serait crypté par UNITY pour éviter toute modif possible de l'utilisateur)?
Pour les générateurs de ressources ça me parait un peu lourd car ça varie toutes les X secondes (3, 5 ou quelque chose comme ça je pense), du coup il faudrait stocker ça dans un sorte de "cache" qui consomme peu j'imagine...
Peut être une espèce de "DataClass" en C# ?

lokilok lokilok
MP
Niveau 10
09 août 2022 à 14:04:50

Pars du principe que tu peux absolument rien sécuriser côté client, qu'il peut tout lire et tout modifier comme il le veut. Toute la logique doit être côté serveur, le client envoie uniquement les commandes, mais c'est le serveur qui vérifie leur validité et les exécute.

J'ai pas trop compris ton truc de API vs SQL, mais ta base de données ne doit jamais être accessible via l'extérieur, il ne faut pas que les clients puissent effectuer des requêtes directement dessus, c'est une grosse faille de sécurité. Les clients envoient des requêtes à ton serveur, ton serveur vérifie la validité des requêtes et en fait à son tour à la base de données, applique des modifications si besoin puis retourne ces données au client (en gros).

Message édité le 09 août 2022 à 14:05:03 par lokilok
NemezysGamer NemezysGamer
MP
Niveau 1
09 août 2022 à 15:19:46

Je comprends et entends ce que tu dis lokilok, Unity peut Hash les données et les reconvertir ensuite mais il est vrai que si un crack connait le système de Hash en question ça pourrait poser problème.
Mais dans ce cas, si je ne peut pas mettre ces données en base et que je ne peux pas non plus les mettre sur le client, il ne me reste que le serveur pour stocker ça mais il ne peux pas gérer la base et toutes les data des clients en même temps, ça me parait beaucoup trop... Du coup, comment sont habituellement stockées ces données qui se modifient très fréquemment dans les jeux vidéos?

ThetaTauTau ThetaTauTau
MP
Niveau 8
09 août 2022 à 15:21:42

Les explications de Lokilok sont très bonnes. Il ne faut jamais faire confiance au client. Ce n'est généralement pas expliqué dans les tutos photons car ils font le plus souvent du peer to peer dans des jeux non persistants, donc si un joueur triche ce n'est pas grave (ça pourrie juste une partie). Mais ce n'est pas le cas dans un "mmo".

Si tu fouille le forum https://jeuweb.org/ tu trouvera des explications détaillées des problèmes propres à ce genre de jeux (pas avec Unity mais la logique est la même). Par exemple https://jeuweb.org/showthread.php?tid=8219 pour les ressources en temps réél. Il y a aussi des gens qui ont fait des mmo par navigateur sur le discord.

lokilok lokilok
MP
Niveau 10
09 août 2022 à 16:05:43

[15:19:46] <NemezysGamer>
Du coup, comment sont habituellement stockées ces données qui se modifient très fréquemment dans les jeux vidéos?

Dans la RAM. De toute façon toutes les données passent d'une manière ou d'une autre par la RAM de ton serveur. Si tu as continuellement besoin de ces données alors elles sont en permanence dans la RAM. Si tu as vraiment trop de données pour une seule machine alors il faut distribuer la charge sur plusieurs serveurs.

NemezysGamer NemezysGamer
MP
Niveau 1
09 août 2022 à 18:05:43

OK, donc en fait, ces données doivent rester sur le serveur (sa RAM) en gérant le nombre max de joueurs sur ce dit serveur.
Donc, je peux (par exemple) créer un script en C# qui stockera ces données et les gèrera sans avoir à les envoyer quelque part (en base ou autre), et je sauvegarde selon des évènements...
Je me sers de la mémoire vive du serveur comme d'un "cache" pour mes données de jeu.... Dites moi si c'est bien ça ou si j'ai compris de travers svp... ^^

ThetaTauTau ThetaTauTau
MP
Niveau 8
09 août 2022 à 19:29:57

Je ne suis pas sur que tu ais compris.

Pour les ressources en temps réel apparent :

  • Le client envoie une requête "Combien ya de ressource à tel endroit?"
  • Le serveur vérifie que le client a bien le droit de voir les ressources à cet endroit (genre c'est la ville du joueur).
  • Le serveur va chercher en BDD la date de dernière mise à jour des ressource, la quantité lors de cette mise à jour et la production, il les transmet au client.
  • Le client stocke la réponse en RAM dans un objet C#
  • A chaque frame le client calcule la quantité de ressource actuelle et met à jour l'interface.
  • Le serveur enregistre quelque part en RAM que le client est entrain de regarder les ressources, du coup si un événement les modifiant se produit, il pourra lui ré-envoyer les données.

Pour acheter une unité :

  • Le client envoie une requête "fait moi telle unité à tel endroit"
  • Le serveur vérifie que l'endroit appartient au joueur, qu'il y a assez de ressources et que le joueur a débloqué les ressources nécessaire.
  • Le serveur fait les modifications nécessaires dans la BDD (retirer des ressources et ajouter l'unité).
  • Le serveur envoie les nouvelles données au client (ressources et unités).
lokilok lokilok
MP
Niveau 10
09 août 2022 à 21:04:52

Ça dépend du type de données, là il parle de données qui sont modifiées en permanence de ce que je comprends, comme la position des joueurs par exemple. Pour ce genre de données tu interroges pas de BDD ça serait trop lent. Si ton jeu notifie la position des autres joueurs 16 fois par secondes par exemple il y a vraiment que peu d'intérêts à stocker ça dans une BDD, tu vas passer ton temps à écrire dedans et à la lire pour au final des données qui seront dans ta RAM 75% du temps. Autant les laisser 100% du temps et économiser la latence de la BDD.

Après si c'est juste pour des ressources style l'argent pour payer des trucs c'est un peu différent effectivement, c'est des données que tu accèdes pas en permanence mais seulement ponctuellement quand tu fais des opérations donc avoir un peu de latence c'est moins grave à priori. Mais d'un autre côté le stocker en permanence dans la RAM c'est plus simple et il y a pas vraiment de désavantage, je pense pas que ce genre de données prennent beaucoup de place en mémoire de toute façon.

Après évidement pour la persistance, pour garder les données en cas de redémarrage du serveur etc, faut pas stocker dans la RAM, mais j'ai pas l'impression que c'était la question.

Message édité le 09 août 2022 à 21:08:22 par lokilok
lokilok lokilok
MP
Niveau 10
09 août 2022 à 21:18:38

En fait il faudrait que tu donnes des exemples concrets l'auteur parce qu'au final je suis pas sûr de tout saisir.

Perso la BDD je m'en servirai vraiment plus comme un cache, la source de vérité c'est la RAM de mon serveur. Mais les jeux auxquels je pense c'est plus des trucs en temps réel style World of Warcraft.

Toi si c'est plutôt des jeux de gestion dit "tableur excel" (enfin les jeux où tu manipules principalement des données) là effectivement la contraintes temps réel est moins importante, à priori tu peux avoir une seconde de latence c'est pas grave. Effectivement dans ces cas là si tu veux que la source de vérité soit ta BDD pour te faciliter la vie (en supposant que ça la rende vraiment plus facile) c'est possible j'imagine sans trop de problème.

Message édité le 09 août 2022 à 21:20:00 par lokilok
NemezysGamer NemezysGamer
MP
Niveau 1
10 août 2022 à 12:46:51

1- ThetaTauTau:
Ok, je me suis sûrement mal exprimé mais c'est bien ce que j'avais compris pour la génération de ressources et la production d'unités, merci pour ta confirmation exhaustive.

2- lokilok:
En fait vous avez raison tous les 2, le jeu prévoit une partie RPG et une partie jeu par navigateur et tout ça en temps réel.

Je vais rentrer un peu plus dans le détail:
- un système de génération de ressources
- un système d'évolution des bâtiments de sa base (via des ressources diverses)
- une map pour situer les bases des joueurs (éléments "statiques": planètes mères, planètes secondaires, astéroïdes etc...)
- des instances JcJ et JcE
- des combats en temps réel (avec des attaques, des déplacements, des pouvoirs etc...)
- de la production et l'évolution d'unités
- la découverte de technologies (via des ressources diverses)
- découverte et évolution de héros (entités non combattantes qui augmentent certaines caractéristiques)
- de l'expérience et des stats en tout genre pour les unités et les héros
- des évènements de jeu (évènements saisonniers, quotidiens etc...)
- la possibilité de combattre des adversaires sur la map (hors des instances)
- un marché commun à tous les joueurs du serveur
- si possible, des rencontres JcJ entre serveurs (j'ai pas du tout regardé comment faire ça pour le moment, ce n'est pas une priorité du tout)
- un système diplomatique (alliances, traités, équipes etc...)
- un mini-jeu dans le jeu (un jeu de cartes basique)
- un tchat/système de communication
Et je vais m'arrêter là, je pense que vous avez l'essentiel.

Comme vous le voyez, il va falloir gérer des données en temps réel (combats, instances, déplacements etc...) et des données persistantes (ressources, unités, bâtiments, technologies, infos des joueurs etc...).
Pour les données persistantes, ça ne devrait pas poser de problème avec SQL (ça je maîtrise) c'est vraiment les données en temps réel qu'il faut que je gère de la bonne façon, et de ce que je comprends, tout va se jouer sur la RAM au final.

C'est là qu'on va voir si j'ai bien compris ce que vous tentez de m'expliquer:

Ces données seront stockées dans des objets C# jusqu'à ce qu'ils soient détruits/modifiés selon un évènement particulier (exemple: fin du combat, les données du dit combat sont envoyées en BDD puis détruites dans la RAM)

Message édité le 10 août 2022 à 12:47:45 par NemezysGamer
DébutPage précedente
1
Page suivantePage suivante
Répondre
Prévisu
?
Victime de harcèlement en ligne : comment réagir ?
La vidéo du moment