Je suis Programmeur en langage C TRES débutant,mais comme je vous le disait un projet l'est venu en tête,celle de créer le meilleurs jeux MMORPG 3d (Je sais sa sera peut-être une daube) sur linux,si on travaille tous ensemble alors "Yes,we can !",ceux qui y sont interessez même si vous êtes débutant prévenez-moi,voilà ce que je cherche:
-5 voir 10 programmeur en langage C
-Scénariste
-graphiste
-etc...(tout sorte de poste )
Mon objectif voir même notre objectif,crée le meilleurs MMORPG sur Linux par la Communauté de Jeux-vidéo.com.
Merci de votre compréhension ! ![]()
Si vous avez des questions,posez les moi
!
c'est dur de gérer tout ce monde-là, tu le sais?
surtout les programmeurs, qui doivent bosser sur le même truc et composer avec les habitudes et défauts de chacun niveau production de code, et surtout avec des gens qui ne se connaissent que via internet. ![]()
Sans vouloir casser tes illusions, tu n'y arriveras pas :L
Fait quelques jets pour avoir une idée de comment programmer ton projet.
Découpe le déjà :
Si tu fais quelque chose de très simple (2D, combat tour par tour, petit serveur), tu vas déjà apprendre _énormément_ et ça va te prendre beaucoup de temps.
Si tu ne sais pas comment tu vas faire techniquement, rien ne t'empêche de passer du temps à y réflechir et à essayer, mais oublie complètement l'idée de gérer une équipe si tu n'as rien à apporter toi même (rien que la conception générale)...
Voilà, j'ai envie de te dire, essaye déjà de faire un jeu de morpion en réseau, histoire de voir comment écrire un protocole et utiliser les sockets, ça va t'amuser ^^
Pour la 2D, une lib comme la SDL devrait t'aider.
C'est trop gros pour toi. Fais déjà plusieurs trucs avant et reviens dans 2 à 5 ans, quand tu auras un peu d'expérience.
Ou fait carrément des études pour si cela t'intéresse vraiment ! ![]()
Encore un jeunot qui croit qu'on peut faire un jeu génial en se disant "oh tiens je vais un jeu génial, allez venez avec moi on y connait rien mais on va exploser Blizzard"
Salut,
C'est pas pratique le C pour faire un gros projet en équipe, pourquoi pas en C++ ?
Je pense que ça ne sert pas à grand chose de poser de telle question quand il est flagrant que l'énergumène autoproclamé ci-dessus n'y connait visiblement rien à l'affaire.
Par contre je ne sais pas quel est le problème avec le langage C et les projets en équipe.
les développeurs sont des gros feignants tu sais... ![]()
Tbop2: tu me vois acceptant de coder pour quelqu'un qui n'a assurément pas assez d'expérience pour juger ce que je vais lui faire ?
Et puis bon, vraiment, un projet sans un vrai leader, ça ne marche pas bien.
"Par contre je ne sais pas quel est le problème avec le langage C et les projets en équipe."
La programmation orientée-objet est par essence beaucoup plus modulaire de par la création de "boites noires". Même si le C peut tout à fait convenir à un projet à grande équipe, un langage orienté-objet propose néanmoins beaucoup plus de facilité à ce niveau en cloisonnant plus efficacement les différentes parties du programme.
"La programmation orientée-objet est par essence beaucoup plus modulaire de par la création de "boites noires" [citation needed]. Même si le C peut tout à fait convenir à un projet à grande équipe, un langage orienté-objet propose néanmoins beaucoup plus de facilité à ce niveau en cloisonnant plus efficacement les différentes parties du programme[citation needed]."
FTFY.
Plus generalement, je ne vois pas pourquoi la Programmation Oriente Objet serait plus modulaire que la Programmation Imperative. Un code est modulaire a partir du moment ou les interfaces de programmation et de communication entre les differentes partie du projet sont clairement indique et documente. Ainsi il est possible de remplacer une section entiere du code par un autre.
On fait ca tres facilement en C en masquant les details d'implementations des fonctions en n'exposant que le prototype des fonctions dans les fichiers d'entetes.
Le "cloisonement" (pour reprendre le terme de mon voisin du dessus) ne vient que d'une architecture logicielle bien pense; ce qui est independant du modele de programmation.
Oui mais pourquoi tu me dis ca a moi Chris ?
+1 godrik Encore ces fameux prejuges de POO > all
J'irais même plus loin, que la POO est à l'opposé du modulaire : le principe à la base de l'OO, c'est d'avoir plusieurs entités qui interagissent/se modifient (!) entre elles, et comme bien souvent, appeler une méthode modifie l'état d'une bonne partie du programme, il faut voir le programme comme un tout. Et surtout connaître le contenu de toutes ces petites boîtes noires, sinon t'as des objets qui se modifient spontanément "sans raison".
"Encore ces fameux prejuges de POO > all"
-> La POO a énormément d'avantages, et se mélange assez facilement avec d'autres paradigmes.
tbop2: [je viens de relire]. Le problème, c'est pas le langage C et les équipes, c'est selon moi le langage C et l'OP a la tête d'une équipe (avec ses compétences actuelles, ça peut bien entendu évolué). Je ne vois pas pourquoi tbol a fait sa remarque, et je trouve que les choses sont bien pire en C++ où il faut en plus taper sur les gens pour qu'ils codent dans le même sous langage raisonnable de C++.
IIIIIIIIIIIIIll: merci pour le correctif.
« La programmation orientée-objet est par essence beaucoup plus modulaire de par la création de "boites noires". »
Et la programmation modulaire est par essence beaucoup plus modulaire que la POO. Ça tombe bien, c'est ce qu'on fait en C. ![]()
Et tu viens encore de me confondre avec Tbol Chris !
Je ne pense vraiment pas qu'il y ait de sens au debat C++ vs C dans le cadre d'un projet. Comme d'habitude on fait avec les restrictions imposees (quelles soit farfelues ou non) et les connaissances de l'equipe. Le reste c'est finalement du bla bla pour deux langages de tres grande qualite qui ont fait leur preuve depuis tres longtemps.
De toute facon moi je dis que dans 10 ans l'assembleur redeviendra fashionable.
Et bien sur on oublie le COBOL dans tout ca.
Non, non. Initialement, j'avais rebondi sur ça : « Par contre je ne sais pas quel est le problème avec le langage C et les projets en équipe. » qui est bien de toi.
À vrai dire, la première fois, je n'avais pas vu le message de tbol et donc je pensais que tu répondais à autre chose.
Oui mais ma question etait un tantinet ironique et sous-entendait que je ne voyais pas ou etait le probleme autre que les prejuges recurrents sur le C et la POO. Enfin on se comprend on s'en fout ![]()
""J'irais même plus loin, que la POO est à l'opposé du modulaire : le principe à la base de l'OO, c'est d'avoir plusieurs entités qui interagissent/se modifient (!) entre elles,""
C'est quoi cette théorie ?
Pour moi le but de la POO en premier lieu c'est justement de pouvoir représenter une entité de la manière la plus atomique possible et d'offrir une interface publique pour interagir avec elle.
""et comme bien souvent, appeler une méthode modifie l'état d'une bonne partie du programme, il faut voir le programme comme un tout. Et surtout connaître le contenu de toutes ces petites boîtes noires, sinon t'as des objets qui se modifient spontanément "sans raison".
""
A nouveau, ça date de quand ça? Depuis quand des objets sont supposés changer d'état tout seuls?
Pour la modularité, elle est offerte à partir d'interfaces définies et de façades, il est évidemment possible de faire pareille sans objets mais la POO présente des concepts d'abstraction qui peuvent faciliter cette réflexion.
Après avec ou sans POO, écrire du code modulaire et/ou testable, c'est comme tout ça s'apprend.