Developpement sous C# et .Net

[Anot]

Bonsoir à tous, :wowowow:

En cette belle soirée j'aimerais avoir l'avis des experts (ou moins experts) du forum ;
Pourquoi ne voyons nous que très peu le langage "C#" et le framework "ASP.Net" pour le développement de jeux par navigateur ?

Ayant mis en pause mon projet pour réussir à m'y "recentrer plus tard" (sous entendu beaucoup de chose funeste .. xD ), je m'étais intéresser dans un premier temps à "Unity" et son export sur navigateur pour peut être gérer une partie du jeux de manière Dynamique sans trop me casser la tête, de fil en aiguille j'ai penser à m'orienter vers le scripting en "C#" parce que les tuto sur le net sont quasiment tous fait en C#(pour Unity j'entend), puis de fil en aiguille et parce que j'aime le scripting a proprement parler j'ai décider d'approfondir a propos du C# et c'est la que je découvre énormément de solutions de dev' pour codeur dans mon genre (Amateur) ou plus (pro) "offert" par microsoft sous visual studio (j'en avais entendu parler sans pour autant m'y intéresser).

Donc j'ai acheter un gros bouquin pour utiliser C# et pour plus tard utiliser C# comme brique de mon projet et vu la "puissance native" du langage (en utilisant .Net et compagnie) j'aimerais savoir pourquoi peu de gens utilisent cet ensemble de langage ?

PS : Je n'ai pas du tout approfondis a propos du dév' par navigateur pour le moment.
PS2 : J'ai fais une recherche rapide j'ai pas trouver de sujet à ce propos !

[Xenos]

Salut,

pour ma part, je dirai que c'est peu répandu chez les mutualisés, qui n'offrent pas souvent ce genre de langage. C'est également un peu moins "plug & play" que PHP (PHP, il faut reconnaitre qu'on installe son wamp, et boum, avec un notepad même pas ++, on fait ses premières pages).

[Ter Rowan]

Je ne suis pas développeur mais c'est la technologie que nous avons choisie mais pas pour des jeux.

A mon sens donc très bon langage. ".net core" la dernière version du framework version suit tous les pattern ou process qu'on avait pu imaginer.

Après un point important : on peut faire de la daube ou des supers trucs avec ce langage (comme avec pratiquement tous les langages a priori ...).

A mon sens, on parle là d'un outil à vocation uniquement professionnel, donc avec des moyens professionnels (aka probablement pas "je veux utiliser un mutu à 2€ par an")

mais pour moi C# c'est du compilé, pas du scripté

[Anot]

Xenos -> Il est vrai que PHP est assez simple pour commencer dès projets (sans parler du fait que le procédural c'est vachement plus simple que la POO pour un amateur)

Ter Rowan -> qu'est ce que tu entend par "c'est du compile, pas du scripte" ? Après c'est sur que faire un petit site avec l'ensemble de ces technologies ça semble abusé.



Mais pour le moment ça reste à voir j'ai pas du tout essayer une application Web sous C# c'est surtout que je le lis partout(J'apprend le C# surtout pour Unity et les nouvelles perspective que ça m'offre et parce que j'aime bien apprendre).
J'adore le PHP et ça "simplicite" de mise en oeuvre (enfin pour moi ça semble plus simple que le C#) et surtout une énorme communauté autour qui permet de rapidement trouver des solutions la ou on voit de gros problème, mais pour des "jeux par navigateur" quasiment que "dynamique" ca semble plus casse gueule.

Après tout dépend du besoin j'imagine.

[Ter Rowan]

scripté = c'est interprété directement par le serveur, tu fais une modif dans un fichier, tu sauves, le serveur interprète directement le fichier

compilé = c est d'abord interprété par un système qui le transforme en exécutable que le serveur exécute, tu fais une modif dans un fichier, tu sauves, le serveur ne change pas son comportement, tu compiles tes fichiers, s'il n'y a pas d'erreur, alors le serveur peut changer son comportement

bon c est pas très clair, mais a la limite tu auras de bonnes définitions dans google. Je pense que tu parlais de "code" plutôt que de "script"

[Vincent G]

Xenos -> Il est vrai que PHP est assez simple pour commencer dès projets (sans parler du fait que le procédural c'est vachement plus simple que la POO pour un amateur)

Ter Rowan -> qu'est ce que tu entend par "c'est du compile, pas du scripte" ? Après c'est sur que faire un petit site avec l'ensemble de ces technologies ça semble abusé.



Mais pour le moment ça reste à voir j'ai pas du tout essayer une application Web sous C# c'est surtout que je le lis partout(J'apprend le C# surtout pour Unity et les nouvelles perspective que ça m'offre et parce que j'aime bien apprendre).
J'adore le PHP et ça "simplicite" de mise en oeuvre (enfin pour moi ça semble plus simple que le C#)  et surtout une énorme communauté autour qui permet de rapidement trouver des solutions la ou on voit de gros problème, mais pour des "jeux par navigateur" quasiment que "dynamique" ca semble plus casse gueule.

Après tout dépend du besoin j'imagine.

Attention au php "simple" sans OO ni MVC. Certes, le résultat serait peut être visible plus rapidement mais à la longue tu risques de t'enfermer dans un système que tu ne maîtrise absolument pas. Pour moi, cela reste ni plus ni moins que de la bidouille.

L'erreur peut être de vite vouloir terminer un projet, sans prendre en compte la finalité du projet. Je pense donc qu'apprendre le OO, ou tout du moins des notions sont un grand plus pour son projet.

Regarde, par exemple, tu veux réaliser un RPG en ligne.

Admettons que nous voulons voir les infos d'un joueur : en procédural, tu vas faire une requête sql et afficher les résultats tels quels dans une bête page HTML, tu referas la même requête encore et encore pour toutes les pages de ton site ou tu souhaites voir un joueur. Ça va vite, très vite à faire ça. Demain, tu va vouloir mettre à jour le joueur car ta plus d'infos à afficher. Et ben tu va te coltiner toutes les pages, réaliser des tests "à l'arrache" car non unitaires, car tu ne pourras pas tester tout le DOM. Donc, délais de réalisation 10 minutes, délais de mise à jour (3 heures*nb_de_maj).

En objet : Tu fais ta requête ailleurs, et tu met toutes les informations de ton joueur dans un objet accessible en public. Tu peux aller piocher les informations que tu souhaites et les mises à jour ne cassent pas tout à chaque fois. Te reste plus qu'a afficher ce que tu souhaites dans la page que tu souhaites. Au moment des tests c'est YOLO mode, tu tests que ton objet est bien complet et comment il réagit dans le DOM, EZ. Délais de réalisation : 20 minutes, délais de mise à jour : 5 minutes.

En MVC, c'est pareil, tu rajoutes juste un modèle et une vue. Donc ça va encore plus vite puisque toute ta logique est déplacée soit dans ton contrôleur soit dans un service et ton DOM ne vient pas interférer avec tes classes.

Ce que je veux dire, vu que t'es intéressé par le C#, c'est de commencer par écrire du vrai PHP. Après tout, PHP reste un langage compilé à la volée et cela - même si tu ne le vois pas de suite - t’apportera plus de pérennité dans le C#.

[Xenos]

Ou alors, t'utilise proprement le SQL, tu fais ta procédure stockée qui renvoie les infos sur un joueur, et tu ne fais qu'une mise à jour de la procédure au lieu de chaque requête. Le procédural n'a rien de dégueulasse. On peut faire du procédural sale en répétant tout partout. On peut faire de l'OO sale en déguisant le procédural en OO. On peut faire du procédural propre en centralisant les actions dans des fonctions réutilisées. On peut faire de l'OO propre en séparant bien l'instanciation des choses de leur utilisation (= en abstrayant ce que l'objet fait, pour lui déléguer les opérations à faire).

Mais comme la question porte sur "pourquoi pas C#?", je ne poursuis pas ce débat ici. L'atout de PHP ne réside donc que dans le fait de pouvoir faire des éditions rapides et à la volée, d'avoir un truc qui tourne rapidement et facilement (et oui, c'est essentiel, car c'est cette première pierre qui lance souvent les projets, qui seront par la suite rectifiés: "Make it Work, make it Right, make it Fast"). L'inconvénient évident, du coup, c'est qu'on a nettement moins d'aide de la part des analyseurs statiques et généralement moins de performances (l'interpréteur va toujours plus vite que l'interprété).

[Vincent G]

Ou alors, t'utilise proprement le SQL, tu fais ta procédure stockée qui renvoie les infos sur un joueur, et tu ne fais qu'une mise à jour de la procédure au lieu de chaque requête. Le procédural n'a rien de dégueulasse. On peut faire du procédural sale en répétant tout partout. On peut faire de l'OO sale en déguisant le procédural en OO. On peut faire du procédural propre en centralisant les actions dans des fonctions réutilisées. On peut faire de l'OO propre en séparant bien l'instanciation des choses de leur utilisation (= en abstrayant ce que l'objet fait, pour lui déléguer les opérations à faire).

Mais comme la question porte sur "pourquoi pas C#?", je ne poursuis pas ce débat ici. L'atout de PHP ne réside donc que dans le fait de pouvoir faire des éditions rapides et à la volée, d'avoir un truc qui tourne rapidement et facilement (et oui, c'est essentiel, car c'est cette première pierre qui lance souvent les projets, qui seront par la suite rectifiés: "Make it Work, make it Right, make it Fast"). L'inconvénient évident, du coup, c'est qu'on a nettement moins d'aide de la part des analyseurs statiques et généralement moins de performances (l'interpréteur va toujours plus vite que l'interprété).

Mouais m'enfin partir sur une méthode de conception vielle de 12 ans (https://secure.php.net/releases/), en partant du principe qu'on referas "quand ça marchera", c'est du suicide. Aujourd'hui on parle de composants, de contrôleurs, de vues, de modèles, ... D'ailleurs tu le dit toi même, faire de l'OO dégueulasse, c'est la faire en procédural.

Donc je maintient mon avis. Si l'OP veut se lancer dans le C#, maîtriser le PHP en OO/MCV serait un plus.

[Anot]

Alors merci pour toute vos réponses,
On peut en conclure pour dire que le PHP est plus utilisé pour ça simplicité "general" je suis bien d'accord que la POO c'est pas léger quelque soit le langage et qu'il faut savoir le maîtriser et que c'est le codeur et non le langage qui peut tout faire bien ou tout foire.

Par contre je rejoins un peu Xenos, pour des gens qui ne son pas Pro pour la plupart ce "proverbe" est pas mal, je pense qu'il faut pas mal d'expérience piur déjà appréhendé un projet suffisamment bien pour comprendre et créer tu te ces composante en amont, même si côté C# et .net je trouve qu'on est quand même bien "accompagne".

Ca me conforte dans l'idée que C# c'est intéressant pour les projets de jeux par navigateur peut être plus dynamique, je relancerait le sujet une fois le sujet plus approfondis.
Merci xD

[Xenos]

Perso, je dirai que si tu veux faire de l'expérimental, pour t'amuser, y'a pas de soucis à essayer du C# (ça permet de trouver de nouvelles pistes & voies).

En revanche, si tu veux vraiment sortir quelque chose, un truc jouable et joué, je te conseille plutôt de laisser tomber le code expérimental parfait, et de prendre directement des trucs existants pré-mâchés (et en ce sens, je pense que les stacks toutes prêtes en NodeJS ou assimilé, pour faire ton temps réelles, seront mieux que de repartir de zéro sur du C# [bien que dans les deux cas, je doute de la pertinence de se lancer seul dans un jeu web "AAA", ou temps réel]). Ca sera pas parfait, "pas adapté", "y'aurait mieux", mais ça existera.