[Studio de création de jeu]Liminary, logiciel tout en un pour jeu multijoueurs

Version imprimable

12/03/2015, 12h09
Invité

[Studio de création de jeu]Liminary, logiciel tout en un pour jeu multijoueurs

Bonjour bonjour,

J'ai décidé de vous présenter mon projet en cours, et qui devrait m'occuper longtemps (en espérant que le présenter me motive un peu à faire avancer la bête... ).
A savoir; c'est un projet que je réalise en loose, quand je n'ai rien d'autre à faire. L'avancement est donc chaotique et il ne sortira pas demain.

Bref, je vous présente donc Liminary.

C'est quoi ce mot !?
"Liminary" c'est un terme anglais vieilli qui désigne l'action de préparer quelquechose.
On peut dire que ça se rapproche un peu du mot français (aussi peu utilisé...) "Liminaire" qui désigne "l'action en elle-même".
Bref, un nom tout à fait à propos pour un outil qui se veut un facilitateur de projet.

Qu'est ce que Liminary:

Liminary est un outil tout en un de développement de jeux multijoueurs, orienté RPG (pour l'instant).
Il se veut à la fois robuste, facile à modifier pour un développeur accompli et facile à prendre en main pour un débutant.

Liminary se compose de 3 pans:
- une interface de création de jeu où l'utilisateur va pouvoir construire son projet (réaliser ses cartes, ses règles de combat, ses quetes, ses animations, sa GUI)
- un client graphique en 3d qui sera à fournir aux joueurs
- un système de serveurs de jeu

Le système de serveurs de jeu peut être décorellé du client graphique. En effet, il propose de communiquer en Binaire, XML et JSON. Il peut aussi fonctionner en mode TCP ou UDP.

Je travaille actuellement sur ce système de serveurs (les autres projets ne sont pas encore lancés).

Quelles sont les technologies utilisées pour Liminary?

Le système de serveurs de jeu est codé en Java; pour des questions de portabilité entre plateforme.
J'utilise Grizzly qui est une surcouche de Java NIO pour la gestion des entrées sorties.Et également Jackson pour la sérialisation/désérialisation JSON. Log4J pour la gestion des traces du système.

Mysql est utilisé pour la base de données.

Des tests automatisés sont écrit au fur et à mesure de l'avancée et tout est compilé avec Maven (en surcouche de Ant).
Il y aura certainement d'autres bibliothèques plus tard en fonction des besoins qui se présenteront.

Une première mouture du client se basera certainement sur les restes d'un précédent projet de RPG (Pentacles Mayhem) dont je retirerais tout ce qui n'avait pas été codé par moi/ n'est pas utilisable pour un client seul / et ajouterais ce qui manquait.
Il sera donc codé en C# et utilisera le moteur Truevision 3D 6.5 et FMOD pour le son. La librairie réseau reste à déterminer.
Ceci changera certainement dans un 2e temps (car Java d'un côté et C# de l'autre ce n'est pas des plus cohérents); mais l'objectif sera de pouvoir avoir un rendu exploitable dans des temps raisonnables et de conserver ce qui marchait.

Le studio de création en lui-même reste sur des technologies à définir (surtout en raison du choix de moteur 3D qui sera déterminant pour la finalisation du projet)
Il sera certainement également développé en Java.

Vue détaillée du fonctionnement du système de serveur

Le système de serveurs se présente comme suit :

Un Master Server qui gère toute les entrées dans le système, le changement d'unité logique (par exemple un changement de canal), la communication inter-serveurs, répertorie les entités actives (joueurs et serveurs) et gère la création des nouveaux personnages.

Un Data Server qui gère l'accès à base de données, les sauvegardes et récupérations d'informations; et fourni aux autres entités du système les informations dont elles ont besoin pour travailler.

Un ou plusieurs Map Server qui vont gérer les cartes du jeu, toute la logique de combat, les quetes etc.

Où est ce que j'en suis?

Mon travail actuel se concentre sur le point d'entrée du système (aka le Master Server).

J'ai commencé à coder une librairie utilitaire qui gère déjà la récupération des paramétrages, la sérialisation/désérialisation des flux et l'accès à la BDD.

Côté serveur pur, j'avais commencé à coder en NIO pur la création des sockets d'écoute, au final je suis en train de retravailler le tout avec Grizzly pour que ce soit plus simple.

J'ai commencé aussi des parties du Data Server, mais le résultat ne me semble pas si probant, il y aura donc certainement une réécriture.

Quand au client C#, je n'ai pas encore commencé la modification. Mais à l'époque il était capable de gérer les maps (propriétaire, arg!), le placement des bâtiments, les animations et déplacement des créatures et du personnage joueur, les cycles jours/nuit et l'environnement. Je pense que ces points évolueront peu (uniquement gestion de la commande à distance). Il faudra que je réécrive la gestion des ambiances sonores (réalisée par un autre dev) et que je retouche la gestion de la GUI.
Le plus gros morceau sera donc la communication client serveur!

La roadmap :

Je vais me concentrer surtout sur le Master Server dans les mois qui viennent.

Nomenclature des échanges interserver et avec les clients
Gestion des connexions clients et autres serveurs
Listing des autres serveurs actifs (pour permettre le routage)
Gestion de la création de comptes clients et de personnages
Gestion de l'authentification, du mode sans compte
Gestion des droits spéciaux (pour les comptes admins)
Sécurité du Master Server

Pour la suite, on verra quand j'en serais là!
13/03/2015, 04h20
tristan_m
Bonjour,

L'objectif de faciliter un projet grâce à la mise à disposition d'une solution fonctionnelle et modifiable est très clair dans votre présentation.
Par contre, je vois également "outil de développement". Donc par pure curiosité, avez-vous prévu des fonctionnalités d'aide au développement?
Ex :
- debugging : breakpoint, step-by-step des scripts utilisateurs côté serveur
- monitoring : bande passante, temps de réponse, cpu, ram
- test : bots éventuellement paramétrables voire programmables, simulation de latence ou de charge
Ce serait évidemment beaucoup de travail sur un projet qui se veut déjà ambitieux,
mais ces fonctionnalités seraient majeures pour mettre en avant la qualité de cet outil,
et vraisemblablement utiles lors du développement de Liminary lui-même.

Ensuite, concernant la méthodologie, je vois quasi-exclusivement la partie Master Server dans la partie effectuée ainsi que dans la roadmap.
J'imagine que c'est l'élément crucial de Liminary, mais je pense qu'il faut rapidement attaquer les autres parties.
- Pour la motivation déjà :
  C'est toujours plaisant de voir une fonctionnalité marcher de bout en bout,
  plutôt que de simplement constater des rapports de tests unitaires dans un coin du projet.
- Pour dérisquer plus rapidement :
  Faire une partie complète dans un premier temps c'est prendre le risque d'avoir oublié/négligé quelque chose de l'autre côté
  et donc de devoir tout refaire ou placer des rustines peu satisfaisantes pour que l'ensemble fonctionne.
- Pour avoir quelque chose à montrer :
  La motivation vient aussi dans le fait de pouvoir présenter ses avancées et dans les retours de la communauté.
  Une démo, une vidéo ou même une capture d'écran montrant 10 personnages gérés par le serveur est plus motivant
  qu'un changelog indiquant que le serveur est capable de gérer 200 personnages mais que la partie client n'est pas implémentée.
  Et idéalement ces présentations permettent d'obtenir des retours constructifs !
Enfin, je reviens sur cette phrase :

Citation:

car Java d'un côté et C# de l'autre ce n'est pas des plus cohérents

Tout dépend de votre objectif.
L'avantage d'utiliser le même langage des deux côtés est que les parties communes client/serveur du protocole ne sont à implémenter qu'une seule fois et sont débuggables des deux côtés.
L'avantage d'utiliser deux langages différents, c'est de s'assurer que le protocole est indépendant d'un framework ou autre lié à l'un des deux langages.
La question est donc : Est-ce que vous proposerez la possibilité de brancher "n'importe quel" client en face du serveur?

Bon courage pour la suite !
13/03/2015, 07h52
Neckara

Bonjour,

Niveau serveur, si tu veux vraiment être portable, je te conseillerais plutôt un langage compilé comme le C++ ou le C.
En effet, je ne suis pas certain qu'installer une JVM soit vraiment super sur une raspberry pi. Mais je peux me tromper.

Pour le client, je trouve dommage d'utiliser C# pour nos amis Linuxiens (même si on peux essayer de bidouiller avec Mono).
Quitte à faire, je préférerais du Java, mais d'autres langages sont aussi possibles.

Après, c'est très dommage d'utiliser des langages différents entre le client et le serveur car tu devras transcoder (?) certaines classes.

Enfin, d'expérience, je ne peux que te déconseiller de commencer par le serveur. Je pense que le mieux est de se concentrer sur le client quitte à avoir un serveur simulé via telnet. C'est beaucoup plus encourageant et valorisant surtout quand on avance pas vite.
Regarde mon moteur, plusieurs mois à bosser sur le système de module, personne n'y comprend rien, pas trop d'échanges. Je fait une simple fenêtre avec un shader, une simple image, ça parle à tout le monde. Au début, c'est certes pas très important, mais on se rend bien compte que sans un soutient moral, c'est difficile d'avancer.
13/03/2015, 08h19
NevilClavain

On voudrait en voir plus. Un lien vers un site ? des screenshots ?
13/03/2015, 13h07
Neckara

Re-bonjour,

Je ne prétend pas tout savoir sur tout et je suis bien conscient que j'ignore encore beaucoup de choses et qu'il peut m'arriver de dire des bêtises.
Il est aussi normal d'avoir des avis qui divergent sur certains sujets.

Le fait de me moinssoyer montre qu'il y a une personne en désaccord avec moi et c'est bien, il vaut mieux cela que de croire qu'on fait unanimité.
Mais j'aimerais tout de même vous demander une petite faveur.

Serait-il possible de me corriger ? Outre le fait que cela me permettra d'en apprendre plus et de m'améliorer, j'attire votre attention sur le fait que ce sujet est avant tout là pour aider akd. Me corriger permettra alors de l'aider, de le conseiller en lui fournissant d'autres arguments et en lui indiquant ce qui était faux dans mes dire (j'ose croire que je ne raconte tout de même pas que des bêtises ^^).

Je pense que ce serait gentil d'avoir une petite réponse.

Citation:

Akd, n'écoute pas Neckara, il ne dit que des bêtises.

En effet, je te déconseille le C, C++ restent des langages difficiles à maîtriser. Pour tes besoins et ton niveau, l'assembleur serait bien plus approprié.

Citation:

Akd, n'écoute pas Neckara, il ne dit que des bêtises.

Peu importe le langage que tu utilises, le tout est que tu utilises un langage avec lequel tu es à l'aise et surtout que tu te fasses plaisir.
13/03/2015, 15h37
Invité
Bonjour et déjà merci pour les premiers retours.

Je vais tâcher de répondre dans l'ordre :
Citation:
Envoyé par tristan_m

L'objectif de faciliter un projet grâce à la mise à disposition d'une solution fonctionnelle et modifiable est très clair dans votre présentation.
Par contre, je vois également "outil de développement". Donc par pure curiosité, avez-vous prévu des fonctionnalités d'aide au développement?
Ex :

debugging : breakpoint, step-by-step des scripts utilisateurs côté serveur
monitoring : bande passante, temps de réponse, cpu, ram
test : bots éventuellement paramétrables voire programmables, simulation de latence ou de charge
Je n'avais absolument pas envisagé cet aspect! O_o
(En fait, justement, je poste ce sujet parce que j'imagine bien qu'il y a pleins de choses auxquelles je n'ai pas pensé, en voilà la preuve).
J'avais éventuellement prévu de faire du monitoring plus tard en tant qu'outil d'aide à l'exploitation; mais pas du tout de debug ou ce genre de chose.
Donc je note, car ça m'a l'air bien intéressant tout ça!

Citation:

Envoyé par tristan_m

Ensuite, concernant la méthodologie, je vois quasi-exclusivement la partie Master Server dans la partie effectuée ainsi que dans la roadmap.
J'imagine que c'est l'élément crucial de Liminary, mais je pense qu'il faut rapidement attaquer les autres parties.

Je pense aussi que rapidement je vais me retrouver travailler tout azimuth sur les composants du système (peut être pas la partie studio de développement mais au moins le client serveur avec des jolis rendus graphiques).

J'ai préféré pour l'instant partir sur l'obscur noeud technique qu'est le Master server car c'est un peu la colonne vertébrale du système (et également parce que comme je travaille une fois de temps en temps sur le bébé, j'oublie une fois sur deux où j'en étais... donc si je pars dans tout les sens, je suis fichue!)
Mais je sais déjà que pour le tester il me faudra à minima un bout de client et un bout du dataServer. Parce que même là, des logs d'exécution sur fond noir, pour faire des rapports d'avancement ça va être sacrément austère!

Citation:

Envoyé par tristan_m

La question est donc : Est-ce que vous proposerez la possibilité de brancher "n'importe quel" client en face du serveur?

Tout à fait! Je suis partie du principe qu'au final, le développeur ne voudra peut être pas être limité à mon client tout pourri!
D'où (et c'est d'ailleurs une des seules briques qui marche pour l'instant!) la possibilité de générer des flux binaires, xml et json.
(et également la communication en TCP et UDP; mais là dessus, il faut que je vérifie les impacts de l'utilisation de grizzly; parce que j'avais précablé avec NIO, là je sais pas ce que ça va donner).

Citation:

Envoyé par Neckara

Bonjour,

Niveau serveur, si tu veux vraiment être portable, je te conseillerais plutôt un langage compilé comme le C++ ou le C.
En effet, je ne suis pas certain qu'installer une JVM soit vraiment super sur une raspberry pi. Mais je peux me tromper.

Je voulais pouvoir faire abstraction de la couche matérielle, d'où mon choix de Java.
Il y a aussi le fait que j'ai pas mal perdu la main dans les autres langages (alors que celui là même si c'est pas mon préféré, j'en fait tous les jours à mon travail). Donc vu que c'est déjà un projet tordu, j'ai voulu me simplifier la vie.
Après, je vois mal qui va utiliser un raspberry pour faire tourner un serveur (mais pareil, je suis peut être hors sujet).

Citation:

Envoyé par Neckara

Pour le client, je trouve dommage d'utiliser C# pour nos amis Linuxiens (même si on peux essayer de bidouiller avec Mono).
Quitte à faire, je préférerais du Java, mais d'autres langages sont aussi possibles.

Là c'est juste pour gagner du temps parce que la gestion de la création de l'environnement sur mon projet en C# était déjà bien avancé (donc pour avoir du visuel, c'est top).
Après je l'ai dit, je suis consciente que plus tard il faudra que je change l'orientation (déjà parce que Truevision 3D sent le sapin :aie:)

Citation:

Envoyé par Neckara

Après, c'est très dommage d'utiliser des langages différents entre le client et le serveur car tu devras transcoder (?) certaines classes.

Ca me fait faire aussi travailler le serveur dans un environnement hétérogène. Avec mon objectif qu'il puisse être utilisé seul, c'est aussi un bon point de départ (surtout pour le mode binaire où j'ai quelques craintes...)

Citation:

Envoyé par Neckara

Enfin, d'expérience, je ne peux que te déconseiller de commencer par le serveur. Je pense que le mieux est de se concentrer sur le client quitte à avoir un serveur simulé via telnet.

C'est dans ce sens que j'avais prévu de travailler quand PM était un meuporg... résultat il a fini en rpg tout court xD... donc cette fois-ci je veux travailler les intéractions client serveur, ca fait partie de mes faiblesses sur ce projet.

Citation:

Envoyé par NevilClavain

On voudrait en voir plus. Un lien vers un site ? des screenshots ?

Pas de site pour le moment (ça ne sera pas le plus long à mettre en place, de ce côté là je maitrise!!).
Je travaillerais le site quand j'aurais au moins une pré-alpha digne de ce nom.

J'avais prévu que ce topic me serve de mini dev-blog quand j'avais des choses intéressantes à présenter.

Pour les screenshots, les rapports de tests c'est tristounet donc j'éviterais de faire des screenshots de mon log Eclipse...
(bon ok! j'ai compris, faut que je me bouge pour avoir du graphisme!!)

Citation:

Akd, n'écoute pas Neckara, il ne dit que des bêtises.

Je ne pense pas, l'objectif de la présentation de mon projet, que je sais peu avancé; c'est aussi pour être critiqué et recevoir des conseils.

Et puis c'est bien quand on est tout seul de pouvoir s'appuyer sur la communauté pour faire évoluer mon opinion (si vous m'aviez dit il y a 5 ans que je coderais un serveur en Java un jour de ma propre volonté...)

(j'ai l'habitude des critiques, tant qu'elles sont constructives, je prends tout!)
13/03/2015, 16h29
Neckara
Citation:

Envoyé par akd

Je voulais pouvoir faire abstraction de la couche matérielle, d'où mon choix de Java.

Pour la couche matérielle, à part les histoires de 32 et 64 bits, je ne vois pas le problème. D'autant plus que le 32 bit s'exécute aussi sur le 64 bit.
Le matériel serait vraiment dérangeant si tu commençais à vouloir faire de l'embarqué et à vouloir optimiser au maximum ton serveur. Mais autant te dire que ce sera parfaitement impossible de le faire dans un langage non-compilé et que je te déconseille très fortement de partir de ce côté là :aie:.

Si tu ne mets pas d'options d'optimisations, gcc (ou un autre compilateur) utiliseras un jeu d'instruction qui est commun à tous les processeurs grand public (?).
Je ne vois donc pas ce que tu entends par "abstraction de la couche matérielle".

Si tu parles de l'OS (Windows, Linux, Mac, …), oui, il faudra recompiler pour chaque OS mais cela s'arrête là. Avec les bonnes bibliothèques et CMake (ou autotools), deux lignes de commandes suffisent pour compiler. On compile donc une seule fois pour chaque OS puis on distribue la release. Donc je ne pense pas que ce soit un problème en soit. Mais ton code fera déjà abstraction de l'OS.

Citation:

Il y a aussi le fait que j'ai pas mal perdu la main dans les autres langages (alors que celui là même si c'est pas mon préféré, j'en fait tous les jours à mon travail). Donc vu que c'est déjà un projet tordu, j'ai voulu me simplifier la vie.

Oui, je comprend. C'est mieux de coder avec un langage avec lequel on est à l'aise.

Citation:

Après, je vois mal qui va utiliser un raspberry pour faire tourner un serveur (mais pareil, je suis peut être hors sujet).

Disons que c'est peu cher, peu coûteux, consomme peu, cela prend peu de place, facile à transporter, … c'est l'idéal pour se faire un petit serveur personnel ou partagé avec quelques amis. C'est peut être aussi plus facile de tester un serveur sur un raspberry que de louer un serveur ou de laisser son PC allumé H24.

Encore mieux, tu peux distribuer une iso, il suffit de la copier sur une carte SD et on a direct le serveur fonctionnel avec la garantie de n'avoir aucun problème. Bref, c'est super pratique, mais il faut aussi voir si cela tient la charge.

Citation:

Là c'est juste pour gagner du temps parce que la gestion de la création de l'environnement sur mon projet en C# était déjà bien avancé (donc pour avoir du visuel, c'est top).

Va falloir poster des vidéos alors car je ne pourrais pas tester :cry:.

Citation:

C'est dans ce sens que j'avais prévu de travailler quand PM était un meuporg... résultat il a fini en rpg tout court xD... donc cette fois-ci je veux travailler les intéractions client serveur, ca fait partie de mes faiblesses sur ce projet.

Disons que tu n'es pas obligé de faire tout le système de connexion/inscription en premier par exemple.

Tu peux dans un premier temps convenir d'un protocole, écrire une fonctionnalité du client et tester avec un faux-serveur telnet.
Ensuite tester avec deux clients toujours avec un faux-serveur. Puis petit à petit écrire des briques de bases/fonctions de bases pour ton faux-serveur.
Ainsi tu fais d'abord progresser le visuel, ce qui parle à tout le monde et ce qui est le plus encourageant et petit à petit, tu construis aussi le serveur.

Ex.
On se moque un peu de l'identification du client, ce n'est pas le plus important, ce qu'on veut, c'est se déplacer dans un monde 2D (par exemple).
Donc on met en dur dans le faux serveur :
- le premier client qui se connecte, c'est Steeve
- le second c'est Datea papy master.
Donc :
- j'affiche une carte écrite en dur ;
- je demande une carte au serveur (ex. telnet) qui me l'envoie puis je l'affiche.
- je me déplace sur le client ;
- j'envoie mes déplacements au serveur ;
- je réceptionne d'autres déplacement via le serveur (toujours telnet).
Jusque là, pas besoin de coder le serveur et on a déjà du visuel assez intéressant. Ensuite :
- j'écris pour le serveur le module pour répercuter les déplacements d'un client aux autres clients.
- je testes en connectant deux clients.
- je rajoute les collisions
- …
Pas de prises de tête, on reste simple.

En gros ne pas hésiter à utiliser des placeholders pour pouvoir ajouter les fonctionnalité quand le moment sera venu.

Et c'est en effet bien plus intéressant d'avoir un déplacement visuel que d'avoir une authentification bien que l'authentification soit très intéressante techniquement.
Tu peux passer des mois sur une authentification, on te dira "ok cool…". Tu passes une journée à faire se déplacer un petit carré et tu as déjà un début de jeu qu'on peu tester. Ce qui est bien plus intéressant.

Citation:

Pour les screenshots, les rapports de tests c'est tristounet donc j'éviterais de faire des screenshots de mon log Eclipse...

C'est pour cela que je te déconseilles de commencer par le serveur.
13/03/2015, 22h07
yildiz-online

Citation:

Envoyé par Neckara

Pour la couche matérielle, à part les histoires de 32 et 64 bits, je ne vois pas le problème. D'autant plus que le 32 bit s'exécute aussi sur le 64 bit.
Le matériel serait vraiment dérangeant si tu commençais à vouloir faire de l'embarqué et à vouloir optimiser au maximum ton serveur. Mais autant te dire que ce sera parfaitement impossible de le faire dans un langage non-compilé et que je te déconseille très fortement de partir de ce côté là :aie:.

Si tu ne mets pas d'options d'optimisations, gcc (ou un autre compilateur) utiliseras un jeu d'instruction qui est commun à tous les processeurs grand public (?).
Je ne vois donc pas ce que tu entends par "abstraction de la couche matérielle".

Si tu parles de l'OS (Windows, Linux, Mac, …), oui, il faudra recompiler pour chaque OS mais cela s'arrête là.

Il faut également prendre en compte l'endianness, l'encoding du système,... ce sont des choses qui jouent un rôle important quand on manipule des sockets...
Devoir compiler n'est pas trivial non plus, d'autant plus que si on augmente le nombre de systèmes sur lesquels on doit compiler, ça augmente aussi la maintenance, ça revient rapidement pénible(parce que non un cmake ça ne se fait pas tout seul, et ça fait bien plus qu'une ligne sur une application complexe)... Ne pas avoir toutes ces préoccupations, c'est faire abstraction de la couche matérielle.
14/03/2015, 04h57
tristan_m

Bonjour,

Pour ma part, je ne voulais suggérer ni de commencer par le client ni d'en faire la première priorité.
A vrai dire, je ne considère pas l'ordre très important.
Par contre je pense qu'il faut valider rapidement que l'implémentation tient la route en face d'un vrai composant,
pour découvrir les éventuels problèmes au plus tôt.

Les faux client/serveur seront très utiles pour tester unitairement chaque composant,
mais il ne faut pas se baser uniquement dessus pour estimer que tout fonctionne.

Puisque vous allez vous occuper à la fois du client et du serveur,
je pense qu'une approche orientée fonctionnalité est à privilégier par rapport à une approche orientée composant.
Une fonctionnalité à la fois, mais de bout en bout,
plutôt que x fonctionnalités uniquement sur le client (resp. serveur), et plus tard sur le serveur (resp. client).
14/03/2015, 08h57
Neckara
Citation:

Envoyé par yildiz-online

Il faut également prendre en compte l'endianness, l'encoding du système,... ce sont des choses qui jouent un rôle important quand on manipule des sockets...

Si tu manipules des sockets à la main, oui, mais rien ne t'empêche d'utiliser des bibliothèques plus haut niveau.
Au pire pour l'endianness, ce n'est pas si horrible que cela (h|n)to*, pour deux petites lignes… d'autant plus qu'aujourd'hui tous les systèmes publiques ont la même endianness (?).

Pour l'encoding du système, je pense qu'il vaut mieux définir soit-même l'encoding du programme (ex. UTF-8) en modifiant la locale.
Si encore une fois, aucune bibliothèque ne le fait pas déjà pour nous.
Sur 20, 000 lignes, 10-15 petites lignes, c'est rien.

Donc on a toujours une abstraction de la couche matérielle.

Citation:

Devoir compiler n'est pas trivial non plus, d'autant plus que si on augmente le nombre de systèmes sur lesquels on doit compiler, ça augmente aussi la maintenance

Ouais mais bon, au général, tu à juste 3 à 6 grand maximum compilations à faire.
Je vais troller, mais Java qui est si "portable" que cela n'empêche pas ces problèmes de maintenances :
- en fonction de la version de la JVM ;
- fonctionnalités qui ne sont pas présentes sous Linux :whistle:
Tu ne conserves aussi qu'un seul code, alors certes pour tester, il a plus de cibles, mais ce sera le cas avec tous les autres langages.

Donc recompiler, ce n'est pas si grave que cela.

Citation:

parce que non un cmake ça ne se fait pas tout seul, et ça fait bien plus qu'une ligne sur une application complexe...

J'ai dit deux lignes pour compiler, pas pour écrire le cmake.
Et on ne peut pas dire que ce soit si compliqué à écrire. Cela prend un peu de temps en début du projet, mais une fois qu'il est écrit, ça va tout seul et ça reste négligeable par rapport à la durée du projet.

Citation:

Ne pas avoir toutes ces préoccupations, c'est faire abstraction de la couche matérielle.

Endianness, 8, 16, 32, 64 bits, jeu d'instructions, je conçois que cela fasse parti de la couche matériel. Mais je ne pense pas que ce soit une réelle préoccupation ici.

OS, locales, etc. je ne suis pas d'accord, ceci ne fait pas parti de la couche matérielle, c'est l'environnement. Et ce n'est pas parce qu'en C (ou C++), on peut faire de l'embarqué, du bas niveau ou du code spécifique à chaque OS qu'on est obligé de le faire.

Je ne peux donc pas prendre cet argument. Après je ne vous oblige pas à coder avec un langage plutôt qu'un autre et si Akd est plus à l'aise en Java, il vaut mieux qu'il code en Java. Mais je ne peux pas vous laisser dire qu'en C ou C++, on ne peut pas faire abstraction du matériel.

EDIT : on pourrait peut-être demander un "split" de ce sujet pour continuer notre discutions sans polluer le sujet d'Akd ?
14/03/2015, 09h03
Invité

Projet qui me semble intéressant! Je vais sûrement m'en inspirer pour rajouter une interface (avec exécution de scripts) à mon moteur.

Mais bon j'en suis encore loin, pour le moment je dois faire la couche d'abstraction pour la réutilisation d'autres moteurs.

Je plussoie ce que je dis Neckara, faire de l'abstraction matérielle n'est pas bien compliquée à faire maintenant en c++ avec CMake, mais il ne faut pas se baser sur les fichier CMake de SFML qui sont fort chiadés. :/

Je suis sûr qu'il y a moyen de le faire plus simplement.
14/03/2015, 09h41
yildiz-online

Citation:

Envoyé par Neckara

EDIT : on pourrait peut-être demander un "split" de ce sujet pour continuer notre discutions sans polluer le sujet d'Akd ?

En effet, juste une clarification:

Tout est abstraction du matériel, ce qui compte ici, c'est le niveau d'abstraction:

assembleur est plus abstrait que les composants physiques
c est plus abstrait qu'assembleur
c ++ est plus abstrait que c
java est plus abstrait que c++
pseudo code est plus abstrait que java
uml est plus abstrait que pseudo code

A ceci on peut ajouter la simplicité d'utilisation: ruby est plus simple que java par exemple, java est plus simple que c++...
14/03/2015, 12h06
Neckara

Si un LW passe par là, serait-il possible de splitter le sujet ?

Citation:

Envoyé par yildiz-online

Tout est abstraction du matériel, ce qui compte ici, c'est le niveau d'abstraction

Pour être plus précis, l'OS a des mécanismes d'abstractions du matériel.
Le langage qui va faire des appels systèmes ne va pas pas abstraire le matériel mais va utiliser une abstraction du matériel fournit par l'OS.
Ensuite, on va avoir des bibliothèques qui vont permettre d'abstraire l'OS/l'environnement.

Ce qui n'empêche pas le langage de toucher directement au matériel, il peut donc utiliser plusieurs niveaux d'abstractions.

Citation:

assembleur est plus abstrait que les composants physiques

L'assembleur n'abstrait pas le matériel. Au contraire, il n'y a rien de moins portable que l'assembleur par rapport au matériel utilisé.
Après, oui, l'assembleur est bien plus "haut niveau" que des portes simples portes NAND.
Je suis un peu bloqué pour pinailler, vu que l'ATIL est down :cry:.

Citation:

c est plus abstrait qu'assembleur

Le C abstrait l'assembleur surtout.

Citation:

c ++ est plus abstrait que c

Non, à la rigueur, il fournit des outils d'abstractions plus poussé. Mais il n'est pas "plus abstrait".
D'autant plus que le C++ et le C on une petite base très proche (pour ne pas dire presque commune).

Que ce soit en C ou en C++, on peut à la fois faire du "bas niveau" et du "haut niveau".
En C, je peux envoyer en e-mail en ligne et le faire en 200 lignes en C++. Cela dépend des bibliothèques, de ce qu'on recherche, etc.

Citation:

java est plus abstrait que c++

Certainement pas.
D'autant plus que le Java ne possède pas certains outils d'abstractions du C++ (ex. surcharge d'opérateurs).
Le C++ permet en effet de faire du plus bas niveau que le Java mais ce qui ne l'empêche pas aussi d'avoir des outils d'abstractions très puissant.

Citation:

pseudo code est plus abstrait que java

Le pseudo code abstrait les langages de programmation.

Citation:

uml est plus abstrait que pseudo code

C'est un peu compliqué.
Le pseudo code va permettre de donner un algorithme en faisant abstraction du langage.

En UML, tu peux faire de même et ce n'est qu'une façon de réécrire l'algorithme d'une manière différente, c'est donc aussi une sorte de pseudo-code "graphique".
L'UML fournit certes plus d'outils, mais je ne vois pas quel diagramme serait "plus abstrait" que du pseudo code.

En UML, on peut en effet abstraire des composants et donner une architecture OC, architecture qu'on peut toujours abstraire avec du pseudo-code.

Citation:

A ceci on peut ajouter la simplicité d'utilisation: […] par exemple, java est plus simple que c++...

Je ne connais pas bien Ruby donc je préfère ne pas dire de bêtises.

"Plus simple", cela dépend pour qui et de l'utilisation qu'on veut en faire.
C++ est "plus compliqué", surtout parce qu'il a plus d'outils et qu'il permet de faire à la fois du haut niveau et du bas niveau.
Mais ce n'est pas parce qu'on fait du C++, qu'on est obligé d'utiliser tous les outils qu'il met à notre disposition.

Par exemple, libérer des ressources est bien plus facile en C++ avec les principes RAII, ce qui est impossible en Java (sauf fichiers depuis java 8 et mémoire).
Le système de flux en Java qui a bien perdu plus d'un débutant me semble plus compliqué à utiliser que ceux du C++.

La "base" (if/else/boucles/appel de fonction/méthodes/création de classes) est tout de même assez proche en Java et en C++.
Le Java et le C++ ont fait des choix différents, certains bons, d'autres moins bons.

Oui, le garbage collector Java est plus "simple" pour libérer la mémoire.
Mais le C++ est "plus simple" pour la libérer au bon moment/dès que possible ainsi que pour libérer les autres types de ressources.

Oui les flux C++ sont plus simples que ceux du Java. Mais le système de décorateur Java est peut-être plus simple pour personnaliser son propre flux.

Oui faire n'importe quoi est plus facile en C++ (quoi qu'il existe des langages pire encore), mais cela rend plus facile le travail en bas niveau.

C'est comme chercher le meilleur langage de programmation, on sait tous que ce n'est pas une question aussi simple et qui dépend de beaucoup de choses.